此參考架構會使用 Azure Integration Services 來協調對企業後端系統的呼叫。 後端系統可以包含軟體即服務 （SaaS） 系統、Azure 服務和企業中現有的 Web 服務。
架構
工作流程
後端系統 。 圖表右側顯示企業部署或依賴的各種後端系統。 這些系統可能包含 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 連線 （OIDC） 通訊協定。 用戶端會從 Microsoft Entra 識別碼取得存取權杖，而 API 閘道 會驗證權杖 以授權要求。 如果您使用標準層或進階版層API 管理，Microsoft Entra ID 也可以協助保護開發人員入口網站的存取。
元件
- Integration Services 是一組服務，可用來整合應用程式、資料和程式。
- Logic Apps 是一個無伺服器平臺，可用來建置整合應用程式、資料和服務的企業工作流程。
- API 管理是用來發佈 HTTP API 目錄的受控服務。 您可以使用它來提升 API 的重複使用和可探索性，以及將 API 閘道部署至 Proxy API 要求。
- Azure DNS 是 DNS 網域的裝載服務。
- Microsoft Entra ID 是雲端式身分識別和存取管理服務。 企業員工可以使用 Microsoft Entra 識別碼來存取外部和內部資源。
案例詳細資料
Integration Services 是一組服務，可用來整合企業的應用程式、資料和程式。 此架構會使用其中兩個服務： Logic Apps 來協調工作流程，並 API 管理 建立 API 目錄。
在此架構中，複合 API 是藉由將 邏輯應用程式 匯入為 API 來建置。 您也可以匯入 OpenAPI （Swagger） 規格或 從 WSDL 規格匯入 SOAP API ，以 匯入現有的 Web 服務。
API 閘道有助於將前端用戶端與後端分離。 例如，它可以重寫 URL，或在要求到達後端之前轉換要求。 它也會處理許多跨領域考慮，例如驗證、跨原始資源分享 （CORS） 支援和回應快取。
潛在的使用案例
此架構足以用於由同步呼叫後端服務觸發工作流程的基本整合案例。 使用 佇列和事件 以這個基本架構為基礎的更複雜架構。
建議
您的特定需求可能與此處顯示的一般架構不同。 使用本節中的建議作為起點。
API 管理
使用API 管理基本、標準或進階版層。 這些層級提供生產服務等級協定（SLA），並支援在 Azure 區域內相應放大。 API 管理的輸送量容量是以單位 來 測量。 每個定價層都有相應放大上限。進階版層也支援跨多個 Azure 區域相應放大。 根據您的功能集和所需的輸送量層級，選擇您的階層。 如需詳細資訊，請參閱 azure API 管理 實例 的API 管理定價 和 容量。
每個 Azure API 管理 實例都有預設功能變數名稱，也就是 的子域 azure-api.net ， contoso.azure-api.net 例如 。 請考慮為您的組織設定 自訂網域 。
Logic Apps
Logic Apps 最適合在不需要低延遲的回應案例中運作，例如非同步或半長時間執行的 API 呼叫。 如果需要低延遲，例如在封鎖使用者介面的呼叫中，請使用不同的技術。 例如，使用部署至Azure App 服務的 Azure Functions 或 Web API。 使用API 管理，將 API 前端指向您的 API 取用者。
區域
若要將網路延遲降到最低，請將API 管理和 Logic Apps 放在相同的區域中。 一般而言，請選擇最接近使用者的區域（或最接近您的後端服務）。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
可靠性
可靠性可確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性要素 概觀。
檢閱每個服務的 SLA：
如果您在具有進階版層的兩個或多個區域之間部署API 管理，則符合較高的 SLA 資格。 請參閱 API 管理定價 。
備份
定期 備份 您的API 管理組態。 將您的備份檔案儲存在與部署服務所在區域不同的位置或 Azure 區域。 根據您的 RTO 選擇災害復原策略：
在災害復原事件中，布建新的API 管理實例、將備份還原至新的實例，然後重新指向 DNS 記錄。
在另一個 Azure 區域中保留API 管理服務的被動實例。 定期將備份還原至該實例，使其與作用中服務保持同步。 若要在災害復原事件期間還原服務，您只需要重新指向 DNS 記錄。 此方法會產生額外的成本，因為您支付被動實例的費用，但會減少復原時間。
針對邏輯應用程式，我們建議使用組態即程式碼方法來備份和還原。 因為邏輯應用程式是無伺服器應用程式，因此您可以從 Azure Resource Manager 範本快速重新建立它們。 將範本儲存在原始檔控制中，將範本與您的持續整合/持續部署 （CI/CD） 程式整合。 在災害復原事件中，將範本部署到新的區域。
如果您將邏輯應用程式部署到不同的區域，請更新 API 管理 中的設定。 您可以使用基本的 PowerShell 腳本來更新 API 的 Backend 屬性。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
雖然這份清單並未完全描述所有安全性最佳做法，但以下是一些特別適用于此架構的安全性考慮：
Azure API 管理服務具有固定的公用 IP 位址。 將呼叫 Logic Apps 端點的存取限制為僅限API 管理的 IP 位址。 如需詳細資訊，請參閱 限制輸入 IP 位址 。
若要確定使用者具有適當的存取層級，請使用 Azure 角色型存取控制 （Azure RBAC）。
使用 OAuth 或 OpenID 連線保護API 管理中的公用 API 端點。 若要保護公用 API 端點，請設定識別提供者，並新增 JSON Web 權杖 （JWT） 驗證原則。 如需詳細資訊，請參閱 使用 OAuth 2.0 搭配 Microsoft Entra 識別碼和API 管理 來保護 API。
連線使用相互憑證從API 管理後端服務。
在API 管理 API 上強制執行 HTTPS。
儲存密碼
請勿將密碼、存取金鑰或連接字串檢查到原始檔控制中。 如果需要這些值，請使用適當的技術來保護和部署這些值。
如果邏輯應用程式需要您在連接器內無法建立的任何敏感性值，請將這些值儲存在 Azure 金鑰保存庫，並從 Resource Manager 範本參考這些值。 針對每個環境使用部署範本參數和參數檔案。 如需詳細資訊，請參閱 保護工作流程 中的參數和輸入。
API 管理使用稱為具 名值 或 屬性 的物件來管理秘密。 這些物件可安全地儲存您可以透過API 管理原則存取的值。 如需詳細資訊，請參閱 如何在 Azure API 管理 原則 中使用具名值。
卓越營運
卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 營運卓越支柱 概觀。
DevOps
為生產環境、開發和測試環境建立個別的資源群組。 不同的資源群組可讓您更輕鬆地管理部署、刪除測試部署，以及指派存取權限。
當您將資源指派給資源群組時，請考慮下列因素：
生命週期 。 一般而言，將具有相同生命週期的資源放在相同的資源群組中。
存取。 若要將存取原則套用至群組中的資源，您可以使用 Azure 角色型存取控制（Azure RBAC）。
計費 。 您可以檢視資源群組的匯總成本。
API 管理 的定價層。 使用開發人員層進行開發和測試環境。 若要將生產前成本降至最低，請部署生產環境的複本、執行測試，然後關閉。
部署
使用 Azure Resource Manager 範本 來部署 Azure 資源，請遵循基礎結構即程式碼 （IaC） 程式。 範本可讓您更輕鬆地使用 Azure DevOps Services 或其他 CI/CD 解決方案將部署自動化。
預備
請考慮暫存工作負載，這表示部署至各種階段，並在每個階段執行驗證，然後再繼續進行下一個階段。 如果您使用此方法，則可以以高度控制的方式將更新推送至生產環境，並將未預期的部署問題降到最低。 建議使用藍綠部署 和 Canary 版本 來更新即時生產環境。 也請考慮在部署失敗時有良好的復原策略。 例如，您可以從部署歷程記錄自動重新部署先前成功的部署。 --rollback-on-errorAzure CLI 中的 flag 參數是很好的範例。
工作負載隔離
將API 管理和任何個別的邏輯應用程式放在個別的 Resource Manager 範本中。 藉由使用不同的範本，您可以將資源儲存在原始檔控制系統中。 您可以將範本一起或個別部署為 CI/CD 程式的一部分。
版本
每次變更邏輯應用程式的設定或透過 Resource Manager 範本部署更新時，Azure 都會保留該版本的複本，並保留所有具有執行歷程記錄的版本。 您可以使用這些版本來追蹤歷程記錄變更，或將版本升級為邏輯應用程式的目前設定。 例如，您可以將邏輯應用程式復原至舊版。
API 管理支援兩個不同的但互補版本控制概念：
版本 可讓 API 取用者根據其需求選擇 API 版本，例如 v1、v2、Beta 或生產環境。
修訂可讓 API 系統管理員在 API 中進行非重大變更，並部署這些變更，以及變更記錄檔，以通知 API 取用者變更。
您可以在開發環境中進行修訂，並使用 Resource Manager 範本在其他環境中部署該變更。 如需詳細資訊，請參閱 發佈 API 的多個版本
您也可以使用修訂來測試 API，再對使用者進行目前和可存取的變更。 不過，不建議使用此方法進行負載測試或整合測試。 請改用個別的測試或生產前環境。
診斷和監控
在 API 管理 和 Logic Apps 中使用 Azure 監視器 進行作業監視。 Azure 監視器會根據針對每個服務所設定的計量提供資訊，且預設為啟用。 如需詳細資訊，請參閱
每個服務也有下列選項：
如需更深入的分析與儀表板，請將 Logic Apps 記錄傳送至 Azure Log Analytics 。
針對 DevOps 監視，請為 API 管理 設定 Azure 應用程式 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 Well-Architected Framework 中的 成本一節。
下一步
相關資源
為了提高可靠性和延展性，請使用訊息佇列和事件來分離後端系統。 此架構會顯示在此系列中的下一篇文章中：
您可能也對 Azure 架構中心的這些文章感興趣：