Web 场 包含两个或多个 Web 服务器(亦称为“节点” ),用于托管应用的多个实例。 若有用户请求到达 Web 场,负载均衡器 会将请求分发到 Web 场中的各个节点。 Web 场提高了:
本主题介绍了在 Web 场中托管且依赖共享资源的 ASP.NET Core 应用的配置和依赖项。
托管和部署 ASP.NET Core
了解如何设置托管环境和部署 ASP.NET Core 应用。 对 Web 场中的每个节点配置进程管理器,以自动启动和重启应用。 每个节点都需要 ASP.NET Core 运行时。 有关详细信息,请参阅文档的托管和部署区域中的主题。
配置 ASP.NET Core 以使用代理服务器和负载均衡器
了解在代理服务器和负载均衡器后方托管的应用程序的配置,这通常会隐藏重要的请求信息。
将 ASP.NET Core 应用部署到 Azure 应用服务
Azure 应用服务是一个用于托管 Web 应用(包括 ASP.NET Core)的 Microsoft 云计算平台服务。 应用服务是提供自动缩放、负载均衡、修补和持续部署的完全托管平台。
如果应用已缩放为多个实例,可能会有需要跨节点共享的应用状态。 若为暂时状态,建议共享 IDistributedCache。 如果需要暂留共享状态,建议在数据库中存储共享状态。
必需为部署到 Web 场的应用配置数据保护和缓存。
应用使用 ASP.NET Core 数据保护系统来保护数据。 数据保护系统依赖一组在密钥环 中存储的加密密钥。 初始化后,数据保护系统会应用在本地存储密钥环的默认设置。 根据默认配置,唯一密钥环存储在 Web 场的各个节点上。 因此,Web 场中的每个节点都无法解密应用在其他任何节点上加密的数据。 默认配置通常不适合在 Web 场中托管应用。 若要实现共享密钥环,可以改为始终将用户请求路由到相同的节点。 若要详细了解与 Web 场部署有关的数据保护系统配置,请参阅配置 ASP.NET Core数据保护。
在 Web 场环境中,缓存机制必须跨 Web 场中的节点共享缓存项。 缓存必须依赖公用 Redis 缓存、共享 SQL Server 数据库,或跨 Web 场共享缓存项的自定义缓存实现。 有关详细信息,请参阅 ASP.NET Core 中的分布式缓存。
下面的方案无需其他配置,但依赖需要配置 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) 攻击。 |
如果未为 Web 场环境配置数据保护或缓存,就会在处理请求时发生间歇性错误。 之所以会发生这种情况是因为,节点不共享相同的资源,并且用户请求并不总是路由回同一节点。
假设用户通过 Cookie 身份验证来登录应用。 用户在 Web 场中的一个节点上登录应用。 如果用户的下一个请求到达登录应用时所用的同一节点,应用便能解密身份验证 Cookie,并允许用户访问应用资源。 如果用户的下一个请求到达其他节点,应用便无法从用户登录时所用的节点解密身份验证 Cookie,并且无法授权用户请求获取的资源。
如果以下任一症状间歇性 出现,问题原因通常是为 Web 场环境配置的数据保护或缓存不正确:
若要详细了解与 Web 场部署有关的数据保护配置,请参阅配置 ASP.NET Core数据保护。 若要详细了解与 Web 场部署有关的缓存配置,请参阅ASP.NET Core 中的分布式缓存。
如果 Web 场应用能够响应请求,则使用终端内联中间件从应用中获取请求、连接和其他数据。 有关详细信息和示例代码,请参阅ASP.NET Core 项目疑难解答和调试。