Dubbo是阿里開源的 ，基於Java開發的一款分散式服務框架，它擁有高效能和透明化的RPC遠端服務呼叫方案以及SOA服務治理方案。Dubbo與Spring無縫整合，並且提供了遠端通訊、叢集容錯、服務自動註冊與發現三大核心功能。
提供了透明化的遠端方法呼叫，只需要簡單的配置，呼叫遠端方法就像呼叫本地方法一樣，沒有任何API的侵入。同時它具備軟負載均衡以及容錯機制，在內網可直接替代F5等硬體裝置實現負載均衡。還可以實現服務自動註冊和發現，不需要寫死服務提供著的IP地址，註冊中心基於介面名查詢服務提供著的IP地址，並且可以平滑的增加和刪除服務提供著。
三大核心功能
遠端通訊：提供了多種基於長連線的NIO框架，多種執行緒模型，多種序列化，以及多種請求響應的資訊交換方式。
叢集容錯：提供了透明的基於介面方法的遠端呼叫，包括多協議支援，軟負載均衡，失敗容錯，地址路由，動態配置等叢集的支援。
五大元件關係
角色說明
Container：服務執行容器，只啟動一次
Provider：服務提供者
Registry：服務註冊與發現的註冊中心
Consumer：服務消費者
Monitor：統計服務的呼叫次數和呼叫時間的監控中心
呼叫關係說明
0、服務容器負責啟動，載入，執行服務提供者。
1、服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2、服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3、註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4、服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
5、服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo的特性
基於透明介面的RPC：Dubbo提供了基於高效能介面的RPC，對使用者是透明的；
智慧負載均衡：Dubbo開箱即用地支援多種負載平衡策略，該策略可感知下游服務狀態以減少總體延遲並提高系統吞吐量；
自動服務註冊和發現：Dubbo支援多個服務登錄檔，可以立即檢測線上/離線服務；
高擴充套件性：Dubbo的微核心和外掛設計確保第三方實現可以輕鬆地將其擴充套件為協議，傳輸和序列化等核心功能；
執行時流量路由：可以在執行時配置Dubbo，以便可以根據不同的規則路由流量，這使得支援藍綠色部署，資料中心感知路由等功能變得容易；
視覺化服務治理：Dubbo提供了用於服務管理和維護的豐富工具，例如查詢服務元資料，執行狀況和統計資訊；
Dubbo架構的特性
連通性
監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示
服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷
註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外
註冊中心透過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
健壯性
監控中心宕機不影響使用，只是會丟失部分取樣資料
資料庫宕機後，註冊中心任然可以透過快取提供服務列表查詢，只是不能再註冊新的服務
註冊中心對等叢集中，任意一臺宕機，會自動切換到另一臺
註冊中心全部宕機，服務消費者和服務提供著任然可以透過本地快取通訊
服務提供著無狀態，任意一臺宕機，不影響使用
服務提供著全部宕機，服務消費者將無法使用，並且會無限次迴圈等待服務提供著恢復
伸縮性
註冊中心是對等叢集，可動態的增加機器部署例項，所有的客戶端會自動發現新的服務
服務提供著無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者的地址給服務消費者
未來架構的升級性
當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力
Dubbo優缺點
優點
1、透明化的基於介面方法的遠端呼叫，只需簡單的配置，呼叫遠端方法就像呼叫本地方法一樣，並且沒有任何API的侵入；
2、軟負載均衡和容錯機制，在內網直接可以替換Ngnix lvs以及F5硬體裝置等，實現負載均衡；
3、服務的自動註冊與發現，動態的配置管理。基於註冊中心的目錄服務，不需要寫死服務提供方的IP地址，服務消費方會根據介面名查詢服務提供方的IP地址；
4、服務介面的監控與治理，Dubbo-admin與Dubbo-monitor提供了完善的服務介面管理與監控功能，針對不同應用的不同介面，可以進行 多版本，多協議，多註冊中心管理；
缺點
目前只支援Java
Dubbo的執行緒模型
Dubbo是阿里開源的 ，基於Java開發的一款分散式服務框架，它擁有高效能和透明化的RPC遠端服務呼叫方案以及SOA服務治理方案。Dubbo與Spring無縫整合，並且提供了遠端通訊、叢集容錯、服務自動註冊與發現三大核心功能。
提供了透明化的遠端方法呼叫，只需要簡單的配置，呼叫遠端方法就像呼叫本地方法一樣，沒有任何API的侵入。同時它具備軟負載均衡以及容錯機制，在內網可直接替代F5等硬體裝置實現負載均衡。還可以實現服務自動註冊和發現，不需要寫死服務提供著的IP地址，註冊中心基於介面名查詢服務提供著的IP地址，並且可以平滑的增加和刪除服務提供著。
三大核心功能
遠端通訊：提供了多種基於長連線的NIO框架，多種執行緒模型，多種序列化，以及多種請求響應的資訊交換方式。
叢集容錯：提供了透明的基於介面方法的遠端呼叫，包括多協議支援，軟負載均衡，失敗容錯，地址路由，動態配置等叢集的支援。
五大元件關係
角色說明
Container：服務執行容器，只啟動一次
Provider：服務提供者
Registry：服務註冊與發現的註冊中心
Consumer：服務消費者
Monitor：統計服務的呼叫次數和呼叫時間的監控中心
呼叫關係說明
0、服務容器負責啟動，載入，執行服務提供者。
1、服務提供者在啟動時，向註冊中心註冊自己提供的服務。
2、服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
3、註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
4、服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
5、服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo的特性
基於透明介面的RPC：Dubbo提供了基於高效能介面的RPC，對使用者是透明的；
智慧負載均衡：Dubbo開箱即用地支援多種負載平衡策略，該策略可感知下游服務狀態以減少總體延遲並提高系統吞吐量；
自動服務註冊和發現：Dubbo支援多個服務登錄檔，可以立即檢測線上/離線服務；
高擴充套件性：Dubbo的微核心和外掛設計確保第三方實現可以輕鬆地將其擴充套件為協議，傳輸和序列化等核心功能；
執行時流量路由：可以在執行時配置Dubbo，以便可以根據不同的規則路由流量，這使得支援藍綠色部署，資料中心感知路由等功能變得容易；
視覺化服務治理：Dubbo提供了用於服務管理和維護的豐富工具，例如查詢服務元資料，執行狀況和統計資訊；
Dubbo架構的特性
連通性
監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示
服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷
服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷
註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外
註冊中心透過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表
註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
健壯性
監控中心宕機不影響使用，只是會丟失部分取樣資料
資料庫宕機後，註冊中心任然可以透過快取提供服務列表查詢，只是不能再註冊新的服務
註冊中心對等叢集中，任意一臺宕機，會自動切換到另一臺
註冊中心全部宕機，服務消費者和服務提供著任然可以透過本地快取通訊
服務提供著無狀態，任意一臺宕機，不影響使用
服務提供著全部宕機，服務消費者將無法使用，並且會無限次迴圈等待服務提供著恢復
伸縮性
註冊中心是對等叢集，可動態的增加機器部署例項，所有的客戶端會自動發現新的服務
服務提供著無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者的地址給服務消費者
未來架構的升級性
當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力
Dubbo優缺點
優點
1、透明化的基於介面方法的遠端呼叫，只需簡單的配置，呼叫遠端方法就像呼叫本地方法一樣，並且沒有任何API的侵入；
2、軟負載均衡和容錯機制，在內網直接可以替換Ngnix lvs以及F5硬體裝置等，實現負載均衡；
3、服務的自動註冊與發現，動態的配置管理。基於註冊中心的目錄服務，不需要寫死服務提供方的IP地址，服務消費方會根據介面名查詢服務提供方的IP地址；
4、服務介面的監控與治理，Dubbo-admin與Dubbo-monitor提供了完善的服務介面管理與監控功能，針對不同應用的不同介面，可以進行 多版本，多協議，多註冊中心管理；
缺點
目前只支援Java
Dubbo的執行緒模型