問題描述，兩個不同的系統，用到不同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" />