【进阶之路】调用链监控原理与zipkin项目简单搭建

在单体服务的架构中，所有的服务，组件都在一台机器上，如果需要监控服务的异常与耗时，往往是比较简单的。我们可以使用 AOP 在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间。在问题追踪的时候，也可以在关键节点打印日志。

但是在微服务架构里就不同了，一次请求会涉及到多个模块与系统，往往需要多台机器的相互协作才能完成。而一系列的请求，不仅会涉及到串联并联、还有同步异步之分。这个时候，如果依然采取单体架构中服务监控的方式，那么确定这个请求背后调用了哪些服务，哪些模块，哪些节点及调用的先后顺序，调用的耗时，或者追踪调用中出现的问题甚至会让开发人员当场去世。于是乎，我们马上就会想到服务追踪系统。

要实现服务追踪，我们有三点问题需要解决：

• 1、埋点并收集服务调用的上下文数据。
• 2、对收集到的数据进行分析、实时处理。
• 3、数据链路的可视化展示。

通过分布式追踪系统能很好地定位如下请求的每条具体请求链路，从而轻易地实现请求链路追踪：

那么，有没有一种规范能让大家都很好的进行链路追踪系统的开发呢？

一、分布式调用链规范OpenTracing

为了解决不同的分布式追踪系统 API 不兼容的问题，诞生了 OpenTracing 规范，OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。

1、OpenTracing是什么？

Opentracing是分布式链路追踪的一种规范标准，具有平台无关的特性，开发者只需修改少量的配置代码，就可以在符合Opentracing标准的链路追踪系统之间自由切换。

被跟踪的服务只需要调用Opentracing接口，就可以被任何实现这套接口的跟踪后台（比如Zipkin, Jaeger等等）支持，而作为一个跟踪后台，只要实现了个这套接口，就可以跟踪到任何调用这套接口的服务。同时，Opentracing对进程间跟踪数据传递与追踪的最小独立单位Span进行了标准化。

2、OpenTracing的数据结构

• 1、Span

Span是一条追踪链路中的基本组成要素，也是最小独立单位。一个span表示一个独立的工作单元，比如可以表示一次函数调用，一次http请求等等。

span中包含以下信息：

• 服务名称(调用请求的名字)

• 服务的开始时间和结束时间

• K/V形式的Tags

• K/V形式的截断日志Logs

• SpanContext（span上下文信息，其中包含 Trace ID 和 Span ID）

• References&#x