分布式调用跟踪系统
分布式调用跟踪系统，是在分布式系统日趋复杂、规模越来越大的背景下，监控系统在功能上的一种延伸。Google在2010年4月发布了一篇题为Dapper, a Large-Scale Distributed Systems Tracing Infrastructure的论文，介绍了Google在该方面的工作。至此，分布式调用跟踪系统的概念，开始为业界所熟知。此后，Twitter也于2012年开源了相关的分布式跟踪系统Zipkin。
举一个Google Dapper论文中的例子，来说明分布式调用跟踪系统是如何工作的。如图1所示，描述用户发起一个请求X，穿过一个简单的分布式系统的调用路径。该简单系统由5个部分组成，包括：前端（A）、两个中间层（B和C）和两个后端（D和E）。当用户发起一个请求X时，首先到达前端A，然后发送两个RPC到服务器B和C。B会马上做出反应，但是C需要与后端D、E交互之后再返回给A，由A来响应最初的请求。对于这样一个请求在多个模块中穿梭的过程，通过Dapper可以记录该请求在每个模块中的接收和发送动作，以及相关统计信息，从而描绘出请求的路径拓扑以及时序图。从该图中我们可以看到，Dapper的跟踪架构极其类似于一种描述调用关系的树形结构，简称为跟踪树。
图1 分布式调用跟踪系统工作示意图
在Dapper跟踪树结构中，树节点是整个架构的基本单元，每个节点称之为一个span。节点之间的连线表示span和它的父span之间的关系。一个调用链上的所有span，具有相同的跟踪ID（traceId），每个span记录着相关的标注信息和事件。这样通过traceId，就可以把与之相关的所有span组织起来，例如图2所示的调用时序图。
图2 Dapper跟踪树调用时序图
分布式调用跟踪系统，本质是通过在业务上、下游代码中埋点，来记录和分析同一次请求在整个调用链上的相关事件，从而帮助研发和运维人员分析系统瓶颈，快速定位异常和优化调用链路。跟踪系统适用于以下业务场景。
- 调用链跟踪：记录和分析同一次请求在调用链上各个节点的各种时间开销，帮助用户排查和跟踪请求。
- 调用链路径分析：分析应用的关键路径是什么，帮助运维和研发人员进行性能评估，合理规划容量。
- 调用链拓扑分析：帮助研发和运维人员理清服务调用的来源和去向，理清服务的相关调用依赖关系。
- 数据可视化：从可视化的角度来呈现各个业务、各个请求的调用关系、拓扑路径、时间开销、依赖程度、调用时序等。
一个健壮的、稳定的分布式调用跟踪系统，需要满足以下三个原则。
- 低消耗：跟踪系统对在线服务的影响应该做到足够小，对一些高度优化过的服务，即使一点点损耗也会很容易察觉到。
- 对业务透明：应用方不需要做任何改动或者只需做少量修改。对于业务的研发人员来说，在理想状态下，是不需要知道有跟踪系统这回事的。如果植入一个跟踪系统，需要依赖应用的开发者高度配合，那么这个跟踪系统推广起来肯定会有很多阻力。
- 可扩展性：能够适应主流的服务架构模型，能够应对服务规模的极速扩张，在性能和可运维方面做到可控。
对于分布式调用跟踪系统有兴趣的读者，可以进一步去学习Google的Dapper论文，以及参考Twitter的开源方案Zipkin。
