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

【问题标题】：Why is Azure SignalR Service recommended when deploying a Blazor Server Side app?为什么在部署 Blazor 服务器端应用程序时建议使用 Azure SignalR 服务？
【发布时间】：2020-06-24 19:42:21
【问题描述】：

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

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

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

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

【问题讨论】：

你点击了“更多信息”吗？
当然，但他们所说的非常笼统，与 Blazor 完全无关。我想知道在仅使用 SignalR 作为 Blazor 服务器端托管模型的一部分的应用程序的特定情况下，是否真的需要 Azure SignalR 服务。

标签： azure blazor-server-side asp.net-core-signalr azure-signalr asp.net-blazor

【解决方案1】：

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

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

当您需要扩展 SignalR 时，您需要实现一种称为背板的模式。使用 Azure SignalR 服务，它已经存在，因此您无需自己动手。

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

【讨论】：

我知道 SignalR 在 Blazor 服务器端的使用方式，问题更多是关于在您的经验中，Blazor 是否需要像 Azure SignalR 这样的某种服务。您谈到了“缩放”，我想您指的是同时处理许多连接？如果是这样，“许多”是多少？因为你看，魔鬼在细节中。我觉得微软故意含糊其辞，以便推出许多人可能不需要的服务。
@tocqueville 不认为这个建议是为了抢钱，它实际上是个好建议，许多开发人员在第一次部署时不会考虑扩展，第一次通常是最后一次我们注意发布警告。如果没有专门实现背板或使用 SingnalR 服务，您的应用程序将无法正常运行当您进行横向扩展时，我们所有人都认为我们的应用程序会变得如此之大，以至于我们必须正确横向扩展......如果成本高，考虑WASM吧……

【解决方案2】：

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

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

将您的应用服务计划扩展到标准或更高版本。
添加其他实例并使用 Redis 或服务总线背板。
使用 SignalR 服务。
从 SignalR 中禁用 websocket，并依赖诸如长轮询之类的东西，这受服务器资源的限制。

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

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

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

【讨论】：

我还刚刚了解到，如果您将 Web 应用程序扩展到多个服务器实例，SignalR 将不再开箱即用：只有连接到发送通知的实例的客户端才能收到它。这是使用 Azure SignalR 服务的另一个原因。
这正是我想要的。谢谢
@tocqueville，这回答了你的问题吗？

【解决方案3】：

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

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

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

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

【讨论】：

绝对是这样，如果你有一个聊天应用程序，比如半实时多人手机游戏，定价可能会很快失控。消息成本似乎太高了。

【解决方案4】：

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

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

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

【讨论】：