本文转载自微信公众号《脑子是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。《微服务之战》是一系列关于微服务设计思维的主题，主要针对微服务后出现的一些矛盾/冲突点，并不涉及具体的知识点深入。如果您有任何问题或建议，欢迎随时交流。背景在经历了微服务的战争：级联故障和雪崩P0级事件后，你摊开双手，葛优躺下。开始自查，想起这次排错的经历，因为还没有基础设施，所以在接到客户反馈后，通过错误日志排查问题。但是在级联错误的情况下，错误日志太多了。不同的服务，不同的环节，几乎都挤在了一起。修复时间主要花在浏览日志上。翻了好几页才找到比较有效的。错误信息。下次要是再出现类似的问题就惨了，MTTR太长了，4个9很快就用完了。这时候你就想到了业界经常提到的一个武器，那就是“分布式链路跟踪系统”。粗略地说，可以看到各种应用的调用依赖：其中最著名的是GoogleDapper论文中介绍的Dapper。起源于Google，为解决不同团队、不同语言、不同模块、部署在不同服务器、不同数据中心带来的软件复杂性（难以分析、无法定位），构建了一个分布式跟踪系统：自那么，开启了业界在分布式链路上的启蒙/启蒙之路。现在很多著名的分布式链接跟踪系统都是基于GoogleDapper论文开发的，基本原理和架构都大同小异。如果对此感兴趣，可以详细查看GoogleDapper，很有意思。（GoogleDapper有trackingtree和Span的概念）模型选择？谁想做链接跟踪，那么你必须选择一个开源产品作为你的分布式链接跟踪系统，不太可能去创建一个新的，首先实现商业目的是最重要的。于是上网搜索，发现了大量产品如下：推特：Zipkin。优步：耶格。弹性堆栈：弹性APM。Apache：SkyWalking（国内开源爱好者吴胜开源）。Naver：Pinpoint（由一家韩国公司开发）。阿里：鹰眼。大众点评：猫。京东：九头蛇。随便一搜，这类产品很多，而且据说各大公司都有自己的内部链接追踪系统，麻烦就大了。都是基于GoogleDapper进化而来，那么本质上有什么区别，怎么去扩展这么多新产品呢？Jaeger先看Uber开发的Jaeger，Jaeger目前由云原生计算基金会（CNCF）托管，是CNCF的第7个顶级项目（2019年10月毕业）：JaegerClient：Jaeger客户端，是Jaeger的特定语言实现OpenTracingAPI，可以手动使用或通过与OpenTracing集成的各种现有开源框架（例如Flask、Dropwizard、gRPC等）来检测应用程序以进行分布式跟踪。JaegerAgent：Jaegerclientagent，在UDP端口监听acceptedspan，并批量发送给Collector。JaegerCollector：JaegerCollector，顾名思义，是面向Agent的，用于收集/管理链接跟踪信息。JaegerQuery：数据查询和前端界面展示。JaegerIngester：可以从Kafka读取数据并写入其他存储介质（Cassandra、Elasticsearch）。了解了Jaeger各个组件的功能之后，我们主要关注其整体架构中的数据流：Jaeger是一个非常经典的架构。client主动向Agent发送链路信息，Agent向Collector上报，再通过queue，最后Floor到storage。然后由另一个可视化管理后台进行查看和分析。更现代的是reporting="collection="storage="analysis的标准化过程。而且你会发现Jaeger和Zipkin在架构上是相似的：ZipkinCollector：Zipkin收集器，用于收集/管理链接跟踪信息。存储：Zipkin数据存储，支持Cassandra、ElasticSearch、MySQL等第三方存储ZipkinQueryService：数据存储和索引后，用于查找和检索跟踪信息WebUI：数据查询和前端界面展示。从时间上看，Jaeger比Zipkin晚了四年。莫非是重新发明了轮子。看完之后，我发现做Jaeger的主要原因是：当时只能通过Scribe发送spans到Zipkin，而Zipkin支持的高性能数据存储只有Cassandra。Uber当时对这两种技术都没有经验，所以选择自己构建一个后端，将一些自定义组件与ZipkinUI结合起来，形成一个完整的跟踪系统。有关更多详细信息，您可以阅读UberEngineering的EvolvingDistributedTracing以了解更多详细信息。阿里鹰眼链路跟踪系统的另一个代表，多是基于日志和流式计算，比如阿里的鹰眼和滴滴的踪迹，如下图所示：更具体的，看大会上的和《异构系统链路追踪——滴滴 trace 实践》我赢了此处详述，推荐对链接追踪感到好奇或担心的朋友阅读。综上所述，大部分在初期选择时都会选择亲和力强的跟踪系统，就像Jaeger属于Go，Zipkin和Skywalking多为Java系统，三者都完全兼容OpenTracing，只是架构有些不同,而所有的都是基于GoogleDapper的发散，所以支持的基本功能和查询页面的优雅是非常重要的。但是，有原始的N个系统。如果要直接对接新链接跟踪系统，还是很麻烦的。因为接入的初衷一定是为了解决原系统的故障/定位问题，而不仅仅是为了新系统。因此，从接入的角度来看，他们大多不会使用现有的开源跟踪系统（除非历史债务不大），数据量可能会非常大。因此，在现有方法的基础上，清洗数据然后创建链接跟踪模式是很常见的。其中，日志往往是一个比较好的切入点，即清洗某些数据，形成一个新的分析系统。重建一个内轮。另外，基于ServiceMesh的“无”侵入式链接跟踪这两年很火，看起来是个很有前途的方向。它的代表作之一Istio使用的是来自CNCF的Jaeger，而Jaeger也兼容Zipkin。耶格尔获胜。
