全链路灰度的挑战、实现思路与解决方案

在传统的单体应用架构中，灰度发布相对简单。只需要在服务的流量入口处进行分流，通过使用 K8s Service 或各种类型的网关即可实现。然而，微服务架构引入了新的复杂性，服务之间的依赖关系错综复杂。有时候，某个功能的发布可能依赖于多个服务，要求灰度流量在整个调用链中准确路由到灰度版本的服务。传统的单个服务流量入口设置分流的做法无法满足这一需求。为了解决微服务架构下的灰度发布问题，全链路灰度发布引入了泳道（Lane）的概念。泳道将灰度视角从单个服务扩展到整个请求的调用链上，确保流量能够精确地在一组指定规则的服务之间流动，就像在预先设置好的泳道中一样。全链路灰度发布方案专为微服务架构设计，旨在应对微服务架构下的灰度发布挑战。

泳道实现的主要难点在于，流量在服务间调用的过程中如何路由到正确的服务版本，但有一个简单的实现思路可以规避这个问题：复制一个包含所有微服务的完整环境，将需要灰度的服务替换为灰度版本。然后只需要在两个环境的流量入口处通过网关对流量进行规则分流，由于两套环境间存在网络隔离，灰度环境天然成为了一个灰度流量泳道。

然而，对于服务数量较多的微服务项目来说，这种方法会浪费资源，因为在灰度环境中创建非灰度服务会消耗额外的资源。如果要同时灰度多个版本，就需要创建多套完整环境，进一步增加了资源的浪费。

若能赋予每个服务路由流量的能力，泳道的设置就可以共用正常服务从而充分利用资源，多版本的全链路灰度发布也可以同时在同一个环境中进行。具体而言，需要两个能力：全链路流量路由和全链路数据透传。

为了实现全链路灰度发布，流量路由规则基于流量染色标记，因此需要将染色标记传递到整个请求链路中，即实现全链路数据透传能力。简单的数据透传可以基于原生的 HTTP Header、Query Parameters 等资源来实现，但在复杂的微服务场景下，应该使用 Tracing Baggage 机制。Tracing Baggage 是分布式链路跟踪工具提供的一种能力，可以携带用户自定义的键值对，主流的跟踪工具如 Skywalking 和 OpenTelemetry 都支持该功能。使用分布式链路追踪框架可以方便地进行日志记录和问题排查，特别适用于灰度发布场景下的需求。

主要有 Istio、JavaAgent 等主流方案，基于流量路由的能力，ZadigX 提供了两套通用方案：