为什么在部署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禁用websocket，并依赖诸如长时间轮询之类的方法，这受服务器资源的限制。

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

当您自己托管SignalR时，它受到一些限制，并且您可以通过多种创造性的方式来吊挂自己。例如，使用SignalR netcore，要求您具有用于多实例环境的ARR亲和令牌。糟透了。从前端关闭连接后，我曾经实施紧密轮询重新连接。当我们的服务器宕机两分钟以上然后重新启动时，这很有趣，并且我们有数千个Web浏览器进行了严格的轮询以尝试重新连接。在标准层Web应用程序中，很难确定多个Websocket连接正在消耗多少内存和CPU。

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

Answer 2

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

Azure SignalR的成本可能急剧增加。邮件除以2k的大小，因此从帐单的角度来看，10k邮件将是5封邮件。

通过免费层，您最多可以建立20个并发连接，每天2万条消息，标准层允许每单位1k并发连接，每天每单位100万条消息。每个单元每月49美元。那就是每百万条消息传递1美元。

这可能看起来并不多，但我发现在短短7天内一项服务就获得了价值3,000美元的SignalR服务。

Answer 3

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

与浏览器连接的每个浏览器屏幕（浏览器标签或iframe） Blazor Server应用程序使用SignalR连接。这是另一个 与典型的服务器呈现的应用相比具有重要的区别。在一个 服务器渲染的应用程序，可在多个浏览器屏幕中打开同一应用程序 通常不会转化为对 服务器。在Blazor服务器应用中，每个浏览器屏幕都需要一个 单独的电路和组件状态的单独实例 由服务器管理。

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

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

Answer 4

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

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

到目前为止，Azure 应用服务 WebSockets 的免费定价层 F1 是有限的（参考 https://docs.microsoft.com/en-us/azure/app-service/faq-app-service-linux#web-sockets）。 Ofcource WebSockets 比长池方法要好得多，由你决定是否为单独的 Azure 服务 (Azure SignalR) 付费。