3、分布式追踪：从理论到实践

分布式追踪：从理论到实践

1. 分布式追踪的价值与挑战

分布式追踪以请求为中心，能帮助我们洞察系统的不同行为。不过，拥有追踪工具并不意味着就能消除应用程序中的性能问题，我们需要学会利用它提出有深度的问题。分布式追踪能够解决微服务可观测性方面的诸多疑问。

作者最早在2010年左右接触到分布式追踪，当时在摩根士丹利参与一个交易捕获和处理系统的工作。该系统采用面向服务的架构（SOA），包含十几个独立的Java应用组件，用于处理场外利率衍生品产品。系统的可观测性挑战在于每笔交易需经过复杂的变更、匹配和确认流程，由不同组件实现。为了了解交易的状态转换，他们使用了一个现已停用的APM供应商提供的分布式追踪平台，但体验不佳，主要问题是应用程序的追踪插桩困难，需要在XML文件中创建面向切面编程（AOP）风格的指令，并匹配内部API的签名，这种方式很脆弱，内部API的变更会使插桩失效，且难以通过单元测试来保证。

2015年年中作者加入Uber时，纽约的工程团队规模较小，很多人在开发后来被称为M3的指标系统。当时Uber刚开始将单体应用拆分为微服务，Python单体应用“API”已使用了一个名为Merckx的类追踪系统。但Merckx是为单体应用设计的，缺乏分布式上下文传播的概念，只能记录SQL查询、Redis调用和其他服务调用，无法进行深层次追踪，且在Uber采用基于事件循环的Tornado框架后，其传播机制无法处理同一线程上的多个并发请求。

2. Jaeger的诞生与发展

Uber在2014年开始构建自己的RPC框架TChannel，该框架内置了追踪插桩功能，生产环境中已有追踪数据生成，但缺乏收集和存储机制。作者用Go编写了一个简单的收集器，接收TCh