分布式调用跟踪系统

本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」,未经作者(laiwei)书面许可,不允许用于商业用途的转载、分发、和演绎。

分布式调用跟踪系统,是在分布式系统日趋复杂、规模越来越大的背景下,监控系统在功能上的一种延伸。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跟踪树调用时序图

分布式调用跟踪系统,本质是通过在业务上、下游代码中埋点,来记录和分析同一次请求在整个调用链上的相关事件,从而帮助研发和运维人员分析系统瓶颈,快速定位异常和优化调用链路。跟踪系统适用于以下业务场景。

  1. 调用链跟踪:记录和分析同一次请求在调用链上各个节点的各种时间开销,帮助用户排查和跟踪请求。
  2. 调用链路径分析:分析应用的关键路径是什么,帮助运维和研发人员进行性能评估,合理规划容量。
  3. 调用链拓扑分析:帮助研发和运维人员理清服务调用的来源和去向,理清服务的相关调用依赖关系。
  4. 数据可视化:从可视化的角度来呈现各个业务、各个请求的调用关系、拓扑路径、时间开销、依赖程度、调用时序等。

一个健壮的、稳定的分布式调用跟踪系统,需要满足以下三个原则。

  • 低消耗:跟踪系统对在线服务的影响应该做到足够小,对一些高度优化过的服务,即使一点点损耗也会很容易察觉到。
  • 对业务透明:应用方不需要做任何改动或者只需做少量修改。对于业务的研发人员来说,在理想状态下,是不需要知道有跟踪系统这回事的。如果植入一个跟踪系统,需要依赖应用的开发者高度配合,那么这个跟踪系统推广起来肯定会有很多阻力。
  • 可扩展性:能够适应主流的服务架构模型,能够应对服务规模的极速扩张,在性能和可运维方面做到可控。

对于分布式调用跟踪系统有兴趣的读者,可以进一步去学习Google的Dapper论文,以及参考Twitter的开源方案Zipkin

本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」,未经作者(laiwei)书面许可,不允许用于商业用途的转载、分发、和演绎。

推荐阅读更多精彩内容