此參考架構使用 Azure Integration Services 協調企業後端系統的呼叫。 後端系統可能包括軟體即服務 (SaaS) 系統、Azure 服務，以及企業中的現有 Web 服務。
Azure Integration Services 是整合應用程式和資料的服務集合。 此架構使用其中兩個服務：Logic Apps 用來協調工作流程，API 管理用來建立 API 目錄。 此架構足夠供基本整合案例使用，其中對後端服務的同步呼叫會觸發工作流程。 使用佇列和事件的更複雜架構建立在此基本架構上。
下載這個架構的 Visio 檔案 。
架構
此架構具有下列元件：
後端系統。 圖表右側是企業已部署或依賴的各種後端系統。 這些可能包括 SaaS 系統、其他 Azure 服務，或者會公開 REST 或 SOAP 端點的 Web 服務。
Azure Logic Apps。 Logic Apps 是一個無伺服器平台，用於建置可整合應用程式、資料和服務的企業工作流程。 在此架構中，邏輯應用程式會由 HTTP 要求觸發。 您也可以為更複雜的協調流程巢狀處理工作流程。 Logic Apps 會使用連接器來整合常用的服務。 Logic Apps 提供數百個連接器，且您可以建立自訂連接器。
Azure API 管理。 API 管理是受控服務，用於發佈 HTTP API 的目錄，以促進重複使用及可搜尋性。 API 管理由兩個相關元件組成：
API 閘道。 API 閘道可接受 HTTP 呼叫，並將它們路由傳送至後端。
開發人員入口網站。 Azure API 管理的每個執行個體都提供開發人員入口網站的存取權。 此入口網站可讓開發人員存取呼叫 API 的文件和程式碼範例。 您也可以在開發人員入口網站中測試 API。
在此架構中，複合 API 是藉由匯入邏輯應用程式為 API 所建立。 您也可以藉由匯入 OpenAPI (Swagger) 規格或從 WSDL 規格匯入 SOAP API 來匯入現有的 Web 服務。
API 閘道有助於分離前端用戶端與後端。 比方說，它可以重新撰寫 URL，或在其到達後端前轉換要求。 它也可處理許多跨領域問題，例如驗證、跨原始來源資源共用 (CORS) 支援，以及回應快取。
Azure DNS。 Azure DNS 是一個適用於 DNS 網域的主機服務。 Azure DNS 採用 Microsoft Azure 基礎結構來提供名稱解析。 只要將您的網域裝載於 Azure，就可以使用您用於其他 Azure 服務的相同認證、API、工具和計費方式來管理 DNS 記錄。 若要使用自訂網域名稱 (例如 contoso.com)，請建立將自訂網域名稱對應至 IP 位址的 DNS 記錄。 如需詳細資訊，請參閱在 API 管理中設定自訂網域名稱。
Azure Active Directory (Azure AD) 。 使用 Azure AD 來驗證呼叫 API 閘道的用戶端。 Azure AD 可支援 OpenID Connect (OIDC) 通訊協定。 用戶端從 Azure AD 取得存取權杖，API 閘道會驗證權杖以授權要求。 當使用 API 管理的標準或進階層，Azure AD 也可以保護開發人員入口網站的存取。
建議
您的特定需求可能與此處所示的一般架構不同。 以本節的建議作為起點。
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 放在相同區域中。 通常會選擇最接近使用者的區域 (或最接近後端服務)。
延展性考量
若要提升 API 管理的延展性，請視需要新增快取原則。 快取也有助於降低後端服務的負載。
若要提供更大的容量，您可以在 Azure 區域中相應放大 Azure API 管理的基本、標準及進階層。 若要分析服務的使用情況，請在 [計量] 功能表上選取 [容量計量] 選項，然後視需要相應增加或相應減少規模。 升級或調整程序需要 15 到 45 分鐘才會生效。
調整「API 管理」服務規模的建議事項：
請在調整時考慮流量模式。 流量模式變動較大的客戶需要更多容量。
容量如果一直大於 66%，可能代表需要相應增加規模。
容量如果一直低於 20%，則可能代表需要相應減少規模。
在生產環境中啟用負載前，一律先以代表性負載進行 API 管理服務負載測試。
使用進階層，您可以跨多個 Azure 區域調整 API 管理執行個體。 這讓 API 管理可適用於更高的 SLA，並讓您在使用者附近多個區域中佈建服務。
Logic Apps 無伺服器模型代表系統管理員不需要針對服務延展性進行規劃。 服務會自動調整規模以滿足需求。
可用性考量
檢閱每個服務的 SLA：
如果使用進階層跨二或多個區域部署 API 管理，即適用於較高的 SLA。 請參閱 API 管理定價。
備份
定期備份 API 管理設定。 將備份檔案儲存在不同於服務所部署區域的位置或 Azure 區域中。 根據 RTO 選擇災害復原策略：
在災害復原事件中，佈建新的 API 管理執行個體、將備份還原至新的執行個體，以及重新指向 DNS 記錄。
將 API 管理服務的被動執行個體保留在其他 Azure 區域中。 定期將備份還原到該執行個體，以讓它與作用中服務保持同步。 若要在災害復原事件中還原服務，您只需重新指向 DNS 記錄。 這種方法會產生額外成本，因為您需要支付被動的執行個體，但可以縮短復原時間。
對於邏輯應用程式，我們建議使用組態即程式碼的方法來備份及還原。 因為邏輯應用程式無伺服器，您可以從 Azure Resource Manager 範本快速進行重新建立。 將範本儲存在原始檔控制中，整合範本與您的持續整合/持續部署 (CI/CD) 程序。 在災害復原事件中，將範本部署到新的區域。
如果您將邏輯應用程式部署至不同的區域，請更新 API 管理中的組態。 您可以使用基本 PowerShell 指令碼來更新 API 的後端屬性。
DevOps 考量
針對生產、部署和測試環境，各別建立資源群組。 個別的資源群組可讓您更輕鬆地管理部署、刪除測試部署及指派存取權限。
當您將資源指派給資源群組時，請考慮下列因素：
生命週期。 一般來說，會將具有相同生命週期的資源放在同一個資源群組中。
存取。 若要將存取原則套用至群組中的資源，您可以使用 Azure 角色型存取控制 (Azure RBAC) 。
計費。 您可以檢視資源群組的彙總成本。
適用於 API 管理的定價層。 使用開發與測試環境的開發人員層。 若要將成本降到最低，請部署生產環境的複本、執行測試，然後關閉。
部署
使用Azure Resource Manager範本來部署 Azure 資源，請遵循基礎結構作為 Code (IaC) Process。 範本可讓您更輕鬆地使用Azure DevOps Services或其他 CI/CD 解決方案來自動化部署。
預備
請考慮暫存您的工作負載，這表示先部署到各種階段，並在每個階段執行驗證，再繼續進行下一個階段;如此一來，您就可以以高度控制的方式將更新推送至生產環境，並將未預期的部署問題降到最低。 建議使用藍綠部署 和 Canary 版本 來更新即時生產環境。 也請考慮在部署失敗時有良好的復原策略;例如，您可以從部署歷程記錄自動重新部署先前成功的部署，Azure CLI 中的 --rollback-on-error 旗標參數是不錯的範例。
工作負載隔離
將 Azure API 管理及任何個別的邏輯應用程式放在其自己的個別 Resource Manager 範本中。 使用不同的範本時，可以將資源儲存於原始檔控制系統中。 您可以一起部署範本，或者在 CI/CD 流程中個別部署。
版本
每次您變更邏輯應用程式的組態或透過 Resource Manager 範本部署更新時，Azure 都會保留該版本的複本，及保留所有具有執行歷程記錄的版本。 您可以使用這些版本來追蹤歷程記錄變更，或將某個版本升階成邏輯應用程式的目前組態。 例如，您可以將邏輯應用程式復原至先前的版本。
「API 管理」支援兩個截然不同但互補的版本設定概念：
版本可讓 API 取用者根據其需求選擇 API 版本，例如 v1、v2、搶鮮版 (Beta) 或生產環境版。
修訂允許 API 管理員在 API 中進行非中斷變更，並部署這些變更以及變更記錄，以便告知 API 取用者所做變更。
您可以使用 Resource Manager 範本，在開發環境中進行修訂，然後在其他環境中部署該變更。 如需詳細資訊，請參閱 發佈 API 的多個版本
您也可以在變更之前使用修訂測試目前使用者能夠存取的 API。 不過，這個方法不建議用於負載測試或整合測試。 請改用個別的測試或生產階段前環境。
診斷和監控
使用 Azure 監視器在 API 管理和 Logic Apps 中進行作業監視。 Azure 監視器預設會啟用，並且會根據針對每個服務所設定的計量來提供資訊。 如需詳細資訊，請參閱
每個服務也具有下列選項：
如需進行更深入的分析並顯示在儀表板上，請將 Logic Apps 記錄傳送至 Azure Log Analytics。
若要進行 DevOps 監視，您可以針對 API 管理設定 Azure Application Insights。
API 管理支援適用於自訂 API 分析的 Power BI 解決方案範本 \(英文\)。 您可以使用此解決方案範本來建立自己的分析解決方案。 若為商務使用者，Power BI 中有可用的報告。
安全性考量
雖然這份清單並未完整地說明所有的安全性最佳做法，以下安全性考量專門用於此架構：
Azure API 管理服務有固定的公用 IP 位址。 將呼叫 Logic Apps 端點的存取權限制成僅供 API 管理的 IP 位址使用。 如需詳細資訊，請參閱 限制輸入 IP 位址。
若要確定使用者具有適當的存取層級，請使用 Azure 角色型存取控制 (Azure RBAC) 。
使用 OAuth 或 Open ID Connect 來保護 API 管理中的公用 API 端點。 若要保護公用 API 端點，請設定識別提供者，並新增 JSON Web 權杖 (JWT) 驗證原則。 如需詳細資訊，請參閱使用 OAuth 2.0 搭配 Azure Active Directory 與 API 管理來保護 API。
使用相互憑證，從 API 管理連線至後端服務。
在 API 管理 API 上強制使用 HTTPS。
儲存祕密
永遠不要將密碼、存取金鑰或連接字串簽入原始檔控制。 如果需要這些值，請使用適當的技術來保護和部署這些值。
如果邏輯應用程式需要您無法在連接器內建立的任何敏感性值，請將這些值儲存在 Azure Key Vault 中，然後從 Resource Manager 範本參考這些值。 針對每個環境使用部署範本參數和參數檔。 如需詳細資訊，請參閱保護工作流程中的參數和輸入。
API 管理中會使用名為「具名值」或「屬性」的物件來管理祕密。 這些物件能安全地儲存可透過 API 管理原則存取的值。 如需詳細資訊，請參閱如何在 Azure API 管理原則中使用具名值。
成本考量
一般而言，使用 Azure 定價計算機來估計成本。 以下是一些其他考慮。
API 管理
我們會向您收取所有執行中「API 管理」執行個體的費用。 如果您已相應增加，且並非隨時需要該層級的效能，請以手動方式相應減少或設定自動調整。
Logic Apps
Logic Apps 會使用無伺服器模型。 計費的計算方式是以動作和連接器執行為基礎。 如需詳細資訊，請參閱 Logic Apps 定價。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的成本一節。
下一步
為了提升可靠性和延展性，使用訊息佇列和事件來分離後端系統。 此模式會顯示在此系列中的下一篇文章中。