Dubbo动态调用实现
问题提出
Dubbo常用使用方式大家都比较熟悉,确定好服务的与服务之间调用关系,确定好相关接口参数,基于spring配置好,启动provider,然后启动consumer去调用相关服务。但有这样的一种场景:
- 所有的Provider的接口都相同,但每个系统有自己的不同实现。例如系统A和B都提供com.HelloService服务,但具体实现不一样,需要Consumer端根据传入参数来区分开来并调用
- Dubbo的Consumer端需要在运行时才知道调用具体的Dubbo服务,而这个<dubbo:reference/>并没有在spring的bean中配置
解决方案
同一个服务不同实现版本
先来看第一种场景,可以通过配置group 的方式实现同一个服务的不同实现版本:
提供者dubbo端配置: <dubbo:service interface="com.HelloService" group="groupA" ref="helloService" /> 消费者consumer配置: <dubbo:reference id="helloService"interface="com.HelloService" group="groupA"/> 说明:只有相同group的才能进行匹配,若要实现消费者任意调用提供者的某个服务,只需要把group设置为“*”,即: <dubbo:reference interface="com.HelloService" group="*" id="helloService"/>
动态调用
需要在实际使用时,构造出Consumer端的服务类,并通过上述的group的方式区分不同的服务实现,如下:
public HelloService getInvokeService(String group) { ApplicationConfig application = new ApplicationConfig(); application.setName("dubboConsumer"); RegistryConfig registry = new RegistryConfig(); registry.setAddress("127.0.0.1:2181"); registry.setProtocol("zookeeper"); ReferenceConfig<HelloService> referenceConfig = new ReferenceConfig<>(); referenceConfig.setApplication(application); referenceConfig.setRegistry(registry); referenceConfig.setGroup(group); referenceConfig.setInterface(HelloService.class); return referenceConfig.get(); }
性能优化
上述实现已经可以满足我们提出的两个要求,但是存在性能问题,因为每次调用该方法,都需要重新生成一个新的ReferenceConfig,并且调用get()方法获取一个代理的实现,该实现封装了与注册中心的连接以及与提供者的连接。为了能够重用该连接,可以将其缓存,这里使用dubbo内置的简单缓存工具类进行缓存,实现代码如下:
public HelloService getInvokeService(String group) { ApplicationConfig application = new ApplicationConfig(); application.setName("dubboConsumer"); RegistryConfig registry = new RegistryConfig(); registry.setAddress("127.0.0.1:2181"); registry.setProtocol("zookeeper"); ReferenceConfig<HelloService> referenceConfig = new ReferenceConfig<>(); referenceConfig.setApplication(application); referenceConfig.setRegistry(registry); referenceConfig.setGroup(group); referenceConfig.setInterface(HelloService.class); ReferenceConfigCache cache = ReferenceConfigCache.getCache(); return cache.get(referenceConfig); }
相关推荐
ATenhong 2020-10-15
supperme 2020-09-08
doctorvian 2020-08-02
aNian 2020-08-01
kongjunlongaa 2020-06-29
Fightingxr 2020-06-26
whileinsist 2020-06-24
doctorvian 2020-06-16
XuNeely 2020-06-16
wangyangsoftware 2020-06-16
大步流星 2020-06-16
aNian 2020-06-16
gaoyongstone 2020-06-16
MartellJenkins 2020-06-11
范群松 2020-06-11
Fightingxr 2020-06-08
XuNeely 2020-06-07
大步流星 2020-06-05