Dubbo分佈式服務框架
基於java的rpc框架（遠程過程調用）是一個soa治理方案
（SOA是Service-Oriented Architecture的首字母簡稱它是一種支持面向服務的架構樣式
Dubbo提供了很多協議，Dubbo協議、RMI協議、Hessian協議，等等
其核心部分包含:
1. 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
2. 集群容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
3. 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。Dubbo能做什麼？
1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。
3. 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。Doubbox 特性：
(1) 連通性：
註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心交互，註冊中心不轉發請求，壓力較小
監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展示
服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷
註冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外
註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
(2) 健狀性：
監控中心宕掉不影響使用，只是丟失部分採樣數據
數據庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務
註冊中心對等集群，任意一臺宕掉後，將自動切換到另一臺
註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊
服務提供者無狀態，任意一臺宕掉後，不影響使用
服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
(3) 伸縮性：
註冊中心為對等集群，可動態增加機器部署實例，所有客戶端將自動發現新的註冊中心
服務提供者無狀態，可動態增加機器部署實例，註冊中心將推送新的服務提供者信息給消費者
(4) 升級性：
當服務集群規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分佈式服務架構不會帶來阻力
Provider
暴露服務方稱之為“服務提供者”。
Consumer
調用 遠程服務方稱之為“服務消費者”。
Registry
服務註冊與發現的中心目錄服務稱之為“服務註冊中心”。
Monitor
統計服務的調用次數和調用時間的日誌服務稱之為“服務監控中心”。
dubbo註冊中心
Dubbo目前支持4種註冊中心,（multicast zookeeper redis simple）
Zookeeper作為Dubbo服務的註冊中心，Dubbo原先基於數據庫的註冊中心，沒采用Zookeeper，Zookeeper一個分佈式的服務框架，是樹型的目錄服務的數據存儲，能做到集群管理數據 ，這裡能很好的作為Dubbo服務的註冊中心，Dubbo能與Zookeeper做到集群部署，當提供者出現斷電等異常停機時，Zookeeper註冊中心能自動刪除提供者信息，當提供者重啟時，能自動恢復註冊數據，以及訂閱請求）
調用
- 服務容器負責啟動，加載，運行服務提供者。
- 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
- 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
- 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
- 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
- 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
Dubbo提供了很多協議，Dubbo協議、RMI協議、Hessian協議
負載均衡：
• 隨機，按權重設置隨機概率。
• 在一個截面上碰撞的概率高，但調用量越大分佈越均勻，而且按概率使用權重後也比較均勻，有利於動態調整提供者權重。
RoundRobin LoadBalance
• 輪循，按公約後的權重設置輪循比率。
• 存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
LeastActive LoadBalance
• 最少活躍調用數，相同活躍數的隨機，活躍數指調用前後計數差。
• 使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。
ConsistentHash LoadBalance
• 一致性 Hash，相同參數的請求總是發到同一提供者。
• 當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
Dubbo的集群容錯機制分為6種，分別是：FailOver，FailFast，FailSafe，FailBack，Forking，Broadcast。
1.FailOver：
• 失敗自動切換，當出現失敗，重試其它服務器。(缺省)
• 通常用於讀操作，但重試會帶來更長延遲。
•
.FailFast
• 快速失敗，只發起一次調用，失敗立即報錯。
• 通常用於非冪等性的寫操作，比如新增記錄。
3.FailSafe
• 失敗安全，出現異常時，直接忽略。
• 通常用於寫入審計日誌等操作。
4.FailBack
• 失敗自動恢復，後臺記錄失敗請求，定時重發。
• 通常用於消息通知操作
5.Forking
• 並行調用多個服務器，只要一個成功即返回。
• 通常用於實時性要求較高的讀操作，但需要浪費更多服務資源
6.Broadcast
• 廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
• 通常用於通知所有提供者更新緩存或日誌等本地資源信息。
