服務不同，容錯策略往往也不同。
消費者根據配置的路由策略選擇某個目標地址之後，發起遠程服務調用，在此期間如果發生了遠程服務調用異常，則需要服務框架進行集群容錯，重新進行選路和調用。集群容錯是系統自動執行的，上層用戶並不需要關心底層的服務調用過程。
一、失敗自動切換（Failover）
服務調用失敗自動切換策略指的是當發生RPC調用異常時，重新選路，查找下一個可用的服務提供者。
服務發佈的時候，可用指定服務的集群容錯策略。消費者可用覆蓋服務提供者的通用配置，實現個性化的容錯策略。
Failover策略的設計思路如下：消費者路由操作完成之後，獲得目標地址，調用通信框架的消息發送接口發送請求，監聽服務端的應答。如果返回的結果是RPC調用異常（超時、流控、解碼失敗等系統異常），根據消費者集群容錯的策略進行容錯路由，如果是Failover，則重新返回到路由Handler的入口，從路由節點繼續執行。選路完成之後，對目標地址進行比對，防止重新路由到故障服務節點，過濾掉上次的故障服務提供者之後，調用通信框架的消息發送節課發送請求信息。
分佈式服務框架提供Failover容錯策略，但是用戶在使用時需要自己保證用對地方，下面是Failover策略的應用場景總結：
讀操作，因為通常是冪等的。
冪等性操作，保證調用1次與N次效果相同。
需要特別指出的是，失敗重試會增加服務調用時延，因此框架必須對失敗重試的次數做限制，通常默認是3，防止無限制重試導致服務調用時延不可控。
二、失敗通知（Failback）
在很多業務場景中個，消費者需要能夠獲取到服務調用失敗的具體信息，通過對失敗錯誤碼等異常信息的判斷，決定後續的執行策略，例如非冪等性的服務調用。
Failback的設計方案如下：服務框架獲取到服務提供者返回的RPC異常響應後，根據策略進行容錯。如果是Failback模式，則不再重試其他服務提供者，而是將RPC異常通知給消費者，由消費者捕獲異常進行後續處理。
三、失敗緩存（Failcache）
Failcache策略是失敗自動恢復的一種，在實際項目中他的應用場景如下：
服務有狀態路由，必須定點發送到指定的服務提供者。當發生鏈路中斷、流控等服務暫時不可用時，服務框架將消息臨時緩存起來，等待週期T，重新發送，知道服務提供者能夠正常處理該消息。
對時延要求不敏感的服務。系統服務調用失敗，通常是鏈路暫時不可用、服務流控、GC掛住服務提供者線程等，這種失敗不是永久性的失敗，他的恢復是可預期的。如果消費者對服務調用時延不敏感，可以考慮採用自動恢復模式，即先緩存，再等待，最後重試。
通知類服務。例如通知粉絲積分增長、記錄接口日誌等，對服務調用的實時性要求不高，可以容忍自動恢復帶來的時延增加。
為了保證可靠性，Failcache策略在設計的時候需要考慮如下幾個要素：
緩存時間、緩存對象上限數等需要作出限制，防止內存溢出。
緩存淘汰算法的選擇，是否支持用戶配置。
定是充實的週期T、充實的最大次數等需要作出限制並支持用戶指定。
重試達到最大上線仍失敗，需要丟棄消息，記錄異常日誌。
四、快速失敗（Failfast）
在業務高峰期，對於一些非核心的服務，希望只調用一次，失敗也不再重試，為重要的核心服務節約寶貴的運行資源。此時，快速失敗是個不錯的選擇。
快速失敗策略的設計比較簡單，獲取到服務調用異常之後，直接忽略異常，記錄異常日誌。
五、容錯策略擴展
無論服務框架默認支持多少種容錯策略，業務在實際使用中一定會有不適應的地方。通過開放容錯策略接口的方式，可以支持用戶自定義擴展容錯策略。
在集群容錯設計的時候，需要考慮擴展性名主要從以下幾個方面進行設計：
容錯接口的開放。
屏蔽底層細節，用戶定製簡單。
配置應該天生支持擴展，不要讓用戶擴展服務框架Schema。