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