万字硬核解析:Spring Cloud Alibaba-全链路灰度设计_springcloudalibaba灰度发布方案

灰度发布概念

-- 摘自百度百科

​ 灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

​ 对比灰度发布，还有蓝绿发布，滚动发布，笔者在工作中用到最多的是滚动发布，滚动发布也并不能平滑的将一部分指定的流量切到新系统上，只能做到切部分流量这部分流量是无法指定的也是随机的，所以基于此笔者就着手做全链路灰度发布相关的研究。蓝绿发布，滚动发布的具体概念自行Google吧。

灰度发布架构

​ 这里我画了一个图，简单描述一下灰度发布，这里有微服务A集群和微服务B集群，每个集群中蓝颜色的是生产实例，绿色就代表发布的灰度版本实例；可以看到网络流量是通过微服务网关为入口流入微服务集群，所以这里微服务网关就负责过滤流量管理灰度规则等，流量经过微服务网关后，可以看到灰度流量就指向了灰度版本，微服务A通过RPC调用微服务B时也通过loadbalancer也将灰度流量发到了微服务B的灰度实例上，这里图中实际缺少了一个点，就是流量由微服务网关和微服务A集群中间也是有个loadbalancer的。

​ 通过上面的图和对于灰度发布架构的描述，我这里总结一下实现微服务全链路灰度发布的核心：

1. 微服务过滤流量并管理灰度发布规则；
2. loadbalancer负责进行灰度流量的重新路由；

Spring Cloud Alibaba技术架构下的灰度发布实现

​ 实现灰度发布的技术方案有很多，比如Nginx + Lua脚本方式，Nginx即可以作为微服务网关又可以做负载均衡；再比如Service Mesh技术Istio + Envoy，Istio作为控制平台管理下发灰度规则，Envoy作为网络调用组件，如果是Service Mesh技术架构可以完全采用这种架构。如果是传统的微服务架构就有可能需要自己研发一套灰度发布的组件，所以通过上面对灰度发布架构的研究，我们大致知道了如何实现灰度发布系统，我这里就基于Spring Cloud Alibaba传统微服务架构实现全链路灰度发布功能。

基础设计

实现灰度发布需要终端应用（客户端）和服务端做一些约定，这个约定就代表着是否是灰度发布的客户端的网络调用，当然如果不做约定也是可以实现灰度功能的，这就需要服务端的组件对流量做更细致的过滤，比如从网络调用的报文中过滤出灰度发布应用的网络调用，这对服务端来说显然更加麻烦，也不利于维护，所以我这里采用客户端和服务端约定的方式来设计。

HttpHeader设计

​ 客户端和服务端在Http请求头中约定一个固定字段来标识，此标识可以代表“是否走灰度”，也可以设置成一个“用户ID”，“客户端IP”等，如果是“用户ID”，“客户端IP”那就在网关层有个配置，网关匹配到对应的参数就走灰度。

​ HttpHeader增加gray字段作为灰度标记

json

复制代码

{ "gray":"123" }

Spring Cloud Gateway改造

​ Spring Cloud Gateway在架构中是微服务网关，在灰度发布的作用就是管理灰度发布规则，设置灰度标记到HttpHeader并且传递下去。管理灰度发布规则需要一个配置，我这里选择放到配置文件当中，先实现一个Spring的自定义配置绑定，代码如下：

java

复制代码

@Configuration @RefreshScope @ConfigurationProperties("spring.cloud.gateway.gray") @Data public class GrayProperties { /** * 灰度开关 */ private Boolean enabled; /** * 灰度匹配内容 */ private List<String> matches = new ArrayList<>(); }

对应的在Spring Cloud Gateway的application.yml中的配置示例如下：

yaml

复制代码

spring: cloud: gateway: gray: enabled: true matches: - 123 - 456 - 10.1.1.10

解释下配置文件，spring.cloud.gateway.gray.enabled