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