微服务的灰度发布就该这样设计

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

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

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

什么是灰度发布？

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

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

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

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

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

1. 网关通过灰度标记将部分流量转发给文章服务B

2. 文章服务B能够实现灰度标记grayTag的透传，最终调用评论服务B

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

1. 网关路由转发实现灰度发布

2. 服务内部通过openFeign调用实现灰度发布（透传灰度标记grayTag）。

网关层的灰度路由转发

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

实现思路如下：

1. 在网关的全局过滤器中根据业务规则给流量打上灰度标记

2. 将灰度标记放入请求头中，传递给下游服务

3. 改造Ribbon负载均衡策略，根据流量标记从注册中心获取灰度服务

4. 请求路由转发

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

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

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

“ 请求头中携带：grayTag=true ”

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

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

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

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

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