處理部分失敗

在微服務架構應用程式等分散式系統中，部分失敗的風險無所不在。 例如，單一微服務/容器可能會失敗或暫時無法回應，或是單一 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 呼叫鏈結太長的微服務而擴大

若要減輕非同步微服務整合會強制執行微服務的自主一節中的這個問題，此指南建議您跨內部微服務使用非同步通訊。

此外，請務必設計微服務和用戶端應用程式來處理部分失敗，也就是建置具有恢復功能的微服務和用戶端應用程式。