分布式链路追踪 对比 一

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，

在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，

对CPU和memory的影响都差不多在10%之内。

分布式调用跟踪系统的设计

（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_S