Spring Cloud Gray 是一套开源的微服务灰度路由解决方案，它由 spring-cloud-gray-client，spring-cloud- gray-client-netflix 和 spring-cloud-tray-server，spring-cloud-gray-webui 组成。
spring-cloud-gray-client 定义了一套灰度路由决策模型，灰度信息追踪模型，以及和 spring-cloud-gray- server的基本通信功能。 spring-cloud-gray-client-netflix 在 spring-cloud-gray-client 的基础上集成了微服务注册中心 eureka，扩展ribbon 的负载均衡规则，提供了对 zuul、feign、RestTemplate 的灰度路由能力，并且无缝支持 hystrix 线程池隔离。 spring-cloud-gray-server 负责灰度决策、灰度追踪等信息的管理以及持久化。 spring-cloud-gray-webui 提供操作界面。
1. 金丝雀测试
先发布1台实例，用于测试验证，指定测试的流量进入这台实例，其它流量依然进入其它正常的实例。优势在于发布成本小，快速测试，并且不影响正常用户体验影响，即使测试不通过，也只需回滚这一台实例，用户无感知。
2. 灰度放量
通过金丝雀测试后，可以逐渐放量到新的版本上。例如，根据userId或者ip放5%的流量到其中一台灰度实例上，观察一段时间没异常，可调整放入20%的流量，如果一台实例扛不住，可再发一台或多台实例。将发布产生的风险保持在可控范围内。
3. 切断实例流量
当线上出现问题，可将某台实例的流量切断，保留现场，设置指定的请求进入实例，在线调试并且不影响其它用户。
4. 数据透传
借助灰度追踪的能力，在网关处记录用户请求的最初的数据，可以将之透传到请求完整的调用链中。
5. 借助“破窗”能力，实例蓝绿发布
首次上灰度时，会存在两种环境，一种是已经依赖了灰度客户端的环境，另一种是正常运行的当前环境。假如微服务的负载均衡是由 ribbon 实现，那么当前环境会请求路由到实例状态为 UP 的实例上，而依赖了灰度客户端的环境，则可以通过”破窗”能力，跟灰度路由结合，可以将匹配灰度策略的请求路由到实例状态为 STARTING 的实例上，不匹配灰度策略的请求路由到实例状态为 UP 的实例上。
在微服务架构中，接口的调用通常是服务消费方按照某种负载均衡策略去选择服务实例；但这无法满足线上更特殊化的一些路由逻辑，比如根据一次请求携带的请求头中的信息路由到某一个服务实例上。Spring Cloud Gray 正是为此而创建。 在Spring Cloud Gray 中定义了几个角色灰度客户端(gray-client)、灰度管控端(gray-server)、注册中心。
注册中心 负责服务的注册和发现。
灰度客户端 灰度的客户端是指依赖了spring-cloud-gray-client的服务，一般是指服务消费方。
灰度管控端 负责灰度信息的管理、持久化等维护工作。
灰度客户端会从灰度管控端拉取一份灰度信息的清单，并在内存中维护这份清单信息，清单中包含服务，服务实例，灰度策略，灰度追踪字段等。当请求达到网关时，网关就会在灰度追踪中将需要透传的信息记录下来，并将传递给转发的服务实例，后面的接口调用也会按照同样的逻辑将追踪信息透传下去，从而保证所有一个请求在微服务调用链中的灰度路由。 如下图所示：
项目已经实现了灰度的内核，如果要与其它的注册中心或者负载均衡中间件集成，只需实现相应的 plugin 即可，spring cloud gray 已经提供了 eureka、ribbon、feign、zuul 以及 spring cloud gateway 和 spring cloud stream 的 plugin，添加相应的 plugin 依赖即可。
目前有三个分支，对 spring cloud 的支持分别如下
