Dubbo是阿里巴巴開源的基于 Java 的高性能 RPC 分布式服務框架，現已成為 Apache 基金會孵化項目。其核心部分包含：
1)集群容錯：提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
2)遠程通訊：提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
3)自動發現：基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
因為是阿里開源項目，國內很多互聯網公司都在用，已經經過很多線上考驗。內部使用了 Netty、Zookeeper，保證了高性能高可用性。使用 Dubbo 可以將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，可用于提高業務復用靈活擴展，使前端應用能更快速的響應多變的市場需求。透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。
Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。
SpringC主從中心loud 使用的 Eureka ，Dubbo推薦使用zookeeper
SpringCloud 將一個應用定義為一個服務,Dubbo 將一個接口定義為一個服務，
SpringCloud是一個生態，而Dubbo是SpringCloud生態中關于服務調用一種解決方案(服務治理）
dubbo：單一長連接和 NIO 異步通訊，適合大并發小數據量的服務調用，以及消費者遠大于提供者。傳輸協議 TCP，異步，Hessian 序列化；
rmi：采用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象需要實現 Serializable 接口，使用 java 標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議 TCP。多個短連接，TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞；
webservice：基于 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；
http：基于 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短連接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多于消費者，需要給應用程序和瀏覽器 JS 調用；
hessian：集成 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 內嵌 Jetty 作為服務器時默認實現，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大于消費者，提供者壓力較大，可傳文件；
memcache：基于 memcached 實現的 RPC 協議 redis：基于 redis 實現的 RPC 協議
首先Dubbo在2014 年開始停止維護過幾年，17 年開始重新維護，并進入了 Apache 項目。
Dubbox 是繼 Dubbo 停止維護后，當當網基于 Dubbo 做的一個擴展項目，如加了服務可 Restful 調用，更新了開源組件等。
管理控制臺主要包含：路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡，等管理功能。
Dubbo 的設計目的是為了滿足高并發小數據量的 rpc 調用，在大數據量下的性能表現并不好，建議使用 rmi 或 http 協議。
Dubbo是一個分布式的服務框架，底層是通過RPC來完成服務和服務之間的調用的。RPC(Remote Procedure Call Protocol)是一種遠程調用協議， 允許像調用本地服務那樣調用遠程其它服務，即實現跨進程交互。Dubbo分為四個模塊，分別為：注冊中心（Registry）、提供者（Provider）、消費者（Consumer）和監控（Monitor）。
1.注冊中心（Registry）：可以是zookeeper、redis、multicast、simple（官方推薦使用Zookeeper）；
2.提供者（Provider）：服務啟動時，Provider引用容器中的服務，并向Registry注冊服務信息（包括IP地址，服務名，方法定義等），同時暴露服務（Consumer是直接和Provider通訊實現服務調用的）。
3.消費者（Consumer）：服務啟動時，Consumer向Registry訂閱服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務注冊到注冊中心以后，注冊中心會將這些服務通過notify到消費者。Consumer直接調用Provider提供的服務。
4.監控（Monitor）：Consumer和Provider會通過異步的方式定時向Monitor發送消息，報告服務的狀態。Monitor在整個架構中是可選的，Monitor功能需要單獨配置，不配置或者配置后掛掉并不會影響服務的調用。
所以，Dubbo的實現思路是通過注冊中心實現服務的動態注冊與發現，Provider暴露服務，Consumer直接和Provider通訊實現服務間的調用的。
1)Dubbo 提供了聲明式緩存，用于加速熱門數據的訪問速度，以減少用戶加緩存的工作量。
2)Dubbo 2.2.0 以上版本支持服務降級。
3)Dubbo目前暫時不支持，后續可能采用基于 JTA/XA 規范實現。
4)Dubbo 允許配置多協議，在不同服務上支持不同協議或者同一服務上同時支持多種協議。
當一個接口有多種實現時，可以用 group 屬性來分組，服務提供方和消費方都指定同一個 group 即可。
Dubbo 缺省會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止 Spring 初始化完成，默認 check="true"，可以通過 check="false" 關閉檢查。
可以的，啟動 dubbo 時，消費者會從 zookeeper 拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用。
去除dubbo超時重試機制，并重新評估設置超時時間。業務處理代碼必須放在服務端，客戶端只做參數驗證和服務調用，不涉及業務流程處理。
當然Dubbo的重試機制其實是非常好的QOS保證，它的路由機制，是會幫你把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況，給出綜合的評估。
檢查 dubbo 的 jar 包有沒有在 classpath 中，以及有沒有重復的 jar 包
檢查暴露服務的 spring 配置有沒有加載
在服務提供者機器上測試與注冊中心的網絡是否通
可以用版本號（version）過渡，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。
容錯指的是某種系統控制在一定范圍內的一種允許或包容犯錯情況的發生。具體容錯策略如下：
1.Failover Cluster失敗自動切換：dubbo的默認容錯方案，當調用失敗時自動切換到其他可用的節點，具體的重試次數和間隔時間可通過引用服務的時候配置，默認重試次數為1也就是只調用一次。
2.Failback Cluster失敗重新恢復：在調用失敗，記錄日志和調用信息，然后返回空結果給consumer，并且通過定時任務每隔5秒對失敗的調用進行重試
3.Failfast Cluster快速失敗：只會調用一次，失敗后立刻拋出異常
4.Failsafe Cluster失敗安全：調用出現異常，記錄日志不拋出，返回空結果
5.Forking Cluster并行調用多個服務提供者：通過線程池創建多個線程，并發調用多個provider,結果保存到阻塞隊列，只要有一個provider成功返回結果，就會立刻返回結果
6.Broadcast Cluster廣播模式：逐個調用每個provider,如果其中一臺報錯，在循環調用結束后，拋出異常
RandomLoadBalance:隨機負載均衡。隨機的選擇一個。是Dubbo的默認負載均衡策略。
RoundRobinLoadBalance:輪詢負載均衡。輪詢選擇一個。
LeastActiveLoadBalance:最少活躍調用數，相同活躍數的隨機。活躍數指調用前后計數差。使慢的 Provider 收到更少請求，因為越慢的 Provider 的調用前后計數差會越大。
ConsistentHashLoadBalance:一致性哈希負載均衡。相同參數的請求總是落在同一臺機器上。
Dubbo是通過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用 kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有通過 kill PID 時，才會執行。
Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 實現分布式服務追蹤
官方微信
官方抖音
京公網安備 11030102010736號