问题描述,两个不同的系统,用到不同sso-server,但是sso-server代码基本一致,登录后跳转路径不同,导致访问的sso-server不是想要的。
针对这种情况有一个解决办法就是给不同项目添加不同的group
项目1:
1
|
<dubbo:registry group=
"test1"
protocol=
"zookeeper"
address=
"${registry.zk.url}"
client=
"zkclient"
register=
"${registry.flag}"
/>
|
项目2:
1
|
<dubbo:registry group=
"test2"
protocol=
"zookeeper"
address=
"${registry.zk.url}"
client=
"zkclient"
register=
"${registry.flag}"
/>
|
即可解决。
但是如果使用dubbo-monitor监控注册中心的时候监控不到,因为这两个系统的dubbo-monitor不在一个组里面,所以这种办法不可取。
而且在项目中配置了
<dubbo:monitor protocol="registry"/> 会报一下错误
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
[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
)
|
看到官方文档有一个多版本的控制:
1
2
3
4
5
6
7
8
9
10
11
12
|
多版本
(+) (#)
当一个接口实现,出现不兼容升级时,可以用版本号过渡,版本号不同的服务相互间不引用。
在低压力时间段,先升级一半提供者为新版本
再将所有消费者升级为新版本
然后将剩下的一半提供者升级为新版本
<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提供方
1
|
<dubbo:service version=
"1.0.0"
interface
=
"com.*.sso.client.service.AuthService"
ref=
"authServiceImpl"
/>
|
消费方
1
|
<dubbo:reference version=
"1.0.0"
id=
"authService"
interface
=
"com.*.sso.client.service.AuthService"
/>
|
系统2:
sso-server提供方
1
|
<dubbo:service version=
"2.0.0"
interface
=
"com.*.sso.client.service.AuthService"
ref=
"authServiceImpl"
/>
|
消费方
1
|
<dubbo:reference version=
"2.0.0"
id=
"authService"
interface
=
"com.*.sso.client.service.AuthService"
/>
|
这样便解决了问题 不用分组只用版本控制
还有一种解决办法,就是指定dubbo的url,如果是docker容器的话指定容器名称也可以解决这个问题即
1
|
<dubbo:reference url=
"127.0.0.1:20880"
id=
"authService"
interface
=
"com.*.sso.client.service.AuthService"
/>
|
或者:
1
|
<dubbo:reference url=
"容器名:20880"
id=
"authService"
interface
=
"com.*.sso.client.service.AuthService"
/>
|
本文转自gaofeng36599 51CTO博客,原文链接:http://blog.51cto.com/786678398/1948614