在对于dubbo的路由机制和注册机制有所了解之后,我们来分析一下如何实现dubbo服务的不同环境隔离。
这一用法的大致思路为:
正常的测试环境中存在着api-consumer调用user-provider的这么一个调用关系,这里我们暂时称之为default版本。
假设某一天,业务方突然有一个a需求需要开发改动这个两个模块,此时就应该有这么一个关系链路出现,这里我们暂且称之为 version-a 版本。
但是由于version-a版本还是待完善阶段,可能还有一些影响主流程的bug存在,直接发布到测试环境替代掉default版本,可能会影响其他正在测试环境正常运作服务对于default版本的调用情况,因此version-a版本的影响需要被单独限制起来。
理想的情况下应该是这种情景:
那么如何实现这种单独的隔离方案呢?
目前自己所处的企业主要是采用dubbo作为微服务架构的基础,所以在进行不同服务环境的隔离时候需要对provider和consumer进行拆分设计。目前在dubbo这块的思路是基于对url配置总线的改造实现,保证不同版本的provider在写入url的时候,会结合需求分支注入一个git.branch的参数:
例如非稳定版本的测试环境中的provider 对应的配置总线中,可以在url的结尾中注入一个git.branch参数:
dubbo://192.168.43.227:9096/com.qiyu.dubbo.common.DubboService?anyhost=true&application=order-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&git.branch=master&interface=com.qiyu.dubbo.common.DubboService&methods=doTest&pid=63261®ister=true&release=2.7.3&side=provider&threadpool=fixed&threads=200×tamp=1609484179452
然后在进行路由选择的时候,凡是非稳定版本的调用方只要在启动参数中携带有对应的git.branch参数方可实现对该provider的调用,否则都会调用到默认的稳定版本测试环境中。
对应的实现代码模块:
重写对应的zk注册工厂
package com.qiyu.dubbo.router.starter.zone.zk;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.common.extension.SPI;
import org.apache.dubbo.registry.Registry;
import org.apache.dubbo.registry.support.AbstractRegistryFactory;
import org.apache.dubbo.remoting.zookeeper.ZookeeperTransporter;
/**
* @Author idea
* @Date created in 3:20 下午 2020/11/26
*/
public class ZoneAwareZookeeperRegisterFactory extends AbstractRegistryFactory {
private ZookeeperTransporter zookeeperTransporter;
/**
* dubbo的spi自动具有依赖注入的功能
*
* @param zookeeperTransporter
*/
public