Dubbo(x)相關（分散式服務框架）
Dubbo
Dubbo是阿里的分散式服務框架，基於zookeeper實現，已於12年底停止維護升級
Dubbox是噹噹團隊基於dubbo升級的一個版本
與zookeeper的關係：Dubbo將註冊中心進行抽象，使得它可以外接不同的儲存媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
Dubbo各種各樣的RPC、支援自定義協議、統一管理、統一監控、資源整合
dubbo，服務治理工具。實現系統之間通訊。
1）服務提供者：啟動時在指定埠上暴露服務，並將服務地址和埠註冊到註冊中心上。
2）服務消費者：啟動時向註冊中心訂閱自己感興趣的服務，以便獲得服務提供方的地址列表。
3）註冊中心，使用zookeeper實現，相當於房產中介。服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小，負責服務的註冊和發現，負責儲存服務提供方上報的地址資訊，並向服務消費方推送。
4）監控中心：負責收集服務提供方和消費方的執行狀態，比如服務呼叫次數、延遲等，用於監控。將dubbo的war工程部署到tomcat，進行一些配置，即可檢視dubbo
5）執行容器：負責服務提供方的初始化、載入以及執行的生命週期管理。
部署階段
服務提供者在指定埠暴露服務，並向註冊中心註冊服務資訊。
服務消費者向註冊中心發起服務地址列表的訂閱。
執行階段
註冊中心向服務消費者推送地址列表資訊。
服務消費者收到地址列表後，從其中選取一個向目標服務發起呼叫。
呼叫過程服務消費者和服務提供者的執行狀態上報給監控中心。
Dubbo超時的實現原理
dubbo預設採用了netty作為網路元件，它屬於一種NIO的模式。消費端發起遠端請求後，執行緒不會阻塞等待服務端的返回，而是馬上得到一個ResponseFuture，消費端通過不斷的輪詢機制判斷是否有返回結果。因為是通過輪詢，輪詢有個需要特別注要的就是避免死迴圈，所以為了解決這個問題就引入了超時機制，只在一定時間範圍內做輪詢，如果超時就返回超時異常。
Dubbo超時重試機制帶來的資料重複問題
常見的應用場景故障: 1、傳送郵件(重複) ；2、賬戶註冊(重複).。
解決方案:
1.對於核心的服務中心，去除dubbo超時重試機制，並重新評估設定超時時間。
(1)、去掉超時重試機制
<dubbo:provider delay="-1" timeout="6000" retries="0"/>
(2)、重新評估設定超時時間
<dubbo:service interface="*.*" ref="*" timeout="延長服務時間"/>
2.業務處理程式碼必須放在服務端，客戶端只做引數驗證和服務呼叫，不涉及業務流程處理
Dubbo的優勢
- 服務註冊中心
- 叢集多種容錯方案（ZK會通過心跳確認dubbo是否宕機）
-
- Failover Cluster（預設）
失敗自動切換，當出現失敗，重試其它伺服器。通常用於讀操作，但重試會帶來更長延遲。可通過 retries="2" 來設定重試次數(不含第一次)。
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
<dubbo:reference> <dubbo:method name="findFoo" retries="2" /> </dubbo:reference>
-
- Failfast Cluster
快速失敗，只發起一次呼叫，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
-
- Failsafe Cluster
安全失敗，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
-
- Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於訊息通知操作。
-
- Forking Cluster
並行呼叫多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設定最大並行數
-
- Broadcast Cluster
廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯 。通常用於通知所有提供者更新快取或日誌等本地資源資訊
3. 直連提供者
在開發階段為了方便測試，通常系統客戶端能指定呼叫某個服務提供者，那麼可以在引用服務時加一個url引數去指定服務提供者
4. 負載均衡：當有多個提供者在提供服務時，能夠使用多種方案選擇提供者
Random 隨機選提供者，並可以給提供者設定權重
RoundRobin 輪詢選擇提供者
LeastActive 最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。使慢的提供者收到更少請求，因為越慢的提供者的呼叫前後計數差會越大。
ConsistentHash 一致性hash，相同引數的請求發到同一臺機器上
服務端服務級別
<dubbo:service interface="..." loadbalance="roundrobin" />
客戶端服務級別
<dubbo:reference interface="..." loadbalance="roundrobin" />
服務端方法級別
<dubbo:service interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:service>
客戶端方法級別
<dubbo:reference interface="..."> <dubbo:method name="..." loadbalance="roundrobin"/></dubbo:reference>
5、服務版本、服務分組
通過服務版本可以控制服務的不相容升級，當同一個服務有多種實現時，可以使用服務分組進行區分
6、多協議
dubbo提供了多種協議給使用者選擇，如dubbo、hessian、rmi。並可為每個服務指定不同的傳輸協議，粒度可以細化到方法，不同服務在效能上適用不同協議進行傳輸，比如大資料用短連線協議，小資料大併發用長連線協議
分散式服務框架、RPC框架
分散式服務框架有：Dubbo、RMI 、Hessian、Webservice、Thrift、grpc(google)、motan、Spring Cloud…
- rpcx: 基於Go的服務治理的rpc框架、客戶端支援跨語言
- grpc: Google 出品的跨語言rpc框架，很弱的(實驗性的)負載均衡, 測試使用的是grpc-go
- go std rpc: Go標準庫的rpc, 不支援跨語言(jsonrpc支援json rpc 1.0)
- thrift: 跨語言的rpc框架，facebook貢獻
- dubbo: 國內較早開源的服務治理的Java rpc框架，雖然在阿里巴巴內部競爭中落敗於HSF，沉寂了幾年，但是在國內得到了廣泛的應用，目前dubbo專案又獲得了支援，並且dubbo 3.0也開始開發
- motan: 微博內部使用的rpc框架，底層支援java,生態圈往service mesh發展以支援多語言
- hprose: 國內開發人員開發的一個跨語言的rpc框架，非服務治理但是效能高效
- twirp: twitch.tv剛剛開源的一個restful風格的rpc框架
- go-micro: Go語言的一個服務治理rpc框架， 在測試中發現效能不太好，所以沒有繼續測試，相關的測試程式碼已在github庫中
- go kit:
- 騰訊 Tars:騰訊公司的rpc框架
- 百度 brpc: 百度公司的rpc框架
- spring cloud:
發展歷史：
1、為了不同語言構造的系統之間能夠互相呼叫
出現了webservice ：不同系統之間互動資料的時候，採用同一種資料格式xml，這種協議稱為soap，soap 協議可以基於http協議傳輸資料，也可以基於ftp smtp 等其他協議傳遞資料，但是大多數都是基於http 。
2、客戶端不知道該傳遞什麼引數，不知道遠端伺服器有提供哪些服務
出現了webservice的介面說明文件wsdl，用這種文件來說明介面的詳情
3、除了webservice 的思想，還有一部分的思想是，不同的語言之間可以建立一種第三方語言，大家可以建立自己對第三方語言的對映
- PHPRPC，Hessian，JSON-RPC
- 框架：
- Microsoft WCF，WebAPI
- ZeroC Ice，Thrift，GRPC protocol buffer
- Hprose
兩種思想的優缺點比較：
首先，都實現了跨語言，這是可以稱讚的。
webservice 的缺點： soap 協議 訊息封裝太複雜，採用xml 傳輸資料，網路消耗和 cpu 解析消耗都特別大，不適合傳遞大量資料，客戶端需要生成很多stub 類。
rpc 框架 ： 傳輸資料多采用二進位制格式 ，訊息序列化和反序列化都比較快，網路消耗小，缺點是客戶端和服務端都要生成很多stub類。
如果 idl 做了修改， 還要重新生成一遍 stub 類。
參考連結：