自从用了灰度发布，睡觉真香！

Posted 2022-11-29 Java技术栈

前言

大家好，我是栈长。

最近，栈长又参加了腾讯云小伙伴邀请的Techo Day 技术开放日 2.0的线上活动，这一期又是干货满满，主要是云原生和微服务方面的，比如：云原生网关、容器、安全、云监控、灰度发布等等，这些内容都与我们现有的微服务系统息息相关。

令栈长印象最深刻的就是微服务灰度发布这个主题，腾讯开源的北极星让我大开眼界，不仅涵盖微服务多个解决方案，还包括市面上少有的、开源的一站式灰度发布解决方案。

看到这，大家心里可能会有以下问题：

• 啥是灰度发布，对咱们业务能带来什么好处？
• 我知道灰度发布，但是灰度发布实现方式那么多，我该怎么选？
• 北极星是啥，和我现在使用的灰度发布框架有啥区别呢？

针对大家这些问题，所以我想有必要给大家做个专题分享，包括灰度发布的基本认识、分类，特别是腾讯开源的北极星项目，看它是如何轻松解决灰度发布的。

什么是灰度发布？

说到灰度发布就不得不提 "全量发布" ，全量发布就是所有系统都同时上线新版本，即对所有用户都同时使用新版本，这会带来什么问题？

全量发布的种种弊端：

• 影响用户体验： 比如某系统在双 11 前上线了一个新功能，需要给符合条件的用户发放优惠券，结果程序出 bug 导致给所有用户都发放了……又或者是新版本系统出现问题，从而影响所有用户……
• 系统异常扩散风险： 比较某系统上线后不久出现了一个内存溢出的异常，流量接而转移到了系统其他实例，从而导致该系统所有实例都内存溢出，所有实例都处于不可用状态……
• 影响服务可用性： 全量发布一般都需要全部停机升级，从而保证要么是新版本，要么是老版本，这显然会导致业务中断，也影响了服务可用性（SLA），就是我们经常看到互联网公司喊口号，我们今年一定要做到 3 个 9、4 个 9，即 99.9%、99.99% 等等，SLA 就是衡量系统服务可用性的一个保证，9 越多代表全年服务可用时间越长服务更可靠，停机时间越短，反之亦然。
• ……

知道了全量发布的种种弊端，就不得不提灰度发布的重要性了，这里引出灰度发布的定义：

灰度发布是针对 "全量发布" 的改进，即按照一定的策略上线部分新版本，同时保留老版本，然后让部分用户体验新版本，通过一段时间新版本的反馈收集，比如：功能、性能、稳定性等指标，然后再决定是否逐步升级直至全量升级或全部回滚到老版本。

灰度发布的好处：

• 降低发布影响面： 就算出问题，也只会影响部分用户，从而可以提前发现出新版本中的问题/ bug，然后在下一次灰度发布前提前修复，避免影响更多用户；
• 提升用户体验： 除了能提前发现 bug，还能很好的收集新版本中的使用反馈，从而提前优化系统，提升用户体验，也能给后续的产品演进带来参考价值。

灰度发布分类

灰度发布的主要分类：

• 金丝雀发布
• 滚动发布
• 蓝绿发布

相信大家都或多或少都听过这些术语的概念，但很多人并不清楚原理及背后的发布流程，下面栈长画了几张图，让大家对这些灰度发布可以有更深刻的认识。

1）金丝雀发布

据说以前有个典故，矿工开矿前，会先放一只金丝雀下去，看金丝雀是否能活下来，用来探测是否有毒气，金丝雀发布也是由此得名。

这个典故用在金丝雀发布上面也是同样一个道理，即先升级服务一个实例，如果该实例没有问题，再全部升级剩余实例，如果有问题，再进行回滚。

金丝雀发布成本较低，只需要一个实例即可降低新版本存在的风险，适合缺乏足够的发布工具研发能力及成长型的小公司。但是，金丝雀发布也有缺点，当升级全部剩余实例时，如果流量过多，可能会导致服务中断。

2）滚动发布

滚动发布则是在金丝雀发布的基础上进行的改进和优化，第一次也是使用金丝雀发布，后续则使用多批次的形式发布剩余实例，每次批次之间会进行观察，如果有问题，再进行回滚。

滚动发布会比较平滑，可以将风险控制到最小程度。它虽然改进了金丝雀发布，但整体发布时间会比较长，回退时间也会更慢，整体流程也更为复杂，适合有一定发布工具研发能力的大公司。

3）蓝绿发布

蓝绿发布比较简单，只是对全量发布的一种优化而已，发布前不用全部停机，而是另外部署新版本全部实例，然后再把流量全部再切换到新版本。

蓝绿发布虽然提升了服务可用性，但没有解决新版本中可能出现的问题，所以核心业务肯定是不建议用的，建议使用滚动发布结合金丝雀发布一起使用，从而降低发布风险。

4）如何选型

上面介绍了 3 种灰度发布模式，那么企业应该怎么去根据自身的业务场景的诉求，去选型使用哪种模式来进行灰度发布呢？下面对各种发布模式做了一个对比，以及列举出常见的选型指引，供大家参考。

策略	零停机	生产流量测试	针对特定用户	机器资源成本	回滚时长	负面影响	实现复杂度
全量发布	×	×	×	低	慢	高	低
蓝绿发布	√	×	×	高（双倍）	快	中	中
金丝雀发布	√	√	√	中（按需）	快	低	中
全链路灰度	√	√	√	中（按需）	快	低	高

全量发布：不建议使用，除非实在没有办法，比如初创公司什么都缺，老板又催。

蓝绿发布：适合于对于资源预算比较充足的业务，或者是比较简单的单体应用，可以快速实现系统的整体变更，适合传统企业使用。

金丝雀和全链路灰度：适合需要针对特定用户或者人群进行现网请求验证的业务，可以显著减低风险，建议成长型企业使用。

业界灰度发布的实现方案

Nacos/ZK + Spring Cloud/dubbo

Nacos 和 ZK 等组件提供的是纯注册中心的功能，不包括灰度发布的能力。用户如果需要实现灰度发布，则需要在框架层通过编码的方式进行扩展，比如实现 Spring Cloud Gateway/Dubbo 的插件等，带来的问题主要有 2 个：

• 不同的业务需要重复造轮子，带来不必要的工作量和质量风险
• 不同框架实现方式和规则不一样，存在互通性的问题。

istio

Istio 通过服务网格的方式提供了灰度发布能力，用户无需自己实现灰度发布逻辑，但是也存在以下问题：

• istio 的数据面不支持 Spring Cloud/Dubbo 等常用的微服务框架接入。
• istio + envoy 的 Proxy 模式，运行时会带来额外的资源和网络开销。

腾讯云实现方案（北极星）

基本介绍

先简单介绍下腾讯云引擎（TSE）：

微服务引擎（Tencent Cloud Service Engine）提供开箱即用的云上全场景微服务解决方案。支持开源增强的云原生注册配置中心（Zookeeper、Nacos、Etcd、Consul、Eureka 和Apollo），服务治理中心（腾讯自研并开源的 PolarisMesh）、云原生网关（nginx Ingress、Kong）以及微服务应用托管的弹性微服务平台。微服务引擎完全兼容开源版本的使用方式，在功能、可用性和可运维性等多个方面进行增强，助力用户快速构建微服务架构。

北极星（PolarisMesh）是腾讯开源的服务发现和治理中心，以注册配置中心为基础，扩展了服务治理功能以及相应的控制面，各部分功能可单独使用，且支持无侵入的接入方案，用户无需改一行代码即可接入所有服务治理功能。

• 基础： 服务发现、服务注册、健康检查、配置管理；
• 扩展： 流量调度（动态路由、负载均衡）、熔断降级（实例、接口、服务三级熔断）、访问控制（限流、鉴权）、可观测（调用度量、链路跟踪）

可以看到，北极星不仅仅是注册中心、配置中心，还是微服务架构中的故障容错、流量控制和安全问题的综合解决方案。虽然业界已经有些组件可以解决其中一部分问题，但是缺少一个标准的、多语言的、框架无关的实现，北极星应运而生。

实现方案

通过北极星可以实现蓝绿、金丝雀或者滚动发布：

阶段一：实例打标

实例打标，指的是发布前先将实例打入新版本标签，这样才能将新版本与稳定旧版本的应用区分开来。

常用的实例打标方法有以下两种：

• 实例自注册： 标签配置在项目的配置文件中，一般是指 Spring Cloud 配置文件中，然后在应用时将标签自动注册到注册中心；

• k8s 部署标签同步： 把实例标签作为 k8s 的部署标签进行配置，然后随应用部署后自动同步到注册中心。

阶段二：网关路由

服务网关，就是服务的网关，它是所有服务的单一访问点，并充当微服务最上层的代理。

通俗地说，就是，外面的请求需要先经过服务网关，再到达微服务，服务网关实现统一接入，外面的请求不能直接访问微服务，一般的访问顺序是这样的：

用户 > Nginx（集群，Keepalive） > 服务网关（集群） > 微服务（集群）

所以，要进行灰度发布就必须在网关层进行路由控制，在网关层可以按照一定的策略把流量分配到不同的实例版本，常用的灰度策略有百分比、用户属性、省市区域等等，比如：可以先把广东省深圳市 30% 的用户路由到新版本。

一般的服务网关都需要自行配置路由规则，而且都是代码硬配置，配置项很多很复杂，不是专业的技术人员很难理解其配置的真正意义，也带来了出错的概率。

而在腾讯云北极星方案中，使用的是云原生网关，支持图形化的云原生路由规则配置，支持直通注册中心，直接将流量拆分到不同版本的实例中，大大简化了配置难度，也提高了配置项可读性和易用性。

阶段三：微服务路由

来看正常的一个路由流程图：

流量经过服务网关后，就需要路由到具体的微服务，而灰度发布后各个微服务存在 V1 旧版本和 V2 新版本，所以就需要保证路由过去的多个微服务调用链也必须是同一个版本，不然就可能会带来灾难性故障。

腾讯云北极星服务治理中心提供了自定义路由的能力，支持通过图形化配置规则的方式，支持自动托管，以及服务调用流量实时监控能力，准确掌握灰度发布的全流程，实现了微服务之间的灰度流量调度。

阶段四：标签透传

上一步，网关层会对灰度流量进行染色，在接下来的微服务调用过程中还需要进行标签透传，即将染色标签在每一个微服务之间进行传递，使得微服务可以识别到灰度流量并进行处理。

使用 Spring Cloud 微服务框架，需要用户自己在项目中进行编码实现，而腾讯北极星方案可以配合腾讯的 Spring Cloud Tencent 微服务框架自动完成标签透传，支持跨线程的透传模式，无需用户感知。

阶段五：灰度完成

1）灰度发布验证

灰度发布后，如何验证灰度发布已经完成/成功了呢？一般需要做以下确认操作：

1）确认流量是否按计划切换到了灰度发布实例；

2）确认灰度发布实例上的请求是否正常执行；

腾讯云北极星方案提供了服务治理监控能力，支持可视化看到流量实时切换情况，以及流量的成功率时延等关键指标，大大简化了灰度发布的事后验证工作。

2）灰度完成后的处理事项

根据不同的灰度发布形式处理：

金丝雀发布： 将稳定版本服务分组全量升级成新版本。

滚动灰度： 将稳定版本分组中的多个服务按一定比例分批升级成新版本。

蓝绿发布： 流量已经全量切换到新版本分组，老版本分组的实例可以下线。

北极星开源版体验

北极星（PolarisMesh）官方网址：

https://polarismesh.cn/

北极星（PolarisMesh）已经开源，点击主页右上角可以进入体验版：

根据提供的默认用户名和密码登录进去，可以在 "服务网格 > 动态路由 > 灰度发布" 找到灰度发布：

我们来体验一下金丝雀发布吧，操作流程如下：

第一步：实例打标

Spring Cloud Tencent 微服务集成北极星过程略，详细请参考下面接入文档：

https://polarismesh.cn/zh/doc/%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8/SpringCloud%E5%BA%94%E7%94%A8%E6%8E%A5%E5%85%A5.html#springcloud%E5%BA%94%E7%94%A8%E6%8E%A5%E5%85%A5

然后在 bootstrap.yml 配置文件中指定版本标签：

spring:
  cloud:
    tencent:
      metadata:
        content:
          version: 2.0.0

在服务实例所在的操作系统中添加环境变量也可进行打标，例如：SCT_METADATA_CONTENT_version=2.0.0 。

由于 Spring Cloud 框架默认不会对所有的请求标签进行透传，因此需要增加 Spring Cloud 透传标识，可以通过添加环境变量（SCT_PROTOCOL_CONTENT_TRANSITIVE_HEADER=gray）的方式进行灰度标识（gray:true）的透传。

第二步：部署应用

Spring Cloud Tencent 接入方式支持虚拟机、Docker Composer、K8S 等多种部署模式，注意需要保证业务进程与北极星服务的网络连通性。

部署后，可以在北极星服务列表中看到成功注册的服务实例：

第三步：微服务路由

通过配置微服务路由，使进行灰度版本的流量的调用，都只在新版本的服务分组中进行。

可以在 "服务网格 > 动态路由 > 自定义路由" 新建路由规则，先配置灰度规则：

该灰度规则只对 credit 服务生效，这样 header 中带有gray:true灰度标签的请求都只流向version=2.0.0的实例分组。

再来配置兜底规则：

该灰度规则只对 credit 服务生效，这样 header 中不带gray:true灰度标签的请求都只流向version=1.0.0的实例分组。

第四步：灰度发布观测

通过北极星的可观测性能力，可以准确看到不同分组的流量切换的过程，以及服务调用成功率，等到灰度分组相关指标没有问题，代表灰度验证完成。

观测路径：“可观测性 > 路由监控”

第五步：灰度发布收尾

灰度验证完成后，需要进行收尾：

• 灰度验证成功，则对老版本分组的实例进行滚动升级到新版本，否则进行回退；
• 在北极星控制台删除自定义路由规则；

可以看到，北极星提供了一整套的灰度发布解决方案，适用各种灰度发布流程，可视化轻松实现灰度规则配置，最重要的是还提供灰度可视化观测，这使得灰度发布更便利、可控性更好。

总结

看到这里，想必大家对灰度发布有了一定程序的认识了，特别是腾讯云提供的北极星一站式解决方案，通过其独特的架构理念和可视化平台解决了微服务应用过程中的种种难题，没有灰度发布的加持，全量发布带来的风险将变得举步维艰。

因为用户体量，或者研发成本的问题，现在很多公司甚至都没用灰度发布，全量发布影响 SLA 不说，一旦造成损失都是不可估量的，所以，不管公司处于什么成长阶段，都必须上灰度发布，这是对用户负责，也是公司能持续发展的重要保障。

这里贴上北极星的 Github 地址，欢迎大家到 Github 上面点个 Star：

https://github.com/polarismesh

作为微服务全面、综合的开源解决方案，北极星在腾讯内部也得到广泛运用：

从数据可以看到北极星在腾讯内部使用之广，这几乎是覆盖所有业务了，经过这么多年的洗礼，北极星也是成熟稳定的项目了，所以，可靠性还是有保障的，可以闭眼使用，不管合适与否，都值得大家去体验一番。

最后，通过参与这次腾讯云的 Techo Day 2.0 技术开放日活动，栈长最大的感触就是，在技术领域，腾讯云确实走在了前沿，真不是吹，Techo Day 2.0 活动分享了很多技术热点及解决方案，涵盖了我们平时开发的方方面面，不仅能学习、接触新兴技术，还能对技术有更多、更深入的认识，特别是栈长介绍的北极星灰度发布，真真正正的是帮助企业提升项目质量，避免发布风险。

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.别再写满屏的爆爆爆炸类了，试试装饰器模式，这才是优雅的方式！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！