Dubbo进阶（八）—— no provider available for the service错误解决方案

#Dubbo进阶（八）—— no provider available for the service错误解决方案
    在分布式项目中Dubbo发布服务报No provider available for the service错误。错误信息如下：

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'dubboServiceTest': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalStateException: Failed to check the status of the service com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest. No provider available for the service com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest from the url zookeeper://22.189.25.95:2181/com.alibaba.dubbo.registry.RegistryService?application=access-provider-ccms-test&dubbo=2.8.4&interface=com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest&methods=getResponseData&pid=8184&side=consumer&timestamp=1523930029357 to the consumer 22.189.25.95 use dubbo version 2.8.4

[2018-04-17 10:57:23.488] [thread-main] [INFO] --  [DUBBO] Notify urls for subscribe url consumer://22.189.25.95/com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest?application=access-provider-ccms-test&category=providers,configurators,routers&check=false&dubbo=2.8.4&interface=com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest&methods=getResponseData&pid=11908&side=consumer&timestamp=1523933842862, urls: [empty://22.189.25.95/com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest?application=access-provider-ccms-test&category=providers&check=false&dubbo=2.8.4&interface=com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest&methods=getResponseData&pid=11908&side=consumer&timestamp=1523933842862, empty://22.189.25.95/com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest?application=access-provider-ccms-test&category=configurators&check=false&dubbo=2.8.4&interface=com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest&methods=getResponseData&pid=11908&side=consumer&timestamp=1523933842862, empty://22.189.25.95/com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest?application=access-provider-ccms-test&category=routers&check=false&dubbo=2.8.4&interface=com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest&methods=getResponseData&pid=11908&side=consumer&timestamp=1523933842862], dubbo version: 2.8.4, current host: 22.189.25.95com.alibaba.dubbo.rpc.RpcException: Forbid consumer 22.189.25.95 access service com.bocsoft.ccms.demo.dubbo.service.IDubboServiceTest from registry 22.189.25.95:2181 use dubbo version 2.8.4, Please check registry access list (whitelist/blacklist).

  

 

  
1
  
2
  
3
 

##解决方案
    Dubbo默认（缺省）会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。
    如果你的Spring容器是懒加载的，或者通过API编程延迟引用服务，请关闭check，否则服务临时不可用时，会抛出异常，拿到null引用，如果check=false，总是会返回引用，当服务恢复时，能自动连上。
    可以通过check=”false”关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

• 1、关闭某个服务的启动时检查：(没有提供者时报错)

<dubbo:reference interface="com.taotao.ItemService" check="false" />

  

 

  
1
 

• 2、关闭所有服务的启动时检查：(没有提供者时报错) 写在定义服务消费者一方

<dubbo:consumer check="false" />

  

 

  
1
 

• 3、关闭注册中心启动时检查：(注册订阅失败时报错)

<dubbo:registry check="false" />

  

 

  
1
 

##附 dubbo+zookeeper与提供者provider、消费者consumer之间通信过程
    先说一下整个系统框架的基本构造：

• zookeeper作为注册中心，使用单独服务器，占用2181端口；
• dubbo-admin作为监控中心，与zookeeper使用相同服务器，tomcat部署占用8080端口；
• provider作为提供者，使用单独服务器，tomcat部署占用8080端口，使用dubbo协议开放20880端口；
• consumer作为消费者，使用单独服务器，tomcat部署占用8080端口；

    疑惑：

• provider服务器端口是8080，为什么telnet测试以及解决方案中开放的端口却是20880？
• 要说dubbo协议开放了20880端口，那8080端口应该也开放啊？
• zookeeper、provider、consumer之间端口开放和屏蔽情况到底是怎么回事？

    带着这些问题，进行了相关的验证，最终得出如下结论，先看图，再解释：

1)、用dubbo协议在20880端口暴露服务
    在提供者的dubbo配置文件中，一般都配置了<dubbo:protocol name="dubbo" port="20880"/>，表明用dubbo协议在20880端口暴露服务，当然如果你不配置，dubbo默认使用20880端口暴露服务，所有消费者都是通过20880端口进行，对于消费者而言，提供者服务器8080端口是透明的，也就是说提供者服务器端口号可以任意改变，服务也不会有任何影响，消费者无需关心。
    所以上面的异常解决办法是开放20880端口给消费者，而不是8080端口给消费者。
    从监控中心可以看到如图：

    除了在指定端口上暴露服务之外，还可以在指定ip上暴露服务，配置如下：

<dubbo:protocol name="dubbo" host="10.1.22.2" port="20880" />

  

 

  
1
 

2)、端口开放情况
    zookeeper作为注册中心，provider注册服务、consumer订阅服务、dubbo-admin监控服务，所以zookeeper注册中心的2181端口需要向provider、consumer、dubbo-admin开放；

    一般情况下，dubbo-admin监控中心与zookeeper注册中心部署在相同的服务器上，zookeeper可以不考虑端口开放给dubbo-admin的情况；

    consumer订阅服务，即拿到了provider在20880端口暴露的服务，当consumer请求服务时，直接从consumer跳到provider，而不是consumer到zookeeper再到provider，所以provider的20880无需开放给zookeeper；

    同理，provider响应服务时，也是直接从provider到consumer，而不是provider到zookeeper再到consumer，所以consumer的8080无需开放给zookeeper；

    zookeeper注册中心是完全被动的。

##总结一下

• zookeeper的2181开放给provider、consumer、dubbo-admin

• provider的20880开放给所有consumer，但8080服务器端口可以完全屏蔽

• consumer的8080开放给所有provider

• dubbo-admin的8080开放给管理员用户，便于通过浏览器监控注册中心服务的情况

• 总结：注册中心只负责服务注册和目录发布，安全授权，实际的服务访问仍然是两个组件之间的点对点连接完成，这种方式下整个架构下获取更高的性能，同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈

##附
Zookeeper 下载地址: 点我下载

Dubbo-admin 下载地址: 点我下载

Dubbo-monitor 下载地址: 点我下载

文章来源: shq5785.blog.csdn.net，作者：No Silver Bullet，版权归原作者所有，如需转载，请联系作者。

原文链接：shq5785.blog.csdn.net/article/details/80142770