随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。

互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。

因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的 Google Dapper。

想要在这个上下文中理解分布式系统的行为，就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。

所以，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。一个请求完整调用链可能如下图所示：

)

那么在业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题：

1. 如何快速发现问题？

2. 如何判断故障影响范围？

3. 如何梳理服务依赖以及依赖的合理性？

4. 如何分析链路性能问题以及实时容量规划？

同时我们会关注在请求处理期间各个调用的各项性能指标，比如：吞吐量（TPS）、响应时间及错误记录等。

1. 吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。

2. 响应时间，包括整体调用的响应时间和各个服务的响应时间等。

3. 错误记录，根据服务返回统计单位时间异常次数。

全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。

有了全链路监控工具，我们能够达到：

1. 请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。

2. 可视化：各个阶段耗时，进行性能分析。

3. 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。

4. 数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。

1 目标要求

如上所述，那么我们选择全链路监控组件有哪些目标要求呢？Google Dapper 中也提到了，总结如下：

1、探针的性能消耗

APM 组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

2、代码的侵入性

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

对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往往由于跟踪系统在应用中植入代码的 bug 或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。

3、可扩展性

一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。

4、数据的分析

数据的分析要快 ，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。

2 功能模块

一般的全链路监控系统，大致可分为四大功能模块：

1.埋点与生成日志

埋点即系统在当前节点的上下文信息，可以分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间，协议类型、调用方ip和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步扩展做准备；

不能造成性能负担：一个价值未被验证，却会影响性能的东西，是很难在公司推广的！

因为要写 log，业务 QPS 越高，性能影响越重。通过采样和异步log解决。

2.收集和存储日志

主要支持分布式日志采集的方案，同时增加 MQ 作为缓冲；

1. 每个机器上有一个 deamon 做日志收集，业务进程把自己的 Trace 发到 daemon，daemon 把收集 Trace 往上一级发送；

2. 多级的 collector，类似 pub/sub 架构，可以负载均衡；

3. 对聚合的数据进行 实时分析和离线存储；

4. 离线分析 需要将同一条调用链的日志汇总在一起；

3.分析和统计调用链路数据，以及时效性

调用链跟踪分析：把同一 TraceID 的 Span 收集起来，按时间排序就是timeline。把ParentID 串起来就是调用栈。

抛异常或者超时，在日志里打印 TraceID。利用 TraceID 查询调用链情况，定位问题。

依赖度量：

1. 强依赖：调用失败会直接中断主流程

2. 高度依赖：一次链路中调用某个依赖的几率高

3. 频繁依赖：一次链路调用同一个依赖的次数多

离线分析：按TraceID汇总，通过Span的ID和ParentID还原调用关系，分析链路形态。

实时分析：对单条日志直接分析，不做汇总，重组。得到当前QPS，延迟。

4.展现以及决策支持

3 Google Dapper

3.1 Span

基本工作单元，一次链路调用（可以是RPC，DB等没有特定的限制）创建一个span，通过一个64位ID标识它，uuid较为方便，span中还有其他的数据，例如描述信息，时间戳，key-value对的（Annotation）tag信息，parent_id等,其中parent-id可以表示span调用链路来源。

Span

上图说明了span在一次大的跟踪过程中是什么样的。Dapper记录了span名称，以及每个span的ID和父ID，以重建在一次追踪过程中不同span之间的关系。如果一个span没有父ID被称为root span。所有span都挂在一个特定的跟踪上，也共用一个跟踪id。

Span数据结构：

type Span struct {
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

3.2 Trace

类似于 树结构的Span集合，表示一次完整的跟踪，从请求到服务器开始，服务器返回response结束，跟踪每次rpc调用的耗时，存在唯一标识trace_id。比如：你运行的分布式大数据存储一次Trace就由你的一次请求组成。

Trace

每种颜色的note标注了一个span，一条链路通过TraceId唯一标识，Span标识发起的请求信息。树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的代表span的开始和结束时间，他们在整个树形结构中却是相对独立的。

3.3 Annotation

注解，用来记录请求特定事件相关信息（例如时间），一个span中会有多个annotation注解描述。通常包含四个注解信息：

(1) cs：Client Start，表示客户端发起请求
(2) sr：Server Receive，表示服务端收到请求
(3) ss：Server Send，表示服务端完成处理，并将结果发送给客户端
(4) cr：Client Received，表示客户端获取到服务端返回信息

Annotation数据结构：

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

3.4 调用示例

请求调用示例

1. 当用户发起一个请求时，首先到达前端A服务，然后分别对B服务和C服务进行RPC调用；

2. B服务处理完给A做出响应，但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务，最后由A服务来响应用户的请求；

调用过程追踪

1. 请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。

2. 除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。

3. 一个没有parent id的span成为root span，可以看成调用链入口。

4. 所有这些ID可用全局唯一的64位整数表示；

5. 整个调用过程中每个请求都要透传TraceID和SpanID。

6. 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。

7. 要查看某次完整的调用则 只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。

整个调用过程追踪

1. 调用链核心工作

   1. 调用链数据生成，对整个调用过程的所有应用进行埋点并输出日志。

   2. 调用链数据采集，对各个应用中的日志数据进行采集。

   3. 调用链数据存储及查询，对采集到的数据进行存储，由于日志数据量一般都很大，不仅要能对其存储，还需要能提供快速查询。

   4. 指标运算、存储及查询，对采集到的日志数据进行各种指标运算，将运算结果保存起来。

   5. 告警功能，提供各种阀值警告功能。

2. 整体部署架构

1. 通过AGENT生成调用链日志。

2. 通过logstash采集日志到kafka。

3. kafka负责提供数据给下游消费。

4. storm计算汇聚指标结果并落到es。

5. storm抽取trace数据并落到es，这是为了提供比较复杂的查询。比如通过时间维度查询调用链，可以很快查询出所有符合的traceID，根据这些traceID再去 Hbase 查数据就快了。

6. logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID，根据traceID查询是很快的。

• AGENT无侵入部署

  通过AGENT代理无侵入式部署，将性能测量与业务逻辑完全分离，可以测量任意类的任意方法的执行时间，这种方式大大提高了采集效率，并且减少运维成本。根据服务跨度主要分为两大类AGENT：

  1. 服务内AGENT，这种方式是通过 Java 的agent机制，对服务内部的方法调用层次信息进行数据收集，如方法调用耗时、入参、出参等信息。

  2. 跨服务AGENT，这种情况需要对主流RPC框架以插件形式提供无缝支持。并通过提供标准数据规范以适应自定义RPC框架：

     （1）Dubbo支持；
     
     （2）Rest支持；
     
     （3）自定义RPC支持；
     

• 调用链监控好处

  1. 准确掌握生产一线应用部署情况；

  2. 从调用链全流程性能角度，识别对关键调用链，并进行优化；

  3. 提供可追溯的性能数据，量化 IT 运维部门业务价值；

  4. 快速定位代码性能问题，协助开发人员持续性的优化代码；

  5. 协助开发人员进行白盒测试，缩短系统上线稳定期；

---

pinpoint链路拓扑

skywalking链路拓扑

zipkin链路拓扑