Dubbo基本原理機制

轉自:http://blog.csdn.net/paul_wei2008/article/details/19355681分布式服務架構：

–高效能和透明化的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，讓其唯一，然後傳遞給服務端，再服務端又回傳回來，這樣就知道結果是原先哪個線程的了。