共用方式為

將微服務部署到 Azure 容器應用程式

Azure 容器應用程式
Azure Cosmos DB
Azure 服務匯流排

此情境展示了原本為 Kubernetes 設計的現有工作負載，後來重新平台以在 Azure 容器應用程式中運行。 容器應用程式支援棕地工作負載，團隊希望簡化基礎設施與容器協調。

範例工作負載是一個容器化的微服務應用程式。 它重用了 Azure Kubernetes Service（AKS）微服務架構中定義的工作負載。 此架構將工作負載重新架設於容器應用程式中，作為其應用平台。

這很重要

此架構著重於減少應用程式碼變更，並將從 AKS 過渡到 Container Apps 的過程視為平台遷移。 目標是複製現有實作，並延後可能影響遷移的程式碼或基礎設施優化。

關於新開發工作負載，請參見 「利用容器應用程式與 DAPR 部署微服務」。

提示

一個 範例實作 支援此架構，並說明本文中描述的一些設計選擇。

架構

圖示顯示該解決方案的執行時架構。

下載此架構的 Visio 檔案。

共享相同環境的服務可從以下方式受益：

  • 內部輸入和服務探索
  • 運行時間記錄的單一 Log Analytics 工作區
  • 一種安全管理秘密與憑證的方法

數據流

  1. 攝取服務： 接收用戶的請求，將其緩衝後發布至 Azure 服務匯流排。 這是進入工作負載的唯一入口。

  2. 工作流程服務： 從服務匯流排接收訊息，並將其派遣至底層微服務。

  3. 封裝服務： 管理套件。 該服務在 Azure Cosmos DB 中維護自己的狀態。

  4. 無人機排程器服務： 排程無人機，並監視飛行中的無人機。 該服務在 Azure Cosmos DB 中維護自己的狀態。

  5. 外送服務： 管理預定或運送途中的配送。 該服務在 Azure Managed Redis 中維護自己的狀態。

  6. 秘密取回： 因為這是現有的工作負載，只有部分元件會存取 Azure Key Vault 來取得執行時的秘密。 其他服務則從容器應用程式環境中接收這些秘密。

  7. 日誌與指標： 環境和所有容器應用程式都會產生日誌和指標，Azure Monitor 會提供這些功能，然後收集並視覺化。

  8. 容器圖片： 容器映像檔是從先前用於 AKS 的現有 Azure 容器登錄檔中擷取，並部署到 Container Apps 環境中。

元件

工作負載會協調使用以下 Azure 服務：

  • 容器應用程式 是一個無伺服器的容器平台，簡化了容器的編排與管理。 在此架構中，容器應用程式會做為所有微服務的主要裝載平臺。

    以下功能取代了許多先前 AKS 架構的功能：

    • 內建的服務探索
    • 受管理的 HTTP 與 HTTP/2 端點
    • 整合式負載平衡
    • 記錄和監視
    • 根據 HTTP 流量或由 Kubernetes 型事件驅動自動調整 （KEDA） 提供支援的事件進行自動調整
    • 應用程式升級和版本設定

  • 容器登錄 檔是一種託管登錄服務，用於儲存和管理私人容器映像檔。 在此架構中，它是所有部署到 Container Apps 環境的容器映像的來源。 該登錄檔與 AKS 實作中使用的相同。

  • Azure Cosmos DB 是一個全球分布式、多模型的資料庫服務。 在此架構中，無人機排程服務使用 Azure Cosmos DB 作為資料儲存庫。

  • Azure DocumentDB 是一個完全管理的 MongoDB 相容資料庫服務，用於建置現代應用程式。 在此架構中，套件服務使用 Azure DocumentDB 作為資料儲存庫。

  • Service Bus 是一種雲端訊息服務，提供非同步通訊功能與混合整合。 在此架構中，它處理擷取服務與基於任務的工作流程微服務之間的非同步訊息傳遞。 現有應用程式中其他服務的設計是讓其他服務能透過 HTTP 請求呼叫它們。

  • Azure Managed Redis 是一個記憶體內快取服務。 在此架構中，它降低了延遲並提升頻繁存取的無人機投遞資料的吞吐量。

  • Key Vault 是一項雲端服務，用於安全儲存與存取如 API 金鑰、密碼和憑證等秘密。 在此架構中，無人機排程器與配送服務使用使用者指派的管理身份來與 Key Vault 進行驗證，並取得執行時所需的秘密。

  • Azure Monitor 是一套全面的監控解決方案，能收集並分析遙測資料。 在此架構中，它會透過 Log Analytics 工作區收集並儲存來自所有應用程式元件的計量和記錄。 你用這些資料監控應用程式、設定警示與儀表板，並進行故障的根本原因分析。

    • Application Insights 是一項提供可擴充監控功能的應用程式效能管理服務。 在此架構中，每個服務都配備了 Application Insights SDK 以監控應用程式效能。

替代項目

進階的 AKS 微服務架構描述了此範例的另一種情境，該架構使用 Kubernetes。

案例詳細資料

你可以透過使用 Container Apps（一個無伺服器環境來托管容器化應用程式）來簡化微服務容器的部署與管理。

虛構公司Fabrikam公司實施無人機配送工作負載，用戶需請求無人機取貨送達。 當客戶預約取件時，後端系統會指派無人機，並通知使用者預估取貨時間。

微服務應用程式已部署至 AKS 叢集。 但Fabrikam團隊並未充分利用先進或平台專屬的AKS功能。 他們將應用程式遷移到 Container Apps，這讓他們能夠執行以下操作：

  • 將應用程式從 AKS 移至 Container Apps 時，盡量減少程式碼變更。 這些程式碼變更與可觀察性函式庫有關，這些函式庫用 Kubernetes 節點資訊來增強日誌和指標，這些在新環境中並不相關。

  • 使用 Bicep 範本部署基礎結構和工作負載：部署其應用程式容器不需要 Kubernetes YAML 指令清單。

  • 透過受管理的入口來揭露應用程式。 內建支援外部基於 HTTPS 的入口來暴露擷取服務，免除了自訂自身入口的需求。

  • 從容器登錄檔拉取容器映像檔。 容器應用程式相容於任何可用儲存庫中的任何 Linux 基礎映像檔。

  • 使用修訂功能來支援應用程式生命週期的需求。 他們可以執行多個特定容器應用程式的版本，並在這些版本間分配流量，用於 A/B 測試或藍綠部署場景。

  • 使用受管理身份來與 Key Vault 和 Container Registry 進行認證。

潛在使用案例

將布朗菲爾德微服務型應用程式部署至平臺即服務 （PaaS），以簡化管理，並避免執行容器協調器的複雜性。 棕地工作負載透過採用此架構而非 Kubernetes 部署，節省了成本，原因如下：

  • 工作負載配置的選擇
  • 營運團隊在第二天的營運任務上花費的時間減少
  • 避免過度配置的能力

備註

並非所有工作負載都能帶來這樣的成本節省。

考慮容器應用程式的其他常見用途：

  • 在無伺服器、以消費為基礎的平台上執行容器化工作負載。
  • 根據 HTTP 或 HTTPS 流量以及 KEDA 支援的事件驅動觸發器，自動調整應用程式的規模。
  • 降低容器化應用的維護負擔。
  • 部署 API 端點。
  • 主機背景處理應用程式。
  • 處理事件驅動的處理。

Optimizations

工作負載團隊的目標是以最小化程式碼變更，將現有工作負載遷移到容器應用程式。 但遷移後，你應該做多項優化，以改善架構和工作負載實作。

改善秘密管理

工作負載採用混合方式管理機密。 受管理身份僅適用於轉換到管理身份不需要修改程式碼的服務。 無人機排程器與配送服務採用使用者指派的管理身份，並使用鑰匙庫來存取儲存的機密。 其餘服務則需要程式碼變更來採用受管理身份，因此這些服務會使用容器應用程式環境提供的秘密資料。

更好的做法是透過應用程式或工作身份來更新所有程式碼，以支援受管理身份，而非環境提供的秘密。 欲了解更多關於工作負載身份的資訊，請參閱 容器應用程式中的受管理身份。

避免採用需要單一修訂模式的設計

工作流程服務容器應用程式以單一版本模式運行。 在單一修訂版本模式下，應用程式有一個修訂版本，並由零個或多個副本支援。 複本由應用程式容器及所需的側車組成。 這個範例沒有使用側車，所以每個複製品是一個單一容器。 工作流程服務並非設計來與訊息結構的前向相容性。 服務的兩個不同版本絕不應同時運行。

如果服務匯流排訊息結構必須變更，您必須先排空匯流排，才能部署新的工作流程服務版本。 更好的做法是更新服務程式碼以實現前向相容，並使用多重修訂模式以減少因排空佇列而產生的停機時間。

以工作為基礎的工作

工作流程服務以長期執行的容器應用程式形式實作。 但它也可以在 容器應用程式中作為工作執行。 工作是一個容器化應用程式，按需啟動，根據可用工作執行至完成，然後關閉並釋放資源。 工作比持續執行複製品更經濟。 將服務遷移為容器應用程式工作，根據隊列中可用的工作來執行，可能是個實際的選擇。 這取決於典型的佇列量，以及工作流程服務的有限、可平行化和資源優化程度。 多做實驗並驗證，找出最佳方法。

實作入口控制

該工作負載利用容器應用程式內建的外部進入功能來揭露導入服務。 入口控制方法無法完全將入口點置於網頁應用程式防火牆（WAF）後方，或將其納入 Azure DDoS 防護計畫中。 你需要在所有面向網頁的工作負載前端都用 WAF。 要在容器應用環境中實現此設定，您應該停用內建的公開入口，並新增 應用程式閘道 或 Azure 前門。

備註

閘道器需要有意義的健康探測，這些探測器能維持入口服務的運作，並防止其縮放到零。

使用Dapr進行現代化

你還可以透過整合分散 式應用程式執行環境（DAPR）進一步現代化工作負載。 它增加了工作負載程式碼與狀態儲存、訊息系統及服務發現機制之間的抽象。 欲了解更多資訊，請參閱 「使用容器應用程式部署微服務」及「DAPR」。 如果你在 Kubernetes 中的工作負載已經使用 Dapr 或常見的 KEDA 擴展器，遷移到 Container Apps 通常很簡單，且能保留該功能。

遷移至使用者認證與授權系統

工作負載不會將授權委派給閘道器。 資料引入服務負責處理客戶端的授權。 更好的做法是將這項責任轉嫁給 內建的認證與授權功能，通常稱為 簡易認證（Easy Auth）。 此變更利用平台功能，並減少擷取微服務中的自訂程式碼。

考量

以下考量實現了 Microsoft Azure Well-Architected 框架的支柱，這是一套指導原則，可用來提升工作負載的品質。 欲了解更多資訊，請參閱 Azure Well-Architected Framework。

可靠性

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

容器應用程式協助你部署、管理、維護及監控工作負載中的應用程式。 你可以透過遵循核心建議來提升可靠性。 部分建議是在從 Kubernetes 遷移過程中實施的。

  • 修訂可協助您以零停機時間部署應用程式更新。 你可以用修訂來管理應用程式更新的部署，並在修訂間分配流量，以支援藍綠部署和 A/B 測試。

  • 透過容器應用程式的可觀察性功能，你可以深入了解環境中執行的元件。 容器應用程式與應用洞察（Application Insights）及日誌分析（Log Analytics）整合。 你可以利用這些資料追蹤操作，並根據指標和事件設定警報，作為可觀察性系統的一部分。

    效能監控能幫助你在負載下評估應用程式。 指標與日誌提供資料，用以識別趨勢、調查失效並進行根本原因分析。

  • 使用 健康探測和就緒探測 來處理起步緩慢的容器，避免在容器尚未準備好前就送出流量。 Kubernetes 實作包含這些端點。 如果它們能提供有效的訊號，就繼續使用。

  • 當服務意外終止時，容器應用程式會自動重新啟動服務。 啟用服務發現功能，讓工作流程服務能夠發現其下游微服務。 使用 韌性策略 來處理逾時並引入斷路器邏輯，無需進一步調整程式碼。

  • 啟用自動擴展規則，以因應流量與工作負載增加的需求。

  • 利用容器應用程式的動態負載平衡與擴展功能來提升可用性。 過度配置你的環境子網路，讓它永遠有足夠的 IP 位址供未來的副本或工作使用。

  • 避免直接在容器應用程式環境中儲存狀態，因為當副本關閉時，所有狀態都會遺失。 將狀態外部化到每個微服務的專用狀態儲存庫。 此架構將狀態分配至三個不同的儲存庫：Azure Managed Redis、Azure Cosmos DB for NoSQL 以及 Azure DocumentDB。

  • 使用多區域拓撲部署所有資源，包括容器應用程式。 欲了解更多資訊，請參閱 容器應用程式中的可用性區域支援。

    將非臨時應用的最低副本數設為每個可用區域至少有一個副本。 在典型運作條件下，複製品會可靠地分布並平衡於區域內的可用區域。

安全性

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

密碼

  • 您的容器應用程式可以將敏感性值儲存並擷取為秘密。 當你為容器應用程式定義一個秘密後，該應用程式及相關的擴展規則即可使用。 如果您是以多重修訂模式執行，所有修訂都會共用相同的秘密。 因為秘密被視為應用程式範圍的變更，如果你改變了秘密的值，就不會產生新的版本。 但要讓任何正在執行的版本載入新的秘密值，你都需要重新啟動它們。 在此案例中，會使用應用程式和環境變數值。

  • 重寫服務程式碼，使用應用程式自身的管理身份來驗證相依性，而非預先共享的秘密。 所有相依項目都有支援受管理的身份驗證的 SDK。

  • 你可以在應用程式層級安全地將敏感值儲存在環境變數中。 當環境變數改變時，容器應用程式會建立新的版本。

網路安全性

  • 為了限制外部存取，只有擷取服務會被設定為外部入口。 後端服務只能透過容器應用程式環境中的內部虛擬網路存取，並設定為內部模式。 只有在需要時才讓服務公開在互聯網上。

    由於此架構使用內建的外部入口功能，此方案無法完全將入口點置於 WAF 後方，或將其納入 DDoS 防護計畫中。 將網頁應用防火牆設置在所有面向網頁的工作負載前面。 欲了解更多關於入口改進的資訊，請參閱 「實施入口控制」。

  • 當你建立環境時，可以提供自訂的虛擬網路。 否則，Microsoft 會自動產生並管理虛擬網路。 您無法操作此Microsoft受控虛擬網路，例如將網路安全組 （NSG） 或強制通道流量新增至輸出防火牆。 範例中使用自動生成的虛擬網路，但自訂虛擬網路能提升安全性控制。 自訂網路讓你能透過 Azure 防火牆套用 NSG 和基於使用者定義路由（UDR）的路由。

欲了解更多關於網路拓撲選項，包括私有端點支援的入口資訊，請參閱 容器應用程式中的網路架構。

工作負載身分識別

  • 容器應用程式支援 Microsoft Entra 管理身份，讓你的應用程式能在不管理容器應用程式憑證的情況下，對其他由 Microsoft Entra ID 保護的資源（如 Key Vault）進行認證。 容器應用程式可以使用系統指派的身份、使用者指定的身份，或兩者兼具。 對於不支援 Microsoft Entra ID 認證的服務，請將秘密存放在 Key Vault 中，並使用管理身份來存取這些秘密。

  • 使用一個專用且由使用者指派的管理身份來存取容器登錄檔。 容器應用程式支援使用與容器登錄檔存取不同的管理身份來進行工作負載操作。 此方法提供細緻的存取控制。 如果你的工作負載有多個容器應用程式環境，不要在實例間共享身份。

  • 使用系統指派的管理身份來管理工作負載身份，將身份生命週期與工作負載元件生命週期綁定。

更多安全建議

  • 此工作負載的 Kubernetes 實作透過 Microsoft Defender for Containers 功能提供保護。 在此架構中，Defender for Containers 只會評估容器登錄檔中容器的 脆弱性 。 Defender for Containers 並不提供容器應用程式的執行時保護。 如果執行時保護是需求，請考慮是否加入非 Microsoft 的安全解決方案。

  • 不要在共用容器應用程式環境中執行工作負載。 將它與其他不需要存取這些微服務的工作負載或元件分隔開來。 建立獨立的容器應用程式環境。 在容器應用程式環境中執行的應用程式和工作，可以發現並存取任何在該環境中運行且啟用內部入口的服務。

成本優化

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

  • 檢視工作量的範例價格估算。 使用 Azure 價格計算器。 配置會有所不同，請依照你的情況調整。

  • 在這種情況下，Azure Cosmos DB、Azure Managed Resit 和 Service Bus Premium 是主要的成本驅動因素。

  • 對於通常消耗 CPU 和記憶體量較低的容器，請先評估其消耗工作負載的特性。 根據你的使用情況估算消費使用模式的成本，有助於收集基準成本資料並評估其他模式。 例如，你可以為使用量高度可預測且穩定且能共享專用節點的元件使用專用工作負載設定檔。 為了優化成本，每個專用配置檔維持三個節點的倍數，以確保有足夠的運算主機與副本分布於各可用區域。

  • 在非活動期間消除運算成本，確保元件能擴展到零，讓你只在需要時付費。 這種方式降低了使用頻率不穩定或不頻繁的應用程式的費用。 健康檢查通常會阻止完全歸零。 在架構中，你可以將工作流程服務重新設計為作業，以便在閒置期間利用自動縮減至零的功能。 這種方式非常適合需要 使用消耗計畫的工作負載。

  • 為避免跨區域網路費用，所有元件（如州儲存庫與容器登錄）部署於同一區域。

卓越營運

卓越營運涵蓋部署應用程式的作業程式，並讓它在生產環境中執行。 如需詳細資訊，請參閱 Operational Excellence的設計檢閱檢查清單。

  • 使用 GitHub Actions 或 Azure Pipelines 整合來設定自動化的持續整合與持續部署（CI/CD）管線。

  • 使用多版本模式搭配流量分割來測試工作負載程式碼和擴展規則的變更。

  • 整合 Application Insights 和 Log Analytics，深入解析你的工作負載。 使用與工作負載其他元件相同的 Log Analytics 工作空間，以整合所有工作負載洞察。

  • 使用基礎設施即程式碼（IaC），如 Bicep 或 Terraform，來管理所有基礎設施部署。 部署包括容器應用程式環境、容器登錄檔及微服務狀態儲存庫。 將微服務部署管線與基礎架構管線分開，因為它們通常不共享相同的生命週期。 Azure 基礎設施的宣告式工作流程應該部署所有資源，但容器應用程式資源除外。

  • 使用命令式的方法來建立、更新及移除容器應用程式。 如果你在不同版本間動態調整流量切換邏輯，那麼這點尤其重要。 在你的部署工作流程中使用 GitHub 動作 或 Azure Pipelines 任務 。 這種命令式方法可以基於 YAML 應用程式的定義。 為了減少健康檢查失敗，部署容器應用程式前，務必確保你的管線已將新的容器映像檔填入你的容器登錄檔。

    Kubernetes 實作中一項重要變革是逐漸從管理 Kubernetes 清單檔案（如定義 Deployment Kubernetes 物件）轉型。 Kubernetes 透過這個 manifest 物件，提供一種 原子式的「一起成功 或 一起失敗 」的微服務部署方法。 在容器應用程式中，每個微服務都是獨立部署的。 你的部署管線負責協調任何必要的排序與回滾策略，以確保安全部署。

效能效率

效能效率是指工作負載能夠有效率地調整以符合使用者需求。 如需詳細資訊，請參閱 效能效率的設計檢閱檢查清單。

  • 工作負載會分散於多個微服務應用程式。

  • 每個微服務獨立，且不與其他微服務共享狀態，這使得獨立擴展成為可能。

  • 利用容器應用程式工作（Container Apps Jobs）進行有限的程序執行，實作暫態運行並降低閒置服務的資源消耗。 評估上下旋轉工作與保持元件溫暖且隨時待命的效能影響。

  • 自動縮放是啟用的。 盡可能偏好事件基礎縮放而非指標化。 例如，如果設計成支援工作流程服務，可以根據服務匯流排佇列深度擴展。 預設的自動擴展器是基於 HTTP 請求。 在重新平台化過程中，重要的是從相同的擴展方法開始，然後再評估擴展優化。

  • 請求會動態負載平衡到可用的版本副本。

  • 包括 CPU 使用率、記憶體、頻寬資訊及儲存空間等指標，皆可透過 Azure Monitor 取得。

部署此案例

請依 照容器應用程式範例情境庫 README.md 中的步驟操作。

參與者

本文由 Microsoft 維護。 下列參與者撰寫本文。

貢獻者：

下一步