实际生产中如有需求变更，并不会直接更新线上服务，最通常的做法便是：切出线上的小部分流量进行体验测试，经过测试后无问题则全面的上线。

这样做的好处也是非常明显，一旦出现了BUG，能够保证大部分的客户端正常使用。

要实现这种平滑过渡的方式就需要用到本篇文章介绍到的全链路灰度发布 。

什么是灰度发布？

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

为什么是全链路灰度发布？

在前面一篇文章有介绍到网关的灰度发布 实现，仅仅是实现了网关路由转发 的灰度发布，如下图：

如上图，网关灰度发布实现的是网关通过灰度标记 路由到文章服务B （灰度服务），至于从文章服务B到评论服务是通过openFeign 内部调用的，默认无法实现灰度标记grayTag 的透传，因此文章服务B最终调用的是评论服务A，并不是评论服务B。

全链路灰度发布需要实现的是：

网关通过灰度标记将部分流量转发给文章服务B
文章服务B能够实现灰度标记grayTag 的透传，最终调用评论服务B

经过以上分析，全链路灰度发布需要实现两个点：

网关路由转发实现灰度发布
服务内部通过openFeign 调用实现灰度发布（透传灰度标记grayTag ）。

下面将以微服务系统为例进行灰度发布配置。

网关层的灰度路由转发

本篇文章将使用Ribbon+Spring Cloud Gateway 进行改造负载均衡策略实现灰度发布。

实现思路如下：

在网关的全局过滤器中根据业务规则给流量打上灰度标记
将灰度标记放入请求头中，传递给下游服务
改造Ribbon负载均衡策略，根据流量标记从注册中心获取灰度服务
请求路由转发

第一个问题：根据什么条件打上灰度标记？

这个需要根据实际的业务需要，比如根据用户所在的地区、使用客户端类型、随机截取流量.....

这里我将直接使用一个标记grayTag ，只要客户端请求头中携带了这个参数，并且设置为true，则走灰度发布逻辑。

请求头中携带：grayTag=true

第二个问题：为什么要在请求头中添加灰度标记传递给下游服务？

这一步非常关键，实现灰度标记透传给下游服务的关键，将灰度标记放在请求头中，下游服务只需要从请求头中获取灰度标记便知道是否是灰度发布，这个和令牌中继一个原理。

第三个问题：灰度标记如何请求隔离？

Spring MVC中的每个请求都是开启一个线程进行处理，因此可以将灰度标记放置在ThreadLocal 中进行线程隔离。

第四个问题：如何知道注册中心的服务哪个是灰度服务？

Nacos支持在服务中配置一些元数据，可以将灰度标记配置在元数据中，这样就能区分哪些是灰度服务，哪些是正常服务。

第五个问题：如何针对特定的服务进行灰度发布？

比如我的微服务系统中涉及的一条调用链路如下图：

需求：现在只对 文章服务、评论服务**进行灰度发布，其他服务依然使用线上正在运行的服务

此时的调用关系就变成了下图：

我们知道网关路由中配置的服务很多，如何只针对文章服务进行灰度发布呢？

很简单：只需要将自定义的Ribbon灰度发布规则只对文章服务生效。

这里涉及到Ribbon中的一个注解：**@RibbonClients** ，只需要在其中的value属性指定需要生效的服务名称，那么此时网关中的配置如下：

@RibbonClients(value ={//只对文章服务进行灰度发布@RibbonClient(value = "article-server",configuration = GrayRuleConfig.class)
} )
@SpringBootApplication
public class GatewayApplication {}

@RibbonClient 可以指定多个，这个注解有如下两个属性：

value ：指定服务的名称，在注册中心配置的服务名称
configuration ：自定义的负载均衡策略，这里是灰度发布的策略

@RibbonClients 其中有一个属性defaultConfiguration ，一旦使用这个属性，那么灰度发布的策略对网关路由中配置的所有服务都将生效。

第六个问题：说了这么多，具体如何实现？

网关中首先需要定义一个全局过滤器 ，伪代码如下：

public class GlobalGrayFilter implements GlobalFilter{@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {//① 解析请求头，查看是否存在灰度发布的请求头信息，如果存在则将其放置在ThreadLocal中HttpHeaders headers = exchange.getRequest().getHeaders();if (headers.containsKey(GrayConstant.GRAY_HEADER)){String gray = headers.getFirst(GrayConstant.GRAY_HEADER);if (StrUtil.equals(gray,GrayConstant.GRAY_VALUE)){//②设置灰度标记GrayRequestContextHolder.setGrayTag(true);}}//③ 将灰度标记放入请求头中ServerHttpRequest tokenRequest = exchange.getRequest().mutate()//将灰度标记传递过去.header(GrayConstant.GRAY_HEADER,GrayRequestContextHolder.getGrayTag().toString()).build();ServerWebExchange build = exchange.mutate().request(tokenRequest).build();return chain.filter(build);}
}

①处的代码 ：从请求头中获取客户端传递过来的灰度标记（这里根据自己业务需要自行更改），判断是否是灰度发布

②处的代码 ：GrayRequestContextHolder 则是自定义的ThreadLocal实现的线程隔离工具，用来存放灰度标记

③处的代码 ：将灰度标记放置在请求头中，传递给下游微服务，这里是和令牌一个逻辑。

注意：这个全局过滤器一定要放在OAuth2.0 鉴权过滤器之前，优先级要调高

全局过滤器中已经将灰度标记打上了，放置在GrayRequestContextHolder 中，下面只需要改造Ribbon的负载均衡的策略去注册中心选择灰度服务。

创建GrayRule ，代码如下：

/*** 灰度发布的规则*/
public class GrayRule extends ZoneAvoidanceRule {@Overridepublic void initWithNiwsConfig(IClientConfig clientConfig) {}@Overridepublic Server choose(Object key) {try {//从ThreadLocal中获取灰度标记boolean grayTag = GrayRequestContextHolder.getGrayTag().get();//获取所有可用服务List<Server> serverList = this.getLoadBalancer().getReachableServers();//灰度发布的服务List<Server> grayServerList = new ArrayList<>();//正常的服务List<Server> normalServerList = new ArrayList<>();for(Server server : serverList) {NacosServer nacosServer = (NacosServer) server;//从nacos中获取元素剧进行匹配if(nacosServer.getMetadata().containsKey(GrayConstant.GRAY_HEADER)&& nacosServer.getMetadata().get(GrayConstant.GRAY_HEADER).equals(GrayConstant.GRAY_VALUE)) {grayServerList.add(server);} else {normalServerList.add(server);}}//如果被标记为灰度发布，则调用灰度发布的服务if(grayTag) {return originChoose(grayServerList,key);} else {return originChoose(normalServerList,key);}} finally {//清除灰度标记GrayRequestContextHolder.remove();}}private Server originChoose(List<Server> noMetaServerList, Object key) {Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(noMetaServerList, key);if (server.isPresent()) {return server.get();} else {return null;}}
}

逻辑很简单，如下：

获取灰度标记
从Nacos注册中心获取灰度服务和正常服务
根据灰度标记去判断，如果灰度发布则选择特定的灰度服务进行转发

定义一个配置类，注入改造的灰度策略GrayRule ，如下：

/*** 灰度部署的负载规则配置类* 注意：这个类一定不要被Spring Boot 扫描进入IOC容器中，一旦扫描进入则对全部的服务都将生效*/
public class GrayRuleConfig {@Beanpublic GrayRule grayRule(){return new GrayRule();}
}

注意：这个GrayRuleConfig不能被扫描进入IOC容器，一旦扫描进入则全局生效

因为不仅仅网关需要用到这个灰度发布策略，凡是涉及到OpenFeign调用的微服务如果需要配置灰度发布都需要用到，因此这里陈某定义了一个公用的gray-starter 。

经过上述步骤网关的灰度发布则已经配置完成，此时只需要通过@RibbonClients指定对应哪个服务灰度发布。

openFeign透传灰度标记

上面在介绍网关的灰度发布配置时，是将灰度标记（grayTag=true ）放在了请求头中，因此在下游服务中需要做的就只是从请求头中将灰度标记取出来，然后将其存入GrayRequestContextHolder 上下文中。

这样一来下游服务中的GrayRule 则能从GrayRequestContextHolder 获取到灰度标记，从注册中心获取灰度服务进行调用了。

问题来了：如何从请求头中取出灰度标记？

在介绍OAuth2.0相关知识时，曾经出过一篇文章：实战！openFeign如何实现全链路JWT令牌信息不丢失？

其中介绍了令牌中继的解决方案，使用的是openFeign的请求拦截器去配置请求头信息。

如上图：openFeign在调用时并不是用的原先的Request，而是内部新建了一个Request，其中复制了请求的URL、请求参数一些信息，但是请求头并没有复制过去，因此openFeign调用会丢失请求头中的信息。

但是可以通过实现RequestInterceptor 将原先的请求头给复制过去，代码如下：

@Component
@Slf4j
public class FeignRequestInterceptor implements RequestInterceptor {@Overridepublic void apply(RequestTemplate template) {HttpServletRequest httpServletRequest = RequestContextUtils.getRequest();Map<String, String> headers = getHeaders(httpServletRequest);for (Map.Entry<String, String> entry : headers.entrySet()) {//② 设置请求头到新的Request中template.header(entry.getKey(), entry.getValue());}}/*** 获取原请求头*/private Map<String, String> getHeaders(HttpServletRequest request) {Map<String, String> map = new LinkedHashMap<>();Enumeration<String> enumeration = request.getHeaderNames();if (enumeration != null) {while (enumeration.hasMoreElements()) {String key = enumeration.nextElement();String value = request.getHeader(key);//将灰度标记的请求头透传给下个服务if (StrUtil.equals(GrayConstant.GRAY_HEADER,key)&&Boolean.TRUE.toString().equals(value)){//① 保存灰度发布的标记GrayRequestContextHolder.setGrayTag(true);map.put(key, value);}}}return map;}
}

①处的代码 ：从请求头中获取灰度发布的标记，设置到GrayRequestContextHolder 上下文中

②处的代码 ：将这个请求头设置到新的Request中，继续向下游服务传递。

其实配置一下RequestInterceptor 就已经完成了，关于灰度发布策略只需要复用网关的GrayRule

注意：也需要使用@RibbonClients注解去标注文章服务调用的哪些服务需要灰度发布。

代码如下：

@RibbonClients(value = {//指定对comments这个服务开启灰度部署@RibbonClient(value = "comments",configuration = GrayRuleConfig.class)
})
public class ArticleApplication {}

Nacos中服务如何做灰度标记

其实很简单，分为两种：

1、在配置文件中指定，如下：

spring:cloud:nacos:discovery:metadata:# 灰度标记grayTag: true

2、在Nacos中动态的指定灰度标记

配置完成之后，在客户端请求的时候只需要携带grayTag=true 这个请求头即可调用灰度服务。

总结

微服务中全链路灰度发布方案其实很简单，重要的就是灰度打标，整体流程如下：

网关中通过全局过滤器实现灰度打标，将灰度标记放入请求头中传递给下游服务
网关通过自定义的负载均衡策略，从注册中心获取灰度服务，进行转发
在openFeign调用时需要从请求头中获取灰度标记，放入上下文中
openFeign调用同样是根据自定义的负载均衡策略从注册中心获取灰度服务，进行调用。

SpringCloud Nacos 实现全链路灰度发布相关推荐

Spring Cloud全链路灰度发布
一.前言实际生产中如有需求变更,并不会直接更新线上服务,最通常的做法便是:切出线上的小部分流量进行体验测试,经过测试后无问题则全面的上线.这样做的好处也是非常明显,一旦出现了BUG,能够保证大部分的 ...
分布式全链路灰度发布的探索与实践
简介:在分布式系统中,由于分布式全链路灰度发布因其链路复杂.技术门槛高.落地难度高逐渐成为金融科技实现全链路灰度发布的难点所在.工行在分布式系统建设方面一直走在同业前列,积极探索分布式全链路灰度发布, ...
工商银行顾欣：分布式全链路灰度发布的探索与实践
作者|顾欣互联网金融时代下,金融产品和服务模式不断创新,金融系统容量需求急剧增长,为进一步满足运维标准提升工作的需求,提升服务连续性水平.中国工商银行(后简称工行)从 2014 年开始分布式架构转型 ...
掌门1对1微服务体系Solar第1弹：全链路灰度蓝绿发布智能化实践
掌门教育自2014年正式转型在线教育以来,秉承"让教育共享智能,让学习高效快乐"的宗旨和愿景,经历云计算.大数据.人工智能.AR/VR/MR以及现今最火的5G,一直坚持用科技赋能教 ...
服务百万商家的系统，发布风险如何规避？微盟全链路灰度实践
一分钟精华速览全链路灰度发布是指在微服务体系架构中,应用的新.旧版本间平滑过渡的一种发布方式.由于微服务之间依赖关系错综复杂,一次发布可能会涉及多个服务升级,所以在发布前进行小规模的生产环境验证,让 ...
基于 Istio 的全链路灰度方案探索和实践
作者|曾宇星(宇曾) 审核&校对:曾宇星(宇曾) 编辑&排版:雯燕背景微服务软件架构下,业务新功能上线前搭建完整的一套测试系统进行验证是相当费人费时的事,随着所拆分出微服务数量的不 ...
苏宁金融App全链路灰度实践
背景 \\ 在这个移动互联网日渐成熟的今天,手机端流量占比高达85%.大家为了抢夺用户手机屏幕上的一席之地,杀成红海,产品的极限飙车.急速迭代.整个系统的日趋复杂可是研发时间一再压缩,变成了移动产品质 ...
微服务全链路灰度新能力
背景微服务体系架构中,服务之间的依赖关系错综复杂,有时某个功能发版依赖多个服务同时升级上线.我们希望可以对这些服务的新版本同时进行小流量灰度验证,这就是微服务架构中特有的全链路灰度场景,通过构建从网 ...
企业深入使用微服务后会面临哪些问题？云原生全链路灰度给了新思路
作者:魁予.十眠如何落地可灰度.可观测.可回滚的安全生产三板斧能力,满足业务高速发展情况下快速迭代和小心验证的诉求,是企业在微服务化深入过程中必须要面对的问题.在云原生流行的当下,这个问题又有了一些 ...

SpringCloud Nacos 实现全链路灰度发布