在像微服務型應用程式一樣的分散式系統中，始終存在局部故障的風險。 例如，單一微服務/容器可能會失敗或可能無法在短時間內回應，或單一 VM 或伺服器可能會當機。 由於客戶端和服務是個別的進程，因此服務可能無法及時回應用戶端的要求。 服務可能會超載並回應非常緩慢的要求，或可能因為網路問題而短暫無法存取。
例如，請考慮 eShopOnContainers 範例應用程式的 [訂單詳細數據] 頁面。 如果使用者嘗試提交訂單時，排序微服務沒有回應，則用戶端程式（MVC Web 應用程式）的不良實作，例如，如果用戶端程式代碼使用同步 RPC 且沒有逾時，將會無限期地封鎖線程等候回應。 除了建立不良的用戶體驗之外，每個沒有回應的等候都會耗用或封鎖線程，而且線程在高度可調整的應用程式中非常有價值。 如果有許多封鎖的線程，應用程式運行時間最終可能會用盡線程。 在此情況下，應用程式可能會變成全域無回應，而不只是部分沒有回應，如圖 8-1 所示。
圖 8-1。 部分失敗，因為相依性會影響服務線程可用性
在以微服務為基礎的大型應用程式中，任何部分失敗都可以放大，特別是如果大部分的內部微服務互動是以同步 HTTP 呼叫為基礎（這被視為反模式）。 想想每天接收數百萬個來電的系統。 如果您的系統有一個錯誤的設計，以長鏈同步 HTTP 呼叫為基礎，這些連入呼叫可能會導致數百萬個傳出呼叫 （假設 1：4 的比例） 與數十個內部微服務作為同步相依性。 在圖 8-2 中顯示了此情況，特別是依賴項 #3，它啟動了一個鏈結，呼叫依賴項 #4，然後呼叫 #5。
圖 8-2。 不正確設計中包含長串 HTTP 請求的影響
在分散式和雲端系統中，間歇性失敗是無法避免的，即使每個相依性本身的可用性都非常出色。 這是你需要考慮的事實。
如果您未設計和實施技術來確保故障容忍，即使是短暫的停機時間也可能擴大。 例如，每個具有99.99% 可用性的50個相依性會導致每個月停機數小時，因為這種波紋效應。 當微服務相依性在處理大量要求時失敗時，該失敗可能會快速使每個服務中的所有可用要求線程飽和，並當機整個應用程式。
圖 8-3。 由長鏈同步 HTTP 呼叫的微服務放大的部分故障
若要將此問題降到最低，在 異步微服務整合強制執行微服務的自主權一節中，本指南鼓勵您在內部微服務之間使用異步通訊。
此外，您必須設計微服務和用戶端應用程式來處理部分失敗，也就是建置復原的微服務和用戶端應用程式。
