事件格線
Azure 服務匯流排
此架構基於 基本企業整合 架構，但包含如何整合企業後端系統。 此架構會使用訊息代理程式和事件來分離服務，以取得更大的延展性和可靠性。 務必熟悉基本整合架構的設計與元件。 這些專案提供此架構核心元件的基本資訊。
架構
本設計所參考的後端系統包括軟體即服務（SaaS）系統、Azure 服務、基於訊息的服務，以及企業內現有的網路服務。
下載此架構的Visio檔案。
案例詳細資料
前述架構建立在 基本企業整合架構之上。 它使用 Azure Logic Apps 直接與後端系統協調工作流程，並使用 Azure API 管理 建立 API 目錄。
此版本的架構會新增兩個元件，以協助讓系統更可靠且可調整：
Azure 服務匯流排 是一個安全且可靠的訊息中介。
Azure 事件方格 是一項事件路由服務。 它採用 發佈與訂閱 事件模式。
此架構會透過訊息代理程式使用異步通訊，而不是對後端服務進行直接的同步呼叫。 異步通訊提供下列優點：
使用 基於佇列的負載平準模式 處理工作負載的突發情況，透過佇列平準化改善負載平衡。
採用 Publisher-Subscriber 模式 ，讓你能向多個消費者廣播訊息
追蹤長時間執行的工作流程的進展，即便涉及多個步驟或多個應用程式也一樣
協助分離應用程式
與現有的訊息式系統整合
提供在後端系統無法使用時將訊息排入佇列的功能
使用 Azure 事件方格，讓系統中的各個元件能在事件發生時即時反應，而不必依賴輪詢或排程任務。 與消息佇列和主題類似，事件方格有助於分離應用程式和服務。 如果應用程式或服務發佈事件，任何感興趣的訂閱者都會收到通知。 您可以新增訂閱者，而不需更新寄件者。
許多 Azure 服務支援將事件傳送到事件網格。 例如，Azure Logic Apps 可以在新增檔案加入 blob store 時監聽事件。 此模式會建立回應式工作流程，在其中上傳檔案或將訊息放在佇列上，會啟動一系列進程。 進程可能會以平行或特定順序執行。
建議
請考慮下列建議。 更多建議請參閱 基本企業整合架構。
服務匯流排
服務匯流排 提供兩種傳遞模式：拉取模式與代理推送模式。
拉式模型： 接收器會持續輪詢以獲取新訊息。 如果您需要管理多個隊列和輪詢時間，輪詢可能效率不高。 但此模型可以簡化您的架構，因為它會移除額外的元件和數據躍點。
代理推送模型： 接收者最初訂閱事件網格主題上的特定事件類型。 當有新訊息可用時，服務匯流排 會透過事件格狀網格（Event Grid）引發並發送事件。 此事件會觸發接收端從 服務匯流排 拉取下一批訊息。 此模型可讓系統幾乎即時接收訊息，但不需要使用資源持續輪詢新訊息。 此架構會使用您必須部署、管理及保護的額外元件。
當你建立一個會消耗 服務匯流排 訊息的標準邏輯應用程式工作流程時，請使用 服務匯流排 內建的連接器觸發器。 內建連接器會觸發擷取大部分提取模型設定，而不需要增加額外的成本。 這項功能可在成本、介面區管理和安全性之間提供正確的平衡，因為連接器會在 Logic Apps 執行時間引擎內持續迴圈。 欲了解更多資訊，請參見 服務匯流排內建連接器觸發器。
使用 PeekLock 模式 來存取一組訊息。 當您使用 PeekLock 時，邏輯應用程式可以執行步驟來驗證每個訊息，再完成或放棄訊息。 此方法可防止意外遺失訊息。
事件方格
當事件網格觸發時，表示 至少發生了一次 事件。 例如，當邏輯應用程式收到 服務匯流排 訊息的事件網格觸發器時，可能會有多個訊息可供處理。
考量
這些考量實現了 Azure Well-Architected 框架的支柱，這是一套指導原則，用以提升工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。
可靠性
可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 欲了解更多資訊，請參閱 可靠性設計審查清單。
Microsoft Entra ID 是一個全球分布式、高度可用的 SaaS 平台。
你可以根據業務需求和成本容忍度，部署 Azure API 管理 在多種高可用性配置中。 欲了解更多資訊，請參閱 確保 API 管理的可用性與可靠性。
Logic Apps Consumption 層級支援地理冗餘儲存。 欲了解更多資訊，請參閱 邏輯應用程式的業務持續性與災難復原。
事件網格中主題、系統主題、網域及事件訂閱與事件資料的資源定義，會自動在區域內的可用性區域間複製。 當其中一個可用性區域發生失敗時，事件網格資源會自動故障轉移至另一個可用性區域，而不需要人為介入。 欲了解更多資訊，請參閱 跨區域災難復原與業務持續性。
所有 服務匯流排 等級皆支援可用性區域。
有關每項服務的保證可用性詳情，請參閱線上服務的服務水平協議(SLA)。
安全性
安全提供防範蓄意攻擊及珍貴資料與系統被濫用的防護。 請參閱 安全性設計審查清單 以獲取更多資訊。
為確保 服務匯流排 的安全性，請將 Microsoft Entra 認證 與 受管理的身分識別 配對。 Entra ID 整合用於 服務匯流排 資源，提供 Azure 角色基礎存取控制（Azure RBAC），以細緻控制客戶端對資源的存取。 你可以使用 Azure RBAC 授權給安全主體，例如使用者、群組或應用程式服務主體。 此案例中的應用程式服務主體是受控識別。
如果無法使用 Entra ID，請使用共享存取簽章（SAS）認證，授權使用者存取及特定權限使用 服務匯流排 資源。
例如，如果你需要將 服務匯流排 佇列或主題暴露為 HTTP 端點來發布新訊息，請使用 API Management 透過前置端點來協助保護佇列。 接著，您可以使用憑證或 OAuth 驗證來協助保護端點的安全。 協助保護端點的最簡單方式是使用具有 HTTP 要求或回應觸發程式的邏輯應用程式作為媒介。
事件方格服務可協助透過驗證程式代碼保護事件傳遞。 如果您使用 Logic Apps 來取用事件，驗證就會自動進行。 如需詳細資訊，請參閱 Event Grid 安全性和驗證。
網路安全性
請考慮整個設計中的網路安全性。
你可以將 服務匯流排 Premium 綁定到虛擬網路子網服務端點。 此設定有助於保護命名空間，因為它只接受來自授權虛擬網路的流量。 你也可以使用 Azure Private Link 只允許透過 private endpoints 對虛擬網路進行私人流量。
你可以設定 Logic Apps Standard 接受透過 私有端點 的入站流量，並透過 虛擬網路整合傳送出站流量。
你可以使用 Azure 虛擬網路來協助保護對 API Management 實例和 API 的存取。 此方法支援 私有端點。 欲了解更多資訊，請參閱 「使用虛擬網路與 API 管理」。
成本最佳化
成本優化著重於減少不必要的費用，並提升營運效率的方式。 欲了解更多資訊，請參閱成本優化設計審查清單。
使用Azure價格計算器來估算費用。 以下是一些其他考量因素。
API Management
您需支付 API 管理實例執行時的所有費用。 如果你擴大規模，且不再需要那種效能，就手動縮小或設定 自動擴展。
對於輕度使用的工作負載，可以考慮 消耗層級，這是一種低成本、無伺服器的選項。 消耗層會按照每次 API 調用進行計費。 其他階層會按每小時收費。
Logic Apps 標準版
Logic Apps Standard 採用 彈性計算模型。 計費是根據每小時使用的 CPU 和記憶體數量計算的。 如需更多資訊，請參閱 Logic Apps 定價。
服務匯流排 佇列、主題與訂閱
服務匯流排 佇列與訂閱支援代理推送與拉取模式以傳遞訊息。 在拉取模型中，每個輪詢要求都被視為一個動作。 即使您將長時間輪詢設定為預設值 30 秒，成本可能很高。 除非您需要即時訊息傳遞，否則請考慮使用 Proxy 推送模型。
服務匯流排 排隊區包含於所有等級：基本、標準及高級。 服務匯流排 主題與訂閱服務提供標準版與高級版。 更多資訊請參閱服務匯流排 價格。
事件方格
事件方格會使用無伺服器模型。 計費是根據作業數目計算。 作業包括涉及網域或主題的事件、進階匹配、傳遞嘗試和管理調用。 使用最多 100,000 次作業是免費的。
更多資訊請參閱 事件網格定價。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 欲了解更多資訊，請參閱營運卓越的設計審核清單。
基本企業整合參考架構提供 DevOps 模式的指引，這些模式與 Well-Architected Framework 的 營運卓越 支柱相符。
盡可能自動化復原作業，以協助改善營運卓越。 以自動化為目標，你可以將 Azure 日誌監控 與 Azure 自動化 結合，以自動化執行 服務匯流排 資源的故障轉移。 關於啟動故障轉移的自動化邏輯範例，請參見 故障轉移流程。
效能效率
效能效率是指工作負載能夠有效率地調整以符合使用者需求。 有關詳細資訊，請參閱效能效率的設計審核清單。
為了達到更高的可擴展性，服務匯流排 Premium 層可以擴展訊息單元的數量。 更多資訊請參閱
如需更多有關 服務匯流排 的建議，請參閱 使用 服務匯流排 訊息提升效能的最佳實務 。