若要處理部分失敗，請使用此處所述的其中一個策略。
跨內部微服務使用異步通訊（例如訊息式通訊）。 強烈建議不要跨內部微服務建立長時間的同步 HTTP 呼叫鏈結，因為不正確的設計最終會成為造成錯誤中斷的主要原因。 相反地，除了用戶端應用程式與第一層微服務或精細 API 閘道之間的前端通訊之外，建議在經過初始要求/回應週期之後，在內部微服務之間只使用異步（訊息型）通訊。 最終一致性和事件驅動架構有助於將波紋效果降到最低。 這些方法會強制執行較高層級的微服務自主性，因此避免發生此處所指出的問題。
使用重試搭配指數退避。 這項技術有助於避免短暫和間歇性失敗，方法是在服務可能僅暫時不可用的情況下，重試請求一定次數。 這可能是因為間歇性網路問題，或當微服務/容器移至叢集中的不同節點時發生。 不過，如果這些重試沒有與熔斷器正確地設計，它可能會加劇連鎖反應，最終甚至導致拒絕服務（DoS）。
解決網路逾時問題。 一般來說，客戶端的設計不應該允許無限期阻塞，應在等待回應時總是使用逾時設定。 使用逾時可確保資源永遠不會無限期地系結。
使用熔斷器模式。 在此方法中，客戶端進程會追蹤失敗的要求數目。 如果錯誤率超過設定的限制，則「斷路器」會跳閘，讓後續嘗試立即失敗。 （如果大量要求失敗，表示服務無法使用，且傳送要求毫無意義。逾時期間之後，客戶端應該再試一次，如果新的要求成功，請關閉斷路器。
提供後援。 在此方法中，客戶端進程會在要求失敗時執行後援邏輯，例如傳回快取的數據或預設值。 這是適合查詢的方法，對於更新或命令而言更為複雜。
限制已排入佇列的要求數目。 用戶端也應該對用戶端微服務可傳送至特定服務之未處理要求數目施加上限。 如果已達到限制，則提出其他要求可能毫無意義，而且這些嘗試應該會立即失敗。 在實作方面，Polly Bulkhead 隔離 原則可用來滿足此需求。 這種方法基本上是一個平行化節流，SemaphoreSlim 作為其實作。 它也允許在艙門外「排隊」。 即使在執行之前，您也可以主動捨去多餘的負載（例如，因為容量被視為已滿）。 這使得其對特定故障情境的反應速度比斷路器快，因為斷路器會等待發生故障。 Polly 中的 BulkheadPolicy 物件會公開 Bulkhead 和佇列的滿度，並提供溢出時觸發的事件，因此也可以用來驅動自動化水平擴充。
其他資源
復原模式
https://learn.microsoft.com/azure/architecture/framework/resiliency/reliability-patterns新增復原和優化效能
https://learn.microsoft.com/previous-versions/msp-n-p/jj591574(v=pandp.10)艙壁。 GitHub 存放庫。 使用 Polly 策略實施。
https://github.com/App-vNext/Polly/wiki/Bulkhead為 Azure 設計有彈性的應用程式
https://learn.microsoft.com/azure/architecture/framework/resiliency/app-design暫時性錯誤處理
https://learn.microsoft.com/azure/architecture/best-practices/transient-faults
