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