底層原理。 默認重試兩次

dubbo在調用服務不成功時，默認會重試2次。
Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質量。
但是如果不合理的配置重試次數，當失敗時會進行重試多次，這樣在某個時間點出現性能問題，調用方再連續重復調用，
系統請求變為正常值的retries倍，系統壓力會大增，容易引起服務雪崩，需要根據業務情況規劃好如何進行異常處理，何時進行重試。

Dubbo缺省協議采用單一長連接和NIO異步通訊，

適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況

分析源代碼，基本原理如下：

1. client一個線程調用遠程接口，生成一個唯一的ID（比如一段隨機字符串，UUID等），Dubbo是使用AtomicLong從0開始累計數字的
2. 將打包的方法調用信息（如調用的接口名稱，方法名稱，參數值列表等），和處理結果的回調對象callback，全部封裝在一起，組成一個對象object
3. 向專門存放調用信息的全局ConcurrentHashMap裏面put(ID, object)
4. 將ID和打包的方法調用信息封裝成一對象connRequest，使用IoSession.write(connRequest)異步發送出去
5. 當前線程再使用callback的get()方法試圖獲取遠程返回的結果，在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，如果沒有，然後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態。
6. 服務端接收到請求並處理後，將結果（此結果中包含了前面的ID，即回傳）發送給客戶端，客戶端socket連接上專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap裏面get(ID)，從而找到callback，將方法調用結果設置到callback對象裏。
7. 監聽線程接著使用synchronized獲取回調對象callback的鎖（因為前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處於等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了），至此，整個過程結束
   1. • 當前線程怎麽讓它“暫停”，等結果回來後，再向後執行？
      答：先生成一個對象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是一種分布式服務框架。 Webservice也是一種服務框架，但是webservice並不是分布式的服務框架，他需要結合F5實現負載均衡。因此，dubbo除了可以提供服務之外，還可以實現軟負載均衡。它還提供了兩個功能Monitor 監控中心和調用中心。這兩個是可選的，需要單獨配置。

我們解釋以下這個架構圖：

Consumer服務消費者，Provider服務提供者。Container服務容器。消費當然是invoke提供者了，invoke這條實線按照圖上的說明當然同步的意思了，多說一句，在實際調用過程中，Provider的位置對於Consumer來說是透明的，上一次調用服務的位置（IP地址）和下一次調用服務的位置，是不確定的。這個地方就是實現了軟負載。

服務提供者先啟動start，然後註冊register服務。

消費訂閱subscribe服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務註冊到註冊中心以後，註冊中心會將這些服務通過notify到消費者。

Monitor這是一個監控，圖中虛線表明Consumer 和Provider通過異步的方式發送消息至Monitor，Consumer和Provider會將信息存放在本地磁盤，平均1min會發送一次信息。Monitor在整個架構中是可選的（圖中的虛線並不是可選的意思），Monitor功能需要單獨配置，不配置或者配置以後，Monitor掛掉並不會影響服務的調用。

二、dubbo原理

本篇博客的內容總體上比較抽象，如果一個想馬上使用dubbo的同學來說，讀這篇博客效果不太好，本篇博客沒有寫怎麽使用、配置dubbo，接下來，我再令寫一篇dubbo入門包含demo的博客。

I、初始化過程細節：
上圖中的第一步start，就是將服務裝載容器中，然後準備註冊服務。和Spring中啟動過程類似，spring啟動時，將bean裝載進容器中的時候，首先要解析bean。所以dubbo也是先讀配置文件解析服務。
解析服務：
1）、基於dubbo.jar內的Meta-inf/spring.handlers配置，spring在遇到dubbo名稱空間時，會回調DubboNamespaceHandler類。
2）、所有的dubbo標簽，都統一用DubboBeanDefinitionParser進行解析，基於一對一屬性映射，將XML標簽解析為Bean對象。
源碼截圖：
在ServiceConfig.export 或者ReferenceConfig.get 初始化時，將Bean對象轉會為url格式，將所以Bean屬性轉成url的參數。
然後將URL傳給Protocol擴展點，基於擴展點的Adaptive機制，根據URL的協議頭，進行不同協議的服務暴露和引用。

a、 只暴露服務端口

在沒有使用註冊中心的情況，這種情況一般適用在開發環境下，服務的調用這和提供在同一個IP上，只需要打開服務的端口即可。
即，當配置 or
ServiceConfig解析出的URL的格式為：
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0
基於擴展點的Adaptiver機制，通過URL的“dubbo：//”協議頭識別，直接調用DubboProtocol的export（）方法，打開服務端口。

b、向註冊中心暴露服務：

和上一種的區別：需要將服務的IP和端口一同暴露給註冊中心。
ServiceConfig解析出的url格式為：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

基於擴展點的Adaptive機制，通過URL的“registry：//”協議頭識別，調用RegistryProtocol的export方法，將export參數中的提供者URL先註冊到註冊中心，再重新傳給Protocol擴展點進行暴露：
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

dubbo的底層原理