一、 业务灰度发布概述

1.1 灰度发布的定义和分类

• 灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段。
• 应用服务网格基于 Istio 提供的服务治理能力，对服务提供多版本支持和灵活的流量策略，从而支持多种灰度发布场景。

1.1.2 金丝雀发布（灰度发布）

• 在生产环境上引一部分实际流量对一个新版本进行测试，测试新版本的性能和表现，在保证系统整体稳定运行的前提下，尽早发现新版本在实际环境上的问题。
• 通过在线上运行的服务中，新加入少量的新版本的服务，然后从这少量的新版本中快速获得反馈，根据反馈决定最后的交付形态。

基于权重的灰度发布

可以根据需要灵活动态的调整不同服务版本的流量比例。

基于内容的灰度发布

可以根据请求的内容控制其流向的服务版本（Cookie，Header，OS，Browser）。

1.1.3 蓝绿发布

• 蓝绿发布提供了一种零宕机的部署方式。不停老版本，部署新版本进行测试，确认没问题，将流量切换到新版本，然后老版本同时也升级到新版本，始终有两个版本同时在线，有问题可以快速切换。
• 在部署应用的过程中，应用始终在线。并且新版本上线过程中，不会修改老版本的任何内容，在部署期间老版本状态不受影响。只要老版本的资源不被删除，可以在任何时间回滚到老版本。

可以根据需要将全部流量在新旧版本之间进行切换。不同于灰度发布的任意切换流量比例，蓝绿发布的流量切换只能是 0 或者 100% 进行全量的切换，这样可以在其中一个版本出现问题的时候迅速切换到另外的版本。

将流量全部流向 Service B 的 v2 版本：

将流量全部流向 Service B 的 v1 版本：

1.2 灰度发布的流程

首先添加灰度版本，然后确认灰度版本正常上线可以接受流量，再配置灰度策略，最后观察灰度版本工作是否正常，是不是符合预期。如果一切正常，且灰度版本验证通过，就可以将灰度本提升为默认流量版本，再把原版本下线。如果灰度版本不正常，直接将灰度版本下线，而不会影响业务处理。

灰度发布全流程自动化管理：

• 灰度版本一键部署，流量切换一键生效。
• 配置式灰度策略，支持流量比例、请求内容（Cookie、OS、浏览器等）、源 IP。
• 一站式健康、性能、流量监控、实现灰度发布过程量化、智能化、可视化。

二、 ASM 灰度发布功能与使用场景介绍

2.1 灰度发布功能-基于内容的灰度发布

可根据请求的内容控制其流向的服务版本（Cookie，Header，OS，Browser）

2.1.1 界面操作

步骤1. 发起金丝雀灰度发布任务，选择一个服务进行灰度发布，选择一个灰度服务，再填入版本号。

步骤2. 给选定服务创建灰度版。选择镜像以及镜像对应的版本。

步骤3. 提交并等待灰度版本正常启动。当版本正常启动后，就可以进行下一步的配置。

步骤4.  在实例正常启动后，可以给灰度版本配置流量规则，分配流量。在这里选择基于内容的策略类型，然后可以配置 Cookie 内容、自定义 Header、允许访问的操作系统、允许访问的浏览器。

步骤5. 经过一段时间的运行，确认灰度版本正常运行，满足业务需求，则可以切换全部流量到灰度版本，原来版本下线。

2.1.2 后台操作

首先部署了一个 v2 版本，一个 k8s 的 Deployment，在 labels 中定义了 app 是 forecast、version 是 v2，其中倒数第四行可以看到镜像的版本是 v2，最后一行配置了容器的端口号是 3002，这部分配置中最重要的是 labels 中的 version 是 v2，使用它来区分服务不同的版本。

上面稍微了解了 Deployment 和 Destination Rule，发布策略其实是定义在 Virtual Service中的。

对于一个 http 请求，如果 Header 中 User-Agent 是 Chrome 的请求，就会被路由到 subset v2，也就是上面的 v2 版本。如果 User-Agent 不是 Chrome 的请求，就会被路由到 subset v1 也就是 v1 版本。

结合上述的 Deployment、Destination Rule 和Virtual Service 就完成了基于内容的灰度发布。

2.2 灰度发布功能-基于权重的灰度发布

可以根据需要灵活动态的调整不同服务版本的流量比例。

2.2.1 界面操作

步骤1. 发起金丝雀灰度任务，选择一个服务进行灰度发布。

步骤 2. 给选定服务创建灰度版本。

步骤 3. 提交并等待灰度版本正常启动。

步骤 4. 在实例正常启动后，可以给灰度版本配置流量规则，分配流量。例如，基于流量的比例，40% 的流量访问 v2 版本，60% 的流量仍然访问 v1 版本。

步骤 5. 经过一段时间的运行，确认灰度版本运行正常，满足业务需求，则可以切换全部流量到灰度版本，原来版本下线。

2.2.2 后台操作

关于 Deployment 和 Destination Rule 的配置和上面基于内容的灰度发布一致，主要区别是在 Virtual Service 上面。

这里没有 header 匹配的相关配置，而从 gateway 中进入的流量直接按照 destination 中 weight 的配置比例访问不同的版本，60% 访问 v1，40% 访问 v2。

2.3 灰度发布功能-蓝绿发布

可以根据需要将全部流量在新旧版本之间切换。

2.3.1 界面操作

步骤 1. 发起蓝绿发布任务，选择一个服务进行蓝绿发布。

步骤 2. 给选定服务创建灰度版本。

步骤 3. 提交并等待灰度版本正常启动，在实例正常启动后，切换全量流量到灰度版本。

步骤 4. 如果发现灰度版本有问题，也可以一键迁移回原版本，从而完成安全快速热回退。

2.3.2 后台操作

关于 Deployment 和 Destination Rule 的配置也和上面基于内容的灰度发布一致，主要区别也是在 Virtual Service 上面。

这里和基于权重发布的区别在于，v2 版本的权重是 100，也就是全部流量都进入 v2。

三、实验：基于 ASM 实现 web app 版本的灰度发布

3.1 实现程序功能简介

这款天气查询服务总共分为 4 个模块：

• frontend：前台服务，展示整个应用的页面，使用js 开发而成。
• advertisement：广告服务，返回静态的广告图片，使用 Golang 开发而成。
• forecast：天气预报服务，返回相应城市的天气数据，使用js 开发而成。
• recommendation：推荐服务，根据天气情况向用户推荐穿衣和运动等信息，使用 java 开发而成。

上图右侧为该服务的应用系统拓扑图。其中需要大家注意的时候，只有 v2 版本才会调用 recommendation 服务，而 v1 版本不会调用该服务。后面实验的时候可以看到调用不同版本的效果。

3.2 实验程序版本介绍

frontend 服务有两个版本：

• v1 版本的界面按钮为绿色。

• v2 版本的界面按钮为蓝色。

forecast 服务有两个版本：

• v1 版本直接返回天气信息。

• v2 版本会根据 recommendation 服务，获取推荐信息，并结合天气信息一起返回数据。

3.3 实验介绍

实验目的：

• 能够对灰度发布的流程有一定的认识和了解。
• 能够理解灰度发布的类型，配置简单的灰度策略。
• 能够掌握检查灰度策略是否生效的方法，包括界面和后台命令。

实验前置条件：

• 在 Kubernetes 集群上启用 Istio 服务网格。
• 在集群上部署好天气预报应用的四个服务的 v1 版本，可实现服务间的访问互通。

实验关键步骤：

1. 观察当前的服务调用关系，服务拓扑图和应用 UI。
2. 对 forecast 服务进行基于权重/内容的灰度发布，权重/策略可任意调整，并观察服务的调用关系。

常用命令：

kubectl get vs -n <namespace-name>     # 查看 virtual service
kubectl get dr -n <namespace-name>     # 查看 destination service 

如果想了解更多实验信息，请访问该课程华为云云原生黄金课程10：Istio灰度发布管理查看详细信息。

四、总结

应用服务网格（Application Service Mesh，简称ASM）是华为云基于开源Istio推出的服务网格平台，它深度、无缝对接了华为云的企业级 Kubernetes 集群服务 CCE，可为客户提供开箱即用的上手体验。无需复杂的后台配置（手写 yaml 文件），只需要通过界面简单的操作就可以实现丰富的灰度发布功能。

本文整理自华为云社区【内容共创】活动第13期。
https://bbs.huaweicloud.com/blogs/330939
任务16. 华为云云原生黄金课程10：Istio灰度发布管理

_­­