基于腾讯云微服务引擎（TSE） ，轻松实现云上全链路灰度发布

概述

软件开发过程中，应用发布非常频繁，通常情况下，开发或运维人员会将系统里所有服务同时上线，使得所有用户都使用上新版本。这样的操作时常会导致发布失败，或因发布前修改代码，线上出现 Bug。

假设一个在线商城，每天都有大量的用户访问，如果直接在所有用户中部署新版本应用，一旦出现问题，所有用户都可能受到影响。相比之下，通过引入灰度发布策略，先将新版本的应用部署到少量的用户中，检查是否存在问题，如果没有，再逐步扩展到更多的用户中，由此解决全量发布的各种弊端。

灰度发布是一种软件发布策略，它允许你在生产环境中渐进式部署应用，新版本只对部分用户可见，在问题出现时尽量减少影响。在微服务体系架构中，服务间的依赖关系错综复杂，有时单个服务发版依赖多个服务同时运行联动，对这个新版本服务的上下游进行分组验证，这是微服务架构中特有的全链路灰度发布场景。

使用腾讯云微服务引擎 TSE 提供的网关和服务治理能力，可以在不修改任何业务代码的情况下，可视化配置灰度规则，实现云上轻松易用的全链路灰度发布。

图1-1 全链路灰度场景架构

接下来演示云原生 API 网关+北极星网格构建的全链路灰度发布能力。下图模拟的云书城应用，由4个后端的微服务组成，采用 Spring Boot + Dubbo 实现，调用链包含：收藏功能、购买功能，用户管理功能和订单功能。用户通过前端页面访问书城，进行内容浏览和书籍下单。

图1-2 云书城前端页面

环境

1

云组件版本

本次实践采用如下组件：

• TSE-云原生网关：v2.5.1
• TSE-北极星网格： v1.12.0.1
• TKE：v1.20
• APM-SkyWalking: v8.5.0

我们将应用部署在腾讯云 TKE 集群中，在实际生产中，全链路灰度对于应用的部署模式没有限制性要求，无论是 CVM 虚拟机，还是自建容器环境，都能应用此方案。

2

灰度服务准备

项目模拟书城收藏服务改版，对 addUserFavoriteBook 接口进行修改：当前基线版本点击【收藏】按钮后，仅显示成功收藏字样，代码示例如下：

public Response<String> addUserFavoriteBook(Long userId, Long isbn) {    Response<String> resp = new Response<String>(ResponseCode.SUCCESS);    try {        FavoritesInfo entity = new FavoritesInfo(userId, isbn);        if (favoritesPersistCmpt.favoriteExist(entity)) {            resp.setMsg("已收藏(version:1.0.0)");            return resp;        }
        favoritesPersistCmpt.addUserFavorite(entity);        resp.setMsg("收藏成功");        BookInfoDto dto = storeClient.getBookInfoByIsbn(isbn);        cacheCmpt.cashUserFavoriteBook(userId, dto);    } catch (Exception e) {        logger.error("failed to add FavoritesInfo", e);        resp.setFailue("服务异常，请稍后重试！");    }    return resp;}

灰度版本修改后，页面点击【收藏】，会详细显示用户 ID 及书籍 ID，代码示例如下：

public Response<String> addUserFavoriteBook(Long userId, Long isbn) {        Response<String> resp = new Response<String>(ResponseCode.SUCCESS);        try {            FavoritesInfo entity = new FavoritesInfo(userId, isbn);            if (favoritesPersistCmpt.favoriteExist(entity)) {                resp.setMsg("已收藏(version:2.0.0)");                return resp;            }            favoritesPersistCmpt.addUserFavorite(entity);            resp.setMsg("用户 userId = " + userId + " 成功收藏 book isbn = " + isbn);            BookInfoDto dto = storeClient.getBookInfoByIsbn(isbn);            cacheCmpt.cashUserFavoriteBook(userId, dto);        } catch (Exception e) {            logger.error("failed to add FavoritesInfo", e);            resp.setFailue("服务异常，请稍后重试！");        }        return resp;    }

为了方便查看全链路服务当前版本，各服务将应用版本号回传给前端，在前端页面上显示。

图2-1 基线版本收藏服务

图2-2 灰度版本收藏服务

3

北极星网格接入

云书城架构中，服务发现能力目前是通过 Nacos 实现，在全链路灰度发布中，服务间需要使用到治理能力，我们采用北极星网格对注册发现功能进行替换。项目选择 Polaris-Dubbo 框架方式接入，通过更新北极星代码依赖，无需修改代码即可完成。对比原项目，有以下几点变化：

• 修改 POM.XML 文件，增加北极星 -Dubbo 服务注册、服务熔断及服务路由依赖包。

//服务注册插件<dependency>  <groupId>com.tencent.polaris</groupId>  <artifactId>dubbo-registry-polaris</artifactId>  <version>${polaris.version}</version></dependency>
//服务熔断插件<dependency>  <groupId>com.tencent.polaris</groupId>  <artifactId>dubbo-circuitbreaker-polaris</artifactId>  <version>${polaris.version}</version></dependency>
//服务路由插件<dependency>  <groupId>com.tencent.polaris</groupId>  <artifactId>dubbo-router-polaris</artifactId>  <version>${polaris.version}</version></dependency>

• 在配置文件中，修改 Dubbo 应用注册中心接入地址。

dubbo.registry.address=polaris://x.x.x.x:8091?username=polaris&password=*****

修改后的项目，代码保持 Dubbo 标准方式进行注册及调用，无需变更。

//注册服务（服务端）@DubboService(version = "${provicer.service.version}")public class ProviderServiceImpl implements ProviderService {}
//服务调用（消费端）@DubboReference(version = "1.0.0")private ProviderService providerService;

4

容器服务部署

完成上述修改后，对微服务应用重新编译打包，推送至镜像仓库。在 TKE 集群中，我们以 Deployment 方式下发应用。其中，收藏服务将基线版本和灰度版本都部署在集群中，其他服务仅部署一个版本，使用服务治理能力进行流量路由。

• 基线版本收藏服务 YAML。

apiVersion: apps/v1kind: Deploymentmetadata:  name: favorites-service  namespace: qcbm  labels:    app: favorites-service    version: v1spec:  replicas: 1  selector:    matchLabels:      app: favorites-service      version: v1  template:    metadata:      labels:        app: favorites-service        version: v1    spec:      containers:        - name: favorites-service          image: ccr.ccs.tencentyun.com/qcbm/favorites-service-polaris          env:            - name: MYSQL_HOST              valueFrom:                configMapKeyRef:                  key: MYSQL_HOST                  name: qcbm-env                  optional: false            - name: REDIS_HOST              valueFrom:                configMapKeyRef:                  key: REDIS_HOST                  name: qcbm-env                  optional: false            - name: MYSQL_ACCOUNT              valueFrom:                secretKeyRef:                  key: MYSQL_ACCOUNT                  name: qcbm-keys                  optional: false            - name: MYSQL_PASSWORD              valueFrom:                secretKeyRef:                  key: MYSQL_PASSWORD                  name: qcbm-keys                  optional: false            - name: REDIS_PASSWORD              valueFrom:                secretKeyRef:                  key: REDIS_PASSWORD                  name: qcbm-keys                  optional: false          ports:            - containerPort: 20880              protocol: TCP

• 灰度版本收藏服务 YAML。

apiVersion: apps/v1kind: Deploymentmetadata:  name: favorites-service-new  namespace: qcbm  labels:    app: favorites-service-new    version: v1spec:  replicas: 1  selector:    matchLabels:      app: favorites-service-new      version: v1  template:    metadata:      labels:        app: favorites-service-new        version: v1    spec:      containers:        - name: favorites-service-new          image: ccr.ccs.tencentyun.com/qcbm/favorites-service-new-polaris          env:            - name: MYSQL_HOST              valueFrom:                configMapKeyRef:                  key: MYSQL_HOST                  name: qcbm-env                  optional: false            - name: REDIS_HOST              valueFrom:                configMapKeyRef:                  key: REDIS_HOST                  name: qcbm-env                  optional: false            - name: MYSQL_ACCOUNT              valueFrom:                secretKeyRef:                  key: MYSQL_ACCOUNT                  name: qcbm-keys                  optional: false            - name: MYSQL_PASSWORD              valueFrom:                secretKeyRef:                  key: MYSQL_PASSWORD                  name: qcbm-keys                  optional: false            - name: REDIS_PASSWORD              valueFrom:                secretKeyRef:                  key: REDIS_PASSWORD                  name: qcbm-keys                  optional: false          ports:            - containerPort: 20880              protocol: TCP

• 前端页面服务以 Service 方式部署，通过 Ingress 模式对接云原生网关，提供集群外部访问能力。

apiVersion: v1kind: Servicemetadata:  name: qcbm-front  namespace: qcbmspec:  ports:    - name: http      port: 80      targetPort: 80      protocol: TCP  selector:    app: qcbm-front    version: v1  type: NodePort

5

云原生网关接入

云原生网关支持将流量直通到 Service 所在的 Pod，无需通过 NodePort 中转。在控制台里绑定 TKE 集群，输入 Service 名，网关通过 Endpoint 里收集 Pod IP，在网关里自动生成 Kong Services 和 Upstream。一旦 TKE Service 发生变化，Ingress Controller 会动态更新 Upstream 里的 Target 信息。

后续操作基于 Kong 里自动生成的 Services，配置基线及灰度网关路由规则。

图2-3 云原生网关绑定 TKE 集群服务

图2-4 云原生网关自动生成 Services

图2-5 云原生网关自动生成 Upstreams

6

链路追踪接入

单体系统时代追踪的范围只局限于栈追踪，而在微服务环境中，追踪不只限于调用栈，一个外部请求需要内部若干服务的联动，完整的一次请求会跨越多个服务。链路追踪的主要目的是排查故障，如当前问题点处于调用链的哪一部分，各服务间输入输出是否符合预期，通过链路追踪，可以查看到服务间的网络传输信息，以及各服务内部的调用堆栈信息。

采用 APM 的 SkyWalking 协议方式进行上报，首先修改 SkyWalking 文件夹里的 agent.config 文件，配置接入点、Token 、自定义空间和服务名称。

collector.backend_service=x.x.x.x:11800agent.authentication=xxxxxxagent.service_name=favorites-service-newagent.namespace=QCBM

在 Dockerfile 中，修改应用程序的启动命令行，以 JavaAgent 方式指定 SkyWalking Agent 的路径 ：

java -javaagent:/app/skywalking/skywalking-agent.jar -jar favorites-service-new.jar

部署后，可以在控制台里验证应用拓扑正确性。

图2-6 应用拓扑图

解决方案

通过四个阶段的操作，实现收藏服务的全链路灰度发布，分别是实例打标、网关路由、微服务路和标签透传。

图3-1 全链路灰度发布方案

1

实例打标及标签透传

实例打标，指的是通过实例标签标识不同的应用，将基线版本与灰度版本区分开。一般有两种方式进行实例打标：一是框架自动同步，将应用名，环境变量等做为实例标签；二是用 K8S 部署时的 CRD Label 作为实例标签。本实践中使用 Dubbo 框架里的 applicaiton 字段来区分基线版本和灰度版本应用。

图3-2 网关路由规则

网关层对灰度流量进行了染色，在微服务调用过程中，需要将染色标签在每一跳进行传递，使得各微服务都可以识别到灰度流量，并进行正确路由处理。

图3-3 标签透传示意图

外部染色标签在入口处，以 HTTP Header 方式存在，在 Dubbo-Gateway 服务处，编码将 HTTP Header 转化为 Dubbo attachment，使得染色标签在微服务内部中继续透传，最终根据 attachment 里的取值做服务间调用依据。

private FavoriteService add(FavoriteService favoriteService, String result) {        logger.info("header:{}", result);        RpcContext.getContext().setAttachment("gray", result == null ? "false" : result);        return favoriteService;    }

2

网关路由

网关作为系统流量入口，负责将外部流量按照一定的用户特征，切分流入灰度版本和基线版本。并对灰度流量进行染色打标，供服务治理中心动态路由规则匹配使用。在实际生产中，一般有三种分流的方法：

• 通过匹配用户请求的 Header 参数，进行流量区分。
• 通过匹配用户请求的 Host 特征，进行流量区分。
• 通过流量百分比进行区分，使用云原生网关能力，将其中一部分流量进行染色处理。

本次实践针对前两种切分方式进行介绍。

图3-4 网关路由示意图

3

微服务路由

北极星网格在全链路灰度中，充当服务治理中心的角色，解决架构中注册发现、故障容错、流量控制和安全问题。通过北极星网格控制台中的配置，把基线和灰度请求，路由到不同的实例分组上，并将灰度请求固定在灰度版本服务间进行传递和处理。

图3-5 动态路由示意图

我们创建了2条服务间动态路由规则，基线和灰度请求按照不同匹配规则，路由至对应实例分组。实现中，北极星基于请求消息内容来对请求匹配，并根据优先级进行流量调度。

图3-6 治理中心路由规则

场景

1

通过Header特征全链路灰度

场景说明

如果客户端访问希望统一域名，比如实践中的 gray.qcbm.yunnative.com，我们可以通过传入不同的 Header，把请求分别路由到基线和灰度环境。当生产环境中存在多个客户分组，或多条灰度路由规则，也可以通过云原生网关进行自定义 Header 染色，使用不同染色标签，进行服务间路由搭配。

图4-1 通过 Header 特征全链路灰度

配置方法

在云原生网关上创建两条路由规则：

• qcbm-front-router-web，HOST 为gray.qcbm.yunnative.com，Header为app:web，路由到 Dubbo-Gateway 服务。
• qcbm-front-router-mobile，HOST 为gray.qcbm.yunnative.com，Header为app:mobile，路由到 Dubbo-Gateway 服务，开启染色(gray:true)。

图4-2 云原生网关路由规则

服务治理中心可以直接使用现成的 app:web 或 app:mobile 标签路由，也可以对路由请求新增染色，使用染色标签路由，优化复杂环境管理。这里我们开启云原生网关的 Request-Transformer 插件，对 qcbm-front-router-mobile 路由报文进行修改，添加 gray:true 头，使用该染色标识进行路由管理。

图4-3 路由染色插件

图4-4 添加染色标识

qcbm-front-router-mobile 路由规则的请求到达 Dubbo-Gateway 后，一旦需要访问收藏服务（FavoriteService），gray:true 染色标签会命中北极星网格灰度服务路由，选择调用 remote.application为favorites-service-new 的服务实例。此实例分组为我们部署的 favorites-service-new 灰度版本 deployment。

图4-5 灰度服务路由

qcbm-front-router-web 路由规则的请求会命中无染色标签的基线服务路由，调用 remote.application 为 favorites-service 的服务实例。此实例分组为我们部署的 favorites-service 基线版本 deployment。

图4-6 基线服务路由

结果验证

我们借用 chrome 浏览器插件 ModHeader，对访问请求按需添加 Header。

• 当添加 app:mobile 后，浏览器访问 gray.qcbm.yunnative.com，我们的访问链路如下：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service-New](灰度)

页面显示如下：

图4-7 灰度请求页面

同时，也可以通过链路监控观察到，gateway-service（基线服务）正确的请求到 favorite-service-new（灰度服务），同时 favorite-service-new 正确请求到 store-service（基线服务）：

图4-8 灰度请求链路详情

• 当添加 app:web 后，浏览器访问 gray.qcbm.yunnative.com，此时我们的访问链路如下：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service](基线)

页面显示如下：

图4-9 基线请求页面

通过链路监控，可以观察到，gateway-service（基线服务）正确的请求到 favorite-service（基线服务），同时 favorite-service 正确请求到 store-service（基线服务）：

图4-10 基线请求链路详情

在北极星网格中，我们可以针对链路的每一跳配置路由规则，每个主调服务都可以定义属于自己的匹配规则。

2

通过域名特征全链路灰度

场景说明

同样的，也可以采用域名对请求进行区分，预期 web 端用户采用 gray.web.yunnative.com 访问基线环境；mobile 端用户采用 gray.mobile.yunnative.com 访问灰度环境。这种分流方式，适用于网关根据用户登录信息，动态分流的场景，不同的用户在登录时，登录模块根据验证信息，返回302报文，给予不同的重定向域名，用户此时使用不同的域名去访问，云原生网关通过 HOST 来做流量区分，动态染色 HTTP 请求。

图4-11 通过域名特征全链路灰度

配置方法

在云原生网关上创建两条路由规则：

• qcbm-front-router-web，HOST 为gray.web.yunnative.com，路由到 Dubbo-Gateway 服务。
• qcbm-front-router-mobile，HOST 为 gray.mobile.yunnative.com，路由到 Dubbo-Gateway 服务，开启染色（gray:true）。

和场景1类似，qcbm-front-router-mobile 路由规则的请求到达 Dubbo-Gateway 后，一旦访问收藏服务（FavoriteService），gray:true 染色标签会命中北极星网格灰度路由，调用 remote.application 为 favorites-service-new 的实例分组；而 qcbm-front-router-web 路由规则的请求会命中无染色标签的网格基线路由，调用 remote.application 为 favorites-service 的实例分组，访问基线环境。

结果验证

• 浏览器访问gray.mobile.yunnative.com时，染色标签会被打上，此时访问链路如下：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service-New](灰度)

页面显示如下：

图4-12 灰度请求页面

同时，也可以通过链路监控观察到，gateway-service（基线服务）正确的请求到 favorite-service-new（灰度服务），同时 favorite-service-new 正确请求到 store-service（基线服务）：

图4-13 灰度请求链路详情

• 当访问gray.web.yunnative.com时，无染色标签，此时我们的链路如下：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service](基线)

页面显示如下：

图4-14 灰度请求页面

通过链路监控，可以观察到，gateway-service（基线服务）正确的请求到 favorite-service（基线服务），同时 favorite-service 正确请求到 store-service（基线服务）：

图4-15 基线请求链路详情

3

灰度服务故障转移

场景说明

在灰度发布过程中，可以通过监测系统性能和用户反馈来评估新功能的质量。如果新功能在测试期间表现良好，可以继续将其推向更多用户，替换原版本应用。如果出现任何问题，可以对灰度服务进行访问熔断处理，及时修复问题，然后继续灰度测试。

图4-16 灰度服务故障转移

配置方法

在北极星网格上配置熔断规则，配合多实例分组路由规则，实现灰度服务故障 Failover。在全链路灰度场景基础上，在北极星网格控制台加上一条熔断规则。

• 当 delUserFavoriteBook 接口错误率大于10%，阈值大于10个，熔断 Favorite-Service-New 灰度服务实例分组，同一 Deployment 里的所有 Pod 进入半开状态。
• 半开时间60秒，期间一旦请求成功则认为服务恢复，关闭熔断。

图4-17 灰度服务熔断规则

接下来，在网格灰度路由中，添加低优先级实例分组，该分组为基线实例。一旦灰度实例分组被熔断，请求会去访问基线实例分组，直到灰度服务修复，熔断关闭。

图4-18 灰度服务路由规则

结果验证

部署一个新的“故障“收藏服务，Dubbo 程序延用 application=favorites-service-new 标签（为区分应用，这里故障灰度服务命名为 Favorites-Service-New-Bad），保证原路由规则可用。该“故障”程序修改了收藏服务的 delUserFavoriteBook 接口代码，当访问时直接抛出异常，模拟服务故障。代码如下所示：

public Response<String> delUserFavoriteBook(Long userId, Long isbn) {        String hostAddress;        try {            hostAddress = InetAddress.getLocalHost().getHostAddress();        } catch (Exception e) {            hostAddress = "ip获取失败";        }        throw new RuntimeException("删除收藏-故障 ip:" + hostAddress);}

浏览器访问 gray.mobile.yunnative.com 时，此时访问链路如下：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service-New-Bad](故障灰度)

页面显示如下：

图4-19 灰度请求页面

进入收藏页面，点击【删除】，程序报错，显示调用异常。

图4-20 灰度服务删除报错

通过链路追踪，也可以查看到服务异常。

图4-21 应用调用拓扑

图4-22 灰度服务删除链路错误

当故障错误大于10次，favorite-service-new 灰度实例分组被熔断，灰度路由进行低优先级目标选择，流量回源至基线实例分组favorite-service，此时测试删除功能正常，因为此时我们的访问链路重新变为：

[云原生网关] --> [Dubbo-Gateway] --> [Favorite-Service](基线正常)

页面显示如下，服务调用已回源：

图4-22 灰度请求页面（已回源）

总结

在灰度发布实施前，需要按照如下三方面，对整体流程进行计划：

• 目标：在开始灰度发布之前，需要了解发布的目标是什么，比如说是测试新版本的性能，还是功能兼容性等，以便在灰度时进行对应的测试和观测。
• 灰度策略：有很多种灰度策略可供选择，例如按用户特征来灰度、按流量来灰度、按地域来灰度等。通过系统用户的特点，选择最合适的灰度策略。
• 灰度范围：在灰度发布过程中，应当能随时控制哪些用户可以访问新版本，当出现问题时，能将请求快速回滚到旧版本上。

灰度发布过程中，确认流量是否已经按计划切换到灰度实例分组，通过监控和日志，检查各服务是否正常运行，是否符合预期。

确定本次发布成功后，可以依次对老版本分组的实例进行滚动升级，多次升级完成灰度发布，一旦出现错误执行回退，有序控制发布节奏。最后，根据实际应用情况，删除或保留网关和治理中心的动态路由规则。

腾讯云TSE提供了完整的全链路灰度发布解决方案，适用各种发布流程，无需侵入代码，通过可视化配置灰度规则，有效地解决了微服务全链路灰度发布难实现的问题，让灰度发布更便捷、更顺利。

往期

推荐

《腾讯云基于 Apache Pulsar 跨地域复制功能实现租户跨集群迁移》

《云原生消息流系统 Apache Pulsar 在腾讯云的大规模生产实践》

《迎接2023 | 北极星开源一周年，感恩礼倾情相送》

《轻量级SaaS化应用数据链路构建方案的技术探索及落地实践》

《Apache Pulsar 技术系列 – 基于不同部署策略和配置策略的容灾保障》

《微服务架构下路由、多活、灰度、限流的探索与挑战》

《TSF微服务治理实战系列（四）——服务安全》

《高并发场景下如何保证系统稳定性》

《微服务上云快速入门指引》

《Apache Pulsar 在微信大流量实时推荐场景下的实践》

《好未来基于北极星的注册中心最佳实践》

《百万级 Topic，Apache Pulsar 在腾讯云的稳定性优化实践》

《预告|ArchSummit 全球架构师峰会杭州站即将盛大开幕》

《千亿级、大规模：腾讯超大 Apache Pulsar 集群性能调优实践》

《云原生时代的Java应用优化实践》

《SpringBoot应用优雅接入北极星PolarisMesh》

扫描下方二维码关注本公众号，

了解更多微服务、消息队列的相关信息！

解锁超多鹅厂周边！

戳原文，查看更多微服务引擎 TSE 的

信息！

点个在看你最好看