在 Google Cloud 上翻新.NET 應用程式的流程

本文將探討單體式應用程式的常見限制，並說明翻新這類應用程式的結構化逐步流程。

本文適用於熟悉 Windows 和 .NET 生態系統的雲端架構師、系統管理員和技術長，可協助他們進一步瞭解現代化程序。雖然本文著重於自建伺服器應用程式 (例如 ASP.NET 或 Windows 服務應用程式)，但您仍可將這些課程內容應用於其他用途。

舊版與現代化應用程式：為何要翻新？

翻新舊版應用程式是一段歷程。您在該歷程的起點和終點，以及獲得的效益，很大程度上取決於應用程式的狀態，以及您投入現代化的時間和精力。

在 .NET 應用程式中，「舊版」和「新版」分別是指什麼？每個應用程式都有不同的舊版和現代化需求。不過，舊版應用程式有一些共同限制。

下圖摘要說明舊版應用程式和現代雲端應用程式的特性。

單體式和現代雲端應用程式的差異。

舊版 .NET 應用程式通常是單體式應用程式，建構於 .NET Framework，代管於內部部署的 Microsoft Windows 伺服器，並連線至執行 Microsoft SQL Server 的內部部署伺服器。您的架構詳細資料可能與這些一般特徵不同，但大多數單體式應用程式都有下列限制：

  • 需要管理執行 Windows 和 SQL Server 的地端伺服器。
  • 受限的部署環境，以及與 Windows 相關的授權費用。
  • 以單體式架構建構的舊版應用程式升級難度較高。
  • 使用內部部署資源規劃、編列預算及擴大規模時，靈活度較低。

為雲端架構建構的應用程式具有多項優點：

  • 與代管服務整合，將管理負擔降至最低。
  • 使用 .NET 和容器即可完全行動化，且無須依附 Windows 或支付授權費用。
  • 以可獨立部署的微服務為基礎，提供高速升級途徑。
  • 無伺服器架構可充分發揮彈性，隨時調整規模和預算。

相較於傳統的內部部署方法，雲端架構能以更具成本效益、效率和韌性的方式執行應用程式。採用雲端架構時，您可更彈性地選擇應用程式的部署位置和時間。

現代化路徑

雖然雲端架構的優點顯而易見，但通往雲端的路徑可能並非如此。從舊版 .NET 架構翻新為雲端架構，並沒有一體適用的單一模式。如下圖所示，現代化過程包含一系列步驟，每個步驟都會移除限制、提升應用程式功能，並為後續階段的現代化作業開創機會。

翻新程序涉及的程序、技術和服務。

現代化步驟分為三個階段：

  1. 在雲端重新託管 (又稱為隨即轉移)
  2. 更換平台
  3. 重新建立架構並重建

翻新前評估和學習

開始進行現代化作業前，請先做好準備。首先，請評估應用程式及其依附元件，判斷哪些應用程式適合進行現代化，哪些應用程式無法變更或遷移 (通常是因為舊版相關或法規原因)。詳情請參閱「遷移至 Google Cloud：評估及探索工作負載」。

在進行這項評估的同時，您的團隊也需要瞭解雲端的功能。 Google Cloud 提供認證、技術指南，以及 Windows 和 .NET 專用的程式碼研究室，可協助加快學習過程。

找出要現代化的應用程式後，您可以開始將傳統應用程式遷移至雲端，並保留原狀或只對應用程式程式碼或設定進行微幅變更。

第 1 階段：在雲端重新託管

第一階段的主要目標是將伺服器管理負擔從地端資源轉移至雲端基礎架構。在這個階段，您要確保基礎架構已準備好遷移至雲端，以便在後續階段針對雲端進行最佳化。

手動遷移與工具輔助遷移

遷移 Windows 型 .NET 應用程式時，通常會先將地端 Windows Server 和 SQL Server 執行個體移至 Compute Engine 虛擬機器 (VM) 執行個體。您可以手動執行這項程序，也可以使用遷移工具自動執行。

在手動遷移作業中，您可以使用 Compute Engine Windows Server 映像檔啟動執行個體。Google Cloud Marketplace 也提供可部署至 Compute Engine 的解決方案，例如 ASP.NET Framework 解決方案，可取得包含 IIS、SQL Express 和 ASP.NET 的 Windows Server VM。

同樣地，您可以從 SQL Server 映像檔啟動 SQL Server 執行個體，也可以直接使用更易於管理的解決方案：Cloud SQL for SQL Server。

Google Cloud 也提供遷移工具，例如 Migrate to Virtual Machines 或 VMware Engine，協助您將內部部署的 VMware VM 遷移至Google Cloud中的 VMware 環境。

設定 VM 後，您通常會建立自訂 VM 映像檔，以便依需求重新建立新的執行個體。這個步驟對於執行個體範本也很重要，詳情請參閱本文後續內容。

如要在雲端使用網域服務，您可以在 Compute Engine 上部署容錯移轉的 Microsoft Active Directory 環境，並搭配虛擬私有雲 (VPC)，也可以直接使用Microsoft Active Directory 的代管服務。

內部部署和雲端連線

將 VM 遷移至雲端時，您可能會將部分工作負載保留在內部部署環境，例如應用程式需要舊版硬體或軟體，或是需要符合法規和當地法規要求。您需要 VPN 或互連解決方案，才能安全地連線內部部署和雲端資源。如要瞭解如何建立及管理這項連線，以及執行混合式雲端和內部部署工作負載的其他影響，請參閱「遷移至 Google Cloud：奠定基礎」。

初始福利

在第 1 階段結束時，您已在雲端執行基本基礎架構，可享有下列優點：

  • 成本最佳化。您可以建立自訂機器類型 (CPU、記憶體和儲存空間)，並依用量付費；隨意啟動及停止 VM 和災難復原環境，只在執行時付費；以及在遷移前取得最適規模調整建議。
  • 提高作業效率。您可以將永久磁碟附加至 VM，並建立快照，簡化備份和還原程序。
  • 提高穩定性。由於有即時遷移功能，您不再需要排定維護時段。

這些初步優點很有幫助，但開始進行雲端最佳化後，您會發現更多好處。

第 2 階段：更換平台

重新平台化時，您會升級應用程式元件 (例如資料庫、快取層或儲存系統) 的部分內容，藉此最佳化應用程式，但不會變更應用程式架構，且程式碼庫的變更幅度極小。第 2 階段的目標是開始使用雲端功能，以利管理、復原、擴充及彈性調整應用程式，不必大幅重組應用程式或離開 VM 環境。

善用 Compute Engine

Compute Engine 提供一些值得探索的標準功能。舉例來說，您可以在 Compute Engine 中使用執行個體範本，從現有的 VM 設定建立範本。執行個體群組是一批相同的 VM，可讓您有效調度應用程式的效能和備援能力。除了負載平衡和備援功能，代管執行個體群組還具備自動調度資源等擴充性功能、自動修復等高可用性功能、區域部署，以及自動更新等安全性功能。

有了這些功能，您就能繼續使用 VM，同時提高應用程式的韌性、備援和可用性，不必完全重組應用程式。

尋找就地更換的項目

將應用程式遷移至雲端時，您需要尋找機會，在 Cloud Marketplace 上，以 Google 和第三方合作夥伴提供的受管理雲端選項，取代代管基礎架構，包括：

  • Cloud SQL，而非自行代管的 SQL Server、MySQL 或 Postgres。Cloud SQL 可讓您專注於管理資料庫，而非管理基礎架構 (例如修補資料庫 VM 的安全性或管理備份)，而且還能免除 Windows 授權需求。
  • Managed Service for Microsoft Active Directory，而非自行代管的 Active Directory。
  • Memorystore， 而非自行代管的 Redis 執行個體。

這些替代方案不需變更程式碼，只需進行少量設定變更，且具備管理負擔極小、安全性提升和可擴充性等優點。

Windows 容器入門

針對雲端最佳化基本函式後，即可開始從 VM 遷移至容器。

容器是輕量型套件，內含應用程式及其所有依附元件。相較於直接在 VM 上執行應用程式，容器可讓您在各種環境中執行應用程式，而且方式更一致、可預測且有效率 (特別是在同一主機上執行多個容器時)。容器周邊的生態系統 (例如 Kubernetes、Istio 和 Knative) 也提供許多管理、復原和監控功能，可進一步加速應用程式的轉換作業，從單一巨型應用程式變成一組專注的微服務。

在一段時間內，容器化是 Linux 專屬功能。Windows 應用程式無法從容器獲益。但隨著 Windows 容器和後續的 Kubernetes 支援，以及 Google Kubernetes Engine (GKE)，情況已有所改變。

如果您不想將 .NET Framework 應用程式遷移至 .NET，但仍想享有容器的優點 (例如靈活度、可攜性和控制權)，Windows 容器就是不錯的選擇。您需要選擇要鎖定的正確作業系統，視 .NET Framework 版本而定，並請注意Windows 容器不支援所有 Windows 堆疊。如要瞭解這個方法的限制和替代方案，請參閱本文稍後的「.NET 和 Linux 容器」。

將 .NET Framework 應用程式容器化為 Windows 容器後，建議您在 Kubernetes 叢集中執行該應用程式。Kubernetes 提供標準功能，例如偵測容器 Pod 何時停止運作並重新建立、自動調度 Pod 資源、自動推出或復原，以及健康狀態檢查。GKE 增添了叢集自動調度資源、區域叢集、高可用性控制層，以及透過 GKE Enterprise 支援混合雲和多雲等功能。如果您決定使用 GKE 或 GKE Enterprise，可以運用 Migrate to Containers 簡化 Windows VM 遷移至容器的程序，並加快遷移速度。Migrate to Containers 可自動將 VM 中的應用程式擷取至容器，您不必重寫或重新建構應用程式。

雖然在 Compute Engine 中使用適當的功能可帶來許多好處，但改用容器和 GKE 有助於充分運用 VM，因為您可以在同一個 VM 上封裝多個 Pod。這項策略可能會減少 VM 數量，並降低 Windows 授權費用。

使用 Kubernetes 和 GKE 宣告式地管理 Windows 和 Linux 容器，也能簡化基礎架構管理作業。完成容器化後，團隊即可準備進入下一階段的現代化程序。

階段 3：重新建立架構並重建

重新平台化只是開始，要充分發揮雲端效益，還需要更多努力。將架構轉換為雲端平台有許多優點，例如：

改用代管服務

開始重寫應用程式的部分內容時，建議您開始從代管服務遷移至受管理服務。舉例來說，您可能會使用下列項目：

雖然您需要額外程式碼才能將應用程式與這些服務整合，但這項投入是值得的，因為您可將平台管理負擔轉移至 Google Cloud。Google Cloud .NET 用戶端程式庫、Visual Studio 工具和 Visual Studio Code 適用的 Cloud Code，可協助您在整合這些服務時，繼續使用 .NET 生態系統和工具。

代管服務也能支援應用程式的運作。您可以將應用程式記錄檔儲存在 Cloud Logging 中，並將應用程式指標傳送至 Cloud Monitoring，在其中使用伺服器和應用程式指標建構資訊主頁。 Google Cloud 提供適用於 Cloud Logging、Cloud Monitoring 和 Cloud Trace 的 .NET 用戶端程式庫。

.NET 和 Linux 容器

如果您的應用程式是只能在 Windows 上執行的舊版 .NET Framework 應用程式，您可能會想繼續在 Compute Engine 的 Windows 伺服器上執行，或是在 GKE 的 Windows Server 容器中執行。雖然這種做法短期內可能有效，但長期來看會嚴重限制您的發展。Windows 需支付授權費用，且整體資源用量大於 Linux，這些因素可能會導致長期持有成本較高。

.NET 是 .NET Framework 的現代模組化版本。雖然 Microsoft 打算支援 .NET Framework，但所有新功能只會新增至 .NET (最終會新增至 .NET 5)。即使您仍想在 Windows 上執行，所有新開發作業都應在 .NET 上進行。

.NET 最重要的面向之一就是跨平台。您可以將 .NET 應用程式容器化為 Linux 容器。Linux 容器比 Windows 容器更輕量，且可在更多平台上更有效率地執行。這個因素會為 .NET 應用程式建立部署選項，讓您擺脫對 Windows 的依賴，以及相關的授權費用。

將 .NET Framework 應用程式移植到 .NET

如要開始轉移至 .NET，建議先閱讀「從 .NET Framework 移植至 .NET 的概觀」。 您可以使用 .NET 可攜性分析器和 .NET API 分析器等工具，判斷組件和 API 是否可移植。其他移植工具 (例如 dotnet try-convert) 也很有幫助。

外部工具可協助您找出相容性問題，並決定要優先遷移哪些元件。最終您需要建立 .NET 專案，逐步將 .NET Framework 程式碼移至新專案，並修正過程中出現的不相容問題。移植程式碼前，請務必先進行測試，然後在移植後測試功能。建議您使用 A/B 測試來測試新舊程式碼。透過 A/B 測試，您可以讓舊版應用程式繼續運作，同時將部分使用者導向新版應用程式。這種做法可讓您測試新應用程式的輸出內容、可擴充性和復原能力。為協助進行 A/B 測試， Google Cloud 提供負載平衡解決方案，例如 Cloud Service Mesh。

推動職場文化變革

從 .NET Framework 和 Windows 伺服器轉換為 .NET 和 Linux 容器，不只是技術上的轉移，這項轉變需要貴機構進行文化轉型。習慣使用 Windows 環境的員工需要適應多平台環境。這項文化轉型需要時間和預算，才能訓練 .NET、Linux 和 Docker 與 Kubernetes 等容器工具。不過，如果從僅限 Windows 的機構轉型為多平台機構，就能使用更多工具和技能。

單體分解

從 .NET Framework 遷移至 .NET 可能會引發幾個問題，包括：

  • 您是否要以 .NET 重寫整個應用程式？
  • 您是否將應用程式拆分為較小的服務，並以 .NET 撰寫這些服務？
  • 您是否只在 .NET 中編寫新服務？

決定這些問題時，必須考量每種方法帶來的效益、所需時間和相關費用。建議您採取平衡的做法，不要一次重寫所有內容。而是可以撰寫新的服務。NET，並在適當時機將現有的單體式應用程式拆解成較小的 .NET 服務。規劃時，下列白皮書可提供協助：

.NET 容器的部署選項

如在 Google Cloud「部署 .NET 應用程式」一節中所述，您有多種選項可在Google Cloud上部署 .NET 容器。將單體式應用程式拆解為微服務時，您可能會決定使用多個代管解決方案，具體取決於微服務的架構和設計。

回答下列問題有助於決定最佳代管策略：

  • 什麼會觸發應用程式？所有代管解決方案都適用於標準 HTTP(S)，但如果您的通訊協定是 TCP/UDP 或專有通訊協定，GKE 可能是唯一選擇。
  • 您的應用程式是否需要特定硬體？Cloud Run 會為每個要求提供合理但有限的 RAM 和 CPU 數量。Knative 服務提供更多自訂選項，例如 GPU、更多記憶體和磁碟空間。
  • 您對擴展有什麼期望？如果應用程式有閒置期，Cloud Run 等無伺服器解決方案可提供將資源調度降至零的選項。
  • 延遲時間有多重要？您的應用程式對 冷啟動的容許程度如何？ 如果對冷啟動的容許度較低，請考慮在 Cloud Run 或 GKE 上使用執行個體數量下限，並啟用自動調度。

建議您詳閱各主機環境的說明文件，瞭解其功能、優缺點和定價模式。

一般來說，如要建立處理 HTTP 要求的微服務，請盡可能部署至 Cloud Run，並在想留在 Kubernetes 生態系統或需要更多自訂選項時，改用 GKE。如果您有長時間執行的程序 (例如監聽佇列的程序)，或是使用 HTTP(S) 以外通訊協定的應用程式，GKE 也是預設選項。

Cloud Run functions 也是不錯的無伺服器部署選項，但本文不會討論這個選項，因為 Cloud Run 提供 Cloud Run functions 的大部分功能，而且 Cloud Run functions 不支援最新版本的 .NET。

Kubernetes 和 GKE

如要在經過容器最佳化的環境中執行，這種做法可能需要 Kubernetes 及其代管版本 GKE。如果您打算部署許多具有不同需求的容器，並想精細控管每個容器的部署和管理方式，則特別適合使用 Kubernetes 和 GKE。

Kubernetes 的設計宗旨是大規模執行容器，並提供 Pod、服務、部署和副本集等建構區塊。正確瞭解及使用這些建構體可能很困難，但您可以將大部分的容器管理負擔轉移給 Kubernetes。此外，微服務架構也很適合使用 Deployment，因為微服務是 Deployment，且後方有一組負載平衡的 Pod，並透過 Service 運作。

除了 Kubernetes，GKE 還提供叢集自動調度資源、自動修復和自動升級等功能，簡化 Kubernetes 管理作業，以及容器隔離和私人登錄檔等安全防護功能。雖然 GKE 會針對叢集中的每個節點收費，但 GKE 支援先占 VM，可降低成本。

GKE 可以管理 Windows 和 Linux 容器。如果您想為 Windows 和現代 Linux 應用程式維護單一混合式環境，這項功能就非常實用。

Knative 和 Cloud Run

對於無狀態 .NET 容器，Knative 和其代管版本 Cloud Run 提供無伺服器容器環境。無伺服器容器提供佈建、自動調度資源和負載平衡等優點，無須費心管理基礎架構。

如要在 Kubernetes 叢集中部署容器，Knative 提供比 Kubernetes 更高層級且更小的 API 介面。因此，Knative 可協助您避開 Kubernetes 的複雜作業，讓容器部署作業更加輕鬆。

Cloud Run 遵循 Knative API，但會在 Google 基礎架構上執行，因此不需要 Kubernetes 叢集。Cloud Run 提供無伺服器容器選項。根據預設，Cloud Run 中的容器會自動調度資源，並在要求期間收費。部署時間以秒為單位。Cloud Run 也提供實用功能，例如修訂版本和流量分配。

Knative serving 是 Cloud Run 的彈性版本，兼具 Knative 和 Cloud Run 的簡便性，以及 Kubernetes 的運作彈性。舉例來說，您可以在 GKE Enterprise 上使用 Cloud Run，為執行容器的基礎執行個體新增 GPU，或將應用程式擴充至多個容器。

Cloud Run 可與其他服務整合，例如 Pub/Sub、Cloud Scheduler、Cloud Tasks，以及 Cloud SQL 等後端服務。無論是自動調度資源的網路前端，或是由事件觸發的內部微服務，都可使用這項功能。

營運現代化

現代化不只關乎應用程式程式碼，這項做法適用於應用程式的整個生命週期，包括建構、測試、部署及監控方式。因此，在考慮現代化時，您需要考量作業。

Cloud Build 可協助您實現應用程式建構、測試及部署週期的現代化和自動化。Cloud Build 不僅提供 .NET 的建構工具，還與 Container Registry 的安全漏洞掃描器和二進位授權整合，可防止從不明原始碼或不安全存放區建構的映像檔在部署環境中執行。

Google Cloud Observability (原稱 Stackdriver) 提供多項服務，可協助您提升應用程式的可觀測性：

您可以使用 Google.Cloud.Diagnostics.AspNetCore 程式庫，將 ASP.NET 應用程式的記錄、指標和追蹤記錄匯出至 Google Cloud 。如要將 OpenTelemetry 指標匯出至 Google Cloud，可以使用 OpenTelemetry.Exporter.Stackdriver 程式庫。

如要進一步瞭解現代化如何套用至團隊程序和文化，請參閱Google Cloud 開發運作解決方案。

後續步驟