azure - 为什么在部署 Blazor 服务器端应用程序时建议使用 Azure SignalR 服务？

Question

当我在 Azure 上发布 Blazor 服务器端应用程序时，Visual Studio 会提示一条消息:

您的应用程序正在使用 SignalR。对于需要扩展的环境，我们强烈建议添加对 Azure SignalR 服务的依赖项。

但是，我的应用程序运行得很好，没有使用 Azure SignalR 服务。所以我想知道集成它是否真的有意义，或者这只是微软从我们口袋里榨取一些额外美元的一种方式......

是否有人尝试过使用和不使用 Azure SignalR 服务来部署 Blazor 服务器端应用程序，以测试性能方面是否存在任何实际差异？我应该从中获得什么样的优势？

Answer 1

这里有一些变量，所以没有人可以告诉你“在 X 个客户端之上，你需要使用 SignalR 服务。”根据解决方案的配置方式，一个组件或另一个组件可能是限制因素。

例如，App Service service limits显示每个 Web 应用程序实例的最大 Web 套接字数。对于基本层，它是 350。当您需要 351 时，您的选择是:

• 将您的应用服务计划扩展至标准或更高版本。
• 添加额外实例并使用 Redis 或服务总线底板。
• 使用 SignalR 服务。
• 从 SignalR 禁用 Websockets 并依赖于长轮询之类的东西，这受到服务器资源的限制。

在您进入标准服务层并扩展到多个 Web 应用程序实例后，您可以自己托管 SignalR。我们已经通过四个标准 S3 实例以这种方式运行了超过 5K 个并发连接的客户端。四是一个误导性的数字，因为我们需要应用程序其他部分的马力，而不仅仅是 SignalR。

当您自己托管 SignalR 时，它会施加一些限制，并且您可以通过多种创造性的方式来吊死自己。例如，使用 SignalR netcore，您需要拥有多实例环境的 ARR 关联 token 。太糟糕了。我曾经在前端关闭连接后实现了紧密轮询重新连接。当我们的服务器宕机超过两分钟后又恢复时，我们有几千个网络浏览器紧密轮询试图重新连接，这很有趣。在标准层 Web 应用程序中，很难掌握多个 Websocket 连接消耗的内存和 CPU 百分比。

所以说完这一切之后，答案是“这取决于很多事情”。完成这两种方式后，我将继续使用 SignalR 服务。