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號