使用 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）、Azure 应用服务、IIS、Nginx、Apache、Docker 上托管实际 Web 应用程序。 还可以在自己的进程中使用自托管。
如果应用程序的目标包括以下几个方面，那么最佳选项是使用 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 个客户端连接。