各大厂分布式链路跟踪系统架构对比

    随着互联网架构的扩张,分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用,这些组件共同构成了繁杂的分布式网络,那现在的问题是一个请求经过了这些服务后其中出现了一个调用失败的问题,只知道有异常,但具体的异常在哪个服务引起的就需要进入每一个服务里面看日志,这样的处理效率是非常低的。

各大厂分布式链路跟踪系统架构对比

    分布式调用链其实就是将一次分布式请求还原成调用链路。显式的在后端查看一次分布式请求的调用情况,比如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求状态等等。

链路跟踪系统的功能 (1)故障快速定位

    通过调用链跟踪,一次请求的逻辑轨迹可以用完整清晰的展示出来。开发中可以在业务日志中添加调用链ID,可以通过调用链结合业务日志快速定位错误信息。

各大厂分布式链路跟踪系统架构对比

(2)各个调用环节的性能分析

    在调用链的各个环节分别添加调用时延,可以分析系统的性能瓶颈,进行针对性的优化。通过分析各个环节的平均时延,QPS等信息,可以找到系统的薄弱环节,对一些模块做调整,如数据冗余等。

各大厂分布式链路跟踪系统架构对比

(3)数据分析等

    调用链绑定业务后查看具体每条业务数据对应的链路问题,可以得到用户的行为路径,经过了哪些服务器上的哪个服务,汇总分析应用在很多业务场景。

(4)生成服务调用拓扑图

    通过可视化分布式系统的模块和他们之间的相互联系来理解系统拓扑。点击某个节点会展示这个模块的详情,比如它当前的状态和请求数量。

各大厂分布式链路跟踪系统架构对比

分布式调用跟踪系统的设计 (1)分布式调用跟踪系统的设计目标

低侵入性,应用透明:作为非业务组件,应当尽可能少侵入或者无侵入其他业务系统,对于使用方透明,减少开发人员的负担

低损耗:服务调用埋点本身会带来性能损耗,这就需要调用跟踪的低损耗,实际中还会通过配置采样率的方式,选择一部分请求去分析请求路径

大范围部署,扩展性:作为分布式系统的组件之一,一个优秀的调用跟踪系统必须支持分布式部署,具备良好的可扩展性

(2)埋点和生成日志

埋点即系统在当前节点的上下文信息,可以分为客户端埋点、服务端埋点,以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容:

TraceId、RPCId、调用的开始时间,调用类型,协议类型,调用方ip和端口,请求的服务名等信息;

调用耗时,调用结果,异常信息,消息报文等;

预留可扩展字段,为下一步扩展做准备;

(3)抓取和存储日志

日志的采集和存储有许多开源的工具可以选择,一般来说,会使用离线+实时的方式去存储日志,主要是分布式日志采集的方式。典型的解决方案如Flume结合Kafka等MQ。

(4)分析和统计调用链数据

一条调用链的日志散落在调用经过的各个服务器上,首先需要按 TraceId 汇总日志,然后按照RpcId 对调用链进行顺序整理。用链数据不要求百分之百准确,可以允许中间的部分日志丢失。

(5)计算和展示

汇总得到各个应用节点的调用链日志后,可以针对性的对各个业务线进行分析。需要对具体日志进行整理,进一步储存在HBase或者关系型数据库中,可以进行可视化的查询。

 

链路跟踪Trace模型

一次典型的分布式调用过程,如下图所示:

各大厂分布式链路跟踪系统架构对比

Trace调用模型,主要有以下概念:

Trace:一次完整的分布式调用跟踪链路。

Span: 追踪服务调基本结构,表示跨服务的一次调用; 多span形成树形结构,组合成一次Trace追踪记录。

Annotation:在span中的标注点,记录整个span时间段内发生的事件。

BinaryAnnotation:可以认为是特殊的Annotation,用户自定义事件。

Annotation类型:保留类型

Cs CLIENT_SEND,客户端发起请求

Cr CLIENT_RECIEVE,客户端收到响应

Sr SERVER_RECIEVE,服务端收到请求

Ss SERVER_SEND,服务端发送结果

用户自定义类型:

Event 记录普通事件

Exception 记录异常事件

Client && Server:对于跨服务的一次调用,请求发起方为client,服务提供方为server

各术语在一次分布式调用中,关系如下图所示:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpssyy.html