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

https://my.oschina.net/u/4587289/blog/8570699

　　

1.  概述

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

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

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

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

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

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

图 1-2 云书城前端页面

2.  环境

2.1 云组件版本

本次实践采用如下组件：

● TSE - 云原生网关：v2.5.1

● TSE - 北极星网格： v1.12.0.1

● TKE：v1.20

● APM-SkyWalking: v8.5.0

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

2.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 灰度版本收藏服务

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;

2.4 容器服务部署

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

● 基线版本收藏服务 YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: favorites-service
  namespace: qcbm
  labels:
    app: favorites-service
    version: v1
spec:
  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/v1
kind: Deployment
metadata:
  name: favorites-service-new
  namespace: qcbm
  labels:
    app: favorites-service-new
    version: v1
spec:
  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: v1
kind: Service
metadata:
  name: qcbm-front
  namespace: qcbm
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: qcbm-front
    version: v1
  type: NodePort

2.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

2.6 链路追踪接入

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

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

collector.backend_service=x.x.x.x:11800
agent.authentication=xxxxxx
agent.service_name=favorites-service-new
agent.namespace=QCBM

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

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

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

图 2-6 应用拓扑图

3.  解决方案

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

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

3.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;
    }

3.2 网关路由

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

● 通过匹配用户请求的 Header 参数，进行流量区分。

● 通过匹配用户请求的 Host 特征，进行流量区分。

● 通过流量百分比进行区分，使用云原生网关能力，将其中一部分流量进行染色处理。

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

图 3-4 网关路由示意图

3.3 微服务路由

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

图 3-5 动态路由示意图

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

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

4.  场景

4.1 通过 Header 特征全链路灰度

1）场景说明

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

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

2）配置方法

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

● 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 基线服务路由

3）结果验证

我们借用 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 基线请求链路详情

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

4.2 通过域名特征全链路灰度

1）场景说明

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

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

2）配置方法

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

● 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 的实例分组，访问基线环境。

3）结果验证

● 浏览器访问 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 基线请求链路详情

4.3 灰度服务故障转移

1）场景说明

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

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

2）配置方法

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

● 当 delUserFavoriteBook 接口错误率大于 10%，阈值大于 10 个，熔断 Favorite-Service-New 灰度服务实例分组，同一 Deployment 里的所有 Pod 进入半开状态。

● 半开时间 60 秒，期间一旦请求成功则认为服务恢复，关闭熔断。

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

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

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

3）结果验证

部署一个新的 “故障 “收藏服务，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 灰度请求页面（已回源）

5.  总结

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

● 目标：在开始灰度发布之前，需要了解发布的目标是什么，比如说是测试新版本的性能，还是功能兼容性等，以便在灰度时进行对应的测试和观测。

● 灰度策略：有很多种灰度策略可供选择，例如按用户特征来灰度、按流量来灰度、按地域来灰度等。通过系统用户的特点，选择最合适的灰度策略。

● 灰度范围：在灰度发布过程中，应当能随时控制哪些用户可以访问新版本，当出现问题时，能将请求快速回滚到旧版本上。

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

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

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