[[417222]]

本文轉載自微信公眾號「數倉寶貝庫」，作者張利兵 。轉載本文請聯系數倉寶貝庫公眾號。

不想看字的同學可直接劃到底部查看思維導圖

問題分析

使用過Dubbo的朋友很多都碰到過如下報錯：

No provider available for the service org.newboo.basic.api.MyDemoService from registry 127.0.0.1:2181 on the consumer 127.0.0.1 using the dubbo version 2.7.6. Please check if the providers have been started and registered.

從源碼來看這個報錯位于

org.apache.dubbo.rpc.cluster.support.AbstractClusterInvoker#checkInvokers

protected void checkInvokers(List<Invoker<T>> invokers, Invocation invocation) { 
    if (CollectionUtils.isEmpty(invokers)) { 
        throw new RpcException(RpcException.NO_INVOKER_AVAILABLE_AFTER_FILTER, "Failed to invoke the method " 
                + invocation.getMethodName() + " in the service " + getInterface().getName() 
                + ". No provider available for the service " + getDirectory().getConsumerUrl().getServiceKey() 
                + " from registry " + getDirectory().getUrl().getAddress() 
                + " on the consumer " + NetUtils.getLocalHost() 
                + " using the dubbo version " + Version.getVersion() 
                + ". Please check if the providers have been started and registered."); 
    } 
} 

當配置reference的check=false時調用它的代碼位于

org.apache.dubbo.rpc.cluster.support.FailoverClusterInvoker#doInvoke

(為true時在啟動時校驗)

從代碼能看出導致這個報錯的直接原因是：invokers為空

此處invoker對應一個provider URL，當沒有provider可用時，invokers為空

排查思路

這個問題看似簡單，但實際情況異常復雜，碰到后無從下手，本文提供一種可行的排查思路。

排查大致分為兩條線，provider端和consumer端。

provider端

出問題第一時間排查provider，因為provider的情況比較少，可以簡單地排除一部分情況。

provider出問題只有一種情況：未注冊到注冊中心

所以對應的排查思路是去看provider有沒有注冊成功：

• 如果有dubbo控制臺或者注冊中心查詢頁面，直接查詢一下即可
• 如果沒有可視化界面，比如zk、etcd可通過相應的客戶端連上去查看是否注冊成功

以zk為例，可通過 ls /dubbo/${service}/providers 查看注冊上的provider

如果provider未注冊成功，那么就需要排查，可能的原因有：

• provider未啟動成功，啟動一下即可
• provider雖然啟動了，但注冊失敗了，查看一下錯誤日志，對癥解決
• 注冊中心地址是否寫錯?環境是否一致?

如果provider已經注冊，說明provider沒問題，再看consumer。

consumer端

consumer端排查還需再細分，以是否訂閱(拉取)到對應provider信息為界

如何查看consumer的訂閱信息

consumer訂閱信息可從緩存文件中查看，緩存文件默認按如下規則生成：

tring defaultFilename = System.getProperty("user.home") + "/.dubbo/dubbo-registry-" + url.getApplication() + "-" + url.getAddress().replaceAll(":", "-") + ".cache"; 

例如：

~/.dubbo/dubbo-registry-ddog-my-demo-c0-127.0.0.1-2181.cache

有多個注冊中心，將有多個緩存文件，文件內容如下：

#Dubbo Registry Cache 
#Wed Aug 11 20:26:15 CST 2021 
org.newboo.basic.api.MyDemoService=empty\://127.0.0.1/org.newboo.basic.api.MyDemoService?application\=ddog-my-demo-c0&category\=routers&check\=false&dubbo\=2.0.2&init\=false&interface\=org.newboo.basic.api.MyDemoService&loadbalance\=xxx&methods\=call&owner\=roshilikang&pid\=3084&qos.enable\=true&qos.port\=33333&release\=2.7.6&side\=consumer&sticky\=false&timestamp\=1628684774590 empty\://127.0.0.1/org.newboo.basic.api.MyDemoService?application\=ddog-my-demo-c0&category\=configurators&check\=false&dubbo\=2.0.2&init\=false&interface\=org.newboo.basic.api.MyDemoService&loadbalance\=xxx&methods\=call&owner\=roshilikang&pid\=3084&qos.enable\=true&qos.port\=33333&release\=2.7.6&side\=consumer&sticky\=false&timestamp\=1628684774590 dubbo\://127.0.0.1\:20880/org.newboo.basic.api.MyDemoService?anyhost\=true&application\=ddog-my-demo-p0&deprecated\=false&dubbo\=2.0.2&dynamic\=true&generic\=false&interface\=org.newboo.basic.api.MyDemoService&methods\=call&owner\=roshilikang&pid\=2058&release\=2.7.6&side\=provider&threads\=500&timestamp\=1628684412247 

搜索文件中是否有對應服務的provider

未成功訂閱

如果沒拿到信息(搜索不到對應的provider)，說明訂閱存在問題，檢查consumer日志是否有報錯，注冊中心地址，環境等配置是否有問題。

成功訂閱

比如這個文件，存在

dubbo\://127.0.0.1\:20880/org.newboo.basic.api.MyDemoService?anyhost\=true&application\=ddog-my-demo-p0&deprecated\=false&dubbo\=2.0.2&dynamic\=true&generic\=false&interface\=org.newboo.basic.api.MyDemoService&methods\=call&owner\=roshilikang&pid\=2058&release\=2.7.6&side\=provider&threads\=500&timestamp\=1628684412247 

說明consumer已經拿到了provider信息

當consumer拿到provider，也不一定就能保證調用不會報No provider，有這么幾種情況需要排查

• 檢查consumer的group、version是否和provider完全匹配，不匹配會報No provider
• 是否被禁用，搜索緩存文件中是否有該服務對應的override URL，且disabled=true
• consumer是否配置了路由規則，如tag路由，條件路由等，路由規則可能導致No provider

group、version是否匹配，有一個不看代碼就知道consumer的version、group配置的小技巧，如果consumer指定了version或group，報錯信息如下(group=read，version=1.0)：

No provider available from registry 127.0.0.1:2181 for service read/org.newboo.basic.api.MyDemoService:1.0 on consumer 127.0.0.1 use dubbo version 2.7.6

service前包含group，用斜線分隔，service后有version用冒號分隔。

以上可覆蓋95%的場景，還有一種比較少見：consumer生成invoker失敗導致invokers為空;

此種情況請仔細檢查錯誤日志，不明的報錯需要關注。此處列舉一些碰到過的case

1. Dubbo 2.6.x中transport實現了netty和netty4，而在2.6.10版本中，netty transport擴展名字被改為了netty3;如果provider使用dubbo 2.6.10且指定了transport為netty3，低版本的dubbo調用時因為沒有實現netty3的擴展而導致invoker生成失敗;此時consumer端看起來是拿到了provider的URL，但也會報No provider錯誤
2. 與1類似，當自定義某些擴展只在provider使用時，provider的一些參數會傳遞給consumer，讓consumer也使用相同擴展，但consumer不一定實現了該擴展，導致invoker生成失敗;比如自定義的dispatcher擴展。

注：可能你會問為什么provider的參數會傳遞給consumer?這合理嗎?舉個例子，如果provider指定序列化協議為json，那consumer是否也要按照provider的序列化協議json來傳輸數據呢?只能說沒有萬全的設計

總結

跟很多問題排查思路一樣，根據已有現象一步步縮小排查范圍，最終鎖定根本原因。用一副思維導圖來總結：