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

一、为什么需要分布式调用跟踪系统

随着分布式服务架构的流行，特别是微服务等设计理念在系统中的应用，业务的调用链越来越复杂，

可以看到，随着服务的拆分，系统的模块变得越来越多，不同的模块可能由不同的团队维护，

一个请求可能会涉及到几十个服务的协同处理， 牵扯到多个团队的业务系统，那么如何快速准确的定位到线上故障？
同时，缺乏一个自上而下全局的调用id，如何有效的进行相关的数据分析工作？

对于大型网站系统，如淘宝、京东等电商网站，这些问题尤其突出。

一个典型的分布式系统请求调用过程：

比较成熟的解决方案是通过调用链的方式，把一次请求调用过程完整的串联起来，这样就实现了对请求调用路径的监控。

二、调用跟踪系统的业务场景

（1）故障快速定位

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

（2）各个调用环节的性能分析

在调用链的各个环节分别添加调用时延，可以分析系统的性能瓶颈，进行针对性的优化。

（3）各个调用环节的可用性，持久层依赖等

通过分析各个环节的平均时延，QPS等信息，可以找到系统的薄弱环节，对一些模块做调整，如数据冗余等。

（4）数据分析等

调用链是一条完整的业务日志，可以得到用户的行为路径，汇总分析应用在很多业务场景。

 

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

（1）分布式调用跟踪系统的设计目标

低侵入性，应用透明：

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

低损耗：

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

大范围部署，扩展性：

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

（2）埋点和生成日志

埋点即系统在当前节点的上下文信息，可以分为客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。

埋点日志通常要包含以下内容：

TraceId、RPCId、调用的开始时间，调用类型，协议类型，调用方ip和端口，请求的服务名等信息；
调用耗时，调用结果，异常信息，消息报文等；
预留可扩展字段，为下一步扩展做准备；

（3）抓取和存储日志

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

（4）分析和统计调用链数据

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

（5）计算和展示

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

四、调用跟踪系统的选型

大的互联网公司都有自己的分布式跟踪系统，
比如Google的Dapper，Twitter的zipkin，淘宝的鹰眼，新浪的Watchman，京东的Hydra等。

（1）Google的Drapper

Dapper是Google生产环境下的分布式跟踪系统，Dapper有三个设计目标：

低消耗：跟踪系统对在线服务的影响应该做到足够小。

应用级的透明：对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统显然是侵入性太强的。

延展性：Google至少在未来几年的服务和集群的规模，监控系统都应该能完全把控住。

Drapper的日志格式：

dapper用span来表示一个服务调用开始和结束的时间，也就是时间区间。

dapper记录了span的名称以及每个span的ID和父ID，如果一个span没有父ID被称之为root span。所有的span都挂在一个特定的trace上，共用一个traceID，这些ID用全局64位整数标示。

Drapper如何进行跟踪收集：

分为3个阶段：

①各个服务将span数据写到本机日志上；

②dapper守护进程进行拉取，将数据读到dapper收集器里；

③dapper收集器将结果写到bigtable中，一次跟踪被记录为一行。 

 

（2）淘宝的鹰眼

关于淘宝的鹰眼系统，主要资料来自于内部分享，

鹰眼埋点和生成日志：

如何抓取和存储日志：

鹰眼的实现小结：

 

详情见：淘宝-分布式调用跟踪系统介绍

参考资料：
分布式追踪系统dapper

Dapper，大规模分布式系统的跟踪系统

李林峰《分布式服务框架原理与实践》