Azure API 管理
Azure 監視器
Azure App Service
在這個情境中，一家旅遊業的電子商務公司透過使用 Azure API Management 遷移舊有的網頁應用程式。 公司將新的 UI 作為平台即服務（PaaS）應用架設於 Azure。 新的使用者介面依賴現有與新的 HTTP API。 這些 API 配備設計更有效的介面，提升效能、簡化整合，並允許未來擴充。
Architecture
下載此架構的 Visio 檔案。
Workflow
下列工作流程對應至上圖：
現有的本地網路應用程式持續直接消耗現有的本地網路服務。
從現有 Web 應用程式對現有 HTTP 服務的呼叫保持不變。 這些呼叫是公司網路內部的。
API 管理會從 Azure 呼叫現有的內部服務。
資安團隊允許來自 API Management 實例的流量透過企業防火牆，透過如傳輸層安全超文本傳輸協定（HTTPS）傳輸層安全（TLS）等 安全傳輸協定 ，傳送至現有的本地服務。
作業小組只允許從 API 管理執行個體對服務的輸入呼叫。 它透過 將 API 管理實例的 IP 位址加入 企業網路邊界內的允許清單來達成此要求。
本地請求流程中新增的超文本傳輸協定（HTTP）服務模組僅作用於外部來源的連線。 管線會驗證 API 管理所提供的憑證。
新 API 具備以下特點：
只有提供 API 介面的 API Management 實例會顯示新的 API。 你不會直接存取新的 API。
你要開發並發佈新的 API，作為 Azure PaaS 網頁 API 應用程式。
你可以使用 Azure App Service 的 Web Apps 功能設定，將新的 API 設定為僅接受 API 管理虛擬 IP (VIP)。
Web Apps 承載了新的 API，並啟用了像 HTTPS 或 TLS 這類安全的傳輸協定。
Azure App Service 透過 Microsoft Entra ID 與開放授權（OAuth）2 提供授權功能。
這個新的瀏覽器網頁應用程式依賴於現有 HTTP API 與新 API 的 API 管理實例。
這家旅遊電子商務公司可以引導部分用戶預覽或測試新介面，同時保留舊介面與現有功能並存。
設定 API Management 實例，將舊有的 HTTP 服務映射到新的 API 合約。 在此配置中，新的網頁介面並未意識到與一組舊有服務或 API 及新 API 的整合。
未來專案團隊可逐步將功能轉移至新 API，並退休原有服務。 團隊在 API 管理設定中處理這些變更，前端介面不受影響，避免重新開發工作。
Components
API 管理 是一個跨所有環境的 API 管理平台與閘道。 在此架構中，它作為現有舊有 API 與新 API 的 表 象。 新的客戶端應用程式只佔用單一一致的介面，團隊可以在這層面具下逐步現代化舊有後端，對前端開發的影響極小。
App Service 是一款交鑰匙的 PaaS 網頁主機解決方案，提供開箱即用的功能，如安全性、負載平衡、自動擴展及自動化管理。 在此架構中，App Service 提供靈活的交鑰匙主機，讓 DevOps 團隊能專注於功能交付。
Alternatives
若組織計劃將基礎設施，包括承載舊有應用程式的虛擬機（VM）全部遷移至 Azure，API 管理可作為任何可定址 HTTP 端點的表象。
如果組織保持現有端點私有且不公開，組織的 API 管理實例可以連結到 Azure 虛擬網路。
當 API 管理連結到 Azure 虛擬網路時，組織可直接透過私有 IP 位址連接後端服務。
在本地環境下，API 管理實例可透過 Azure VPN 閘道及站對站網際網路協定安全（IPsec）VPN 連線 或 Azure ExpressRoute，私密連接內部服務。 此情境成為 Azure 與本地部署的混合體。
組織可以在內部模式中部署 API 管理執行個體，使其保持私用。 組織接著可以使用 Azure Application Gateway 的部署，允許部分 API 公開存取，而其他則保留在內部。 欲了解更多資訊，請參閱透過 應用閘道整合內部虛擬網路中的 API 管理。
組織可能會決定在內部部署託管其 API。 此變更的原因之一是組織無法將本專案範圍內的下游資料庫相依性移至雲端。 在這種情況下，組織可以透過 自架閘道器在本地利用 API 管理。
自架閘道是一種容器化的 API 管理閘道部署，透過外接接字連接到 Azure。 要使用自架閘道器，您必須符合以下先決條件：
你必須在 Azure 中使用母資源部署自架閘道，這會增加額外成本。
您必須使用 API Management 的 Premium 等級。
案例詳細資料
一家旅遊業的電子商務公司希望現代化其傳統的瀏覽器軟體堆疊。 現有的堆疊大多是單一架構，但近期專案中已有一些 基於簡單物件存取協定（SOAP）的 HTTP 服務 。 公司考慮創造額外的收入來源，以將部分內部智慧財產變現。
專案目標包括解決技術債務、持續維護改進，以及加速功能開發，同時減少回歸錯誤。 專案採用迭代流程來避免風險，並並行執行以下步驟：
開發團隊將應用程式的後端現代化，該應用由部署在虛擬機上的關聯式資料庫組成。
內部開發團隊撰寫新的商業功能，並透過新的 HTTP API 公開。
一個合約開發團隊打造了一個新的瀏覽器介面，由 Azure 主機。
公司會分階段推出新的應用程式功能。 這些功能逐漸取代了現有的本地瀏覽器客戶端與伺服器介面功能，這些功能支撐著公司的電子商務業務。
管理團隊的成員不想不必要地現代化。 他們也想要維持對範圍和成本的控制。 為了達成這些目標，他們決定保留現有的 SOAP HTTP 服務。 他們也會想要將現有 UI 的變更降到最低。 他們可以利用 API 管理 來解決專案的許多需求與限制。
潛在使用案例
此情境凸顯了如何現代化舊有的瀏覽器軟體堆疊。
你可以用這個情境來執行以下任務：
- 瞭解您的企業如何受益於使用 Azure 生態系統。
- 規劃服務遷移到 Azure。
- 了解轉向 Azure 可能如何影響現有 API。
Considerations
這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。
Reliability
可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。
部署 API Management 實例時啟用 可用區域 。 將 API Management 部署到可用區域的選項僅在高級服務層級中提供。
使用部署在不同區域且具有額外閘道實例的可用區域。 這種組合能提升服務可用性，即使某區域離線。 多區域部署僅在高級服務層級提供。
整合 Application Insights，透過 Azure Monitor 顯示指標以便監控。 例如，你可以利用容量指標來判斷 API 管理資源的整體負載，以及是否需要 更多擴展單元。 追蹤資源容量與健康狀況以提升可靠性。
確保下游的相依項，例如由 API 管理涵蓋的 API 所依賴的後端服務，也具備韌性。
成本優化
成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。
API 管理分為八個層級：
- 使用量
- 開發人員
- Basic 與 Basic v2
- 標準與標準 v2
- Premium 與 Premium v2
欲了解更多這些層級差異的資訊，請參閱 API 管理定價。
您可以透過新增和移除單元來擴充 API 管理。 每個單位的容量依其層級而定。
Note
你可以用開發者層級來評估 API 管理的功能。 不要將其用於生產。
要查看部署需求的預計成本，可以在 Azure 價格計算器中修改擴展單元和 App Service 實例的數量。
Contributors
本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。
主要作者：
- 本·金布雷特 |資深客戶工程師
其他參與者：
- 安德魯·卡迪 |資深軟體工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。