关于OpenTracing

一、OpenTracing是什么

OpenTracing是一种分布式系统链路跟踪的设计原则、规范、标准。
传统的监控包括业务指标监控、服务质量监控等，只能对业务能的整体性能进行监控，而随着微服务和分布式的盛行，一个业务系统会由很多个服务组成，服务之间会进行相互调用。每一个前端请求都会形成一个复杂的分布式服务调用链路。这将导致的问题是：

• 出问题后难以定位问题
• 无法准确获取系统的整体性能和运行情况
• 无法获取对服务之间的调用关系

分布式链路追踪技术应运而生，但是要让自己的应用支持分布式跟踪太难了！不仅需要在进程内进行跟踪数据的传递，还要在进程之间传递。更难的是，还需要其他组件对分布式跟踪的支持，其中包括：

• 开源的服务（比如NGINX, Cassandra, Redis，Mysql）
• 在服务内引入的开源库（比如 grpc, ORMs)
• 已有的业务逻辑

解决办法是制定一个统一的标准，然后让大家都遵守这个标准来实现分布式跟踪信息的描述和传递。这样只要使用的是按照标准实现的服务，就能够进行完整的分布式跟踪。这个标准就是OpenTracing。

二、OpenTracing做了什么

OpenTracing实现了：

• 后台无关的一套接口，被跟踪的服务只需要调用这套接口，就可以被任何实现这套接口的跟踪后台（比如Zipkin, Jaeger等等）支持，而作为一个跟踪后台，只要实现了个这套接口，就可以跟踪到任何调用这套接口的服务
• 标准化了对跟踪最小单位Span的管理：定义了开始Span，结束Span和记录Span耗时的API。Span的定义可以参照开源分布式跟踪系统Zipkin介绍（架构篇）
• 标准化了进程间跟踪数据传递的方式：定义了一套API方便跟踪数据的传递
• 标准化了进程内当前Span的管理：定义了存储和获取当前Span的API

OpenTracing没有实现：

• 不对进程间传递的跟踪数据的编码定标准
• 不对向后台发送的跟踪数据的编码定标准
• 原因：让跟踪后台自己决定最适合他们的编码方式

三、OpenTracing的架构

OpenTracing架构图

250782_720w.jpeg

• 应用代码和开源控件写代码调用一套抽象出来的OpenTracing API（浅绿色的那一块）。而实现OpenTracing API的代码库（深绿色的那一块）则负责缓存和编码跟踪数据，以及进程间跟踪数据的上下文信息，以及如何和它自己的后台系统进行通信
• 通过这样的一种方式，应用代码就可以随意的更换OpenTracing的实现而不用改一行自己的代码。比如如果自己用Zipkin用得不爽了，就可以换到Jaeger后台。如果一开始直接调用Zipkin的API而不是OpenTracing的API，那么要换到Jaeger后台就得把所有调用Zipkin API的地方都换成调用Jaeger API，而OpenTracing免除了这方面的工作