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 類。
參考鏈接：