聊聊 Spring Cloud 全链路灰度发布 方案~
源 / 文/
实际生产中如有需求变更，并不会直接更新线上服务，最通常的做法便是：切出线上的小部分流量进行体验测试，经过测试后无问题则全面的上线。
这样做的好处也是非常明显，一旦出现了BUG，能够保证大部分的客户端正常使用。
要实现这种平滑过渡的方式就需要用到本篇文章介绍到的全链路灰度发布。
什么是灰度发布？
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
为什么是全链路灰度发布？
在陈某前面一篇文章有介绍到网关的灰度发布实现，仅仅是实现了网关路由转发的灰度发布，如下图：
如上图，网关灰度发布实现的是网关通过灰度标记路由到文章服务B（灰度服务），至于从文章服务B到评论服务是通过openFeign内部调用的，默认无法实现灰度标记grayTag的透传，因此文章服务B最终调用的是评论服务A，并不是评论服务B。
全链路灰度发布需要实现的是：
网关通过灰度标记将部分流量转发给文章服务B 文章服务B能够实现灰度标记grayTag的透传，最终调用评论服务B
经过以上分析，全链路灰度发布需要实现两个点：
网关路由转发实现灰度发布 服务内部通过openFeign调用实现灰度发布（透传灰度标记grayTag）。
下面将以陈某的《Spring Cloud Alibaba实战》专栏中的服务为例进行灰度发布配置。
网关层的灰度路由转发
本篇文章将使用Ribbon+Spring Cloud Gateway 进行改造负载均衡策略实现灰度发布。
实现思路如下：
在网关的全局过滤器中根据业务规则给流量打上灰度标记 将灰度标记放入请求头中，传递给下游服务 改造Ribbon负载均衡策略，根据流量标记从注册中心获取灰度服务 请求路由转发
第一个问题：根据什么条件打上灰度标记？
这个需要根据实际的业务需要，比如根据用户所在的地区、使用客户端类型、随机截取流量.....
这里我将直接使用一个标记grayTag，只要客户端请求头中携带了这个参数，并且设置为true，则走灰度发布逻辑。
“请求头中携带：grayTag=true
”
第二个问题：为什么要在请求头中添加灰度标记传递给下游服务？
这一步非常关键，实现灰度标记透传给下游服务的关键，将灰度标记放在请求头中，下游服务只需要从请求头中获取灰度标记便知道是否是灰度发布，这个和令牌中继一个原理。
第三个问题：灰度标记如何请求隔离？
Spring MVC中的每个请求都是开启一个线程进行处理，因此可以将灰度标记放置在ThreadLocal中进行线程隔离。
第四个问题：如何知道注册中心的服务哪个是灰度服务？
Nacos支持在服务中配置一些元数据，可以将灰度标记配置在元数据中，这样就能区分哪些是灰度服务，哪些是正常服务。
第五个问题：如何针对特定的服务进行灰度发布？
比如我的《Spring Cloud Alibaba实战》中涉及的一条调用链路如下图：
“需求：现在只对文章服务、评论服务进行灰度发布，其他服务依然使用线上正在运行的服务
”
此时的调用关系就变成了下图：
我们知道网关路由中配置的服务很多，如何只针对文章服务进行灰度发布呢？
“很简单：只需要将自定义的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{
@Override
public Mono 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 {
@Override
public void initWithNiwsConfig(IClientConfig clientConfig) {
}
@Override
public Server choose(Object key) {
try {
//从ThreadLocal中获取灰度标记
boolean grayTag = GrayRequestContextHolder.getGrayTag().get();
//获取所有可用服务
List serverList = this.getLoadBalancer().getReachableServers();
//灰度发布的服务
List grayServerList = new ArrayList<>();
//正常的服务
List 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 noMetaServerList, Object key) {
Optional server = getPredicate().chooseRoundRobinAfterFiltering(noMetaServerList, key);
if (server.isPresent()) {
return server.get();
} else {
return null;
}
}
}
逻辑很简单，如下：
获取灰度标记 从Nacos注册中心获取灰度服务和正常服务 根据灰度标记去判断，如果灰度发布则选择特定的灰度服务进行转发
定义一个配置类，注入改造的灰度策略GrayRule，如下：
/**
* 灰度部署的负载规则配置类
* 注意：这个类一定不要被Spring Boot 扫描进入IOC容器中，一旦扫描进入则对全部的服务都将生效
*/
public class GrayRuleConfig {
@Bean
public 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 {
@Override
public void apply(RequestTemplate template) {
HttpServletRequest httpServletRequest = RequestContextUtils.getRequest();
Map headers = getHeaders(httpServletRequest);
for (Map.Entry entry : headers.entrySet()) {
//② 设置请求头到新的Request中
template.header(entry.getKey(), entry.getValue());
}
}
/**
* 获取原请求头
*/
private Map getHeaders(HttpServletRequest request) {
Map map = new LinkedHashMap<>();
Enumeration 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调用同样是根据自定义的负载均衡策略从注册中心获取灰度服务，进行调用。
end
顶级程序员：topcoding
做最好的程序员社区：Java后端开发、Python、大数据、AI
一键三连「分享」、「点赞」和「在看」