問題現象
dubbo 服務提供者正常註冊，消費者也正常消費，在dubbo-admin上觀察沒問題。本地服務proxy也正常生成，但無法調用成功。每次調用都是下面的錯誤信息：
Failed to invoke the method getAllowUrls in the service com.xxx.bss.api.AcxxxQueryApi. No provider available for the service com.xxx.bss.api.AcxxxQueryApi:dev from registry 10.0.10.21:15311 on the consumer 10.200.190.182 using the dubbo version 2.6.4. Please check if the providers have been started and registered.
這個問題隱蔽很，應用啓動沒問題，也無啓動報錯信息，甚至warn都沒有。
排查分析
項目在添加新的二方包之後，原來好好的dubbo忽然就調不通了。一開始以爲只是個別服務，嘗試了所有dubbo服務之後，都不成功。報錯都是一樣。檢查了dubbo admin，發現提供者和消費者都正常。
於是朝着包衝突方向去排查，把代碼回退到可以正常調用dubbo服務的版本，也就是未添加新二方包的版本。
於是分析可以調用的版本和調用失敗的版本的包依賴。
最後發現，不能正常調用的代碼版本中，沒有依賴netty-3.2.5.Final.jar 這個包，於是將該包手動強制依賴到項目中。就可以正常調用。
正常情況下，dubbo 包都會傳遞依賴netty包進來的，爲什麼netty包會被幹掉呢。仔細排查代碼中也沒有任何地方進行exclusion.於是懷疑是maven 仲裁的時候，選用了二方包依賴進來的包中某個包恰巧把netty包給幹掉了。導致jar 包依賴短路，短路的包把依賴丟棄了。從而少了netty包。
最後排查結果確實如此，是因爲我新引進來的二方包，將dubbo 包的依賴全部進行exclusion了。
如下圖是包缺失的證據：
netty 包被二方包排除依賴的證據：
解決方法
<dependency>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
<version>${netty_version}</version>
</dependency>
<netty_version>3.2.5.Final</netty_version>
即可解決。不同的dubbo 版本換成對應的netty版本即可。
總結
雖然問題解決了，但是有必要說兩句。
1.二方包想要減少進入業務方代碼，exclusion是好的想法，但exclusion不夠徹底。如果直接exclusion掉dubbo，就不會造成maven仲裁選用缺失依賴的dubbo。
2.dubbo 報錯也不夠友好，很明顯這種異常並不是因爲沒有provider造成的，而是底層網絡框架包丟失了。異常應該更加細化和詳盡。