灰度发布浅见

在之前的稳定性生产文章中有一项对于研发人员比较重要的措施是变更管控，关于变更管控其实在实际生产活动中有很多措施，因为对于不太的行业，其行业特点和稳定性生产的要求也不一样，例如下图，我们可以看到信通院调研的不同行业的特点区别确实是很不同的，如果拿着互联网的经验去能源、证券这类监管和稳定性要求特别高的行业来实施，那可能要经常面临罚款甚至停业整顿的处罚。但是我自己的经验只是在互联网比较多，所以本次只能介绍一点在互联网变更管控中降影响和降发生的一个措施：灰度发布。

本次我来回顾下在实际工作中用到的两种灰度发布工具：分别是技术上的配置中心和业务上的ab测试工具。

一、技术上的

（一）网关的全链路灰度

现在已经知道的是阿里云MSE实现全链路灰度和腾讯云的TSE可以为多应用发布提供全链路灰度能力，让在不修改业务代码的情况下实现全链路流量控制，端到端构建从网关到多个后端服务的全链路灰度。在多应用同时发布新版本的情况下，支持多个应用进行灰度验证，确保应用平滑发布上线。

但是我还没在生产环境使用过，大家感兴趣的可以在官网试用下：MSE实现全链路灰度 (aliyun.com)、微服务平台 TSF 灰度发布-操作指南-文档中心-腾讯云 (tencent.com)

（二）配置中心

在实际工作中我在技术上主要是通过apollo和nacos的灰度发布功能。

1、nacos：

这个主要是在配置中心使用了开关或者业务功能的其他一些标志，借用配置中心可以感知nacos客户端的ip地址来进行灰度的，官网在此处标记了使用方法：FAQ (nacos.io)

2、apollo：

使用方法如下：100004458(apollo-demo)项目有两个客户端：

10.32.21.19
10.32.21.22

灰度目标：

当前有一个配置timeout=2000，我们希望对10.32.21.22灰度发布timeout=3000，对10.32.21.19仍然是timeout=2000。

2.1 创建灰度

首先点击application namespace右上角的创建灰度按钮。

点击确定后，灰度版本就创建成功了，页面会自动切换到灰度版本Tab。

2.2 灰度配置

点击主版本的配置中，timeout配置最右侧的对此配置灰度按钮

在弹出框中填入要灰度的值：3000，点击提交。

2.3 配置灰度规则

切换到灰度规则Tab，点击新增规则按钮

在弹出框中灰度的IP下拉框会默认展示当前使用配置的机器列表，选择我们要灰度的IP，点击完成。

如果下拉框中没找到需要的IP，说明机器还没从Apollo取过配置，可以点击手动输入IP来输入，输入完后点击添加按钮

注：对于公共Namespace的灰度规则，需要先指定要灰度的appId，然后再选择IP。

2.4 灰度发布

配置规则已经生效，不过灰度配置还没有发布。切换到配置Tab。

再次检查灰度的配置部分，如果没有问题，点击灰度发布。

在弹出框中可以看到主版本的值是2000，灰度版本即将发布的值是3000。填入其它信息后，点击发布。

发布后，切换到灰度实例列表Tab，就能看到10.32.21.22已经使用了灰度发布的值。

切换到主版本的实例列表，会看到主版本配置只有10.32.21.19在使用了。

后面可以继续配置的修改或规则的更改。配置的修改需要点击灰度发布后才会生效，规则的修改在规则点击完成后就会实时生效。

2.5 全量发布

如果灰度的配置测试下来比较理想，符合预期，那么就可以操作全量发布。

全量发布的效果是：

灰度版本的配置会合并回主版本，在这个例子中，就是主版本的timeout会被更新成3000
主版本的配置会自动进行一次发布
在全量发布页面，可以选择是否保留当前灰度版本，默认为不保留。

我选择了不保留灰度版本，所以发布完的效果就是主版本的配置更新、灰度版本删除。点击主版本的实例列表，可以看到10.32.21.22和10.32.21.19都使用了主版本最新的配置。

2.6 放弃灰度

如果灰度版本不理想或者不需要了，可以点击放弃灰度。

2.7 发布历史

点击主版本的发布历史按钮，可以看到当前namespace的主版本以及灰度版本的发布历史。

原文：Apollo使用指南 - 五、灰度发布使用指南 - 《携程 Apollo v1.4 开发指南》 - 书栈网 · BookStack（这个网站是一个好网站啊）

二、业务上的

在实际工作中我在技术上主要是通过ab测试的工具实现灰度功能，但是ab组件我还没开发过，这里主要是介绍一个开源的组件，和之前的使用过的类似的一个组件：FeatureProbe，官网地址：适用场景 | FeatureProbe,它的使用场景主要有：

（一）功能灰度放量给用户

FeatureProbe 最常见的应用场景是管理新功能的发布。当我们发布一个新功能或上线一个新运营活动时，可以先为一小部分用户启用这些功能，而不影响大多数用户，确保降低发布的风险。如果这些用户在使用中没有问题，我们就可以向更多的用户开放新版本，重复这个过程，直到所有的用户都更新到最新版本。

使用案例

新上线的功能，首先开放给 10% 的用户，如果没有问题，在逐步放量到 50%， 100% 的用户

操作流程
- 运营人员在 FeatureProbe 上创建一个名叫"Promotional Percentage Rollout"的开关，初始化放量 10%:
- 开发人员在代码中引用 FeatureProbe 的 sdk 访问这个活动开关，并拿到相应展示内容展示给用户。
- 在确认10%放量没有问题之后，运营人员直接把灰度比例逐步调大，直到放量给所有用户。

（二）配置在线促销活动

许多公司定期开展促销活动。这些活动在大多数情况下使用类似的模板，通过使用 FeatureProbe 实现模板化配置，运营团队只需要修改几个参数就可以创建一个新的促销活动。

使用案例

运营人员想推出商品秒杀活动，需要根据不同城市设置不同的商品价格，以往都是需要通过开发在代码中写好，一旦价格需要变动，开发人员要在代码中修改线上商品价格，在经过审核部署发布等一些列操作，才能生效，使用 FeatureProbe 的功能开关，只需要运营人员修改一下“价格”，便可一秒发布生效。

操作流程
- 运营人员在 FeatureProbe 上创建一个名叫"Promotional Campaign"的开关，配置不同价格规则和城市生效策略:
- 开发人员在代码中引用 FeatureProbe 的 sdk 访问这个活动开关，并拿到相应展示内容展示给用户。
- 在测试上线之后，运营人员直接把"Promotional Campaign"开关"启用"，配置内容便即刻生效了
- 价格需要变动的情况下，运营人员只需要直接修改 variations 中的价格，并分发给对应的人群即可

（三）执行降级预案

通常我们可以将提供给用户的服务划分为核心服务链路和非核心链路，当非核心链路上的服务出现异常时，我们可以通过关闭非核心服务来保障核心服务正常，也就是常说的服务降级。

使用案例

某电商APP在用户搜索商品时提供了一个高级排序推荐的功能。由于高级排序推荐消耗计算资源较高，在用户高峰访问时段经常访问超时。通过FeatureProbe配置开关，可以在高峰时段关闭高级推荐，退回到简单排序功能从而保障用户体验。

操作流程
- 开发人员环境下创建一个名叫"Service Degrade"的开关，开关配置如下图所示:
- 开发人员在代码中关联开关的 key（service_degrade），设置 boolean 类型的 variations（是否打开降级）
- 当依赖的库存服务发生故障后，可以将策略改为『关闭』，从而快速进行降级。

（四）A/B 实验

我们经常会遇到多个产品方案听起来都有道理，不知道选哪个好的情况。这种情况下，可以先在小量人群上尝试多个方案，通过数据比较，找出最理想/最受欢迎的方案，再投放的全量人群，从而获得最好的投放效果。

使用案例

某APP的支付按钮的颜色想由红色改为了绿色，于是使用 FeatureProbe 的功能开关，针对这两种颜色对巴黎的用户做个实验，看到底哪个颜色点击率更高

操作流程
- 产品经理创建一个名叫"Button Color AB Test"的开关，开关配置如下图所示:
- 开发人员在代码中关联开关的 key（color_ab_test），设置 string 类型的 variations（颜色分类）对应好定义的参数 city。
- 在一切准备就绪后，产品经理直接把"Button Color AB Test"开关"启用"，配置内容便即刻生效了
- 产品经理通过查看实验分组和埋点点击数据得出结论：支付按钮为绿色购买率会更高。于是全量用户开放为绿色。