开发 SignalR 应用
SignalR 目前有 两个版本 可用于 Web 应用程序：
- ASP.NET SignalR
- new ASP.NET Core SignalR
ASP.NET Core SignalR 是以前版本的重写。 因此，ASP.NET Core SignalR 与早期 SignalR 版本不兼容。 API 和行为不同。 Azure SignalR 服务支持这两个版本。
Azure SignalR 服务允许在多个平台（Windows、Linux 和 macOS）上托管实际的 Web 应用程序Azure 应用服务， 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 个客户端连接。