MinTalk | 为什么需要做分布式追踪

去年夏天应曹老师的邀请，给交大软件工程课的同学们做了一次后端服务器架构的入门分享，从如何设计一个最简单的服务器开始，一步步把如今常见的负载均衡，CDN等等概念一个个引荐给大家，没有涉及任何技术细节，只是想让大家理解为什么会有这些技术，他们分别是为了解决什么问题而出现，那次分享的内容我也想晚点写篇文章记录一下。

分享的结尾，为同学们引荐了微服务的概念，然后就以各种赞美微服务的好而结束，似乎有种王子和公主终于在一起了的感觉，然而也就像童话的结尾都是骗人的一样，最近也终于体验到了把应用拆的碎碎的之后的一些问题。

起因是最近遇到的一次线上问题，某API出现了大量错误，于是大家开始各种猜测是哪个环节出了问题。由于调用链上设计的服务太多了，哪里出问题都是有可能的，于是找问题花了不少力气。虽然结果当然是其中一个节点出了问题，但是这样满世界找到底是哪里出现漏洞的感觉实在是太差，于是终于意识到，是时候开始做链路追踪了，简单地说，就是提供一个可以展示API在系统中的调用路径的工具，更快的发现真正出问题的节点。

其实，服务调用的链路追踪，只是提高微服务系统可见性的三大支柱的其中一个。在研究这个问题的过程中，有一张图很好的解决了我对日志，监控和链路追踪这三者这件关系的困惑。

上图的作者写了一篇很好的文章阐述这三者之间的关系。总体而言，监控（Metrics）指的是将一些可聚合的指标进行展示，比如出现500错误的个数，日志（Logging）则更多的偏重于应用具体发生了什么的详细记录，一般包含大量的文件，而链路追踪(Tracing)更关注于API的调用链路，及服务和服务之间的关系。这三者有重合的部分，比如日志中其实也包含了所有API调用的记录，而服务的500错误其实也是API的状态的一部分，但也可以看出各自关注的重点其实是不同的。

这张图虽然讲的是一些方法论的内容，但对我们之后讨论链路追踪应该做什么不该做什么，还是起到了很好的参考作用。正因为有很多两边都可以做的事情，所以要不要做，哪个模块来做，甚至选择哪个第三方的工具来做，其实都取决于我们想解决的问题是哪个范围内。

最终我们选择的开源软件，也是专注于链路追踪模块，而不支持偏监控和日志要做的事情，这也是考虑到我们已有的工具已经覆盖了这两块的内容，而我们最缺的，其实恰恰是纯Trace要做的事情，即展示一个完整的API调用链。

决定了目标问题，就要开始看如何解决问题了。下一篇文章，再来讲述业界是如何解决这个问题的，从Google的一篇论文开始聊起，下次见！

引用

https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html