此範例架構是以基本企業整合 架構為基礎 所建置。 它會擴充該架構，以示範如何使用訊息代理程式和事件來整合企業後端系統，以將服務分離，以取得更大的延展性和可靠性。 請確定您已熟悉該設計和基本整合架構中使用的元件。 它提供此架構核心元件的基礎資訊，在此不會重現。
架構
此設計中所參考的後端系統可能包含軟體即服務 （SaaS） 系統、Azure 服務和企業中現有的 Web 服務。
下載此架構 的 Visio 檔案 。
工作流程
此處顯示的架構是以較簡單的架構為基礎，如基本企業整合 所示 。 該架構會使用 Logic Apps 直接與後端系統協調工作流程，並 API 管理 建立 API 目錄。
此版本的架構會新增兩個元件，以協助讓系統更可靠且可調整：
Azure 服務匯流排 。 服務匯流排是安全的可靠訊息代理程式。
Azure 事件方格 。 事件方格是事件路由服務。 它會使用 發佈/訂閱 （pub/sub） 事件模型。
使用訊息代理程式進行非同步通訊提供下列優點，比對後端服務進行直接、同步呼叫：
- 使用佇列型負載撫平模式 ，提供負載撫平來處理工作負載 中的高載。
- 提供使用「發行者-訂閱者」模式 將訊息廣播給多個取 用者。
- 可靠地追蹤涉及多個步驟或多個應用程式的長時間執行的工作流程進度。
- 有助於分離應用程式。
- 與現有的訊息式系統整合。
- 當後端系統無法使用時，允許將工作排入佇列。
事件方格可讓系統中的各種元件在事件發生時回應事件，而不是依賴輪詢或排程的工作。 如同訊息佇列和主題，它有助於分離應用程式和服務。 應用程式或服務可以發佈事件，且任何感興趣的訂閱者都會收到通知。 您可以新增訂閱者，而不需更新寄件者。
許多 Azure 服務都支援將事件傳送至事件方格。 例如，邏輯應用程式可以在將新檔案新增至 Blob 存放區時接聽事件。 此模式可啟用回應式工作流程，其中上傳檔案或將訊息放在佇列上會啟動一系列程式。 進程可能會以平行方式或特定循序執行。
建議
基本企業整合 中所述 的建議適用于此架構。
服務匯流排
服務匯流排有兩種傳遞模式： 提取 或 Proxy 推送 。 在提取模型中，接收者會持續輪詢新訊息。 輪詢可能會沒有效率，特別是如果您有許多佇列，每個佇列都會收到一些訊息，或訊息之間有很多時間。 在 Proxy 推送模型中，服務匯流排有新訊息時，透過事件方格傳送事件。 接收者會訂閱 事件。 觸發事件時，接收者會從服務匯流排提取下一批訊息。
當您建立邏輯應用程式來取用服務匯流排訊息時，建議您搭配 Event Grid 整合使用 Proxyed Push 模型。 它通常更有成本效益，因為邏輯應用程式不需要輪詢服務匯流排。 如需詳細資訊，請參閱 事件方格整合概觀 Azure 服務匯流排。 目前，事件方格通知需要服務匯流排 進階版層 。
使用 PeekLock 來存取訊息群組。 當您使用 PeekLock 時，邏輯應用程式可以執行步驟來驗證每個訊息，再完成或放棄訊息。 這種方法可防止意外訊息遺失。
Event Grid
引發事件方格觸發程式時，表示 至少發生一個 事件。 例如，當邏輯應用程式取得服務匯流排訊息的事件方格觸發程式時，它應該假設有數個訊息可供處理。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
可靠性
可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性要素 概觀。
- Microsoft Entra ID： Microsoft Entra ID 是全域散發的高可用性 SaaS 平臺。 如需保證的可用性詳細資料， 請參閱 SLA 。
- API 管理： 根據商務需求和成本承受度，API 管理可以部署在數個高可用性設定中。 如需 選項的完整檢閱，請參閱確保API 管理可用性和可靠性 。 另請參閱 SLA 以 取得保證的可用性詳細資料。
- Logic Apps： 取用方案層上的 Logic Apps 可使用異地備援儲存體。 如需設計商務持續性和災害復原解決方案的相關資訊，請參閱 指引 。 另請參閱 SLA 以 取得保證的可用性詳細資料。
- 事件方格： 主題、系統主題、網域和事件訂用帳戶和事件資料的事件方格資源定義會自動複寫到區域中的三個可用性區域 （可用時）。 當其中一個可用性區域發生失敗時，事件方格資源會自動容錯移轉至另一個可用性區域，而不需要人為介入。 如需 設計災害復原解決方案以容錯移轉至另一個區域的指引，請參閱跨區域的 異地災害復原。 另請參閱 SLA 以 取得保證的可用性詳細資料。
- 服務匯流排： 服務匯流排 進階版支援 異地災害復原 和 可用性區域 。 複 寫適用于標準服務匯流排。 另請參閱 SLA 以 取得保證的可用性詳細資料。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
若要保護服務匯流排，請使用 與受控識別 配對的 Microsoft Entra 驗證 。 適用于服務匯流排資源的 Microsoft Entra 整合提供 Azure 角色型存取控制 （RBAC），以對用戶端對資源的存取進行更細緻的控制。 您可以使用 Azure RBAC 將許可權授與安全性主體，這可能是使用者、群組或應用程式服務主體（在此案例中為受控識別）。
如果無法使用 Microsoft Entra ID，您可以使用 共用存取簽章 （SAS） 。 您可以使用 SAS 驗證 ，將具有特定許可權 的服務匯流排資源存取權授與使用者。
例如，如果您需要將服務匯流排佇列或主題公開為 HTTP 端點，若要張貼新訊息，請使用 API 管理 在端點前面保護佇列。 然後，您可以視需要使用憑證或 OAuth 驗證來保護端點。 保護端點的最簡單方式是使用邏輯應用程式搭配 HTTP 要求/回應觸發程式作為媒介。
事件方格服務會透過驗證程式代碼保護事件傳遞。 如果您使用 Logic Apps 來取用事件，則會自動執行驗證。 如需詳細資訊，請參閱 事件方格安全性和驗證 。
網路安全性
整個設計都應該考慮網路安全性。
- 服務匯流排進階版 可以系結至虛擬網路 （VNet） 子網服務端點，保護命名空間只接受來自授權虛擬網路的流量。 此外，使用 私人端點 透過 Private Link 鎖定 VNet 流量到私人流量 。
- Logic Apps Standard 和 進階版 Logic Apps 可以設定為接受透過 私人端點 的輸入流量，以及透過 VNet 整合 傳送輸出流量。
- API 管理 提供數個選項，可讓您使用 Azure 虛擬網路保護對API 管理實例和 API 的存取。 如需 選項的完整檢閱，請參閱使用虛擬網路搭配 Azure API 管理 檔。 也支援私人端點 。
成本最佳化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。
一般而言，使用 Azure 定價計算機 來預估成本。 以下是一些其他考慮。
API 管理
當實例執行時，您需支付所有API 管理實例的費用。 如果您已相應增加且不需要該層級的效能，請手動相應減少或設定 自動調整 。
針對輕量使用量工作負載，請考慮 耗用量層 ，這是低成本無伺服器選項。 取用層會依 API 呼叫計費，而其他層則每小時計費。
Logic Apps
Logic Apps 使用 無 伺服器模型。 計費是根據動作和連接器執行來計算。 如需詳細資訊，請參閱 Logic Apps 定價 。
服務匯流排佇列、主題和訂用帳戶
服務匯流排佇列和訂用帳戶都支援 Proxy 推送和提取模型來傳遞訊息。 在提取模型中，每個輪詢要求都會計量為動作。 即使長時間輪詢為 30 秒（預設值），成本可能很高。 除非您需要即時傳遞訊息，否則請考慮使用 Proxy 推送模型。
服務匯流排佇列會包含在所有層中（基本、標準和進階層）。 雖然服務匯流排主題和訂用帳戶可在標準和進階層中使用。 如需詳細資訊，請參閱 Azure 服務匯流排定價 。
Event Grid
事件方格會使用無伺服器模型。 計費是根據作業數目計算（事件執行）。 這些作業包括網域和主題的事件輸入、進階比對、傳遞嘗試及管理呼叫。 最多 100,000 個作業的使用量是免費的。
如需詳細資訊，請參閱 事件方格定價 。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的 成本一節。
卓越營運
基本企業整合參考架構 提供 DevOps 模式的指引，其符合架構完善的架構營運 卓越 支柱。
盡可能自動化復原作業是卓越營運不可或缺的一部分。 考慮到自動化，您可以將 Azure 記錄監視 與 Azure 自動化 結合 ，以自動化服務匯流排資源的容錯移轉。 請參閱容錯移轉流程 檔中的 圖表，以取得起始容錯移轉的自動化邏輯範例。
效能效益
效能效率是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 如需詳細資訊，請參閱 效能效率要素概觀 。
為了達到更高的延展性，服務匯流排 進階版層可以相應放大傳訊單位數目。 如需 檢閱進階版層 權益，請參閱服務匯流排 進階版和標準傳訊層檔。 此外，請參閱 自動調整功能 檔，以瞭解如何設定傳訊單位的自動調整。
如需更多服務匯流排建議，請參閱 使用服務匯流排傳訊 來改善效能的最佳做法。
下一步
如需詳細資訊，請參閱服務匯流排檔：