为什么在部署 Blazor 服务器端应用时推荐使用 Azure SignalR 服务？

Question

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

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

但是，我的应用程序可以正常工作，无需使用 Azure SignalR 服务。所以我想知道整合它是否真的有意义，或者这只是微软从我们口袋里多掏几美元的一种方式......

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

Answer 1

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

例如，应用服务服务限制显示每个 Web 应用实例的最大 Web 套接字数。对于基本层，它是 350。当您需要 351 时，您的选择是：

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

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

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

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

Answer 2

我知道这是一个老问题，但我想添加一些有关成本的有价值的信息。

Azure SignalR 的成本可能会急剧增加。消息按大小除以 2k，因此从计费角度来看，10k 消息将是 5 条消息。

使用免费层，您最多可以获得 20 个并发连接，每天 20k 条消息，标准层允许每个单元 1k 并发连接和每个单元每天 100 万条消息。每个单元每月 49 美元。然后是每百万条消息传递 1 美元。

这似乎不是很多，但我看到一项服务在短短 7 天内累积了价值超过 3,000 美元的 SignalR 服务。

Answer 3

Blazor 服务器应用程序构建在 ASP.NET Core SignalR 之上。每个客户端都通过一个或多个称为电路的 SignalR 连接与服务器进行通信。电路是 Blazor 对 SignalR 连接的抽象，可以容忍临时网络中断。当 Blazor 客户端发现 SignalR 连接已断开时，它会尝试使用新的 SignalR 连接重新连接到服务器。

连接到 Blazor 服务器应用的每个浏览器屏幕（浏览器选项卡或 iframe）都使用 SignalR 连接。与典型的服务器渲染应用程序相比，这是另一个重要的区别。在服务器渲染的应用程序中，在多个浏览器屏幕中打开同一应用程序通常不会转化为对服务器的额外资源需求。在 Blazor 服务器应用中，每个浏览器屏幕都需要单独的电路和单独的组件状态实例以由服务器管理。

每当您需要缩放 SignalR 时，您都需要实现一种称为背板的模式。使用 Azure SignalR 服务，它已经存在，因此您无需自己执行此操作。

https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-3.1