通常，系統的魯棒性來自全面有效的錯誤管理。由于在我們的軟硬件系統環境中，任何一個部分都可能發生錯誤，因此我們需要以不同的方式予以處理。例如：

• 數據中心——整個數據中心(DC)可能由于電源故障、網絡連接故障、環境災難等，而變得不可用。
• 硬件設備——服務器、存儲部件可能出現硬盤故障、磁盤寫滿、可分配的資源耗盡、以及其他硬件錯誤等問題。
• 軟件應用——無論應用程序的技術堆棧如何，都可能出現應用報錯、軟件行為異常、以及程序級別的缺陷等。

為了應對上述來自各個方面的故障，我們往往需要通過如下手段，來提供系統的自愈能力：

• 通過監控，提供電源、網絡、冷卻系統、以及其他方面的冗余，來實現數據中心的高可用性。
• 通過云端部署，來減少錯誤的實例，使用更加成熟的技術堆，基于微服務的分布式架構。
• 監控服務器的各種參數，采用各種高可用性的部署模式，運用帶有DevOps強大功能的容器化模式。
• 通過應用各種可替代的架構與設計模式，來最小化錯誤。例如，用戶請求的異步處理，可以有助于避免服務器過載的出現，并能夠為用戶提供一致性的體驗。

可見，無論是系統架構師、還是應用設計人員，他們的主要目標都要根據實際業務需求和成本影響，精心考慮和設計各個組件的高可用性，并能夠優雅地處理應用程序的錯誤。

模式的簡要說明

目前，業界有許多種架構模式和方法，可以滿足不同的應用架構范式、功能需求、NFR(Non-Failure Request)、以及應用程序的故障恢復能力。例如：

• 如果應用是基于微服務的，那么我們的重點就應當放在微服務的集成依賴性的容錯上。
• 如果應用是基于事件的架構，那么除了正常的錯誤處理之外，我們還應該注意處理冪等性、以及在出現問題時可能造成的數據丟失上。
• 基于API同步的應用程序，雖然可以便捷地將錯誤返回給調用者，但是如果問題持續更長的時間，我們則需要更加實用的監控、以及事件管理機制。
• 在基于批處理的組件中，我們可能應該將重點放在以冪等的方式，重新啟動或恢復原有的批處理能力上。

錯誤代碼

如果沒有關于錯誤代碼的通用約定與指南，每個應用或系統將會按照自定義的默認錯誤代碼方式，根據用例和設計自行處理。而這有可能會導致不同方式相互之間的沖突。可見，在應用程序的錯誤處理過程中，我們該事先定義好錯誤代碼，通過標準化且直觀的錯誤處理方式，既提高解決問題的效率，又能夠通過離線分析的方式，統計錯誤數量、負載峰值、以及特定類型故障的影響等細節。

錯誤處理

下面的示意圖展示了如何在基于事件的應用程序中，處理各種錯誤。當然，其中具體涉及到的步驟，可能會因架構模式的不同而有所差異。

首先，我們應當區分應用程序的可重試(retryable)錯誤和不可重試(non-retryable)錯誤。例如，當輸入的消息本身存在問題時，通常除非得到人工干預，否則重試此類錯誤是沒有意義的。而那些數據庫連接方面的問題，是值得進行重試的。

當應用程序出現重試類型的錯誤時，我們可以選擇統一的“錯誤重試配置”方式，來進行微調處理。如下表所示，在基于事件的服務中，一旦基礎設施組件出現可用性的缺失，我們需要通過預定義的反復重試機制，來及時確認運營商是否已及時修復。這往往比直接懷疑和處置由并發量請求所引發的問題可能性，要更加符合常理。

觸發事件

在所有重試都以失敗告終時，我們需要有一種方法，來觸發事件并升級錯誤。在簡單情況下，我們可以將問題的相關信息，直接以通知的形式，反饋給用戶，并且建議其重新提交所需的請求。但是有些問題源于某個內部技術問題，所引發并導致的用戶體驗度的驟降。例如，在基于事件的架構中，異步集成模式通常使用DLQ(譯者注：Dead Letter Queue，死信隊列)作為錯誤處理模式。不過，DLQ只是整個過程中的一個臨時步驟。我們仍然需要通過觸發事件或發送警報的方式，去可靠地升級錯誤。那么，我們該如何設計一個事件與警報相集成的管理系統呢?下面，我們將討論兩種主要的方法：

第一種方法：當應用程序完成了所有重試之后，我們需要利用其可用的日志功能，構建可靠的錯誤報告路徑，以減少丟失出錯信息的可能。雖然業界已有成熟的日志記錄標準。但是，我們仍然需要將各個錯誤日志區別開來，以免事件管理系統中充滿了不相關的錯誤信息。我們通常將此類日志稱為“錯誤警報”。它們往往是由專用的代碼庫和組件，按照預先設定的格式，及時產生大量的錯誤信息。下面是一段代碼示例：

Java
  {
      "logType": "ErrorAlert",
      "errorCode": "subA.compA.DB.DatabaseA.Access_Error",
      "businessObjectId": "234323",
      "businessObjectName": "ACCOUNT",
      "InputDetails" : "<Input object/ event object>",
      "InputContext" : " any context info with the input",
      "datetime": "date time of the error",
      "errorDetails" : "Error trace",
      "..other info as needed": "..."
  }

由于大多數組織會使用不同的日志監控技術棧，因此，我在此以日志聚合器(log aggregator)為例，會將各種日志路由到不同的組件處，以便讀取日志事件、對應的配置，并按需觸發警報。如下圖所示，如果出現需要在監控的基礎上，去解決被發現的問題時，我們往往需要再次調用DLQ予以處理。

為了讓警報能夠反應有意義且具有操作性的事件，我們通常需要對它們進行必要的配置。由于組織采用的事件管理系統存在著差異性，因此不同的配置可能會驅動不同類型的后續操作。以下是各種需要配置屬性的示例。其錯誤代碼會在整個系統中遵循特定的分類方法。當然，它們也可以按需集中到一個中央的配置管理系統中。

如下圖所示，第二種方法是將錯誤警報的調度程序組件寫入DLQ，而非各個日志中，而其他方面則與第一種方法基本相似。也就是說，它是基于DLQ的。

哪種方法更好?

從應用程序的角度來看，基于日志的方法更具有靈活性，當然也存在著如下缺點：

1. 在錯誤到達事件管理系統之前，我們需要處理各個部件之間的相互集成。
2. 一般來說，日志數據的關鍵性程度并不是很高，但是如果我們用它來觸發事件的話，那么就需要檢查它是否存在著丟失或不全的風險。在曾經的系統實施的過程中，我就曾碰到過應用請求出現的峰值，導致日志數據丟失的問題。當時我們就不得不放棄了該方法。當然，這是一種極端的情況，并非所有的日志記錄環境都會遇到此類狀況。

而基于DLQ的方法則存在著如下優、缺點：

1. 我們可以在消息傳遞系統上，將基于DLQ的方法，作為非DLQ方式的冗余傳輸鏈路。當然，是否真的需要此類冗余機制，則完全取決于所傳輸的數據的重要性。
2. 如果我們需要結合現有系統中的其他應用，那么在將其連接至中央總線(central bus)并發送錯誤警報時，消息路由器的數量則可能會受到一定的限制。而就這種結合方案本身而言，它不但會增加系統的復雜性，而且提高了額外出錯的可能性。
3. 推倒重來的方式只是“看起來很美”。畢竟越少的組件或總線需要被集成，錯誤警報事件傳輸的可靠性才會越高。

小結

可見，為了有效地處理應用程序中可能出現的錯誤，我們需要一種整體的解決方法，能夠無縫地集成到現有的IT系統中，實現對于錯誤和問題的有效管理。雖然上文主要討論的是如何將應用程序的錯誤處理，集成到事件管理系統中，但是對于本文開頭提到的各種硬件問題，此類思路與方法同樣具有適用性。當然，所有這些都應當以自動化的方式，聚集到一處，以便它們能夠進一步關聯上各種錯誤與問題，進而采用單一的解決方案，來處置所有可能出現的問題。

前文也向您展示了兩種依賴于事件管理系統、并能夠與現代技術(如API或某種SDK)相集成的處置方法。當然，具體方法的采用也會因平臺而異。不過值得注意的是，在根據問題創建重復性事件時，為了避免“淹沒”事件管理系統。我們應當盡量少地使用集成，而盡量多地采用開箱即用的事件管理系統。對此，一些自動化的、智能化的事件去重方案，往往能夠有效地解決此類問題。

譯者介紹

陳 峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。

原文標題：Building Resiliency With Effective Error Management，作者：Shailesh Agarwal