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()方法繼續執行就能拿到呼叫