关闭

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

216人阅读 评论(0) 收藏 举报
分类:

分布式消息追踪

先推荐个文章,云栖的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标识了日志埋点的顺序和嵌套关系:
      rpc生成规则

    • 埋点日志技术挑战:

      1. 异步调用,业务调用mq或其他组件,发生线程切换,通过上下文传递的埋点信息丢失,mq客户端认为自己是首节点,重新生成traceID,导致调用链串接不起来;
      2. 性能影响:频繁写日志,占用系统资源,导致正常的业务无法运行;
  • 采样率
    每次调用不一定需要全采样,支持动态设置采样率;

  • 采集和存储埋点日志
    日志采集存储

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

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

价值

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

可靠性设计

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

服务状态监测

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

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

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

服务健康度检测

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

服务故障隔离

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

  • VM级故障隔离
    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调度模型的选择:阻塞还是非阻塞;
      NIO
    2. 序列化框架的选择;
    3. 线程模型;
      reactor
  • 分布式事务:这里写了些,不细,云栖搜沈询的视频看吧,讲的不错,深入浅出,容易理解;

  • 团队协作:

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

总结

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

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:73031次
    • 积分:1466
    • 等级:
    • 排名:千里之外
    • 原创:62篇
    • 转载:76篇
    • 译文:1篇
    • 评论:16条
    最新评论