分布式服務框架：

• 高性能和透明化的RPC遠程服務調用方案
• SOA服務治理方案
• Apache MINA 框架基于Reactor模型通信框架，基于tcp長連接

Dubbo缺省協議采用單一長連接和NIO異步通訊，
適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況
分析源代碼，基本原理如下：

client一個線程調用遠程接口，生成一個唯一的ID（比如一段隨機字符串，UUID等），Dubbo是使用AtomicLong從0開始累計數字的

將打包的方法調用信息（如調用的接口名稱，方法名稱，參數值列表等），和處理結果的回調對象callback，全部封裝在一起，組成一個對象object

向專門存放調用信息的全局ConcurrentHashMap里面put(ID, object)

將ID和打包的方法調用信息封裝成一對象connRequest，使用IoSession.write(connRequest)異步發送出去

當前線程再使用callback的get()方法試圖獲取遠程返回的結果，在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，如果沒有，然后調用callback的wait()方法，釋放callback上的鎖，讓當前線程處于等待狀態。

服務端接收到請求并處理后，將結果（此結果中包含了前面的ID，即回傳）發送給客戶端，客戶端socket連接上專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap里面get(ID)，從而找到callback，將方法調用結果設置到callback對象里。

監聽線程接著使用synchronized獲取回調對象callback的鎖（因為前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處于等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了），至此，整個過程結束。

當前線程怎么讓它“暫停”，等結果回來后，再向后執行？

答：先生成一個對象obj，在一個全局map里put(ID,obj)存放起來，再用synchronized獲取obj鎖，再調用obj.wait()讓當前線程處于等待狀態，然后另一消息監聽線程等到服 務端結果來了后，再map.get(ID)找到obj，再用synchronized獲取obj鎖，再調用obj.notifyAll()喚醒前面處于等待狀態的線程。

正如前面所說，Socket通信是一個全雙工的方式，如果有多個線程同時進行遠程方法調用，這時建立在client server之間的socket連接上會有很多雙方發送的消息傳遞，前后順序也可能是亂七八糟的，server處理完結果后，將結果消息發送給client，client收到很多消息，怎么知道哪個消息結果是原先哪個線程調用的？

答：使用一個ID，讓其唯一，然后傳遞給服務端，再服務端又回傳回來，這樣就知道結果是原先哪個線程的了。

總結

以上是生活随笔為你收集整理的Dubbo基本原理机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。