调用链路_基于Opentracing + Uber Jaeger实现全链路灰度调用链

当网关和服务在实施全链路分布式灰度发布和路由时候，我们需要一款追踪系统来监控网关和服务走的是哪个灰度组，哪个灰度版本，哪个灰度区域，甚至监控从Http Header头部全程传递的灰度规则和路由策略。这个功能意义在于：

• 可以监控全链路中基本的调用信息，也可以监控额外的灰度信息，有助于我们判断灰度发布和路由是否执行准确，一旦有问题，也可以快速定位

• 可以监控流量何时切换到新版本，或者新的区域，或者新的机器上

• 可以监控灰度规则和路由策略是否配置准确

• 可以监控网关和服务灰度上下级树状关系

• 可以监控全链路流量拓扑图

笔者尝试调研了一系列分布式追踪系统和中间件，包括Opentracing、Uber Jaeger、Twitter Zipkin、Apache Skywalking、Pinpoint、CAT等，并结合业界动向，CNCF技术委员会通过OpenTelemetry规范整合基于Tracing的OpenTracing规范(官方推荐Jaeger做Backend)和基于Metrics的OpenSensus规范(官方推荐Prometheus做Backend)，最后决定采用Opentracing + Uber Jaeger方式来实现，重要原因除了易用性和可扩展性外，Opentracing支持WebMvc和WebFlux两种方式，业界的追踪系统能支持WebFlux相对较少

[OpenTracing] OpenTracing已进入CNCF，正在为全球的分布式追踪系统提供统一的概念、规范、架构和数据标准。它通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加(或更换)追踪系统的实现。对于存在多样化的技术栈共存的调用链中，Opentracing适配Java、C、Go和.Net等技术栈，实现全链路分布式追踪功能。迄今为止，Uber Jaeger、Twitter Zipkin和Apache Skywalking已经适配了Opentracing规范

笔者以Nepxion社区的Discovery开源框架(对该开源框架感兴趣的同学，请访问如下链接)为例子展开整合

源码主页，请访问
https://github.com/Nepxion/Discovery

指南主页，请访问
https://github.com/Nepxion/DiscoveryGuide

文档主页，请访问
https://gitee.com/Nepxion/Docs/tree/master/web-doc

整合的效果图

基本概念

灰度调用链主要包括如下11个参数。使用者可以自行定义要传递的调用链参数，例如：traceId, spanId等；也可以自行定义要传递的业务调用链参数，例如：mobile, user等

1. n-d-service-group - 服务所属组或者应用
2. n-d-service-type - 服务类型，分为“网关”和“服务”
3. n-d-service-id - 服务ID
4. n-d-service-address - 服务地址，包括Host和Port
5. n-d-service-version - 服务版本
6. n-d-service-region - 服务所属区域
7. n-d-version - 版本路由值
8. n-d-region - 区域路由值
9. n-d-address - 地址路由值
10. n-d-version-weight - 版本权重路由值
11. n-d-region-weight - 区域权重路由值

核心实现

Opentracing通用模块

源码参考
https://github.com/Nepxion/Discovery/tree/master/discovery-plugin-strategy-opentracing

由于OpenTracing扩展需要兼顾到Spring Cloud Gateway、Zuul和服务，它的核心逻辑存在着一定的可封装性，所以笔者抽取出一个公共模块discovery-plugin-strategy-opentracing，包含configuration、operation、context等模块，着重阐述operation模块，其它比较简单，不一一赘述了

在阐述前，笔者需要解释一个配置，该配置将决定核心实现以及终端界面的显示</