[转]分布式系统为什么需要 Tracing？
淘宝如何实现的：
在前端请求到达服务器时，应用容器在执行实际业务处理之前，会先执行 EagleEye 的埋点逻辑（类似 Filter 的机制），埋点逻辑为这个前端请求分配一个全局唯一的调用链ID。这个ID在 EagleEye 里面被称为 TraceId，埋点逻辑把 TraceId 放在一个调用上下文对象里面，而调用上下文对象会存储在 ThreadLocal 里面。调用上下文里还有一个ID非常重要，在 EagleEye 里面被称作 RpcId。RpcId 用于区分同一个调用链下的多个网络调用的发生顺序和嵌套层次关系。对于前端收到请求，生成的 RpcId 固定都是0。
当这个前端执行业务处理需要发起 RPC 调用时，淘宝的 RPC 调用客户端 HSF 会首先从当前线程 ThreadLocal 上面获取之前 EagleEye 设置的调用上下文。然后，把 RpcId 递增一个序号。在 EagleEye 里使用多级序号来表示 RpcId，比如前端刚接到请求之后的 RpcId 是0，那么 它第一次调用 RPC 服务A时，会把 RpcId 改成 0.1。之后，调用上下文会作为附件随这次请求一起发送到远程的 HSF 服务器。
HSF 服务端收到这个请求之后，会从请求附件里取出调用上下文，并放到当前线程 ThreadLocal 上面。如果服务A在处理时，需要调用另一个服务，这个时候它会重复之前提到的操作，唯一的差别就是 RpcId 会先改成 0.1.1 再传过去。服务A的逻辑全部处理完毕之后，HSF 在返回响应对象之前，会把这次调用情况以及 TraceId、RpcId 都打印到它的访问日志之中，同时，会从 ThreadLocal 清理掉调用上下文。如图6-1展示了一个浏览器请求可能触发的系统间调用。
图6-1-一个浏览器请求可能触发的系统间调用
图6-1描述了 EagleEye 在一个非常简单的分布式调用场景里做的事情，就是为每次调用分配 TraceId、RpcId，放在 ThreadLocal 的调用上下文上面，调用结束的时候，把 TraceId、RpcId 打印到访问日志。类似的其他网络调用中间件的调用过程也都比较类似，这里不再赘述了。访问日志里面，一般会记录调用时间、远端IP地址、结果状态码、调用耗时之类，也会记录与这次调用类型相关的一些信息，如URL、服 务名、消息topic等。很多调用场景会比上面说的完全同步的调用更为复杂，比如会遇到异步、单向、广播、并发、批处理等等，这时候需要妥善处理好 ThreadLocal 上的调用上下文，避免调用上下文混乱和无法正确释放。另外，采用多级序号的 RpcId 设计方案会比单级序号递增更容易准确还原当时的调用情况。
最后，EagleEye 分析系统把调用链相关的所有访问日志都收集上来，按 TraceId 汇总在一起之后，就可以准确还原调用当时的情况了。
图6-2-一个典型的调用链
如图6-2所示，就是采集自淘宝线上环境的某一条实际调用链。调用链通过树形展现了调用情况。调用链可以清晰地看到当前请求的调用情况，帮助问题定 位。如上图，mtop应用发生错误时，在调用链上可以直接看出这是因为第四层的一个(tair@1)请求导致网络超时，使最上层页面出现超时问题。这种调用链，可以在 EagleEye 系统监测到包含异常的访问日志后，把当前的错误与整个调用链关联起来。问题排查人员在发现入口错误量上涨或耗时上升时，通过 EagleEye 查找出这种包含错误的调用链采样，提高故障定位速度。
调用链数据在容量规划和稳定性方面的分析
如果对同一个前端入口的多条调用链做汇总统计，也就是说，把这个入口URL下面的所有调用按照调用链的树形结构全部叠加在一起，就可以得到一个新的树结构（如图6-3所示）。这就是入口下面的所有依赖的调用路径情况。
图6-3-对某个入口的调用链做统计之后得到的依赖分析
这种分析能力对于复杂的分布式环境的调用关系梳理尤为重要。传统的调用统计日志是按固定时间窗口预先做了统计的日志，上面缺少了链路细节导致没办法对超过两层以上的调用情况进行分析。例如，后端数据库就无法评估数据库访问是来源于最上层的哪些入口；每个前端系统也无法清楚确定当前入口由于双十一活动流量翻倍，会对后端哪些系统造成多大的压力，需要分别准备多少机器。有了 EagleEye 的数据，这些问题就迎刃而解了。
- 埋点
- 实现线程内 trace 上下文传递，即服务器内部的方法互调时不需要强制在方法形参中加 Message 参数；
- 实现 trace 埋点逻辑自动织入功能，即业务开发人员不需要在方法中打印 trace 日志，只需要给该方法加注解标识 ；
- 原理：
- 利用 Javaagent 机制，执行 main 方法之前，会先执行 premain 方法，在该方法中将字节码转换器载入 instrumentation，而后 jvm 在加载 class 文件之前都会先执行字节码转换器。
- 字节码转换器中的逻辑为，识别出注解 trace 的类及方法，并修改该方法字节码，织入埋点逻辑。进入方法时会初始 trace 上下文信息，并存储在线程的 threadLocals 中，退出方法会打印 trace 日志并清空该方法的上下文。
- 数据聚合
- 应用层 trace 日志通过 flume agents 实时发送至 flume collector；
- 数据存储
- 服务端分别通过 hdfs-sink 和 hbase-sink，实时录入至 hbase、hdfs；
- hdfs 有 tmp 临时文件存放实时聚合过来的数据，每5分钟生成一个 done 文件；
- 数据分析和统计
- load 程序每 4 分钟检查 done 文件并存放至 hive 表 hkymessage 指定分区；
- 分析程序每5分钟执行一次, 将生成统计数据入库, 结果集数据如下：
数据格式：{5个分层的5个响应时段请求个数合集} {5个分层5-10s和大于10s散点数据合集} 当前5分钟最后一次请求rootid 统计时间
- 数据展示
- 基于 Python 的 Django
