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