基于Spring cloud ribbon实现多版本控制

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

在spring cloud的微服务体系中,大多是使用eureka做为注册中心,ribbon做为负载均衡,hystrix做为断路器。但是在国内网络中却鲜少关于spring-cloud的接口多版本控制的开源项目,而在国内,spring cloud做为越来越被创业公司认同的微服务框架,多版本控制的需求也越来越明显,于是就有了fm-cloud-bamboo这个多版本控制的项目。

多版本控制

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

场景

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

  • 来源1:
    外部请求通过网关(zuul)转发而来。
  • 来源2:
    内部服务之间的调用请求。

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

网关的转发过程是:zuul > hystrix > ribbon
内部服务调用的过程有两种:
RestTemplate > hystrix > ribbon
Feign > hystrix > ribbon

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

代码设计

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

这里写图片描述

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

  • 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衔接起来。

  • RestTemplate衔接
    ClientHttpRequestInterceptor是RestTemplate的拦截器接口,可以通过这个接口添加bamboo的逻辑, 从而将RestTemplate和bamboo衔接起来。
    BambooClientHttpRequestIntercptor是ClientHttpRequestInterceptor接口的实现类,它加入了bamboo的逻辑。
    这里写图片描述

  • Feign衔接
    BambooFeignClient类实现了feign.Client接口, 该类是一个代理类,主要的Feign的调用逻辑依然由被代理的类去执行,在该类中添加了bamboo的逻辑,从而将Feign和bamboo衔接起来。
    这里写图片描述

  • Zuul衔接
    实现两个ZuulFilter接口,分别是pre和post类型,将bamboo的逻辑加入其中。Pre类型的ZuulFilter获取请求信息,并执行LoadBalanceRequestTrigger#before方法。Post类型的ZuulFilter执行LoadBalanceRequestTrigger#after方法,并清除存在ThradLocal中的相关信息。
    这里写图片描述

  • Hystrix衔接
    Hystrix实现降级、断路器等功能,但是在使用线程池隔离时,ThreadLocal存储的信息如何传递下去呢?使用HystrixRequestVariableDefault可以解决这个问题。可以查看com.netflix.hystrix.strategy.concurrency包下的HystrixContexSchedulerAction、HystrixContextCallable、HystrixContextRunnable,它们都有一段相同功能的代码
    这里写图片描述
    parentThreadState也是一个HystrixRequestContext对象,它是在hystrix创建线程之前的,也就是处理http请求的线程的HystrixRequestContext对象,我们一般也是维护这个对象。在使用线程池隔离时,hystrix会将parentThreadState中的信息复到到新线程中,实现跨线程的数据传递,从而在后面的逻辑中可以获取到parentThreadState中维护的信息,包括ribbon的路由信息。在bamboo中,将一步骤的逻辑放到BambooRequestContext中,将BambooRequestContext实例本身传递下去。
    这里写图片描述

  • Ribbon 路由规则
    Bamboo中的BambooZoneAvoidanceRule继承了ZoneAvoidanceRule,所以它会有ZvoidanceRule的一切特性,在此基础上,还加入了版本过滤的逻辑,这个逻辑主要是由BambooApiVersionPredicate实现。从BambooRequestContext中获取请求的接口的版本,如果有该没有获取到版本,就返回true;如果有获取到版本,就获取服务实例的metadata中的version信息,并进行匹配校验,返回结果。
    这里写图片描述

使用指导

在使用多版本控制时,需要修改服务提供方的两个文件,分别是pom.xml和application.yaml。

  1. 将bamboo-start项目添加到maven中。
    这里写图片描述
  2. 在application.yaml中添加versions属性,标明服务支持哪些版本。
    这里写图片描述
    在服务消费方,只需要在pom.xml添加bamboo-starter到maven中即可。

在一个名为eureka-client的项目中加入1,2两个步骤, 启动服务。网关做为服务消费方,在pom.xml中加入fm-cloud-starter-bamboo, 并在application.yaml中加入zuul的配置:
这里写图片描述

启动服务后,访问http://localhost:10002/gateway/client/api/test/get?version=2 会返回数据,因为eureka-client支持version=2
这里写图片描述

如果访问http://localhost:10002/gateway/client/api/test/get?version=3 会报错, 因为找不到支持版本3的服务实例
这里写图片描述

项目地址

https://github.com/saleson/fm-cloud/tree/master/fm-cloud/fm-cloud-plugins/fm-cloud-bamboo

猜你喜欢

转载自blog.csdn.net/mr_rain/article/details/79133190