微服务场景下分布式链路追踪

1. 概述

在单体应用中，客户端请求服务端获得相应，如果出现异常，则很容易定位到问题所在，简单的加一些日志打印、xdebug等皆可完成问题的定位。
那么在当前并发高、微服务场景下，一个请求经过多个服务，如果链路中某个服务异常，问题的排查、定位则会变得异常困难，此时请求链路追踪则发挥较大的作用。
基于以上的场景、问题，引入本文主要要介绍的内容Tracing。

2. 什么是Distributed Tracing

Distributed Tracing提供了在复杂网络中展示、解析链路调用的方法、理论，最早出现在Google的Dapper论文中。在互联网中，一个trace即代表本次请求、事务或者流程在系统中执行的过程，从trace中也可以解析出如：请求链路、请求时间、响应时间以及其他数据，帮助开发者更快速的定位问题。
现在市场上也有诸如：Zipkin, Dapper, HTrace, X-Trace等链路追踪系统，但各个系统之间不兼容，开发人员若想整合一套跨语言、系统的分布式追踪系统还是比较困难的。

3. OpenTracing Api

OpenTracing Api 提供了一套标准的、独立的框架用来解决分布式链路跟踪的兼容问题。这就意味着，如果开发者想要尝试不同的分布式链路跟踪系统，则只需要替换掉Trace相关部分，或者部分配置即可。
主要特点：

• 后台无关的一套接口
  • 只要实现了接口，即可实现应用跟踪
• 标准化了对跟踪最小单位Span的管理
  • 定义了开始Spa