作者：不止思考/王奎（本文来自作者投稿）
“ 呼叫链监控 ”是在微服务兴起后才有的一种新流行的监控模式。因为在我们传统单体应用的专案中，不存在服务链/呼叫链的概念，所以也就根本没有呼叫链监控的需求了。
当我们开始微服务架构之后，我们的很多服务变成分散式的了，并且我们对服务进行了拆分，拆分之后，使用者的一个请求进来，会依次经过不同的服务节点进行处理，处理完成后再返回结果给使用者。那么在整个处理的链条中，如果有任何一个节点出现了延迟或者问题，都有可能导致最终的结果出现异常，有的时候不同的服务节点甚至是由不同的团队开发的、部署在不同的服务器上，那么在这么错综复杂的环境下，我们想要排查出是链条中的具体哪个服务节点出了问题，其实并不容易。
因此大家就想到了一个办法，将这个请求经过的每一个节点都记录下来，形成一个完整的呼叫链监控系统，那么一旦发生请求呼叫异常的情况，只需要去排查这个呼叫链日志就能很清楚看到出错的环节在哪儿。
一、为什么需要“ 呼叫链监控 ”？
“呼叫链监控”是在微服务架构中非常重要的一环。它除了能帮助我们定位问题以外，还能帮助专案成员清晰的去了解专案部署结构，毕竟一个几十上百的微服务，相信在执行时间久了之后，专案的结构很可能就是下面图片这样了，在这种情况下，团队开发者甚至是架构师都不一定能对专案的网络结构有很清晰的了解，那就更别谈系统优化了。
好了，说了这么多，咱们下面就来具体看一下“呼叫链监控”的作用有哪些：
二、“ 呼叫链监控”的原理？
在呼叫链监控系统中，有几个核心概念需要了解：
从图中可见，一次请求只有一个唯一的trace id=12345，在请求过程中的任何环节都不会改变。在这个请求的呼叫链中，SpanA呼叫了SpanB，然后SpanB又呼叫了SpanC和SpanD，每一次Span呼叫都会生成一个自己的span id，并且还会记录自己的上级span id是谁。通过这些id，整个链路基本上就都能标识出来了。
好了，了解了核心概念之后，我们再来看一下它具体是如何工作的，下面选取Twitter开源的Zipkin原理图作为参考：
所有的呼叫链监控系统都由 资料埋点采集、资料储存处理、资料分析展示 几大部分组成，Zipkin也不例外。
图中左上角Reporter部分整合到应用程序中采集资料，并将资料上报，由Collector进行收集，然后通过Storage模组负责储存，落地到储存系统中（Zipkin用的是Cassandra）。而API模组是可以将处理后的资料提供对外服务的，UI模组就是资料统计展示层了。
三、“ 呼叫链监控”的应用？
了解了呼叫链监控的原理之后，我们再看看目前业内有哪些主流的开源呼叫链监控系统：
以上，就是对微服务架构中“ 呼叫链监控”的一些思考。
【本文作者】
王奎：不止思考的技术人，一名驻扎在武汉互联网的程序员老兵。
