灰度发布:揭秘背后的原理与实践浅见

简介: 揭秘灰度发布背后的原理与实践浅见

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

image.gif 编辑

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

一、技术上的

(一)网关的全链路灰度

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

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

(二)配置中心

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

1、nacos:

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

image.gif 编辑

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右上角的创建灰度按钮。

image.gif 编辑

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

image.gif 编辑

2.2 灰度配置

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

image.gif 编辑

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

image.gif 编辑

image.gif 编辑

2.3 配置灰度规则

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

image.gif 编辑

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

image.gif 编辑

image.gif 编辑

image.gif 编辑

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

image.gif 编辑

image.gif 编辑

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

2.4 灰度发布

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

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

image.gif 编辑

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

image.gif 编辑

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

image.gif 编辑

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

image.gif 编辑

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

2.5 全量发布

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

全量发布的效果是:

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

image.gif 编辑

image.gif 编辑

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

image.gif 编辑

2.6 放弃灰度

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

image.gif 编辑

2.7 发布历史

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

image.gif 编辑

image.gif 编辑

原文: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"开关"启用",配置内容便即刻生效了
  • 产品经理通过查看实验分组和埋点点击数据得出结论:支付按钮为绿色购买率会更高。于是全量用户开放为绿色。

(五)白名单

其他还有的场景是使用白名单功能,觉得可以使用组件的人群组功能实现,步骤如下:

1、在平台创建人群组

  1. 进入平台点击人群组/+人群组新建一个新的人群

image.gif 编辑

填入名称和标识,点击布 创建并发

image.gif 编辑

从列表中点击新创建的人群组,进入编辑

image.gif 编辑

添加一个规则,选择类型,输入属性email,

  • 选择string类型
  • 规则是其中之一
  • 然后输入两个测试人员email
  • 点击发布

image.gif 编辑

6. 此时还没有开关使用这个『用户组』,这里直接点击下一步,并且确认变更。

image.gif 编辑

2、在开关中使用人群组

下面,我们来到开关列表,创建两个开关都使用以上创建的人群组qa_email

  1. 创建一个返回值为bool型的开关feature1,使用默认配置即可,然后点击创建并发布

image.gif 编辑

进入开关feature1的编辑页面,状态改为生效,点击+ 增加规则,选择人群组规则

image.gif 编辑

编辑规则

  • 选择属于人群组
  • 选择测试人员email人群组
  • 为人群组设置返回值variation2
  • 其余返回规则设置返回值variation1

image.gif 编辑

发布开关feature1,重复以上步骤1-4,创建另一个使用相同人群组的开关feature2,以上所有功能均有对于的代码客户端实现

以上就是我在生产上实践过和认识到的灰度发布的一些认识,希望对大家有用。

目录
相关文章
|
测试技术 uml
UML之用例图
UML之用例图
701 1
|
SQL 存储 数据库
SQL实践篇(二):为什么微信用SQLite存储聊天记录
SQL实践篇(二):为什么微信用SQLite存储聊天记录
1248 1
|
10月前
|
Java 测试技术 API
从一起知名线上故障,谈配置灰度发布的重要性
一起知名线上故障:一个新功能在没有经过充分测试和灰度发布的情况下被直接部署到生产环境,并且处理推送关键配置没有灰度过程。导致全球大规模服务中断约7小时。故障由空指针异常引发,暴露了错误处理不足和灰度机制缺失等问题。配置灰度发布,如Nacos支持的IP或标签灰度,可有效降低风险,提升系统稳定性。
|
负载均衡 Java 测试技术
面试官:说说微服务灰度发布的底层实现?
面试官:说说微服务灰度发布的底层实现?
620 1
面试官:说说微服务灰度发布的底层实现?
|
存储 前端开发 测试技术
前后端分离后灰度发布实现方式
前后端分离后灰度发布实现方式
613 3
|
知识图谱
YOLOv11改进策略【Conv和Transformer】| 2023 引入CloFormer中的Clo block 双分支结构,融合高频低频信息(二次创新C2PSA)
YOLOv11改进策略【Conv和Transformer】| 2023 引入CloFormer中的Clo block 双分支结构,融合高频低频信息(二次创新C2PSA)
412 8
YOLOv11改进策略【Conv和Transformer】| 2023 引入CloFormer中的Clo block 双分支结构,融合高频低频信息(二次创新C2PSA)
|
存储 关系型数据库 MySQL
基于Seata实现分布式事务
通过以上步骤,你可以使用 Seata 实现分布式事务,确保在微服务架构中的事务一致性。Seata 支持多种语言和框架,能够满足不同业务场景的需求。欢迎关注威哥爱编程,一起学习成长。
599 1
|
存储 负载均衡 NoSQL
一文让你搞懂 zookeeper
一文让你搞懂 zookeeper
20033 16
|
Kubernetes Cloud Native Dubbo
全链路灰度的挑战、实现思路与解决方案
全链路灰度的挑战、实现思路与解决方案
1592 114
|
机器学习/深度学习 PyTorch TensorFlow
Pytorch 与 Tensorflow:深度学习的主要区别(1)
Pytorch 与 Tensorflow:深度学习的主要区别(1)