对于微服务实现或云原生架构来说，其中一个非常重要的点就是可观测性，分布式服务的本质决定了需要对它进行有效的度量与观测。
而可观测性又主要分为日志，度量以及链路追踪三个方面的工作。
今天我要讲的就属于可测试性的其中一个方面，也就是链路追踪技术Jaeger。Jaeger是CNCF云原生计算基金会已毕业的16个技术项目之一。
在本篇中，我将主要阐述：
- 1. 链路追踪要解决什么问题，在架构中的作用
- 2. Jaeger的独特的优势与特点，它与过往微服务中使用较多的zipkin又有什么差别
- 3. opentelemetry与Jaeger搭配使用
为什么要链路追踪
在分布式系统中，服务中分散的，因而服务之间会存在互相调用的情况存在。系统对外的提供的任何一个业务功能，实质上后面都可能有数个以上的服务相互合作参与完成。
比如一个搜索功能，它实质上经过的服务链路是这样的：Rest服务 -> 授权验证服务 -> 搜索服务。那理所当然的，我们就面临一个困境，当出现问题时或搜索很久未有响应时，究竟是什么原因引起的？
这就是链路追踪要解决的问题。
关于Jaeger
Jaeger是一个分布式链路追踪技术，由Uber公司创建的一个技术，后捐献给了CNCF，在19年10月正式成为毕业项目。
在分布式链接追踪技术中，在云原生未兴起而微服务盛行的时期，可能另一个技术更为人所关注，那就是zipkin。zipkin也是一个分布式链接追踪技术。
它们都是分布式链路追踪的技术实现，在实现链接追踪的可观测性上，两个技术都是非常好的选择。
Jaeger具有以下一些特点：
- • 云原生CNCF的支持，隶属于CNCF毕业项目。
- • 分布式实现，高性能易于扩容
- • 支持opentracing标准，与OpenTelemetry的搭配非常契合
- • 支持不同的存储实现，包括Cassandra与Elasticsearch，还有一个提供给测试环境使用的内存实现
- • 内置了对度量工具Prometheus的支持
如上所示，上图我的一个项目中使用jaeger的查询UI数据。可以看出这个业务服务调用了两个模块，分别是rest security。这就是链路追踪的作用，它把分散的调用链路连接起来，供你查询与分析系统。
jaeger提供了UI查询工具，你可以方便的查询到任意一个请求的完整链路，调用的服务及时间等。
jaeger与zipkin
其实在链路追踪，zipkin可能更为人所熟悉，因为它流行的时间更久。而jaeger是后来的参与者。
因此，有必要稍微说一下zipkin与jaeger的差别，以便做出正确的选择
zipkin更成熟，jaeger更具活力与未来
zipkin最开始来自于Google的Dapper，而后由Twitter发展与完善，基于Java语言实现。
而jaeger则是由Uber开发的，后捐献给CNCF云原生计算基金会，基于Go语言来实现。
由于zipkin是先行者，使用较多较广，又是基于Java语言，相对更加成熟，这是它的优势。而jaeger则是后来者，当前可能并不占主流，但它是CNCF的官方项目，又基于高性能的Go语言实现，在未来的云原生架构中更具活力与未来。
中心式实现与分布式实现
zipkin是中心式的实现机制，链路追踪中的Collector,Storage,Query等模块并不能分开部署，只能以整体进行部署。而jaeger的实现思路并不相同，你可以以一个整体的服务来部署上述这些子模块，也可以分别按需对它们进行分布式部署。
这意味着，在分布式部署中，jaeger更具优势。灵活性与扩容性会表现的更好。相比较而言，中心化的zipkin在这一点上会表现稍差一点。
但这个差别只在项目比较大时才会有所体现。
OpenTelemetry Jaeger
Jaeger其实也有自己的收集器，Jaeger Client。但现在，基本上会使用更标准与流行的OpenTelemetry来搭配使用。OpenTelemetry是遵守了OpenTracing技术中立的链路追踪标准的实现。
所以，我们通常会在服务中，使用OpenTracing来做链路追踪的收集，然后收集的数据会汇报给jaeger。
事实上，OpenTelemetry不仅仅能做链路追踪，它还能做metric度量，度量的数据可能与另一个CNCF技术prometheus搭配使用，来实现分布式度量。
因此，在云原生架构中，可能你会使用OpenTelemetry Jaeger Prometheus搭配起来做到分布式的可观测性，最有意思的是，这三个技术都属于CNCF云原生计算基金会。
后面会再聊到度量工具Prometheus。
