
将事件拼接成链路
|
59
正是“分布式”的由来。微服务架构的流行导致调试定位微服务间故障和性能问题的需
求攀升。但是,一旦请求跨边界
—
比如从机房到云基础设施中,或者从你控制的基础
设施到你不控制的
SaaS
服务,然后返回
—
这时对于诊断问题、优化代码和构建更可
靠的服务,分布式链路追踪可能就非常有用。
分布式链路追踪的普及也意味着完成该任务的几种方法和相互竞争的标准已经出现。
2010
年谷歌出版的由
Ben Sigelman
等人所写的
Dapper
论文也首先吸引了大众的关注,
随即又有两个非常著名的开源链路追踪项目
—
2012
年推特的
Zipkin
(
https
:
//zipkin.io
)
和
2017
年
Uber
的
Jaeger
,此外还有
Honeycomb
(
https://hny.co
)和
Lightstep
(
https://
lightstep.com
)的一些商业解决方案。
虽然这些链路追踪项目在实施上有些许区别,但其核心方法和价值异曲同工。正如在第
一部分探讨的那样,扩展成一个错综复杂的依赖节点成为现代分布式系统的一种趋势。
正因为分布式链路追踪能够清晰地展示系统中服务和组件的关系,分布式链路追踪才显
得更有价值。
链路能帮助你理解系统依赖关系。依赖关系可能使问题变得模糊不清,如果不能清晰
理解依赖关系,调试可能就会变得尤为困难。比如,如果下游数据库服务出现性能
瓶颈,那么服务延迟可能就会堆积。在上游三到四层检测到延迟时,确定系统的哪个
组件是问题的根源可能会非常困难,因为现在在几十个其他服务中都可以看到相同的
延迟。
可观测系统中的链路仅是一连串相关联的事件。为了理解链路与可观测性基本构建块的 ...