昨天碰到了这个异常原因是容器初始化失败,就是消费者没有获得服务
在网上搜了很多解决方案,都没能解决
最终发现是linux发布zookeeper后防火墙没有关闭。
先说一下整个系统框架的基本构造:
-
zookeeper作为注册中心使用单独服务器,占用2181端口
-
provider作为提供者使用单独服务器,tomcat部署占用8080端ロ使用dubbo协议开放20880端口
-
consumer作为消费者,使用单独服务器tomcat部署占用8080端口
再看上面的异常,虽然解决了是不是有人和我一样有一些问题想不通:
-
provider服务器端口是8080,为什么telnet测试以及解决方案中开放的端口却是20880
-
要说dubbo协议开放了20880端口,那8080端口应该也开放啊
带着这些问题,进行了相關的验证最终得出如下结论,先看图再解释:
port="20880"/>,表明用dubbo协议在20880端口暴露服务当然如果你不配置,dubbo默认使用20880端ロ暴露服务所有消费者都是通过20880端口进行,对于消费者而言提供者服务器8080端口是透明的,也就是说提供者服务器端口号可以任意改变服务也不会有任何影响,消费者无需关心
所以上面的异常解决办法是开放20880端口给消费者,而不是8080端口给消费者
从监控中心可以看到洳图:
除了在指定端口上暴露服务之外,还可以在指定ip上暴露服务配置如下:
zookeeper注册中心是完全被动的。
总结一下:
- zookeeper的2181开放給provider、consumer、dubbo-admin
- provider的20880开放给所有consumer但8080服务器端口可以完全屏蔽
- consumer的8080开放给所有provider
- dubbo-admin的8080开放给管理员用户,便于通过浏览器监控注册中心服务的情况
- 总结:注冊中心只负责服务注册和目录发布安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成这种方式下整个架构下获取更高嘚性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈