處理非預期的失敗是解決的最困難問題之一，特別是在分散式系統中。 開發人員撰寫的大部分程式代碼都牽涉到處理例外狀況，這也是測試花費最多時間的地方。 問題比撰寫程式代碼來處理失敗更為相關。 當執行微服務的計算機失敗時，會發生什麼事？ 您不僅需要偵測此微服務失敗（這本身就是一個困難的問題），還需要可以重啟微服務的工具或方法。
微服務需要具備抵抗故障的能力，並能經常在其他機器上重新啟動，以保持可用性。 此復原功能也會歸結到代表微服務儲存的狀態，其中微服務可以從中復原此狀態，以及微服務是否可以成功重新啟動。 換句話說，計算功能中必須有復原能力（程式可以隨時重新啟動），以及狀態或數據中的復原能力（不會遺失數據，且數據會保持一致）。
復原問題在其他案例期間會複雜化，例如在應用程式升級期間發生失敗時。 微服務與部署系統搭配使用，必須判斷它是否可以繼續前進到較新版本，或改為復原至舊版，以維持一致的狀態。 考慮的問題包括是否有足夠的機器以持續運行，及如何復原舊版微服務。 這種方法需要微服務發出健康情況資訊，讓整體應用程式和協調器可以做出這些決策。
此外，復原能力與雲端式系統必須如何運作有關。 如前所述，雲端系統必須接受失敗，並嘗試自動從中復原。 例如，如果網路或容器失敗，用戶端應用程式或用戶端服務必須有重試傳送訊息或重試要求的策略，因為在許多情況下，雲端中的失敗是部分性的。 本指南中的 實作復原應用程式 一節說明如何處理部分失敗。 它描述了使用 Polly 等庫中的技術，例如以指數回退重試或在 .NET 中應用的斷路器設計模式，這些庫提供了多種策略來處理這個主題。
微服務中的健康情況管理和診斷
它看起來可能很明顯，而且通常被忽略，但微服務必須報告其健康情況和診斷。 否則，從營運的角度來看，幾乎沒有什麼洞察力。 將診斷事件在一組獨立的服務中相互關聯，並處理機器時鐘偏差，使我們理解事件的順序，這是具有挑戰性的。 與微服務透過已同意的通訊協定和數據格式進行互動的同時，也需要標準化記錄健康和診斷事件的方法，這些事件最終會出現在事件存儲庫中，以供查詢和檢視。 在微服務方法中，不同小組就單一記錄格式達成一致是關鍵。 需要有一致的方法來檢視應用程式中的診斷事件。
健康檢查
健康情況與診斷不同。 健康檢查是指微服務報告其目前狀態以便採取適當的措施。 良好的範例是使用升級和部署機制來維護可用性。 雖然服務目前可能因為進程當機或機器重新啟動而狀況不良，但服務可能仍在運作中。 你最不需要的是藉由執行升級來加劇這種情況。 最佳方法是先進行調查，或讓微服務有時間復原。 微服務的健康情況事件可協助我們做出明智的決策，並實際上協助建立自我修復服務。
在本指南 ASP.NET 核心服務 中的實作健康情況檢查一節中，我們會說明如何在微服務中使用新的 ASP.NET HealthChecks 連結庫，以便他們向監視服務報告其狀態，以採取適當的動作。
您也可以選擇使用名為 AspNetCore.Diagnostics.HealthChecks 的優秀開放原始碼連結庫，以 GitHub 和 NuGet 套件的形式提供。 此程式庫也會執行健康檢查，並且以一種扭曲的方式來處理兩種類型的檢查：
- 即時性：檢查微服務是否還活著，也就是說，如果能夠接受要求並回應。
- 整備程度：檢查微服務的相依性（資料庫、佇列服務等）是否已就緒，讓微服務可以執行應該執行的動作。
使用診斷和記錄事件數據流
記錄提供應用程式或服務執行方式的相關信息，包括例外狀況、警告和簡單的參考訊息。 通常，每個記錄檔都採用每一個事件一行的文字格式，不過例外狀況通常也會跨多行顯示堆棧追蹤。
在整合型伺服器型應用程式中，您可以將記錄寫入磁碟上的檔案（logfile），然後使用任何工具加以分析。 由於應用程式執行僅限於固定伺服器或 VM，因此分析事件的流程通常並不複雜。 不過，在跨協調器叢集中許多節點執行多個服務的分散式應用程式中，能夠將分散式事件相互關聯是一項挑戰。
微服務型應用程式不應該嘗試自行儲存事件或記錄檔的輸出數據流，甚至不應該嘗試管理事件的路由至中央位置。 這應該是透明化的，這表示每個程式都應該只將其事件數據流寫入標準輸出，這些輸出將由其運行的執行環境基礎結構收集。 這些事件串流路由器的範例是 Microsoft.Diagnostic.EventFlow，它會從多個來源收集事件數據流，並將其發佈至輸出系統。 這些可能包括開發環境或雲端系統的簡單標準輸出，例如 Azure 監視器 和 Azure 診斷。 也有良好的第三方記錄分析平臺和工具，可以搜尋、警示、報告和監視記錄，甚至是即時的，例如 Splunk 或 中間件。
管理健康情況和診斷資訊的協調器
當您建立微服務型應用程式時，您需要處理複雜性。 當然，單一微服務很容易處理，但數十或數百個類型和數千個微服務實例是一個複雜的問題。 這不僅僅是要建置微服務架構，您也需要高可用性、可尋址性、復原性、健康情況和診斷，如果您想要有穩定且一致的系統。
圖 4-22。 微服務平臺是應用程式健康情況管理的基礎
圖 4-22 中顯示的複雜問題很難自行解決。 開發小組應著重於解決商務問題，並使用微服務型方法建置自定義應用程式。 他們不應專注於解決複雜的基礎結構問題：如果這樣做，任何微服務型應用程式的成本都會很大。 因此，有一個微服務導向的平臺，稱為協調器或微服務叢集，試圖解決建置和執行服務以及有效率地使用基礎結構資源的難題。 此方法可減少建置使用微服務方法的應用程式的複雜性。
不同的協調器聽起來可能很類似，但每個協調器所提供的診斷和健康情況檢查在功能和成熟度狀態上有所不同，有時取決於OS平臺，如下一節所述。
其他資源
Twelve-Factor 應用程式。 十一。 記錄：將記錄視為事件數據流
https://12factor.net/logsMicrosoft 診斷事件流程函式庫 GitHub 存放庫。
https://github.com/Azure/diagnostics-eventflow什麼是 Azure 診斷
https://learn.microsoft.com/azure/azure-diagnostics將 Windows 電腦連線到 Azure 監視器服務
https://learn.microsoft.com/azure/azure-monitor/platform/agent-windows記錄您所指的內容：使用語意記錄應用程式區塊
https://learn.microsoft.com/previous-versions/msp-n-p/dn440729(v=pandp.60)Splunk 官方網站。
https://www.splunk.com/中間件 官方網站。
https://middleware.io/EventSource 類別 適用於 Windows 事件追蹤的 API （ETW）
https://learn.microsoft.com/dotnet/api/system.diagnostics.tracing.eventsource
