1)Dubbo 提供了聲明式緩存，用于加速熱門數(shù)據(jù)的訪問速度，以減少用戶加緩存的工作量。
2)Dubbo 2.2.0 以上版本支持服務降級。
3)Dubbo目前暫時不支持，后續(xù)可能采用基于 JTA/XA 規(guī)范實現(xiàn)。
4)Dubbo 允許配置多協(xié)議，在不同服務上支持不同協(xié)議或者同一服務上同時支持多種協(xié)議。
當一個接口有多種實現(xiàn)時，可以用 group 屬性來分組，服務提供方和消費方都指定同一個 group 即可。
Dubbo 缺省會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止 Spring 初始化完成，默認 check="true"，可以通過 check="false" 關閉檢查。
可以的，啟動 dubbo 時，消費者會從 zookeeper 拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。每次調(diào)用時，按照本地存儲的地址進行調(diào)用。
去除dubbo超時重試機制，并重新評估設置超時時間。業(yè)務處理代碼必須放在服務端，客戶端只做參數(shù)驗證和服務調(diào)用，不涉及業(yè)務流程處理。
當然Dubbo的重試機制其實是非常好的QOS保證，它的路由機制，是會幫你把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質(zhì)量。但是請一定要綜合線上的訪問情況，給出綜合的評估。
檢查 dubbo 的 jar 包有沒有在 classpath 中，以及有沒有重復的 jar 包
檢查暴露服務的 spring 配置有沒有加載
在服務提供者機器上測試與注冊中心的網(wǎng)絡是否通
可以用版本號（version）過渡，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。
容錯指的是某種系統(tǒng)控制在一定范圍內(nèi)的一種允許或包容犯錯情況的發(fā)生。具體容錯策略如下：
1.Failover Cluster失敗自動切換：dubbo的默認容錯方案，當調(diào)用失敗時自動切換到其他可用的節(jié)點，具體的重試次數(shù)和間隔時間可通過引用服務的時候配置，默認重試次數(shù)為1也就是只調(diào)用一次。
2.Failback Cluster失敗重新恢復：在調(diào)用失敗，記錄日志和調(diào)用信息，然后返回空結(jié)果給consumer，并且通過定時任務每隔5秒對失敗的調(diào)用進行重試
3.Failfast Cluster快速失?。褐粫{(diào)用一次，失敗后立刻拋出異常
4.Failsafe Cluster失敗安全：調(diào)用出現(xiàn)異常，記錄日志不拋出，返回空結(jié)果
5.Forking Cluster并行調(diào)用多個服務提供者：通過線程池創(chuàng)建多個線程，并發(fā)調(diào)用多個provider,結(jié)果保存到阻塞隊列，只要有一個provider成功返回結(jié)果，就會立刻返回結(jié)果
6.Broadcast Cluster廣播模式：逐個調(diào)用每個provider,如果其中一臺報錯，在循環(huán)調(diào)用結(jié)束后，拋出異常
RandomLoadBalance:隨機負載均衡。隨機的選擇一個。是Dubbo的默認負載均衡策略。
RoundRobinLoadBalance:輪詢負載均衡。輪詢選擇一個。
LeastActiveLoadBalance:最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機。活躍數(shù)指調(diào)用前后計數(shù)差。使慢的 Provider 收到更少請求，因為越慢的 Provider 的調(diào)用前后計數(shù)差會越大。
ConsistentHashLoadBalance:一致性哈希負載均衡。相同參數(shù)的請求總是落在同一臺機器上。
Dubbo是通過 JDK 的 ShutdownHook 來完成優(yōu)雅停機的，所以如果使用 kill -9 PID 等強制關閉指令，是不會執(zhí)行優(yōu)雅停機的，只有通過 kill PID 時，才會執(zhí)行。
Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 實現(xiàn)分布式服務追蹤
官方微信
官方抖音
京公網(wǎng)安備 11030102010736號