我知道这个问题听起来很奇怪，但最近的测试让我对SignalR的实现产生了怀疑。
我的启动类中有以下内容(为了尽可能简化设置，省略了其他设置(：
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR().AddAzureSignalR();
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<BearHub>("/bear");
});
}
我的Azure帐户中有一个付费SignalR订阅，当我使用.AddAzureSignalR((部分时，它会从我的应用程序设置文件中读取。它运行良好。
稍后，我们需要添加一些集成测试。出于某种原因，经过几次尝试，我们发现当我们删除AddAzureSignalR((部分时，内存中的SignalR测试类可以正常工作！！这让我想起，早在Azure成为许多公司的选择之前，我就见过SignalR的例子。这意味着：公司只是在正常的应用程序服务中使用SignalR。。。或者我是这么认为的。
因此，当我使用AzureSignalR而不仅仅是具有SignalR功能的应用程序服务时，我不确定我要添加什么。我去了Azure SignalR网站，它声称有些事情不清楚：
您不必仅仅因为解决方案中需要实时功能就配置和维护服务器。SignalR服务是完全管理的，可以轻松地为您的应用程序添加实时通信功能。不再担心托管、可扩展性、负载平衡等细节！
我不需要同时维护带有应用程序服务的服务器。我既不需要担心托管、可扩展性和平衡。可能平衡部分是关键，因为它可以以比应用程序服务更好的方式自动管理。但其他观点似乎只是宣传
享受Azure提供的一切！轻松集成Azure功能、Azure Active Directory、Azure存储、Azure应用程序服务、Azure分析、Power BI、物联网、认知服务、机器学习等服务。
只有SignalR和应用程序服务才是如此。如果我删除AddAzureSignalR((部分，它不会改变。
我不确定我们是否在为不需要的东西付费(即使它一点也不贵(
Azure SignalR服务与其他服务相比是相当新的。SignalR早在2013年就开始了。因此，您可以在没有Azure SignalR服务的情况下在应用程序服务中使用它。我们自己也这么做。我甚至猜测大多数Signal R应用程序仍在使用它们的"；拥有"；基础设施，只是因为它们还没有迁移。
MSDN甚至有一个官方的完整样本来做这件事。
在提到的好处中，SaaS解决方案对我来说有两个主要好处：
- 将SignalR与其他基础设施解耦
- 缩放。如果使用应用程序服务进行扩展，则必须使用redis背板，这在成本和基础设施方面是一个相当大的飞跃