读-李林峰-分布式服务框架和原理18-21

分布式消息追踪

先推荐个文章，云栖的https://yq.aliyun.com/articles/91435，介绍了分布式调用链的一些场景和阿里的分布式调用链组件eagle，记得原来云栖有个视频介绍这个的，没找到。

随着分布式架构的发展，系统调用日趋复杂，一个业务场景可能涉及底层n多的服务调用，服务调用又涉及不同的组件：
1. 服务框架；
2. mq；
3. 缓存；
4. 数据库组件；
5. 大数据……
这时候就需要分布式消息跟踪系统。

业务场景分析

- 故障的快速定位，调用关系：A-B-C…..,如果没有消息跟踪，A调用出问题了，就只能通过日志分析，找B，B再找C，一级一级找下去，估计累死；
- 调用路径分析，分析调用路径关系，找出服务热点，易发故障点，评估风险，性能统计等；
- 调用来源和去向分析，分析依赖关系，各种kpi性能统计分析。

系统设计

每次业务请求生成全局唯一traceId，通过埋点将调用链各节点的日志串联，形成完整的日志调用关系链，日志的实时采集，汇总，分析，portal展示分析结果。

• 系统架构
  

  1. 调用链埋点日志生成；
  2. 分布式采集和存储埋点日志；
  3. 在线、离线计算，调用链数据分析和汇总；
  4. portal展示；

• 埋点日志

  • 埋点的分类：

    1. 客户端埋点，调用时生成调用上下文，包括traceID，调用ip，调用方接口或业务名称，时间，被调用的服务名、方法名、ip地址和端口等信息；
    2. 服务端埋点，当前节点生成的上下文，包括被调用的服务，处理结果，时间等等信息；

  • 埋点日志的实现，通常包含：

    1. 埋点规范，用于业务二次开发和第三方中间件/系统对接；
    2. 埋点日志类库，生成埋点上下文，打印埋点日志等；
    3. 中间件预置埋点功能，隔离业务代码，无需业务方代码侵入，也可以通过埋点日志类库，将业务字段带入调用链上下文；

  • 日志生成规则：
    

  • 埋点日志上下文包含：

    1. traceID， rpcID，调用开始时间，调用类型，协议类型，调用方ip端口，被调用方ip和端口，请求方接口，请求的服务等信息；
    2. 调用的耗时，结果，异常信息，报文信息等；
    3. 扩展信息；

  • traceID，全局唯一，除了uuid生成外，通常使用一些业务信息组装traceid，包含信息：

    1. ip地址和端口：调用发起方和被调用方ip，端口；
    2. 时间戳：埋点上下文的生成时间；
    3. 顺序号：标识链路传递序列的rpcID；
    4. 进程号；
    5. 随机数，一般会有递增的Atomic序列；

  • rpcID标识了日志埋点的顺序和嵌套关系：
    

  • 埋点日志技术挑战：

    1. 异步调用，业务调用mq或其他组件，发生线程切换，通过上下文传递的埋点信息丢失，mq客户端认为自己是首节点，重新生成traceID，导致调用链串接不起来；
    2. 性能影响：频繁写日志，占用系统资源，导致正常的业务无法运行；

• 采样率
  每次调用不一定需要全采样，支持动态设置采样率；

• 采集和存储埋点日志
  

• 计算和展示，支持多维度的汇总分析；

• 调用链扩展，埋点日志支持扩展，主要是应用的相关信息组装到调用链中；

分布式消息跟踪，这东西可以做的很复杂，想想阿里单独做一个调用链组件就能明白这玩意可以做的多复杂，主要是涉及的系统，组件太多，加入埋点日志，还要做到不影响业务应用，设计起来细节太多。

可靠性设计

服务化后，分布式调用面临的故障风险更高：
1. 网络类故障：链路闪断，读写超时等；
2. 序列化反序列失败；
3. 畸形码流；
4. 流控和调用失败；
5. 其他异常….

服务状态监测

服务提供者不可用，如果没有发现，消费端继续路由到该机器，调用发生失败。为了保证路由的正确性，服务提供者不可用时，即使从本地缓存中清除，直到提供者恢复。

• 基于服务注册中心状态检测
  

• 链路有效性状态检测机制
  
  通常消费端和提供者采用长连接，通过心跳保证链路的可靠性。存在一种场景，消费者和提供者与注册中心网络可达，但提供者和消费者之间不可达，所以就需要通过二者之间的心跳来维持链路可达。

服务健康度检测

集群环境，由于硬件和网络等原因，导致提供者的负载是不均衡的。利用健康度检测，可以对所有服务实例进行检查，评分，然后调整路由权重，平衡压力。
健康度检测需要采集性能kpi指标：
1. 调用时延；
2. QPS；
3. 成功率；
4. 基础资源的使用情况，cpu，内存等；
健康度评分通常由独立的监控节点负责，消费端和提供者将kpi数据上报监控节点，监控中心汇总分析后打分，然后下发消费端，由消费端做路由的权重调整。

服务故障隔离

• 进程级故障隔离
  
  进程级隔离，在服务发生内存泄漏异常，导致整个进程不可用。

• VM级故障隔离
  
  一台物理机部署几个虚机，虚机部署服务服务，物理机挂了服务还是不可用。

• 物理机故障隔离
  
  分布式集群部署，服务实例部署不同物理机。机房挂了，服务不可用。

• 机房故障隔离
  

  1. 本地机房优先；
  2. 注册中心，服务订阅发布同步；

其他可靠性

• 服务注册中心
  考虑zk的使用。

• 监控中心
  宕机，只影响采用数据和日志汇总，不影响服务调用。

• 服务提供者
  容错策略的配置，路由切换，本地调用或mock，服务放行。

微服务架构

这章题目太大，讲的不是很清楚，别看了，改天找资料再学习下，好像有个微服务框架实践的书，没看过，不知道怎么样。面试阿里的时候被问过微服务，当时有点懵逼，不知道从哪里下手回答。转载个文章，云栖肥侠的微服务（Microservice）那点事，https://yq.aliyun.com/articles/2764，当时看完留言咨询过微服务与rpc的区别，回复说是没区别，不知道是不是忽悠我，个人理解他说的没区别应该是说技术实现上区分不大，但是在服务的管理和运维等地方还是有区分的。不谈技术实现，微服务这个理念现在还是很流行的，出去聊天，不说2句微服务，都感觉你落伍了，艹。

1. 微服务的“微”，强调的是专注于细，你的服务划分粒度要足够的小，达到微自治，自我管理；
2. 技术实现通常基于http，rest方式开放；
3. 容器的发展绝对大大促进了MSA的发展；
4. 因为服务的粒度足够小，所以Devops

知乎的文章，回答的不错：SOA和微服务架构的区别 https://www.zhihu.com/question/37808426;

服务化最佳实践

• 性能和时延问题

  1. io调度模型的选择：阻塞还是非阻塞；
     
  2. 序列化框架的选择；
  3. 线程模型；
     

• 分布式事务：这里写了些，不细，云栖搜沈询的视频看吧，讲的不错，深入浅出，容易理解；

• 团队协作：

  1. 共用注册中心：一般不会，肯定开发测试用不同的环境，容许屏蔽注册中心，直连服务提供者；
  2. 服务降级和mock测试：开发测试环境，提供者还未提供服务，可以做本地mock测试；
  3. 服务接口的兼容性：其实这里应该包含2部分，一个是框架本身对服务的支持，还有服务接口的不同版本间兼容性。

总结

1. 这本书不错，值得多看几遍；
2. 一定要找rpc的源码研究下，空谈误国，实干兴邦。