共用方式為

使用 Azure API 管理移轉 Web 應用程式

Azure API 管理
Azure 監視器
Azure App Service

在此案例中，旅遊產業的一家電子商務公司使用 Azure API 管理來移轉舊版 Web 應用程式。 新介面以平台即服務（PaaS）形式託管於 Azure，並依賴現有與新 HTTP API。 這些 API 附帶設計更完善的介面，提升效能、更易整合及未來擴充性。

Architecture

架構圖

下載此架構的 Visio 檔案。

Workflow

  1. 現有的內部部署 Web 應用程式會繼續直接取用現有的內部部署 Web 服務。
  2. 從現有 Web 應用程式對現有 HTTP 服務的呼叫保持不變。 這些呼叫是公司網路內部的。
  3. 從 Azure 到現有的內部服務會進行輸入呼叫：
  4. 新 API：
  5. 新的瀏覽器型網頁應用程式依賴 Azure API Management 實例，適用於既有的 HTTP API 和新的 API。
  6. 旅遊電子商務公司現在可以將某些使用者導向至新的 UI (預覽或測試)，同時保留舊的 UI 和現有的功能並存。

API 管理執行個體已設定為將舊版 HTTP 服務對應至新的 API 合約。 在此設定中，新的 Web UI 並不知道與一組舊版服務/API 和新 API 的整合。

未來專案團隊可逐步將功能移植至新 API，並退休原有服務。 團隊在 API 管理設定中處理這些變更，前端介面不受影響，避免重新開發工作。

Components

  • Azure API 管理 會抽象化後端 API，以及為開發人員和應用程式新增跨領域功能和探索。 在此情境中，使用 API 管理作為新客戶端應用程式一致存取的介面，並採用現代標準，重新組合現有的舊有後端 API 並加入新的 API 功能。 由於 API 管理 外觀既存在，又會讓開發人員以反覆的方式將 API 管理外觀背後的舊版後端現代化，而且對新的前端開發影響最小到零。
  • Azure App Service 是 Web 裝載的一項關鍵平臺即服務（PaaS）服務，可提供現成的功能，例如安全性、負載平衡、自動調整和自動化管理。 Azure App 服務是針對此解決方案開發的新 API 的絕佳選擇，因為它提供彈性的周全裝載功能，讓 DevOps 小組能夠專注於提供功能。

Alternatives

  • 如果組織計劃將其基礎結構完全移至 Azure，包括裝載舊版應用程式的虛擬機器 (VM)，API 管理仍然是一個很好的選項，因為它可做為任何可定址 HTTP 端點的外觀。

  • 如果組織已決定將現有的端點保持為私人，且不會公開這些端點，則組織的 API 管理實例可能會連結到 Azure 虛擬網路：

  • 組織可以在內部模式中部署 API 管理執行個體，使其保持私用。 接著，組織可以使用部署與 Azure 應用程式閘道 ，為某些 API 啟用公用存取，而其他 API 則保持內部狀態。 如需詳細資訊，請參閱 在內部虛擬網路中整合API管理與應用程式閘道。

  • 組織可能會決定在內部部署裝載其 API。 這項變更的其中一個原因是組織無法將此專案範圍內的下游資料庫相依性移至雲端。 如果是這樣，組織仍可透過 自架閘道器在本地利用 API 管理。

    自我裝載閘道是 API 管理閘道的容器化部署，可連線回輸出通訊端上的 Azure。 第一個必要條件是，若 Azure 中沒有父資源，就無法部署自我裝載閘道，這會產生額外費用。 其次，需要 API 管理的進階分層。

案例詳細資料

旅遊業中的電子商務公司正在將其舊版瀏覽器型軟體堆疊現代化。 雖然現有的堆疊大多是整合型，但最近專案存在一些 以簡單物件存取通訊協定 （SOAP） 為基礎的 HTTP 服務 。 該公司正在考慮建立額外的收入來源，以獲利其開發的一些內部智慧財產權。

專案的目標包括解決技術債務、改善持續維護，以及以較少的回歸錯誤加速特徵開發。 本專案採用反覆流程以避免風險，並同時進行以下步驟：

  • 開發團隊現代化了應用程式的後端，該後端由虛擬機上託管的關聯式資料庫組成。
  • 內部開發團隊撰寫新的業務功能，並透過新的 HTTP API 公開。
  • 一個合約開發團隊打造了一個新的瀏覽器介面，並以 Azure 為主機。

新的應用程式功能會分階段交付。 這些功能逐漸取代現有的瀏覽器用戶端/伺服器介面功能（本地託管），而這些功能現在支撐著公司的電子商務業務。

管理團隊的成員不想不必要地現代化。 他們也想要維持對範圍和成本的控制。 為了這樣做，他們已決定保留其現有的 SOAP HTTP 服務。 他們也會想要將現有 UI 的變更降到最低。 他們可以使用 Azure API 管理 來解決許多專案的需求和條件約束。

潛在使用案例

此案例強調將舊版瀏覽器型軟體堆疊現代化。

您可以使用此案例：

  • 瞭解您的企業如何受益於使用 Azure 生態系統。
  • 規劃將服務移轉至 Azure。
  • 瞭解移轉至 Azure 將如何影響現有的 API。

Considerations

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

API 管理以四種階層提供：開發人員、基本、標準和進階。 欲了解更多關於這些層級差異的資訊，請參閱 Azure API 管理定價指引。

您可以透過新增和移除單元來擴充 API 管理。 每個單位的容量依其層級而定。

Note

您可以使用開發人員分層來評估 API 管理功能。 不要將其用於生產。

若要檢視預估的成本並自定義您的部署需求，您可以修改 Azure 定價計算機中的縮放單位和 App Service 實例數目。

Contributors

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

後續步驟

產品檔案：

學習模組：