復原事件中樞和函式設計
錯誤處理、設計等冪性和管理重試行為是一些您可以採取的重要措施，以確保事件中樞觸發的函式具有彈性且能夠處理大量數據。 本文涵蓋這些重要概念，並提供無伺服器事件串流解決方案的建議。
Azure 提供三個主要傳訊服務，可與 Azure Functions 搭配使用，以支援各種獨特的事件驅動案例。 由於其分割取用者模型和以高速率擷取數據的能力，Azure 事件中樞 通常用於事件串流和巨量數據案例。 如需 Azure 傳訊服務的詳細比較，請參閱選擇 Azure 傳訊服務 - 事件方格、事件中樞和 服務匯流排。
串流優點和挑戰
瞭解串流的優點和缺點可協助您瞭解事件中樞等服務的運作方式。 當您做出具影響力的架構決策、疑難解答問題，以及優化效能時，您也需要此內容。 請考慮下列關於事件中樞和函式解決方案的重要概念：
串流不是佇列：事件中樞、Kafka，以及以分割取用者模型為基礎的類似供應專案，不會在訊息代理程式中內建支援某些主要功能，例如 服務匯流排。 也許這些差異的最大指標是讀取是 非破壞性的事實。 這可確保 Functions 主機讀取的數據之後仍可供使用。 相反地，訊息是不可變的，而且會保留給其他取用者讀取，包括可能再次讀取相同的取用者。 因此，實作競爭取用者等模式的解決方案可能更適合訊息代理程式，例如 服務匯流排。
缺少固有的寄不出的信件支援： 死信通道不是事件中樞或 Kafka 中的原生功能。 通常， 寄不出的信件概念 會整合到串流解決方案中，以說明無法處理的數據。 這項功能刻意不是事件中樞中的內生元素，而且只會在取用者端新增，以製造類似的行為或效果。 如果您需要寄不出的信件支援，您應該檢閱您選擇的串流訊息服務。
工作單位是分割區： 在傳統訊息代理程式中，工作單位是單一訊息。 在串流解決方案中，分割區通常被視為工作單位。 如果事件中樞中的每個事件視為需要訂單處理或財務事務處理的相異訊息，則建議有機會探索更合適的傳訊服務，以獲得最佳效能或處理。
沒有伺服器端篩選： 事件中樞能夠大幅調整且輸送量的原因之一，是因為服務本身的額外負荷較低。 伺服器端篩選、索引和跨訊息代理程序協調等功能不是事件中樞架構的一部分。 函式偶爾會根據本文或標頭中的內容，將其路由至其他事件中樞來篩選事件。 這種方法在事件串流中很常見，但隨附於初始函式讀取和評估每個事件的警告。
每個讀取器都必須讀取所有數據： 因為伺服器端篩選無法使用，取用者會循序讀取分割區中的所有數據。 這包括可能不相關的數據，甚至可能格式不正確。 您可以使用數個選項和策略來彌補這些挑戰，本節稍後會討論這些挑戰。
這些重要的設計決策可讓事件中樞盡其所能：支援大量事件湧入，併為取用者提供強固且具彈性的服務。 每個取用者應用程式都負責維護自己的用戶端位移或數據指標至這些事件。 低負荷讓事件中樞成為事件串流負擔得起且功能強大的選項。
等冪
Azure 事件中樞的核心原則之一是傳遞至少一次的概念。 此方法可確保一律會傳遞事件。 這也表示函式等取用者可以多次，甚至重複接收事件。 因此，事件中樞觸發的函式必須支援 等冪取用 者模式。
在至少傳遞一次的假設下運作，特別是在事件驅動架構的內容中，是可靠地處理事件的負責任方法。 您的函式必須具有等冪性，以便處理相同事件的結果多次與處理一次相同事件的結果相同。
重複的事件
有幾個不同的案例可能會導致將重複事件傳遞至函式：
檢查點：如果 Azure Functions 主機當機或不符合批次檢查點頻率設定的閾值，則不會建立檢查點。 因此，取用者的位移不會進階，下次叫用函式時，它會從最後一個檢查點繼續。 請務必注意，檢查點會在每個取用者的數據分割層級進行。
已發佈重複的事件： 許多技術可以降低將相同事件發佈至數據流的機會，但取用者仍負責以等冪方式處理重複專案。
遺漏通知： 在某些情況下，服務連出要求可能會成功，不過，永遠不會收到來自服務的通知（ACK）。 這種感知可能會導致傳出呼叫失敗，並從函式起始一系列重試或其他結果。 最後，可以發佈重複的事件，或未建立檢查點。
重複數據刪除技術
針對相同的輸入設計函式應該是與事件中樞觸發程式系結配對時採用的預設方法。 您應該考慮下列技術：
尋找重複專案： 在處理之前，請採取必要步驟來驗證事件是否應該處理。 在某些情況下，這需要調查以確認它仍然有效。 處理事件也可能因為數據新鮮度或使事件失效的邏輯而不再需要處理事件。
設計等冪性事件： 藉由在事件承載內提供其他資訊，可以確保多次處理它不會有任何有害影響。 以事件為例，其中包含從銀行帳戶取款金額的事件。 如果未負責處理，有可能將帳戶餘額遞減多次。 不過，如果相同的事件包含帳戶的更新餘額，它可以用來對銀行帳戶餘額執行 upsert 作業。 這個事件攜帶的狀態轉移方法偶爾需要生產者和取用者之間的協調，而且當參與服務有意義時，應該使用。
錯誤處理和重試
錯誤處理和重試是分散式、事件驅動應用程式和 Functions 的一些最重要的品質，但不會例外。 對於事件串流解決方案，需要適當的錯誤處理支援非常重要，因為如果無法正確處理，數千個事件可能會快速變成相等的錯誤數目。
錯誤處理指引
如果沒有錯誤處理，實作重試、偵測運行時間例外狀況，以及調查問題可能很棘手。 每個函式至少應該有一些層級或錯誤處理。 一些建議的指導方針如下：
使用 Application Insights： 啟用並使用 Application Insights 來記錄錯誤並監視函式的健康情況。 請留意處理大量事件案例的可設定取樣選項。
新增結構化錯誤處理： 針對每個程式設計語言套用適當的錯誤處理建構，以攔截、記錄和偵測函式程式碼中預期的和未處理的例外狀況。 例如，在 C#、Java 和 JavaScript 中使用 try/catch 區塊，並利用 Python 中的區塊來處理例外狀況。
記錄： 在執行期間攔截例外狀況提供了記錄可用來可靠地偵測、重現和修正問題的重要信息的機會。 記錄例外狀況，不只是訊息，而是本文、內部例外狀況和其他有用的成品，稍後會很有説明。
請勿攔截並忽略例外狀況： 您可以執行的最糟糕的事情之一是攔截例外狀況，並且不執行任何動作。 如果您攔截泛型例外狀況，請將它記錄在某處。 如果您未記錄錯誤，則很難調查錯誤和回報的問題。
重試
在事件串流架構中實作重試邏輯可能相當複雜。 支援取消令牌、重試計數和指數輪詢策略只是一些可使其具有挑戰性的考慮。 幸運的是，Functions 提供 重試原則 ，可彌補您通常會自行撰寫程式代碼的許多工作。
使用重試原則搭配事件中樞系結時必須考慮的幾個重要因素，包括：
避免無限次重試：當最大重試計數設定設為 -1 值時，函式會無限期重試。 一般而言，無限次重試應該與 Functions 一起使用，而且幾乎永遠不會搭配事件中樞觸發程式系結使用。
選擇適當的重試策略：固定延遲策略可能最適合從其他 Azure 服務接收回壓的案例。 在這些情況下，延遲有助於避免這些服務發生的節流和其他限制。 指數 輪詢 策略可提供重試延遲間隔的更多彈性，而且通常會在與第三方服務、REST 端點和其他 Azure 服務整合時使用。
保留間隔和重試計數很低： 可能的話，請嘗試維持少於一分鐘的重試間隔。 此外，請將重試嘗試次數上限保留為相當低的數目。 在函式取用方案中執行時，這些設定特別相關。
斷路器模式： 預期會不時發生暫時性錯誤，以及重試的自然使用案例。 不過，如果在處理函式期間發生大量失敗或問題，則停止函式、解決問題並稍後重新啟動可能很合理。
Functions 中重試原則的重要要點是，這是重新處理事件的最佳工作功能。 它無法取代錯誤處理、記錄和其他提供程式碼復原能力的重要模式的需求。
失敗和損毀數據的策略
有數個值得注意的方法可供您用來補償因事件數據流中失敗或不正確的數據而發生的問題。 一些基本策略如下：
停止傳送和讀取： 若要修正基礎問題，請暫停事件的讀取和寫入。 這種方法的優點是數據不會遺失，而且作業可以在修正推出之後繼續。這種方法可能需要架構中的斷路器元件，而且可能需要通知受影響的服務，以達到暫停。 在某些情況下，可能需要停止函式，直到問題解決為止。
卸除訊息： 如果訊息不重要或被視為非任務關鍵性，請考慮繼續且不處理訊息。 這種方法不適用於需要強式一致性的案例，例如在國際象棋比對或以財務為基礎的交易中錄製移動。 建議在函式內部處理錯誤，以攔截和卸除無法處理的訊息。
重試： 有許多情況可能會保證事件的重新處理。 最常見的案例是呼叫另一個服務或相依性時發生的暫時性錯誤。 網路錯誤、服務限制和可用性，以及強式一致性可能是最頻繁的使用案例，可證明重新處理嘗試的合理性。
死信： 這裡的想法是將事件發佈至不同的事件中樞，讓現有的流程不會中斷。 這種看法是，它被移出熱路，可以稍後或由不同的程序處理。 此解決方案經常用來處理有害訊息或事件。 使用不同取用者群組所設定的每個函式仍會遇到其數據流中損毀或損毀的數據，且必須負責處理。
重試和死信： 在達到臨界值之後，最終發佈至無效信件數據流之前，多次重試嘗試的組合，是另一個熟悉的方法。
使用架構登錄： 架構登錄可作為主動式工具，以協助改善一致性和數據品質。 隨著架構的發展，Azure 架構登錄可以支援架構的轉換，以及版本設定和不同的相容性模式。 架構的核心是生產者和取用者之間的合約，這可能會降低發行至數據流之無效或損毀數據的可能性。
最後，沒有完美的解決方案，需要徹底檢查每個策略的後果和取捨。 根據需求，一起使用其中數種技術可能是最佳方法。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- 大衛·巴科爾 |主要解決方案專家 GBB
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
在繼續之前，請考慮檢閱下列相關文章：