知道军哥的灰度发布路由组件好长时间了,但是由于项目需要和紧急度一直都没有深入的去了解和使用,最近因为新项目上线,涉及到一些灰度发布灰度路由的需求,因此决定开始研究一下。
军哥(任浩军)实际不但开发了灰度发布组件,还开发出来很多其他的实用组件,在这打个广告,算是表达了对军哥架构思路的佩服之情。
Discovery从Spring Cloud 很早版本的时候就开始支持了,后来到了Spring Cloud G版本才开始使用,现在是使用的Discovery5.0.0,还没有正式发布,按军哥的意思是等待Spring Cloud Alibaba发布最新版本,阿里巴巴Nacos也是刚刚发布了1.0.0版本。所以提前编译打包了5.0.0的代码到私有仓库,直接引包来使用了,写这篇文章的时候军哥还没有正式在Maven仓库提交5.0.0的版本镜像呢
军哥的文档写的还算是比较详细的,按着文档操作说明来做,应该能够成功应用,但是在使用的过程中,还是有些使用不明白的地方,和需要理解的地方,在这里讲解一下也算做个记录。
首先如何引入依赖,灰度组件中有好多模块,分别是作用在不同地方的依赖,起到不同的作用。
从功能上划分,分为注册中心客户端(discovery-plugin-starter-*),配置中心客户端(discovery-plugin-config-center-starter-*),用户自定义和编程灰度路由策略(服务客户端,网关客户端)(discovery-plugin-strategy-starter-*),控制台(discovery-console-starter-*)依赖几大块。
从注册中心细分,又分为 eureka(discovery-plugin-starter-eureka),consul(discovery-plugin-starter-consul),Zookeeper(discovery-plugin-starter-zookeeper),nacos(discovery-plugin-starter-nacos),
从配置中心细分,又分为Apollo(discovery-plugin-config-center-starter-apollo),nacos(discovery-plugin-config-center-starter-nacos),redis(discovery-plugin-config-center-starter-redis),(如果需要持久化,这部分必不可少)
控制台的细分,又分为eureka (discovery-console)eureka有一点不同没有特意封装,直接使用discovery-console即可, Apollo(discovery-console-starter-apollo), nacos(discovery-console-starter-nacos), redis(discovery-console-starter-redis)
管理中心实现,Spring Boot Admin (discovery-plugin-admin-center)
图形化灰度发布等桌面程序 (discovery-console-desktop)
如果你是微服务客户端,使用eureka作为注册中心来使用的,那么微服务的pom依赖需要按需引入
如果你是微服务客户端,使用nacos作为注册中心,配置中心来使用的,那么微服务的pom依赖需要按需引入
如果你是微服务的网关,以Spring Cloud Gateway为例,你需要引入除了上面注册中心配置中心的引入不变,
discovery-plugin-starter-eureka、discovery-plugin-starter-nacos、discovery-plugin-config-center-starter-nacos正常引入依赖
如果是基于Gateway则还需要引入
如果是基于Zuul则还需要引入
如果用到了Hystrix,则灰度Hystrix做线程模式的服务隔离必须引入的插件
上面就是普通微服务,还有网关的配置引入依赖就这些即可了。
做灰度发布路由,还需要一个动态配置功能,那么这就需要建立一个控制台后台服务,你需要自己新建一个控制台的后端服务,如果是基于eureka来使用的,则控制台要引入
组件没有特意为eureka再包装一层,封装类似于discovery-console-starter-eureka的东西,而是直接使用的discovery-console即可
如果是基于nacos的需要引入
上面这个是控制台后台服务的引入方式,这样启动后就会启动一个控制台后台服务他会和注册中心相互注册实现服务的读取管理
还有一个桌面端的使用类似前端需要连接控制台后台来实现配置功能,这个需要运行 discovery-console-desktop这个服务里的ConsoleLauncher,然后通过控制台后端服务的URL + 端口号连接到控制台服务上即可,这里需要输入一个帐号密码这个需要时先在控制台后台服务里配置一个properties文件,用户名=密码的形式即可,
以上这些配置完成后,依赖部分就可以说搞定了,如果要实现灰度路由还要在对应这些服务的yml或者properties文件中配置一些必要的属性。
例如要标识微服务的版本,用于网关在灰度路由时选择路由的路径,以同一个服务的不同实例为例
A微服务1.0实例
# Eureka config for discovery
eureka.instance.metadataMap.group=example-service-group
eureka.instance.metadataMap.version=1.0
eureka.instance.metadataMap.region=dev
A微服务1.1实例
# Eureka config for discovery
eureka.instance.metadataMap.group=example-service-group
eureka.instance.metadataMap.version=1.1
eureka.instance.metadataMap.region=dev
通过meta信息来标识服务自身的身份,以便路由时通过对应版本过滤掉规则外的服务只保留符合规则的服务进行负载均衡调用。
下面启用 discovery-console-desktop 控制台桌面程序 并连接 控制台服务,控制台服务作为普通微服务注册到注册中心,并通过注册中心获取服务列表以便在控制台桌面程序显示,在控制台桌面程序中选中网关服务执行更新灰度规则,实际是rest调用网关服务的/config/update-*方法, 选择的服务的/config/update-sync同步,选择的服务的/config/update-async异步,执行POST请求传递规则xml数据,discovery-plugin-admin-center 模块的src/main/java/com/nepxion/discovery/plugin/admincenter/endpoint/ConfigEndpoint.java类中的updateSync 会执行调用方法,并调用discovery-plugin-framework模块下的onRuleUpdated方法调用setDynamicRule完成规则的缓存,利用Caffeine(高性能java缓存库)完成规则的缓存存储RuleCache ,这样灰度的路由规则就会存储在网关的缓存当中,以便在调用网关的时候从缓存当中取出路由规则使用。 这就是基于版本的灰度路由使用的基本流程了, 下一次讲一下灰度策略的使用