在這分布式系統(tǒng)架構(gòu)盛行的時代，很多互聯(lián)網(wǎng)大佬公司開源出自己的分布式RPC系統(tǒng)框架，例如：阿里的dubbo，谷歌的gRPC，apache的Thrift。

而在我們公司一直都在推薦使用dubbo，今天就來講講在使用dubbo過程出現(xiàn)的qos-server端口沖突問題。

什么是dubbo的qos-server呢？

qos是dubbo的在線運維命令，dubbo2.5.8新版本重構(gòu)了telnet模塊，提供了新的telnet命令支持，新版本的telnet端口與dubbo協(xié)議的端口是不同的端口，默認為22222，可以通過配置文件dubbo.properties修改。

在dubbo2.5.7版本之前是不支持注解配置的，因此公司框架對dubbo做了二次封裝，通過自定義注解@EnableDuubo來支持dubbo的注解配置，并簡化了server provider，server consumer，server registry配置，開發(fā)人員只要在spring boot啟動類中添加@EnableDuubo即可開始自己的業(yè)務(wù)代碼開發(fā)，節(jié)省大量的時間。

最近在項目開發(fā)過程中由于需要調(diào)試，在本地同一臺機器上開了兩個運行實例，一個是dubbo provider實例，一個是dubbo consumer實例。

首先啟動provider實例沒有任務(wù)問題，當啟動consumer以后，控制臺卻拋出如下問題，

為了解決端口沖突，開始在項目中使用各種idea搜索快捷鍵搜索關(guān)鍵字qos-server和22222都沒有搜索到任何信息。

一般日志都會打印包名和類型，便于快速定位問題，然后這里日志打印根本沒有輸出包名和類，趕緊修改日志打印格式配置，終于得到如下錯誤信息

原來是這個錯誤是dubbo的com.alibaba.dubbo.qos.server的Server類中打印出來，查看Server類源碼發(fā)現(xiàn)在方法start中調(diào)用了netty的初始化方法，并將port作為被外部訪問的qos-server端口，代碼如下

問題來了

問題1

什么時候會啟用qos服務(wù)呢，端口是何時被賦值的呢？

在Server類中可以看到唯一為 port參數(shù)賦值的方法只有setPor()方法，查看發(fā)現(xiàn)也只有在QosProtocolWrapper中調(diào)用了setPort()方法，查看源碼可以發(fā)現(xiàn)，在該類的startQosServer()方法中會首先從url中解析qos.enable參數(shù)，如果未獲取到該參數(shù)值，則默認啟動qos服務(wù)，同時服務(wù)端口也是從url中解析，默認使用22222。

問題2

那么這個url到底是啥呢？

其實斷點程序可以發(fā)現(xiàn)，該url就是項目中對dubbo的一些配置信息，例如注冊中心地址，超時時間，超時重試次數(shù)等等，由于項目中沒有對qos服務(wù)的配置，因此全部采用了默認配置，導致端口沖突。

問題3 

如何禁用qos服務(wù)呢？

雖然qos端口沖突并影響服務(wù)消費者消費服務(wù)，但是每次程序啟動總是拋出端口沖突異常，有強迫證的程序肯定以為程序哪里出錯了，總會有那么一點忐忑。

而且大多數(shù)情況可能并不需要這個qos服務(wù)，默認開啟浪費端口，浪費機器資源（雖然資源占用并不一定很多），如果你是 java 注解配置，可以通過如下代碼禁用qos服務(wù)，有些版本可能沒有提供該API，如下是dubbo 2.6.2中的API

或者通過dubbo官網(wǎng)已經(jīng)給出了文檔來配置

dubbo2.6.8 的配置項
dubbo.application.qos-port=2222
dubbo.application.qos-enable=true
dubbo.application.qos-accept-foreign-ip=false

問題4

為什么我獨立搭建dubbo分布式服務(wù)的時候沒有出現(xiàn)qos-server端口沖突呢？

原因在于qos-server 需要netty4版本的支持，默認情況下dubbo不會引用netty4的依賴包，（而項目中有依賴netty4，因此拋出端口異常，）因此在QosProtocolWrapper類中調(diào)用Server類的start()方法啟動qos服務(wù)時，會拋出ClassNotFoundException，QosProtocolWrapper的startQosServer()方法僅僅try catch了異常，未做任何處理，因此根本沒有拋出任何異常，這是極其反對的一種做法，至少打個日志啊。

源碼如下：

總結(jié)

1.開發(fā)過程中日志打印及日志打印格式是非常重要的，可能大大減少問題定位的時間，因此一定要注意有效的日志輸出

2.要學會解決問題的思路，端口沖突是一個很常見的問題，通過百度或者谷歌搜索可能幾分鐘就能解決，只是想借此來更多的了解框架的實現(xiàn)細節(jié)，知其然知其所以然。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。