搭配 Azure Functions 使用 Azure 事件中樞 的解決方案，受益於可調整、符合成本效益且能夠近乎即時地處理大量數據的無伺服器架構。 與這些服務一起順暢地運作，有許多功能、設定和複雜度會為其關聯性增添複雜度。 本文提供如何透過強調效能、復原、安全性、可觀察性和規模的重要考慮和技術，有效利用這項整合的指引。
事件中樞核心概念
Azure 事件中樞 是可高度調整的事件處理服務，每秒可接收數百萬個事件。 在深入瞭解 Azure Functions 整合的模式和最佳做法之前，最好先瞭解事件中樞的基本元件。
下圖顯示事件中樞串流處理架構：
事件
事件是通知或狀態變更，表示為過去發生的事實。 事件是固定的，並保存在事件中樞，也稱為 Kafka 中的主題。 事件中樞是由一或多個 分割區所組成。
資料分割
當傳送者未指定分割區時，接收的事件會分散到事件中樞內的分割區。 每個事件都是以一個分割區撰寫，而且不會跨分割區進行多重轉換。 每個分割區的運作方式都是記錄是以僅限附加模式寫入的記錄檔。 認可記錄的類比經常用來描述如何將事件新增至數據分割中序列結尾的本質。
使用多個數據分割時，它允許從相同的事件中樞內使用平行記錄。 此行為提供多個程度的平行處理原則，並增強取用者的輸送量。
取用者和取用者群組
分割區可由多個取用者取用，每個取用者讀取和管理自己的位移。
事件中樞具有取用者群組的概念，可讓多個取用應用程式各有個別的事件串流檢視，並以自己的步調獨立讀取數據流，以及有自己的位移。
若要深入瞭解，請參閱 深入探討事件中樞的概念和功能。
使用 Azure Functions 取用事件
Azure Functions 支援 事件中樞的觸發 程式和 輸出 系結。 本節說明 Azure Functions 如何使用觸發程式回應傳送至事件中樞事件數據流的事件。
每個事件中樞觸發函式的實例都會由單 一 EventProcessorHost 實例支援。 觸發程式（由事件中樞提供）可確保只有一個 EventProcessorHost 實例可以在指定的分割區上取得租用。
例如，請考慮具有下列特性的事件中樞：
- 10 個分割區。
- 1,000 個事件平均散發所有分割區，每個分割區中的訊息數目不一。
當您的函式第一次啟用時，只有一個函式實例。 讓我們呼叫第一個函式實例 Function_1。 Function_1具有一個 EventProcessorHost 實例，可保留所有 10 個分割區的租用。 這個實例正在從分割區 1-10 讀取事件。 從這一點開始，會發生下列其中一個情況：
不需要新的函式實例：
Function_1可以在 Functions 調整邏輯生效之前處理所有 1,000 個事件。 在此情況下，所有 1,000 則訊息都會由Function_1處理。
已新增其他函式實例：事件型調整或其他自動化或手動邏輯可能會判斷
Function_1訊息數目超過可以處理的訊息，然後建立新的函式應用程式實例 （Function_2）。 這個新函式也有相關聯的 EventProcessorHost 實例。 當基礎事件中樞偵測到新的主機實例嘗試讀取訊息時，它會平衡主機實例之間的分割區。 例如，可能會將分割區 1-5 指派給Function_1，並將 6-10 分割區指派給Function_2。
新增了更多函式實例：事件型調整或其他自動化或手動邏輯會判斷和
Function_1Function_2訊息數目都大於可以處理的訊息，則會建立新的Function_N函式應用程式實例。 實例會建立至 N 等於或大於事件中樞數據分割數目的點。 在我們的範例中，事件中樞會再次對分割區進行負載平衡，在此案例中，整個實例Function_1...Function_10。
發生調整時，N 實例的數目可能大於事件中樞分割區的數目。 當事件驅動調整穩定實例計數時，或是因為其他自動化或手動邏輯所建立的實例數目比分割區多，就可能發生這種情況。 在此情況下， EventProcessorHost 實例只會從其他實例取得數據分割上的鎖定，因為在任何指定時間，只有來自相同取用者群組的一個函式實例可以從其鎖定的分割區存取/讀取。
當所有函式執行完成時（有或沒有錯誤），檢查點會新增至相關聯的記憶體帳戶。 當檢查點成功時，永遠不會再次擷取所有 1,000 則訊息。
使用使用量和進階 Azure 方案，可以進行動態事件型調整。 Kubernetes 裝載的函式應用程式也可以利用 事件中樞的 KEDA 縮放程式。 當函式應用程式裝載於專用 （App Service） 方案中時，目前無法進行事件型調整，因此您必須根據工作負載判斷正確的實例數目。
若要深入瞭解，請參閱 Azure Functions 的 Azure 事件中樞 系結和 Azure Functions 的 Azure 事件中樞 觸發程式。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 大衛·巴科爾 |主要解決方案專家 GBB
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
相關資源
- 監視無伺服器事件處理 提供監視無伺服器事件驅動架構的指引。
- 無伺服器事件處理 是參考架構，詳細說明此類型的一般架構，其中包含程式碼範例和重要考慮的討論。