你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用 Azure SignalR Service 缩放 ASP.NET Core SignalR 应用程序
开发 SignalR 应用
SignalR 目前有两个版本可用于 Web 应用程序：
- ASP.NET SignalR
- 新 ASP.NET Core SignalR
ASP.NET Core SignalR 是以前版本的重写。 因此，ASP.NET Core SignalR 未向后兼容早期的 SignalR 版本。 API 和行为不同。 Azure SignalR 服务支持这两个版本。
Azure SignalR 服务允许在多个平台（Windows、Linux 和 macOS）上托管实际的 Web 应用程序，Azure App 服务、IIS、Nginx、Apache、Docker。 还可以在自己的进程中使用自托管。
如果应用程序的目标包括：Azure SignalR 服务是最佳选择：
- 支持使用实时内容更新更新 Web 客户端的最新功能，
- 跨多个平台运行（Azure、Windows、Linux 和 macOS）
- 在不同环境中托管
为什么不自行部署 SignalR？
将支持 SignalR 的 Azure Web 应用部署为整个 Web 应用程序的后端组件仍是一个有效的方法。
使用 Azure SignalR 服务的关键原因之一是其简便性。 借助 Azure SignalR 服务，无需处理性能、可伸缩性、可用性等问题。 已通过 99.9% 服务级别协议解决了这些问题。
此外，通常情况下，WebSocket 是支持实时内容更新的首选技术。 但是，缩放时，负载均衡大量持久性 WebSocket 连接是要解决的复杂问题。 常见的解决方案是使用：DNS 负载均衡、硬件负载均衡器和软件负载均衡。 Azure SignalR 服务为用户解决此问题。
对于 ASP.NET Core SignalR，另一个原因是你根本不需要实际托管一个 Web 应用程序。 Web 应用程序的逻辑可以使用无服务器计算。 例如，可能仅通过 Azure Functions 触发器按需托管和执行代码。 此方案可能很有挑战性，因为代码仅按需运行，并且不会维护与客户端的长期连接。 Azure SignalR 服务可以处理这种情况，因为该服务已为用户管理连接。 有关详细信息，请参阅有关如何将 SignalR 服务与 Azure Functions 配合使用的概述。 由于 ASP.NET SignalR 使用不同的协议，因此 ASP.NET SignalR 不支持此类无服务器模式。
它如何缩放？
通常使用 SQL Server、Azure 服务总线或 Azure Cache for Redis 对 SignalR 进行缩放。 Azure SignalR 服务为用户处理缩放方法。 其性能和成本可与不具备处理这些其他服务的复杂性的方法相媲美。 用户只需更新服务的单元计数。 每个单元最多支持 1000 个客户端连接。