Dubbo深刻學習瞭解

1. Dubbo的生產者須要配置dubbo service標籤，這裏面有幾個核心參數要配置：
   1. Id名
   2. Interface 接口路徑
   3. Ref 接口名
   4. Registry 註冊zk上的地址
   5. Group分組
   6. Check 檢查服務是不是可用的 默認check是true的，設置爲true的話，默認服務在啓動時，檢查到不可用時會拋出異常，防止spring將服務加載進容器中，能夠最快速的發現問題。。咱們組的話在測試環境上通常會配置成false的
   7. Retries 超時嘗試重連。Dubbo在超時後未配置的狀況下，默認的重連次數是2次，咱們的實際配置是0次
   8. Timeout，dubbo響應超時時間，這個根據實際業務狀況設定，未設置的狀況下默認是1000毫秒

 

1. Dubbo的消費者須要配置dubbo reference標籤，核心參數與生產端一致
2. Dubbo默認是使用dubbo協議的，咱們使用的也是dubbo協議，能夠根據dubbo  protocol標籤來配置切換協議。
   1. 連接個數：單連接
   2. 連接方式：長鏈接
   3. 傳輸協議：TCP
   4. 傳輸方式：NIO異步傳輸
   5. Dubbo適用於請求入參數據較小的狀況，對於文件、超大字符串不建議使用
   6. Dubbo的消費者數量是遠大於提供者的，此時經過NIO保證穩定（單一長鏈接防止阻塞）
3. Dubbo的通訊過程

首先咱們已經知道了dubbo是採用socket長鏈接雙工的模式來處理通訊的，那從客戶端發起請求，到遠程服務端響應，這是一個異步的過程，這個過程是如何實現的呢

 

1. 首先，客戶端發起dubbo調用請求，此時呢dubbo會根據內置機制生成一個惟一的識別標識id
2. 將調用信息（接口名稱、入參、接口方法）以及callback相應信息所有封裝成一個Object對象
3. 將id和object放進一個全局的concurrentHashMap(客戶端和服務端都在用)中的put方法中
4. 而後再把這個id和Object封裝成一個conRequest類，使用IOsession.write(conRequest)異步發送出去
5. 而後客戶端發完請求之後，會使用callback方法的get方法試圖去獲取遠程服務端的響應結果，此時先要經過synchronized獲取鎖，而後開始檢查是否有響應結果，若是沒有的話，就經過wait方法，先把鎖釋放掉，讓線程繼續去等待
6. ===============客戶端的活動暫時到這，接下來開始服務端的表演=============
7. 服務端開始處理業務邏輯，處理完之後，把處理結果放進Object對象裏的callback中，而後經過id找到concurrentHashmap，把結果put進去。同時將結果回傳給客戶端
8. 客戶端是專門有一個監聽消息的線程，當他監聽到有結果返回時，使用synchronized獲取回調對象callback的鎖（由於前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處於等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了）。