在此案例中，旅遊產業的一家電子商務公司使用 Azure API 管理來移轉舊版 Web 應用程式。 新的 UI 將會裝載為 Azure 上的平台即服務 (PaaS) 應用程式，且會同時相依於現有和新的 HTTP API。 這些 API 會隨附一組設計較佳的介面，其可提供更好的效能、更輕鬆的整合，以及未來的擴充性。
架構
工作流程
- 現有的內部部署 Web 應用程式會繼續直接取用現有的內部部署 Web 服務。
- 從現有 Web 應用程式對現有 HTTP 服務的呼叫保持不變。 這些呼叫是公司網路內部的。
- 從 Azure 到現有的內部服務會進行輸入呼叫：
- 安全性小組允許來自 API 管理執行個體的流量，使用安全傳輸 (HTTPS 或 SSL) 將公司防火牆傳遞至現有的內部部署服務。
- 作業小組只允許從 API 管理執行個體對服務的輸入呼叫。 它會將 API 管理執行個體的 IP 位址新增至公司網路周邊內的允許清單，以符合這項需求。
- 新的課程模組會設定為 HTTP 服務的內部部署要求管線 (僅針對來自外部的連線採取行動)。 管線會驗證 API 管理提供的憑證。
- 新 API：
- 只會透過提供 API 外觀的 API 管理執行個體呈現。 不會直接存取新的 API。
- 已開發並發佈為 Azure PaaS Web API 應用程式。
- 已設定 (透過 Azure App 服務的 Web Apps 功能設定，只接受 API 管理虛擬 IP (VIP)。
- 裝載於 Web Apps 中，且已開啟安全傳輸 (HTTPS 或 SSL)。
- 已啟用授權，Azure App 服務透過 Microsoft Entra ID 和 Open Authorization (OAuth) 2 提供。
- 新的瀏覽器型 Web 應用程式取決於現有 HTTP API 和新 API 的 Azure API 管理執行個體。
- 旅遊電子商務公司現在可以將某些使用者導向至新的 UI (預覽或測試)，同時保留舊的 UI 和現有的功能並存。
API 管理執行個體已設定為將舊版 HTTP 服務對應至新的 API 合約。 在此設定中，新的 Web UI 並不知道與一組舊版服務/API 和新 API 的整合。
未來，專案小組會逐漸將功能移植到新的 API，並淘汰原始服務。 小組會在 API 管理組態內處理這些變更，讓前端 UI 不受影響，並避免重建工作。
元件
- Azure API 管理會抽象化後端 API，以及為開發人員和應用程式新增跨領域功能和探索。 在此案例中，會重新組合現有的舊版後端 API，並新增新的 API 功能，方法是使用 API 管理做為新用戶端應用程式一致且使用新式標準的外觀。 由於 API 管理 外觀既存在，又會讓開發人員以反覆的方式將 API 管理外觀背後的舊版後端現代化，而且對新的前端開發影響最小到零。
- Azure App 服務 是 Web 裝載的周全平台即服務 (PaaS) 服務，可提供現成的功能，例如安全性、負載平衡、自動縮放和自動化管理。 Azure App 服務是針對此解決方案開發的新 API 的絕佳選擇，因為它提供彈性的周全裝載功能，讓 DevOps 小組能夠專注於提供功能。
替代項目
如果組織計劃將其基礎結構完全移至 Azure，包括裝載舊版應用程式的虛擬機器 (VM)，API 管理仍然是一個很好的選項，因為它可做為任何可定址 HTTP 端點的外觀。
如果組織已決定將現有的端點保持為私人，而不會公開這些端點，則組織的 API 管理執行個體可能會連結到 Azure 虛擬網路：
- 當 API 管理連結至 Azure 虛擬網路時，組織可以透過私人 IP 位址直接定址後端服務。
- 在內部部署案例中，API 管理執行個體可以透過 Azure VPN 閘道和站對站網際網路通訊協定安全性 (IPSec) VPN 連線或 Azure ExpressRoute 私下連線回內部服務。 此案例接著會變成 Azure 和內部部署的混合式。
組織可以在內部模式中部署 API 管理執行個體，使其保持私用。 接著，組織可以使用部署搭配 Azure 應用程式閘道，為某些 API 啟用公用存取，而其他 API 則保持內部狀態。 有關詳細資訊，請參閱將內部虛擬網路中的 API 管理與應用程式閘道整合。
組織可能會決定在內部部署裝載其 API。 這項變更的其中一個原因是組織無法將此專案範圍內的下游資料庫相依性移至雲端。 如果是這種情況，組織仍然可以使用自我裝載閘道，利用本機 API 管理。
自我裝載閘道是 API 管理閘道的容器化部署，可連線回輸出通訊端上的 Azure。 第一個必要條件是，若 Azure 中沒有父資源，就無法部署自我裝載閘道，這會產生額外費用。 其次，需要 API 管理的進階分層。
案例詳細資料
旅遊業中的電子商務公司正在將其舊版瀏覽器型軟體堆疊現代化。 雖然現有的堆疊大多是整合型，但最近專案存在一些以簡單物件存取通訊協定 (SOAP) 為基礎的 HTTP 服務。 該公司正在考慮建立額外的收入來源，以獲利其開發的一些內部智慧財產權。
專案的目標包括解決技術債務、改善持續維護，以及以較少的回歸錯誤加速特徵開發。 專案會使用反覆流程來避免風險，並平行執行一些步驟：
- 開發小組會將應用程式的後端現代化，其中包含裝載於 VM 上的關係資料庫。
- 內部開發小組會撰寫新的商務功能，以透過新的 HTTP API 公開。
- 合約開發小組會建置新的瀏覽器型 UI，此 UI 將會裝載於 Azure 中。
新的應用程式功能將會分階段傳遞。 這些功能將逐漸取代現有的瀏覽器型用戶端/伺服器 UI 功能 (裝載於內部部署)，而此功能現在可支援公司的電子商務業務。
管理團隊的成員不想不必要地現代化。 他們也想要維持對範圍和成本的控制。 為了這樣做，他們已決定保留其現有的 SOAP HTTP 服務。 他們也會想要將現有 UI 的變更降到最低。 他們可以使用 Azure API 管理來解決許多專案的需求和條件約束。
潛在使用案例
此案例強調將舊版瀏覽器型軟體堆疊現代化。
您可以使用此案例：
- 瞭解您的企業如何受益於使用 Azure 生態系統。
- 規劃將服務移轉至 Azure。
- 瞭解移轉至 Azure 將如何影響現有的 API。
考量
這些考慮能實現 Azure Well-Architected Framework 的支柱，其為一組有助於提高工作負載品質的指導原則。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。
- 請考慮部署已啟用可用性區域的 Azure API 管理執行個體。 API 管理部署至可用性區域的選項僅適用於進階服務層級。
- 可用性區域可以與部署到不同區域的其他閘道執行個體搭配使用。 如果某個區域離線，這可以提高服務可用性。 多區域部署也僅在進階服務層級中可用。
- 請考慮與 Azure 應用程式 Insights 整合，其也會透過 Azure 監視器呈現計量以進行監視。 例如，容量計量可用來判斷 API 管理資源的整體負載，以及是否需要額外的向外延展單位。 追蹤資源容量和健康情況可改善可靠性。
- 請確定下游相依性，例如裝載 API 管理外觀 API 的後端服務，也具有復原性。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。
API 管理以四種階層提供：開發人員、基本、標準和進階。 如需這些層級差異的詳細指引，請參閱 Azure API 管理定價指引。
您可以透過新增和移除單元來擴充 API 管理。 每個單位的容量依其層級而定。
注意
您可以使用開發人員分層來評估 API 管理功能。 不要將其用於生產。
若要檢視預估的成本並自訂您的部署需求，您可以修改 Azure 定價計算機中的縮放單位和 App Service 執行個體數目。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Ben Gimblett | 資深客戶工程師
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
產品文件：
學習課程模組：