Spring cloud 多版本控制及灰度发布

在我们使用spring mvc单体架构时， 我们可以通过uri，或者请求头做多版本路由，虽然同一个功能需要维护多个版本的接口，但是对于系统而言，不会因为新增一个接口版本而影响到老用户。当我们使用spring cloud构建微服务平台时，也希望能做到这一点，然而spring cloud并没有提供这个功能。

在springcloud的微服务体系中，大多是使用eureka做为注册中心，ribbon做为负载均衡，hystrix做为断路器。但是在国内网络中却鲜少关于spring-cloud的接口多版本控制的开源项目，而在国内，spring cloud做为越来越被创业公司认同的微服务框架，多版本控制的需求也越来越明显，于是就有了fm-cloud-bamboo这个多版本控制的项目。在开发这个项目的过程，发现只要再做一些扩展，就可以实现灰度管理，于是又有了fm-cloud-graybunny。

多版本控制

该项目是在spring-cloud-ribbon的基础上进行扩展，以实现接口的多个版本的调用及负载均衡，支持feign方式和断路器(spring-cloud-hystrix)。

• 场景

服务A部署了两个实例 serivceA-1,serviceA-2,spring cloud ribbon默认是轮询的方式将请求分别转到两个实例上。如果由于业务原因，服务需要从1.0升级到2.0。

场景1：将所有服务实例平缓的过度到2.0。

场景2：2.0的服务实例需要兼容1.0的服务接口。

• 思路

在spring cloud微服务体系中，服务的请求来源无外乎两个方面：

来源1：外部请求通过网关(zuul)转发而来。

来源2：内部服务之间的调用请求。

不论网关转发过来的请求，还是内部服务调用过来的请求，都需要ribbon做负载均衡，所以可以扩展ribbon的负载均衡策略从而实现不同版本的请求转发到不同的服务实例上。

Java

网关的转发过程是:zuul > hystrix > ribbon

内部服务调用的过程有两种:

RestTemplate > hystrix > ribbon

Feign > hystrix > ribbon

而其中hystrix有一个线程池隔离的能力，会创建另一个线程去请求服务，拥有更好的控制并发访问量、以及服务降级等能力，但是会出现一个问题，就是线程变量(ThreadLocal)的传递问题，这可以通过com.netflix.hystrix.strategy.concurrency.HystrixRequestVariableDefault对象解决。

• 代码设计

虽然整个项目实现起来代码量不少， 但是在接口设计上，却只有三个简单的接口负责数据传递，路由的逻辑依然是封装在实现了IRule接口的实现类中(后面分析)。

Java

• BambooRibbonConnectionPoint：

这个接口是负责将bamboo跟ribbon连接起来的，将请求的信息， 以及根据业务需要添加的一些路由信息，和获取请求接口的目标版本，还有触发执行LoadBanceRequestTrigger等，都是由该接口的实现类DefaultRibbonConnectionPoint负责实现。

Java

• RequestVersionExtractor:

这个接口负责获取请求需要访问的目标接口的版本。比如有些接口版本是放在路径上，如:/v1/api/test/get。也有放在uri参数中:/api/test/get?v=1。也有可能放到header中，所以在bamboo抽象出来一个接口， 具体的实现由开发者根据业务去实现。

• LoadBalanceRequestTrigger:

Ribbon请求的触发器，在ribbon请求发起时， 会被执行。这个接口有三个方法，分别是判断是否需要执行的方法(shouldExecute)，以及请求之前执行(before)和请求完成之后执行(after)，如果出现异常，after方法依然会被执行。

• 代码实现

上面三个接口只是简单的实现了获取请求的目标版本、触发ribbon请求的触发器，以及将信息向下一步传递。在这一段中，将介绍如何与zuul、feign、RestTemplate以及ribbon和hystrix衔接起来。