43 | 一个完整的分布式追踪系统是什么样子的？
周志明
你好，我是周志明。这节课我们来讨论链路追踪的话题。
虽然在 2010 年之前，就已经有了 X-Trace、Magpie 等跨服务的追踪系统了，但现代分布式链路追踪公认的起源，是 Google 在 2010 年发表的论文《Dapper : a Large-Scale Distributed Systems Tracing Infrastructure》，这篇论文介绍了 Google 从 2004 年开始使用的分布式追踪系统 Dapper 的实现原理。
此后，所有业界有名的追踪系统，无论是国外 Twitter 的Zipkin、Naver 的Pinpoint（Naver 是 Line 的母公司，Pinpoint 的出现其实早于 Dapper 论文的发表，在 Dapper 论文中还提到了 Pinpoint），还是国内阿里的鹰眼、大众点评的CAT、个人开源的SkyWalking（后来进入 Apache 基金会孵化毕业），都受到了 Dapper 论文的直接影响。
那么，从广义上讲，一个完整的分布式追踪系统，应该由数据收集、数据存储和数据展示三个相对独立的子系统构成；而从狭义上讲，则就只是特指链路追踪数据的收集部分。比如Spring Cloud Sleuth就属于狭义的追踪系统，通常会搭配 Zipkin 作为数据展示，搭配 Elasticsearch 作为数据存储来组合使用。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式追踪系统是现代分布式系统中不可或缺的组成部分。本文从Google的Dapper论文出发，介绍了分布式追踪系统的起源和影响，以及追踪与跨度的概念。文章指出一个完整的分布式追踪系统应该由数据收集、数据存储和数据展示三个相对独立的子系统构成。在功能性和非功能性上都有不小的挑战，包括低性能损耗、对应用透明、随应用扩缩和持续的监控。此外，文章还介绍了分布式追踪的三种主流的数据收集方式，分别是基于日志的追踪、基于服务的追踪和基于边车代理的追踪。基于日志的追踪对网络消息没有侵入性，但可能不如其他两种追踪实现来的精准。分布式追踪的主要需求是如何围绕着一个服务调用过程中的Trace和Span，来低损耗、高透明度地收集信息。这些信息对于排查故障和分析性能提供了重要的数据支持。 此外，文章还介绍了追踪规范化的重要性，以及OpenTracing和OpenCensus等规范的出现和发展。这些规范的制定和推广，有望解决目前追踪系统互不兼容的问题，为追踪系统的标准化和统一提供了方向。 总的来说，本文通过介绍分布式追踪系统的基本概念、实现方式和规范化发展，为读者提供了对分布式追踪系统的全面了解和认识，有助于读者在实际工作中选择合适的追踪方式和工具，以提高系统的可观测性和性能分析能力。
该试读文章来自《周志明的软件架构课》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(9)
- 最新
- 精选
qinsi文中写道：“日志追踪对网络消息完全没有侵入性”，这个不确定个人理解是否正确 根据个人理解，像是TraceID和SpanID等信息，都是需要通过网络从调用方传递到被调用方，这样才能最终串起整棵Trace Tree。文中所提到的几种数据收集方式，只要Trace信息随着请求一起发送，就对网络消息有侵入性（当然这里可以argue说把Trace信息放在http header里或是grpc metadata里可以做到对消息体无侵入，但这类情况下的无侵入性是由网络协议提供的，而非不同的追踪数据收集方式导致的）。作者回复: TraceID和SpanID是现代追踪系统的基础，是追踪的既有属性了，而不是日志的。举个例子类比，在一次HTTP访问后，日志中记录了HTTP消息中的某项信息，譬如agent吧，这时候很难去说因为log中打印了agent，所以log对HTTP消息是有侵入的，无论是否打印agent到日志，agent都客观地存在与HTTP消息里。
2021-03-035
zhanyd关于Dapper中的“追踪”与“跨度”在网上看到调用追踪的过程： 1.请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。 2.除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。 3.一个没有parent id的span成为root span，可以看成调用链入口。 4.所有这些ID可用全局唯一的64位整数表示； 5.整个调用过程中每个请求都要透传TraceID和SpanID。 6.每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。 7.要查看某次完整的调用则 只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。 https://juejin.cn/post/68449035607322132612021-03-0314
陈珙谢谢老师的分享，当时我们团队在微服务搭建的中后期引入的，也是因为随着微服务的规模变大后，跟踪定位问题越来越困难，经过多种产品的对比，最后选择了支持多语言,侵入性相对比较低的skywalking，根据团队的需要我针对sdk进行了扩展添加了request 和response的信息记录，在排查定位问题时结合efk能很快速的解决，同时他的耗时记录让我提前的解决了不少的性能问题。 当时引入skywalking的时候有个小插曲，开始我的微服务选择的是Fabio这个均衡器，因为Fabio在做请求转发的时候把skywalking的部分跟踪信息丢了，导致记录跟踪并不能串起来，使用查看效果并不好，后来也是多方面的考虑与取舍，坚持保留skywalking，把Fabio换成了Comsul-Teamplate+Nginx才解决了这个问题。2021-03-0316
walkingonair打卡，公司在用elk和pinpoint，说来惭愧，之前一直理解的是分布式日志和分布式服务预警解决方案，没想到背后还有这么多知识，还是怪自己没有深入去了解，今天又学到了。2021-03-031
鱼丸粗面公司之前用的自研的trace框架，在像opentelemeter迁移2024-01-04归属地：广东
锐老师提到“Pinpoint 这种详细程度的追踪，对应用系统的性能压力是相当大的”，有没有相关资料，比如什么情况下不能使用2022-04-21
stonejianbu此前因为有分布式框架的直接插件式支持，有在项目中使用jaeger基于服务的追踪。但后又切换到不同项目使用不同语言和框架，框架没有直接支持，自己也没有去着手实现，所以也没有使用追踪功能。 自己有调试使用kubernetes+istio，对于安全（传输、认证授权）、可视化（日志、追踪和度量）和灰度发布等功能应用，深感将这些功能下沉到基础设施带来的效益巨大。跟周大一样，对于网格化抱有很大信心，未来可期。2022-03-30
无心水使用的jaeger，对应用有一定的侵入性，需要写代码，排除其他依赖。感觉不好用，应该使用skywalking，不知道基础架构部是怎么做的选型2022-01-20
good boby系统架构采用的Spring Cloud 在链路追踪上采用的zipkin+sleuth2021-05-11
收起评论