通过

ASP.NET Core Web 应用的 Azure 托管建议

小窍门

此内容摘自电子书、使用 ASP.NET Core 和 Azure 构建新式 Web 应用程序，可在 .NET Docs 上获取或作为可脱机阅读的免费可下载 PDF。

下载 PDF

架构现代 Web 应用程序：使用 ASP.NET Core 和 Azure 的电子书封面缩略图。

“世界各地的业务线领导者都绕过 IT 部门从云（也称为 SaaS）获取应用程序，并像购买杂志订阅一样为他们付费。 当服务不再需要时，他们可以取消订阅，且不会留下任何未使用的设备堆放在角落。
- 达里尔·普卢默，该公司分析师

无论应用程序的需求和体系结构如何，Microsoft Azure 都可以支持它。 托管需求可以像静态网站或由数十个服务组成的复杂应用程序一样简单。 对于 ASP.NET Core 整体 Web 应用程序和支持服务，建议使用几种已知配置。 本文的建议根据要托管的资源类型（无论是完整的应用程序、单个进程还是数据）进行分组。

Web 应用程序

可以使用以下方法托管 Web 应用程序：

  • 应用服务 Web 应用

  • 容器（多个选项）

  • 虚拟机（VM）

其中，应用服务 Web 应用是大多数方案的建议方法，包括基于容器的简单应用。 对于微服务体系结构，请考虑使用基于容器的方法。 如果需要对运行应用程序的计算机进行更多控制，请考虑使用 Azure 虚拟机。

应用服务 Web 应用

应用服务 Web 应用提供一个完全托管且优化的平台，专门用于托管 Web 应用程序。 它是一个平台即服务（PaaS）产品/服务，可让你专注于业务逻辑，而 Azure 负责运行和缩放应用所需的基础结构。 应用服务 Web 应用的一些主要功能：

  • DevOps 优化（持续集成和交付、多个环境、A/B 测试、脚本支持）。

  • 全球规模和高可用性。

  • 可连接至 SaaS 平台和本地数据。

  • 安全性和符合性。

  • Visual Studio 的集成。

Azure 应用服务是大多数 Web 应用的最佳选择。 部署和管理已集成到平台中，站点可以快速缩放以处理高流量负载，内置负载均衡和流量管理器提供高可用性。 可以使用联机迁移工具轻松地将现有站点移动到 Azure 应用服务。 可以从 Web 应用程序库使用开源应用，也可以使用所选框架和工具创建新网站。 使用 WebJobs 功能，可以轻松地将后台作业处理添加到应用服务 Web 应用。 如果有使用本地数据库在本地托管的现有 ASP.NET 应用程序，则有一个明确的迁移路径。 可以将应用服务 Web 应用与 Azure SQL 数据库配合使用（或者根据需要安全访问本地数据库服务器）。

建议将本地 .NET 应用迁移到 Azure 应用服务的迁移策略

在大多数情况下，从本地托管 ASP.NET 应用迁移到应用服务 Web 应用的过程非常简单。 应用本身几乎不需要修改，并且可以快速开始利用 Azure 应用服务 Web 应用提供的许多功能。

除了未针对云进行优化的应用外，Azure 应用服务 Web 应用是许多简单的整体式（非分布式）应用程序的出色解决方案，例如许多 ASP.NET 核心应用。 在此方法中，体系结构是基本且易于理解和管理的：

基本 Azure 体系结构

单个资源组中的少量资源通常足以管理此类应用。 通常部署为单个单元的应用，而不是由许多独立流程构成的应用，非常适合采用这种 基本体系结构方法。 尽管在体系结构上很简单，但此方法仍允许托管应用纵向扩展（每个节点的资源更多）和横向扩展（更多托管节点），以满足任何需求增加。 通过自动缩放，可以将应用配置为根据需求和跨节点的平均负载自动调整托管应用的节点数。

用于容器的应用服务 Web 应用

除了支持直接托管 Web 应用外， 适用于容器的应用服务 Web 应用 还可用于在 Windows 和 Linux 上运行容器化应用程序。 使用此服务，可以轻松部署和运行可随业务缩放的容器化应用程序。 应用具有上面列出的应用服务 Web 应用的所有功能。 此外，容器 Web 应用还支持使用 Docker Hub、Azure 容器注册表和 GitHub 实现流畅的 CI/CD。 可以使用 Azure DevOps 定义将更改发布到注册表的生成和部署管道。 然后，可以在过渡环境中测试这些更改，并使用部署槽位自动部署到生产环境，从而允许零停机升级。 可以同样轻松地回滚到以前的版本。

在某些情况下，用于容器的 Web 应用最有意义。 如果你有现有的应用可以容器化，无论是在 Windows 容器还是 Linux 容器中，都可以使用此工具集轻松托管这些应用。 只需发布容器，然后配置用于容器的 Web 应用，以便从所选注册表中拉取该映像的最新版本。 这是从经典应用托管模型迁移到云优化模型的“直接迁移”方法。

将容器化的本地 .NET 应用程序迁移到用于容器的 Azure Web 应用

如果开发团队能够迁移到基于容器的开发过程，此方法也非常有效。 使用容器开发应用的“内部循环”包括使用容器生成应用。 对代码和容器配置所做的更改将推送到源代码管理，自动化生成负责将新的容器映像发布到 Docker 中心或 Azure 容器注册表等注册表。 然后，这些映像用作进一步开发的基础，并作为部署至生产环境的依据，如下图所示：

端到端 Docker DevOps 生命周期工作流

使用容器进行开发具有许多优势，尤其是在生产中使用容器时。 同一容器配置用于在运行应用的每个环境中托管应用，从本地开发计算机到生成和测试系统到生产环境。 此方法大大减少了计算机配置或软件版本差异导致的缺陷的可能性。 开发人员还可以使用他们最高效的工具（包括作系统），因为容器可以在任何 OS 上运行。 在某些情况下，涉及许多容器的分布式应用程序在单个开发计算机上运行可能非常资源密集型。 在这种情况下，升级到 Kubernetes 和 Azure Dev Spaces 可能是一个合适的选择，这将在下一部分中介绍。

随着较大应用程序的某些部分被分解成其较小的独立 微服务，其他设计模式可用于改进应用行为。 API 网关可以简化访问，并将客户端与后端分离，而不是直接使用单个服务。 为不同的前端提供单独的服务后端也允许服务与其使用者协同发展。 可以通过单独的 Sidecar 容器访问公用服务，该容器可能包括使用 大使 模式的常见客户端连接库。

指出了多个常见设计模式的微服务示例体系结构。

详细了解在构建基于微服务的系统时要考虑的设计模式。

Azure Kubernetes 服务

Azure Kubernetes 服务（AKS）管理托管的 Kubernetes 环境，使无需容器业务流程专业知识即可快速轻松地部署和管理容器化应用程序。 它还通过按需预配、升级和缩放资源来消除持续作和维护的负担，而无需使应用程序脱机。

AKS 通过将大部分责任卸载到 Azure 来减少管理 Kubernetes 群集的复杂性和作开销。 作为托管的 Kubernetes 服务，Azure 会为你处理运行状况监视和维护等关键任务。 此外，只需为群集中的代理节点付费，而不是为主节点付费。 作为托管 Kubernetes 服务，AKS 提供：

  • 自动化 Kubernetes 版本升级和补丁更新。
  • 轻松扩展群集。
  • 自我修复型托管控制平面（主节点）。
  • 节省成本：仅支付运行的代理池节点。

通过 Azure 处理 AKS 群集中的节点管理，不再需要手动执行许多任务，例如群集升级。 由于 Azure 会为你处理这些关键的维护任务，因此 AKS 不提供对群集的直接访问（例如 SSH）。

利用 AKS 的团队还可以利用 Azure Dev Spaces。 Azure Dev Spaces 可帮助团队专注于微服务应用程序的开发和快速迭代，使团队可以直接使用在 AKS 中运行的整个微服务体系结构或应用程序。 Azure Dev Spaces 还提供了一种独立更新微服务体系结构部分的方法，而不会影响 AKS 群集或其他开发人员的其余部分。

Azure Dev Spaces 工作流示例

Azure Dev Spaces：

  • 最大程度地减少本地计算机设置时间和资源要求
  • 允许团队更快速地迭代
  • 减少团队所需的集成环境数量
  • 在开发/测试时，无需模拟分布式系统中的某些服务

详细了解 Azure Dev Spaces

Azure 虚拟机

如果现有应用程序需要进行大量修改才能在应用服务中运行，则可以选择虚拟机以简化迁移到云。 但是，与 Azure 应用服务相比，正确配置、保护和维护 VM 需要更多的时间和 IT 专业知识。 如果考虑使用 Azure 虚拟机，请确保考虑到修补、更新和管理 VM 环境所需的持续维护工作。 Azure 虚拟机是基础结构即服务（IaaS），而应用服务是 PaaS。 还应考虑将应用作为 Windows 容器部署到用于容器的 Web 应用是否适合你的方案。

逻辑进程

可以独立于应用程序其余部分的单个逻辑进程以“无服务器”方式部署到 Azure Functions。 使用 Azure Functions，只需编写给定问题所需的代码，而无需担心要运行它的应用程序或基础结构。 可以从各种编程语言中进行选择，包括 C#、F#、Node.js、Python 和 PHP，从而为手头的任务选择最高效的语言。 与大多数基于云的解决方案一样，只需为使用的时间付费，并且可以信任 Azure Functions 根据需要进行纵向扩展。

数据

Azure 提供了各种各样的数据存储选项，以便应用程序可以使用相应的数据提供程序来获取相关数据。

对于事务数据、关系数据，Azure SQL 数据库是最佳选择。 对于以读取为主的高性能数据，受 Azure SQL 数据库支持的 Redis 缓存是一个不错的解决方案。

可以通过多种方式（从 SQL 数据库列到 Azure 存储中的 Blob 或表）存储非结构化 JSON 数据，到 Azure Cosmos DB。 其中，Azure Cosmos DB 提供了最佳的查询功能，对于必须支持查询的大量基于 JSON 的文档，建议使用此选项。

用于协调应用程序行为的暂时性命令或基于事件的数据可以使用 Azure 服务总线或 Azure 存储队列。 Azure 服务总线提供更大的灵活性，建议在应用程序内部和之间使用非普通消息传送服务。

体系结构建议

应用程序的要求应决定其体系结构。 有许多不同的 Azure 服务可用。 选择正确的决策是一个重要决定。 Microsoft提供了参考体系结构库，以帮助识别针对常见方案优化的典型体系结构。 你可能会发现一个与应用程序要求密切相关的参考体系结构，或者至少提供了一个起点。

图 11-1 显示了一个示例参考体系结构。 此图描述了针对针对市场营销优化的 Sitecore 内容管理系统网站的推荐体系结构方法。

图 11-1

图 11-1. Sitecore 营销网站参考体系结构。

参考 - Azure 托管建议

以前