在 Web 场中托管 ASP.NET CoreHost ASP.NET Core in a web farm

本文内容

作者：Chris Ross

Web 场 包含两个或多个 Web 服务器（亦称为“节点” ），用于托管应用的多个实例。若有用户请求到达 Web 场，负载均衡器 会将请求分发到 Web 场中的各个节点。Web 场提高了：

  • 可靠性/可用性 – 如果一个或多个节点失败，负载均衡器可以将请求路由到其他正常运行的节点，以继续处理请求。
  • 容量/性能 – 多个节点可以处理的请求数多于一个服务器。负载均衡器均衡工作负载的方式是，将请求分发到各个节点。
  • 可伸缩性 – 如果需要更多或更少容量，可以增加或减少活动节点数，与工作负载保持一致。Azure 应用服务等 Web 场平台技术可以应系统管理员的请求自动添加或删除节点，也可以自动开始，而无需人为干预。
  • 可维护性 – Web 场节点可以依赖一组共享服务，这就简化了系统管理。例如，Web 场中的节点可以依赖单一数据库服务器，以及静态资源（如图像和可下载文件）的公用网络位置。

本主题介绍了在 Web 场中托管且依赖共享资源的 ASP.NET Core 应用的配置和依赖项。

常规配置General configuration

托管和部署 ASP.NET Core了解如何设置托管环境和部署 ASP.NET Core 应用。对 Web 场中的每个节点配置进程管理器，以自动启动和重启应用。每个节点都需要 ASP.NET Core 运行时。有关详细信息，请参阅文档的托管和部署区域中的主题。

配置 ASP.NET Core 以使用代理服务器和负载均衡器了解在代理服务器和负载均衡器后方托管的应用程序的配置，这通常会隐藏重要的请求信息。

将 ASP.NET Core 应用部署到 Azure 应用服务Azure 应用服务是一个用于托管 Web 应用（包括 ASP.NET Core）的 Microsoft 云计算平台服务。应用服务是提供自动缩放、负载均衡、修补和持续部署的完全托管平台。

应用数据App data

如果应用已缩放为多个实例，可能会有需要跨节点共享的应用状态。若为暂时状态，建议共享 IDistributedCache。如果需要暂留共享状态，建议在数据库中存储共享状态。

必需配置Required configuration

必需为部署到 Web 场的应用配置数据保护和缓存。

数据保护Data Protection

应用使用 ASP.NET Core 数据保护系统来保护数据。数据保护系统依赖一组在密钥环 中存储的加密密钥。初始化后，数据保护系统会应用在本地存储密钥环的默认设置。根据默认配置，唯一密钥环存储在 Web 场的各个节点上。因此，Web 场中的每个节点都无法解密应用在其他任何节点上加密的数据。默认配置通常不适合在 Web 场中托管应用。若要实现共享密钥环，可以改为始终将用户请求路由到相同的节点。若要详细了解与 Web 场部署有关的数据保护系统配置，请参阅配置 ASP.NET Core 数据保护。

缓存Caching

在 Web 场环境中，缓存机制必须跨 Web 场中的节点共享缓存项。缓存必须依赖公用 Redis 缓存、共享 SQL Server 数据库，或跨 Web 场共享缓存项的自定义缓存实现。有关详细信息，请参阅 ASP.NET Core 中的分布式缓存。

依赖组件Dependent components

下面的方案无需其他配置，但依赖需要配置 Web 场的技术。

方案依赖…
身份验证数据保护（请参阅配置 ASP.NET Core 数据保护）。有关详细信息，请参阅 使用 cookie 而无需 ASP.NET Core 标识的身份验证 和 在 ASP.NET 应用中共享身份验证 cookie。
标识身份验证和数据库配置。有关详细信息，请参阅 ASP.NET Core 上的标识简介。
会话数据保护（加密 Cookie）（请参阅配置 ASP.NET Core 数据保护）和缓存（请参阅ASP.NET Core 中的分布式缓存）。有关详细信息，请参阅会话和状态管理：会话状态。
TempData数据保护（加密 Cookie）（请参阅 配置 ASP.NET Core 数据保护）或会话（请参阅会话和状态管理：会话状态）。有关详细信息，请参阅会话和状态管理：TempData。
防伪造数据保护（请参阅配置 ASP.NET Core 数据保护）。有关详细信息，请参阅 在 ASP.NET Core 防止跨站点请求伪造 (XSRF/CSRF) 攻击。

疑难解答Troubleshoot

数据保护和缓存Data Protection and caching

如果未为 Web 场环境配置数据保护或缓存，就会在处理请求时发生间歇性错误。之所以会发生这种情况是因为，节点不共享相同的资源，并且用户请求并不总是路由回同一节点。

假设用户通过 Cookie 身份验证来登录应用。用户在 Web 场中的一个节点上登录应用。如果用户的下一个请求到达登录应用时所用的同一节点，应用便能解密身份验证 Cookie，并允许用户访问应用资源。如果用户的下一个请求到达其他节点，应用便无法从用户登录时所用的节点解密身份验证 Cookie，并且无法授权用户请求获取的资源。

如果以下任一症状间歇性 出现，问题原因通常是为 Web 场环境配置的数据保护或缓存不正确：

  • 身份验证中断 – 身份验证 Cookie 配置不正确或无法解密。OAuth（Facebook、Microsoft、Twitter）或 OpenIdConnect 登录失败，出现错误“关联失败”。
  • 授权中断 – 标识丢失。
  • 会话状态丢失数据。
  • 缓存项消失。
  • TempData 失败。
  • POST 失败 – 防伪造检查失败。

若要详细了解与 Web 场部署有关的数据保护配置，请参阅配置 ASP.NET Core 数据保护。若要详细了解与 Web 场部署有关的缓存配置，请参阅ASP.NET Core 中的分布式缓存。

从应用中获取数据Obtain data from apps

如果 Web 场应用能够响应请求，则使用终端内联中间件从应用中获取请求、连接和其他数据。有关详细信息和示例代码，请参阅ASP.NET Core 项目故障排除和调试。

其他资源Additional resources