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

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

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

然而，我的应用程序运行正常，没有使用Azure Signal服务。所以我想知道整合它是否真的有意义，或者这只是微软从我们口袋里挤出一些额外的钱的一种方式

是否有人尝试过部署Blazor服务器端应用程序，包括Azure Signal服务和不包括Azure Signal服务，以测试性能是否存在任何实际差异？我应该从中得到什么样的好处

Blazor服务器应用程序构建在ASP.NET核心信号器之上。每个 客户端通过一个或多个信号器连接与服务器通信 称为电路。电路是Blazor对信号机的抽象 允许临时网络中断的连接。当 Blazor客户端看到信号器连接断开，它 尝试使用新的信号器连接重新连接到服务器

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

无论何时需要缩放信号器，都需要实现一个称为背板的模式。使用Azure信号器服务，它已经存在，所以您不需要自己做

---

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

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

• 将应用程序服务计划扩展到标准或更高级别
• 添加其他实例并使用Redis或Service Bus背板
• 使用信号机服务
• 从SignalR禁用WebSocket，并依赖长轮询之类的方式，这受到服务器资源的限制

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

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

---

所以在说了所有这些之后，答案是“这取决于很多事情。”在两种方式都做了之后，我会继续使用信号服务

我知道这是个老问题，但我想补充一些关于成本的有价值的信息

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

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

---

这可能看起来不多，但我已经看到一项服务在短短7天内累积了价值超过3000美元的信号服务。

如果您没有真正投入生产，或者这是一个宠物项目，只需将Blazor Hub配置更新为长池，而不是WebSocket，这样您就不会在控制台中出现错误

        app.UseEndpoints(endpoints =>
        {
            //...
            endpoints.MapBlazorHub(options =>
            {
                options.Transports = HttpTransportType.LongPolling;
            });
            //...
        });

到目前为止，Azure应用程序服务的免费定价第F1层WebSocket是有限的（参考）。

---

Ofcource WebSockets比长池方法好得多，这取决于您是否为单独的Azure服务（Azure Signal）付费。

您是否单击了“更多信息”？当然，但他们所说的非常通用，与Blazor没有任何关系。我想知道，在特定情况下，仅将SignalR用作Blazor服务器端托管模型的一部分的应用程序是否真的需要Azure SignalR服务。我知道SignalR在Blazor服务器端是如何使用的，问题更多的是，根据您的经验，Blazor是否非常需要Azure Signal之类的服务。您提到了“缩放”，我想您指的是同时处理多个连接？如果是这样的话，“多少”是多少？因为你看，魔鬼就在细节中。我觉得微软故意含糊其辞，以便推出一项许多人可能不需要的服务。我还刚刚了解到，如果将web应用扩展到多个服务器实例，SignalR将不再是现成的：只有连接到发送通知的实例的客户端才会收到通知。这是使用Azure Signal服务的另一个原因。这正是我想要的。Thanks@tocqueville，这回答了你的问题吗