當用戶請求 A、P、H、I 四個服務獲取數據時，在正常流量下系統穩定運行，如果某天系統進來大量流量，其中服務 I 出現 CPU、內存占用過高等問題，結果導致服務 I 出現延遲、響應過慢，隨著請求的持續增加，服務 I 承受不住壓力導致內部錯誤或資源耗盡，一直不響應，此時更糟糕的是其他服務對 I 有依賴，那么這些依賴 I 的服務一直等待 I 的響應，也會出現請求堆積、資源占用，慢慢擴散到所有微服務，引發雪崩效應。
基本的容錯模式
常見的容錯模式主要包含以下幾種方式：
1.主動超時：Http請求主動設置一個超時時間，超時就直接返回，不會造成服務堆積
2.限流：限制最大并發數
3.熔斷：當錯誤數超過閾值時快速失敗，不調用后端服務，同時隔一定時間放幾個請求去重試后端服務是否能正常調用，如果成功則關閉熔斷狀態，失敗則繼續快速失敗，直接返回。（此處有個重試，重試就是彈性恢復的能力）
4.隔離：把每個依賴或調用的服務都隔離開來，防止級聯失敗引起整體服務不可用
5.降級：服務失敗或異常后，返回指定的默認信息
服務降級
由于爆炸性的流量沖擊，對一些服務進行有策略的放棄，以此緩解系統壓力，保證目前主要業務的正常運行。它主要是針對非正常情況下的應急服務措施：當此時一些業務服務無法執行時，給出一個統一的返回結果。服務熔斷
熔斷這一概念來源于電子工程中的斷路器（Circuit Breaker）。在互聯網系統中，當下游服務因訪問壓力過大而響應變慢或失敗，上游服務為了保護系統整體的可用性，可以暫時切斷對下游服務的調用。服務熔斷與服務降級比較
服務熔斷對服務提供了proxy，防止服務不可能時，出現串聯故障（cascading failure），導致雪崩效應。
服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮。
1.共性：
目的 -> 都是從可用性、可靠性出發，提高系統的容錯能力。
最終表現->使某一些應用不可達或不可用，來保證整體系統穩定。
粒度 -> 一般都是服務級別，但也有細粒度的層面：如做到數據持久層、只許查詢不許增刪改等。
自治 -> 對其自治性要求很高。都要求具有較高的自動處理機制。
2.區別：
觸發原因 -> 服務熔斷通常是下級服務故障引起；服務降級通常為整體系統而考慮。
管理目標 -> 熔斷是每個微服務都需要的，是一個框架級的處理；而服務降級一般是關注業務，對業務進行考慮，抓住業務的層級，從而決定在哪一層上進行處理：比如在IO層，業務邏輯層，還是在外圍進行處理。
實現方式 -> 代碼實現中的差異。
服務熔斷恢復需注意的問題
如果服務是冪等性的，則恢復重試不會有問題；而如果服務是非冪等性的，則重試會導致數據出現問題。
如若轉載，請注明出處：開源字節 https://sourcebyte.cn/article/233.html
