共用方式為

ASP.NET Core Web 應用程式的 Azure 裝載建議

小提示

此內容摘自電子書《使用 ASP.NET Core 和 Azure 架構現代化 Web 應用程式》，可在 .NET Docs 上取得，或下載免費 PDF 以便離線閱讀。

下載 PDF

ASP.NET Core 與 Azure 架構現代 Web 應用程式的電子書封面縮圖。

「世界各地的企業營運領導者都略過 IT 部門從雲端取得應用程式（也稱為 SaaS），並像雜誌訂用帳戶一樣為他們付費。 當不再需要服務時，他們可以取消訂閱，不會有設備閒置在角落。
- 達里爾·普盧默，加姆分析家

無論您的應用程式需求和架構為何，Microsoft Azure 都可以支援它。 您的裝載需求可以像靜態網站或由數十項服務組成的複雜應用程式一樣簡單。 針對 ASP.NET Core 整合型 Web 應用程式和支援服務，建議使用數個已知的組態。 本文的建議會根據要裝載的資源類型來分組，無論是完整的應用程式、個別進程或數據。

Web 應用程式

Web 應用程式可以託管於：

  • 應用服務網頁應用程式

  • 容器（數個選項）

  • 虛擬機器（VM）

其中，App Service Web Apps 是大多數案例的建議方法，包括簡單的容器型應用程式。 針對微服務架構，請考慮以容器為基礎的方法。 如果您需要進一步控制執行應用程式的機器，請考慮使用 Azure 虛擬機。

應用服務網頁應用程式

App Service Web Apps 提供完全受控的平臺，專為裝載 Web 應用程式而優化。 這是一個平臺即服務 （PaaS） 供應專案，可讓您專注於商業規則，而 Azure 則負責執行和調整應用程式所需的基礎結構。 App Service Web Apps 的一些主要功能：

  • DevOps 優化（持續整合和傳遞、多個環境、A/B 測試、腳本支援）。

  • 全域規模和高可用性。

  • 與 SaaS 平臺和本地部署資料的連接。

  • 安全性與合規性。

  • Visual Studio 整合。

Azure App Service 是大部分 Web 應用程式的最佳選擇。 部署和管理已整合到平臺中，網站可以快速調整以處理高流量負載，而內建負載平衡和流量管理員則提供高可用性。 您可以使用線上移轉工具輕鬆地將現有網站移至 Azure App Service。 您可以從 Web 應用連結庫使用開放原始碼應用程式，或使用您選擇的架構和工具建立新網站。 WebJobs 功能可讓您輕鬆地將背景工作處理新增至 App Service Web 應用程式。 如果您有使用本機資料庫裝載於內部部署的現有 ASP.NET 應用程式，則有明確的移轉路徑。 您可以搭配 Azure SQL Database 使用 App Service Web 應用程式（或視偏好安全存取內部部署資料庫伺服器）。

建議將內部部署 .NET 應用程式移轉至 Azure App Service 的移轉策略

在大部分情況下，從本地托管的 ASP.NET 應用程式移至 App Service 網頁應用程式是一個直接的過程。 應用程式本身幾乎不需要修改，而且可以快速開始利用 Azure App Service Web Apps 所提供的許多功能。

除了未針對雲端優化的應用程式之外，Azure App Service Web Apps 是許多簡單整合型（非分散式）應用程式的絕佳解決方案，例如許多 ASP.NET Core 應用程式。 在此方法中，架構是基本且易於瞭解和管理：

基本 Azure 架構

單一資源群組中的少數資源通常足以管理這類應用程式。 通常部署為單一單位的應用程式，而不是由許多個別程式所組成的應用程式，是這個 基本架構方法的絕佳候選專案。 雖然架構上很簡單，但這種方法仍然允許托管的應用程式擴充（每個節點的資源更多）和擴展（更多托管的節點），以滿足任何需求的增加。 透過自動調整，可以將應用程式設定為根據需求自動調整裝載應用程式的節點數目，以及跨節點的平均負載。

容器專用的 Azure App Service Web 應用程式

除了支援直接裝載 Web 應用程式之外， App Service Web Apps for Containers 也可用來在 Windows 和 Linux 上執行容器化應用程式。 使用此服務，您可以輕鬆地部署及執行容器化應用程式，以配合您的業務進行調整。 應用程式具有上述 App Service Web Apps 的所有功能。 此外，Web Apps for Containers 支援使用 Docker Hub、Azure Container Registry 和 GitHub 簡化的 CI/CD。 您可以使用 Azure DevOps 來定義將變更發佈至登錄的組建和部署管線。 然後，這些變更可以在預備環境中進行測試，並使用部署插槽自動部署到生產環境，從而實現零停機升級。 復原至舊版可以同樣容易完成。

有幾種情況下使用容器化 Web 應用程式最為合適。 如果您有現有的應用程式可以容器化，無論是在 Windows 或 Linux 容器中，您都可以使用此工具組輕鬆地裝載這些應用程式。 只要發佈您的容器，然後設定 Web Apps for Containers，即可從您選擇的登錄提取該映射的最新版本。 這是一種「直接搬遷」方法，用於從傳統應用程式托管模型移轉到雲端最佳化模型。

將容器化內部部署 .NET 應用程式遷移至適用於容器的 Azure Web Apps

如果您的開發小組能夠移至以容器為基礎的開發程式，此方法也能正常運作。 使用容器開發應用程式的「內部迴圈」包括使用容器建置應用程式。 對程式代碼和容器組態所做的變更會推送至原始檔控制，而自動化組建會負責將新的容器映像發佈至 Docker Hub 或 Azure Container Registry 等登錄。 這些映像接著會作為其他開發的基礎，以及部署至生產環境的基礎，如下圖所示：

端對端 Docker DevOps 生命週期工作流程

使用容器進行開發提供許多優點，尤其是在生產環境中使用容器時。 相同的容器組態可用來裝載應用程式執行所在的每個環境中，從本機開發計算機建置和測試系統到生產環境。 這種方法可大幅降低機器組態或軟體版本差異所造成的瑕疵可能性。 開發人員也可以使用其最具生產力的工具，包括作系統，因為容器可以在任何作系統上執行。 在某些情況下，涉及許多容器的分散式應用程式可能非常需要大量資源，才能在單一開發計算機上執行。 在此案例中，升級至使用 Kubernetes 和 Azure Dev Spaces 可能很合理，如下一節所述。

由於較大型應用程式的部分會細分成較小的獨立 微服務，因此可以使用其他設計模式來改善應用程序行為。 API 閘道可以簡化存取，並將用戶端與其後端分離，而不是直接使用個別服務。 針對不同的前端擁有不同的服務後端，也可讓服務與其取用者一致發展。 常見的服務可以透過個別 的 Sidecar 容器來存取，其中可能包含使用 大使 模式的常見用戶端連線連結庫。

已指出數個常見設計模式的微服務範例架構。

深入瞭解建置微服務型系統時要考慮的設計模式。

Azure Kubernetes Service

Azure Kubernetes Service （AKS） 會管理裝載的 Kubernetes 環境，讓您快速且輕鬆地部署和管理容器化應用程式，而不需要容器協調流程專業知識。 它也會藉由隨選布建、升級和調整資源，而不需要讓應用程式離線，藉此消除持續作業和維護的負擔。

AKS 藉由將大部分責任卸除至 Azure，以減少管理 Kubernetes 叢集的複雜度和作業額外負荷。 作為裝載的 Kubernetes 服務，Azure 會為您處理健康情況監視和維護等重要工作。 此外，您只需支付叢集中的代理節點，而不是針對主控付費。 作為託管的 Kubernetes 服務，AKS 提供：

  • 自動化 Kubernetes 版本升級和修補。
  • 輕鬆的叢集擴展。
  • 自我修復的託管控制平面（控制節點）。
  • 節省成本 - 僅針對執行中的代理程式集區節點付費。

透過 Azure 處理 AKS 叢集中節點的管理，您不再需要手動執行許多工作，例如叢集升級。 因為 Azure 會為您處理這些重要的維護工作，因此 AKS 不會提供叢集的直接存取權（例如 SSH）。

利用 AKS 的 Teams 也可以利用 Azure Dev Spaces。 Azure Dev Spaces 可讓小組直接使用在 AKS 中執行的整個微服務架構或應用程式，協助小組專注於其微服務應用程式的開發和快速反覆專案。 Azure Dev Spaces 也可讓您獨立更新微服務架構的部分，而不會影響 AKS 叢集或其他開發人員的其餘部分。

Azure Dev Spaces 工作流程範例

Azure Dev Spaces：

  • 將本機計算機設定時間和資源需求降到最低
  • 允許團隊更快速地進行迭代
  • 減少小組所需的整合環境數目
  • 在開發/測試時，移除模擬分散式系統中特定服務的需求

深入瞭解 Azure Dev Spaces

Azure 虛擬機器

如果您有需要在 App Service 中執行大量修改的現有應用程式，您可以選擇虛擬機以簡化移轉至雲端。 不過，相較於 Azure App Service，正確設定、保護和維護 VM 需要更多時間和 IT 專業知識。 如果您要考慮 Azure 虛擬機，請務必考慮修補、更新和管理 VM 環境所需的持續維護工作。 Azure 虛擬機是基礎結構即服務 （IaaS），而 App Service 則是 PaaS。 您應該考慮是否將您的應用程式部署為 Windows 容器並在 Web 容器應用程式中運行，這可能是適合您情境的可行選項。

邏輯進程

個別的邏輯進程可以從應用程式的其餘部分分離，以「無伺服器」的方式獨立部署至 Azure Functions。 Azure Functions 可讓您只撰寫特定問題所需的程式代碼，而不必擔心應用程式或基礎結構可執行它。 您可以選擇各種程式設計語言，包括 C#、F#、Node.js、Python 和 PHP，讓您挑選手邊工作最具生產力的語言。 和大多數雲端解決方案一樣，您只需支付您使用的時間量的費用，而且您可以放心選擇 Azure Functions，它會根據需要自動擴展。

資料

Azure 提供各種不同的資料記憶體選項，讓您的應用程式可以使用適當的數據提供者來處理有問題的數據。

對於交易式關係型數據，Azure SQL Database 是最佳選項。 對於高效能的以讀取為主的數據，使用 Azure SQL Database 支援的 Redis 快取是一個不錯的解決方案。

非結構化 JSON 數據可以透過各種方式儲存，從 SQL Database 資料行到 Azure 記憶體中的 Blob 或資料表，到 Azure Cosmos DB。 其中，Azure Cosmos DB 提供最佳的查詢功能，而且是大量必須支持查詢的 JSON 型文件的建議選項。

用來協調應用程式行為的暫時性命令或事件型數據可以使用 Azure 服務總線或 Azure 記憶體佇列。 Azure 服務總線提供更大的彈性，而且是應用程式內和之間非簡單傳訊的建議服務。

架構建議

您的應用程式需求應該會決定其架構。 有許多不同的 Azure 服務可供使用。 選擇正確的決策是一個重要的決定。 Microsoft提供參考架構庫，以協助識別針對常見案例優化的一般架構。 您可能會找到與應用程式需求緊密對應，或至少提供起點的參考架構。

圖 11-1 顯示範例參考架構。 此圖描述針對針對營銷優化的 Sitecore 內容管理系統網站的建議架構方法。

圖 11-1

圖 11-1。 Sitecore 行銷網站參考架構。

參考 – Azure 裝載建議

以前