大厂全链路灰度发布最佳实践

分享内容

1. 版本发布策略的现状及存在的问题
2. 业界常用的软件发布策略对比
3. 为什么需要采用灰度发布
4. 全链路灰度发布的实现思路
5. 灰度发布逻辑工程实践与成果展示
6. 总结

引言

在日常发布中，如何保证系统的高可用及稳定性，是我们始终以来的重要任务。我们深知一个可靠、高效的系统对用户体验和业务运行的关键性作用。

在软件发布与功能验证的环节，我们仍然会面临许许多多的挑战，全链路灰度发布方案专为微服务架构设计，旨在应对微服务架构下的灰度发布挑战。

1 版本发布策略的现状及存在的问题

目前，大部分系统都是应用了基于 k8s 容器的滚动发布方案，或者在滚动发布的逻辑上，实现了优雅停机的逻辑。

1.1 现状

• 优雅停服 1 个节点，保留其他节点依然提供生产服务
• 通过日志，观察一段时间，看新的节点是否运行正常。如果不正常，就回滚版本
• 如果运行正常，继续 1、2 的步骤，一直到所有节点部署完成
• 测试人员上生产做基本验证

1.2 存在问题

• 不能有效的控制灰度流量，导致测试人员要全部节点部署完，才可以做生产验证
• 目前的滚动发布逻辑，无法做到增量更新，一旦新版本出了问题，肯定会影响到生产的运行
• 难以实现全天候平滑稳定的发版
• 如果版本发布涉及不同服务之间的依赖关系，或者前后端都需要调整，当前策略无法一步到位满足全链路灰度测试场景

2 业界常用的软件发布策略对比

3 什么是灰度发布？为什么需要采用灰度发布？

3.1 什么是灰度发布？

灰度发布，简单来说就是先小范围进行版本发布，充分验证功能符合预期后，再逐步扩大发布范围。如果出现负面反馈或功能异常时，则需要停止放量，回滚到原先的稳定版本。

从技术上来说，灰度发布是一种流量控制方案，对服务的请求流量按用户或者其它特性打标签，保证特定标签的流量只经过特定标签的服务路径。

3.2 为什么采用灰度发布？

1、降低发布风险

在新版本发布之前，通过灰度发布把新版本先部署到一小部分用户，以便能更快地发现并解决潜在的问题。

2、提高发布质量

因为在灰度发布期间可以及时发现和解决问题，所以能够在全量发布之前不断完善代码质量，提高系统稳定性和可靠性。

3、优化用户体验

在灰度发布期间，我们可以根据用户反馈来针对性地优化产品功能和界面，确保用户使用的体验最佳。

4、降低对系统性能的影响

由于灰度发布只向部分用户发布新版本，所以能够限制新版本对整个系统的影响。

4 全链路灰度发布的实现思路

全链路流量路由目前有两种主流实现：

1、基于 Istio

采用 Istio 这个开源 Service Mesh 组件，通过在每个服务的容器中部署 Envoy 透明代理，拦截服务之间的网络通信并按指定规则转发，从而实现了全链路流量路由，无需对现有代码进行修改。

2、基于服务发现组件

通过支持为服务设置元数据的服务注册中心，如 Nacos，可以标记服务实例的特征，例如灰度版本。每个服务可以通过注册中心获取其他服务实例的版本信息，并通过修改代码逻辑或 Java Agent 实现流量路由

接下来，我们详细来讲基于服务发现组件来实现灰度发布逻辑的方案。

5 灰度发布逻辑工程实践

5.1 灰度链路流程图

5.2 后端代码改造

代码改造原理是通过 Spring Cloud 的默认负载均衡器 LoadBalancer，结合 nacos 提供的注册中心和配置中心，实现基于微服务网关调用和服务间 OpenFeign 调用的生产和灰度隔离。

以下代码是以 Loadbalancer 为例，扩展的灰度逻辑，如果目前系统基于 Ribbon, 可以考虑使用 Loadbalancer 替换掉 Ribbon, 也可以直接基于 Ribbon 定义自己的灰度负载均衡逻辑，实现方法在本文中不做详细描述。

步骤 1：指定灰度启动节点

指定灰度节点与生产节点，用于负载均衡器按规则选择不同的链路，用于区别流量，建设 jenkins 部署脚本时，设置在启动项里面。

/**
* 指定灰度启动节点
*/
--spring.cloud.nacos.discovery.metadata.tag=gray
/**
* 指定生产启动节点
*/
--spring.cloud.nacos.discovery.metadata.tag=master

​

步骤 2：灰度负载均衡逻辑的实现

Spring Cloud 的负载均衡逻辑，无论负载均衡器是 LoadBalancer 或者是 Ribbon，默认逻辑都是轮循逻辑，可以保证每一个上线节点浏量的平均分配，但是无法保证灰度策略的实现，因此，必须得重新定义新的负载均衡逻辑。