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