问题描述,两个不同的系统,用到不同sso-server,但是sso-server代码基本一致,登录后跳转路径不同,导致访问的sso-server不是想要的。
针对这种情况有一个解决办法就是给不同项目添加不同的group
项目1:
<dubbo:registry group="test1" protocol="zookeeper" address="${registry.zk.url}" client="zkclient" register="${registry.flag}"/>
项目2:
<dubbo:registry group="test2" protocol="zookeeper" address="${registry.zk.url}" client="zkclient" register="${registry.flag}"/>
即可解决。
但是如果使用dubbo-monitor监控注册中心的时候监控不到,因为这两个系统的dubbo-monitor不在一个组里面,所以这种办法不可取。
而且在项目中配置了
<dubbo:monitor protocol="registry"/> 会报一下错误
[ERROR]:2017-07-17 08:58:06,794 -- com.alibaba.dubbo.monitor.dubbo.DubboMonitor -- [DUBBO] Unexpected error occur at send statistic, cause: Forbid consumer 172.28.1.14 access service com.alibaba.dubbo.monitor.MonitorService from registry 10.1.0.230:2181 use dubbo version 2.8.4, Please check registry access list (whitelist/blacklist)., dubbo version: 2.8.4, current host: 172.28.1.14 com.alibaba.dubbo.rpc.RpcException: Forbid consumer 172.28.1.14 access service com.alibaba.dubbo.monitor.MonitorService from registry 10.1.0.230:2181 use dubbo version 2.8.4, Please check registry access list (whitelist/blacklist). at com.alibaba.dubbo.registry.integration.RegistryDirectory.doList(RegistryDirectory.java:579) at com.alibaba.dubbo.rpc.cluster.directory.AbstractDirectory.list(AbstractDirectory.java:73) at com.alibaba.dubbo.rpc.cluster.support.AbstractClusterInvoker.list(AbstractClusterInvoker.java:260) at com.alibaba.dubbo.rpc.cluster.support.AbstractClusterInvoker.invoke(AbstractClusterInvoker.java:219) at com.alibaba.dubbo.rpc.cluster.support.wrapper.MockClusterInvoker.invoke(MockClusterInvoker.java:72) at com.alibaba.dubbo.rpc.proxy.InvokerInvocationHandler.invoke(InvokerInvocationHandler.java:52) at com.alibaba.dubbo.common.bytecode.proxy12.collect(proxy12.java) at com.alibaba.dubbo.monitor.dubbo.DubboMonitor.send(DubboMonitor.java:113) at com.alibaba.dubbo.monitor.dubbo.DubboMonitor$1.run(DubboMonitor.java:70) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
看到官方文档有一个多版本的控制:
多版本 (+) (#) 当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用。 在低压力时间段,先升级一半提供者为新版本 再将所有消费者升级为新版本 然后将剩下的一半提供者升级为新版本 <dubbo:service interface="com.foo.BarService" version="1.0.0" /> <dubbo:service interface="com.foo.BarService" version="2.0.0" /> <dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> <dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" /> 不区分版本:(2.2.0以上版本支持) <dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
所以可以借助这种方式,指定不同版本
系统1:
sso-server提供方
<dubbo:service version="1.0.0" interface="com.*.sso.client.service.AuthService" ref="authServiceImpl"/>
消费方
<dubbo:reference version="1.0.0" id="authService" interface="com.*.sso.client.service.AuthService" />
系统2:
sso-server提供方
<dubbo:service version="2.0.0" interface="com.*.sso.client.service.AuthService" ref="authServiceImpl"/>
消费方
<dubbo:reference version="2.0.0" id="authService" interface="com.*.sso.client.service.AuthService" />
这样便解决了问题 不用分组只用版本控制
还有一种解决办法,就是指定dubbo的url,如果是docker容器的话指定容器名称也可以解决这个问题即
<dubbo:reference url="127.0.0.1:20880" id="authService" interface="com.*.sso.client.service.AuthService" />
或者:
<dubbo:reference url="容器名:20880" id="authService" interface="com.*.sso.client.service.AuthService" />