微服务架构（三）服务的基本组成部分

1. 服务描述: 服务名, 服务提供哪些信息, 服务的返回格式等, 常用的服务描述方式包括restful xml和idl

get /pet/{id} 获取某个id的pet
//xml 多基于rpc协议
<motan:service ref='userService' requestTimeout="40" retries="2" interfce="cn.sina.api.user.service.UserService" baseicService="serviceBasicConfig"/>
//IDL Interface Definition Language，接口定义语言 一般使用thrift和grpc协议 利用protobuf(protocol buffer)文件定义接口
service HelloService{
    rpc SayHello(HelloRequest) returns (HelloResponse)
}

message HelloRequest{
    string greeting = 1;
}

message HelloResponse{
    string reply = 1;
}

2. 注册中心: 登记所有服务, 方便消费者调用时, 查找需要请求的地址, 过程: 1 服务提供者启动时, 根据配置文件向注册中心注册自己的服务 2 服务消费者在启动时, 根据配置文件中的服务信息向注册中心订阅服务 3 注册中心返回提供者提供的地址给消费者 4 当服务的提供者发生变化时, 注册中心将变更通知给消费者
3. 服务框架: 获得请求地址后还有问题需要考虑 1 采用什么协议 tcp udp http 2 数据传输方式 同步 异步, 单链接or多路复用 3 压缩格式
4. 服务监控: 1 指标收集, 每次一服务调用的耗时以及是否成功收集 2 数据处理 根据1收集的数据计算qps avgtime等 3 数据展示, 将处理的数据可视化展示, 用作服务监控和报警
5. 服务追踪: 记录每个节点, 消费者发起调用前, 生成一个id, 请求时带着id, 提供者接收到请求后, 记录下这次的id, 然后处理请求, 如果提供者请求其他服务, 就再生成一个自己的id, 把这个id继续传递, 以此类推
6. 服务治理 1 单击故障, 通过一定的策略进行单击摘除 2 单IDC故障, 自动切换故障IDC到正常IDC 3 依赖服务不可用, 熔断机制 还有自动扩缩容等
   业务选型: rpc协议的性能要高于http. 性能要求较高的情况下可选用rpc, 但是当采用xml配置的时候, 耦合度比较高, 消费者和提供者的配置都要使用xml进行配置, 如果服务发生变化, 就要进行xml的修改 idl的服务端和客户端代码是自动生成的, idl文件难以维护, 返回值发生变更就要同步更新服务的消费者
   图片.png