此參考架構使用 Azure 整合服務來協調對企業後端系統的呼叫。 後端系統可以包括軟體即服務 (SaaS) 系統、Azure 服務以及企業現有的網路服務。
架構
下載此架構的 Visio 檔案。
工作流程
後端系統。 圖表右方顯示企業已部署或依賴的各種後端系統。 這些系統可能包括 SaaS 系統、其他 Azure 服務或揭露 REST 或 SOAP 端點的 Web 服務。
Azure Logic Apps。 在此架構中，邏輯應用程式由 HTTP 要求觸發。 您也可以巢狀化工作流程，以進行更複雜的協調。 Logic Apps 使用連接器來整合常用的服務。 Logic Apps 提供數百個連接器，而且您可以建立自訂連接器。
Azure API 管理。 API 管理包含兩個相關元件：
API 閘道。 API 閘道會接受 HTTP 呼叫，並將這些呼叫路由到後端。
開發人員入口網站。 Azure API 管理的每個執行個體都提供開發人員入口網站的存取權。 此入口網站可讓您的開發人員存取文件和呼叫 API 的程式碼範例。 您也可以在開發人員入口網站測試 API。
Azure DNS。 Azure DNS 透過使用 Azure 基礎結構提供名稱解析。 只要將您的網域託管在 Azure 中，您就可以使用與其他 Azure 服務相同的認證、API、工具和帳單來管理 DNS 記錄。 若要使用自訂網域名稱，例如 contoso.com，請建立 DNS 記錄，將自訂網域名稱對應到 IP 位址。 如需更多資訊，請參閱在 API 管理中設定自訂網域名稱。
Microsoft Entra ID。 使用 Microsoft Entra ID 來驗證呼叫 API 閘道的用戶端。 Microsoft Entra ID 支援 OpenID Connect (OIDC) 通訊協定。 用戶端從 Microsoft Entra ID 獲得存取標記，API 閘道會驗證權杖，以授權要求。 如果您使用 API 管理的標準或進階層級，Microsoft Entra ID 也能協助確保存取開發人員入口網站的安全性。
元件
- 整合服務是服務的集合，您可以使用該服務來整合應用程式、資料和程序。
- Logic Apps 是一個無伺服器平台，用於建立整合應用程式、資料和服務的企業工作流程。
- API 管理是用於發佈 HTTP API 目錄的管理服務。 您可以使用該服務來促進 API 的重複使用和可探索性，並部署 API 閘道來代理 API 要求。
- Azure DNS 是 DNS 網域的託管服務。
- Microsoft Entra ID 是雲端身分識別和存取權管理服務。 企業員工可以使用 Microsoft Entra ID 存取外部和內部資源。
案例詳細資料
整合服務是服務的集合，您可以使用該服務來整合您企業的應用程式、資料和程序。 此架構使用其中兩種服務：Logic Apps 可協調工作流程，而 API 管理則可建立 API 目錄。
在此架構中，複合 API 是透過匯入邏輯應用程式作為 API 來建立的。 您也可以透過匯入 OpenAPI (Swagger) 規格或從 WSDL 規格匯入 SOAP API 來匯入現有的 Web 服務。
API 閘道有助於將前端用戶端與後端解耦。 例如，它可以重寫 URL，或在要求到達後端之前進行轉換。 它還可以處理許多跨領域的問題，例如驗證、跨來源資源分享 (CORS) 支援和回應快取。
潛在使用案例
此架構足以應付基本的整合情境，在此情境中，工作流程是由後端服務的同步呼叫所觸發。 使用佇列和事件的更複雜架構建立在此基本架構之上。
建議
您的具體需求可能與此處所示的一般架構不同。 請使用本節中的建議作為起點。
API 管理
使用 API 管理的基本、標準或進階層級。 這些層級提供生產服務級別協定 (SLA)，並支援 Azure 區域內的擴展。 API 管理的輸送容量以單位計量。 每個定價層級都有最大擴展能力。進階層級也支援跨多個 Azure 區域的擴展。 根據您的功能集和所需輸送量級別選擇您的層級。 如需更多資訊，請參閱 API 管理定價和 Azure API 管理執行個體的容量。
每個 Azure API 管理執行個體都有一個預設網域名稱，它是 azure-api.net 的子網域，例如 contoso.azure-api.net。 考慮為您的組織設定自訂網域。
Logic Apps
Logic Apps 最適用於不需要低延遲回應的情況，例如異步或半長時間執行的 API 呼叫。 如果需要低延遲，例如封鎖使用者介面的呼叫，請使用不同的技術。 例如，使用 Azure Functions 或部署到 Azure App Service 的 Web API。 使用 API 管理將 API 前置到您的 API 取用者。
區域
為了盡量減少網路延遲，請將 API 管理與 Logic Apps 置於同一區域。 一般而言，選擇最接近使用者的區域 (或最接近後端服務的區域)。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需更多資訊，請參閱可靠性支柱的概觀。
檢閱每項服務的 SLA：
如果您使用進階層級在兩個或以上的區域部署 API 管理，就有資格獲得更高的 SLA。 請參閱 API 管理定價。
備份
定期備份您的 API 管理設定。 將備份檔案儲存於與部署服務的區域不同的位置或 Azure 區域。 根據您的 RTO，選擇災難復原策略：
在災難復原事件中，佈建新的 API 管理執行個體，將備份還原至新的執行個體，並重新指向 DNS 記錄。
在另一個 Azure 區域保留 API 管理服務的被動執行個體。 定期將備份還原到該執行個體，使其與主動服務保持同步。 若要在災難復原事件中還原服務，您只需要重新指向 DNS 記錄。 此方法會產生額外成本，因為您需要支付被動執行個體的費用，但可縮短復原時間。
對於邏輯應用程式，我們建議採用設定即程式碼的方式來備份和還原。 由於邏輯應用程式是無伺服器的，因此您可以從 Azure Resource Manager 範本快速重新建立這些應用程式。 將範本儲存於原始碼控制中，將範本與您的持續整合/持續部署 (CI/CD) 程序整合。 在災難復原事件中，將範本部署到新的區域。
如果您將邏輯應用程式部署到不同的區域，請更新 API 管理中的設定。 您可以使用基本的 PowerShell 指令碼更新 API 的後端屬性。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。
雖然這份清單並未完全描述所有安全性最佳實務，但以下是一些特別適用於此架構的安全性注意事項：
Azure API 管理服務有固定的公用 IP 位址。 請限制呼叫 Logic Apps 端點的存取權限，僅限於 API 管理的 IP 位址。 如需更多資訊，請參閱限制傳入 IP 位址。
若要確保使用者擁有適當的存取層級，請使用 Azure 角色型存取控制 (Azure RBAC)。
使用 OAuth 或 OpenID Connect 保護 API 管理中的公用 API 端點安全性。 若要確保公用 API 端點的安全性，請設定身分提供者，並新增 JSON Web 權杖 (JWT) 驗證原則。 如需更多資訊，請參閱使用 Microsoft Entra ID 和 API 觀禮的 OAuth 2.0 來保護 API。
使用相互認證從 API 管理連線到後端服務。
在 API 管理 API 上強制執行 HTTPS。
儲存密碼
切勿將密碼、存取金鑰或連線字串檢查到原始碼控制中。 如果需要這些值，請使用適當的技術來確保安全性並部署這些值。
如果邏輯應用程式需要任何無法在連接器中建立的敏感值，請將這些值儲存於 Azure Key Vault 中，並從資源管理員範本中引用這些值。 針對每個環境使用部署範本參數和參數檔案。 如需更多資訊，請參閱工作流程中的安全性參數和輸入。
API 管理透過使用稱為命名值或屬性的物件來管理密碼。 這些物件安全性地儲存您可透過 API 管理原則存取的值。 如需更多資訊，請參閱如何在 Azure API 管理原則中使用命名值。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運支柱的概觀 (部分機器翻譯)。
DevOps
為生產、開發和測試環境建立單獨的資源組。 單獨的資源群組可以更輕鬆地管理部署、刪除測試部署和指派存取權限。
將資源指派給資源群組時，請考慮這些因素：
生命週期。 一般而言，請將具有相同生命週期的資源放在相同的資源群組中。
存取。 若要對群組中的資源套用存取原則，可以使用 Azure 角色型存取控制 (Azure RBAC)。
計費。 您可以檢視資源群組的滾動成本。
API 管理的定價層級。 開發人員定價階層適用於開發和測試環境。 若要在生產前期間將成本降至最低，請部署生產環境的複本，執行測試，然後關閉。
部署
使用 Azure 資源管理器範本依照基礎架構即程式碼 (IaC) 流程部署 Azure 資源。 這些範本讓使用 Azure DevOps 服務或其他 CI/CD 解決方案進行自動化部署變得更加容易。
預備
考慮暫存您的工作負載，也就是將工作負載部署到不同階段，並在每個階段執行驗證，然後再進入下一個階段。 如果您使用此方法，您就可以以高度受控的方式將更新推送到生產環境，並最大限度地減少意外的部署問題。 藍綠部署和 Canary 版本是更新即時生產環境的建議部署策略。 此外，還要考慮在部署失敗時有良好的回溯策略。 例如，您可以從部署歷史中自動重新部署先前成功的部署。 Azure CLI 中的 --rollback-on-error 標誌參數就是一個很好的例子。
工作負載隔離
將 API 管理和任何個別邏輯應用程式置於各自獨立的資源管理員範本中。 透過使用獨立的範本，您可以將資源儲存在原始碼控制系統中。 您可以將這些範本一併或單獨部署，作為 CI/CD 程序的一部分。
版本
每次透過資源管理員範本變更邏輯應用程式的組態或部署更新時，Azure 都會保留該版本的副本，並保留有執行歷程記錄的所有版本。 您可以使用這些版本追蹤歷史變更，或將版本提升為邏輯應用程式的目前設定。 例如，您可以將邏輯應用程式回滾到先前的版本。
API 管理支援兩個不同但互補的版本概念：
版本允許 API 用戶根據自己的需求選擇 API 版本，例如 v1、v2、測試版或正式環境。
修訂允許 API 管理員對 API 進行非破壞性的變更，並部署這些變更以及變更記錄，以通知 API 取用者有關的變更。
您可以在開發環境中進行修改，然後透過使用 Resource Manager 範本在其他環境中部署該變更。 如需更多資訊，請參閱發佈多個版本的 API。
您也可以使用修訂來測試 API，然後再讓變更生效並讓使用者可以存取。 但是，此方法不建議用於負載測試或整合測試。 請使用獨立的測試或生產前環境。
診斷和監控
在 API 管理和 Logic Apps 中使用 Azure 監視器進行作業監控。 Azure 監視器根據為每個服務設定的指標提供資訊，並預設為啟用。 如需詳細資訊，請參閱
每個服務也有下列選項：
若要進行更深入的分析和儀表板顯示，請將 Logic Apps 日誌傳送至 Azure Log Analytics。
若要進行 DevOps 監控，請針對 API 管理設定 Azure Application Insights。
API 管理支援用於自訂 API 分析的 Power BI 解決方案範本。 您可以使用此解決方案範本來建立自己的分析解決方案。 對於商務使用者，Power BI 可提供報告。
效能效益
效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 如需詳細資訊，請參閱效能效率支柱概觀。
若要增加 API 管理的可擴展性，請在適當的地方加入快取原則。 快取也有助於降低後端服務的負載。
若要提供更大的容量，您可以在 Azure 區域中擴展 Azure API 管理的基本、標準和進階層級。 若要分析服務的使用方式，請選擇計量功能表上的容量計量，然後視情況擴大或縮小。 升級或調整程序需要 15 到 45 分鐘才會生效。
調整 API 管理服務的建議：
調整時請考慮流量模式。 流量模式較不穩定的客戶需要更大的容量。
持續的容量大於 66% 可能表示需要擴大。
持續低於 20% 的容量可能表示有機會縮減。
在生產中啟用負載之前，請務必使用具有代表性的負載測試 API 管理服務。
使用進階層級，您可以跨多個 Azure 區域擴展 API 管理執行個體。 這可讓 API 管理符合更高的 SLA，並讓您在多個區域的使用者附近提供服務。
Logic Apps 的無伺服器模式意味著管理員無需為服務的可擴展性規劃。 該服務會自動調整以符合需求。
成本最佳化
通常會使用 Azure 定價計算機估算成本。 以下是一些其他考量因素。
API 管理
所有 API 管理執行個體都會向您收費。 如果您已擴展，但不需要一直維持該級別的效能，請手動縮小規模或設定自動擴展。
Logic Apps
Logic Apps 使用無伺服器模式。 計費是根據動作和連線器的執行來計算。 如需更多資訊，請參閱 Logic Apps 定價。
有關詳細資訊，請參閱 Microsoft Azure 架構完善的框架中的 DevOps 成本部分。
下一步
相關資源
為了獲得更高的可靠性和可擴展性，請使用訊息佇列和事件來解耦後端系統。 本系列的下一篇文章將展示此架構：
您可能也會對 Azure 架構中心的這些文章感興趣：