azure - 使用 Azure Servicebus 背板时出现奇怪的间歇性 SignalR 故障

Question

在使用 SignalR 2.2.0 以及将 Microsoft ASP.NET SignalR 服务总线消息传递底板与某些 Azure 服务总线实例结合使用时，我们在开发和生产环境中发现了奇怪的行为。一些服务总线似乎损坏并被堵塞，我们看到了下面描述的问题。

首先，这是我的 OWIN 启动代码:

public void Configuration(IAppBuilder app)
{
    string connectionString = System.Configuration.ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"];
    GlobalHost.DependencyResolver.UseServiceBus(connectionString, "MyApplicationName");

    // Branch the pipeline here for requests that start with "/signalr"
    app.Map("/signalr", map =>
    {
        map.UseCors(CorsOptions.AllowAll);
        var hubConfiguration = new HubConfiguration
        {
            //EnableJSONP = true,
            EnableDetailedErrors = true
        };
        map.RunSignalR(hubConfiguration);
    });
}

我们问题的症状是 SignalR 使用任何传输方式连接时出现间歇性故障。与没有背板的情况下运行相比，性能很慢，并且在 SignalR 客户端上启用了详细日志记录，我看到消息“SignalR:尝试连接时 webSockets 传输超时”。然后 SignalR 尝试通过其余的传输(永久帧、长轮询)，然后放弃。

最重要的是:对于我们的一些服务总线实例，性能非常稳定，我们从未遇到过问题。其他服务总线实例会导致上述问题。

为什么我们有多辆服务巴士？我们的应用程序只使用一个，但每个开发人员都有一个服务总线实例可供使用。 Azure 服务总线已损坏，而且我不知道原因，这让我彻夜难眠。

问题:

1. 其他人也遇到过这个问题吗？
2. 您是否见过服务总线实例因 SignalR 或其他应用程序而损坏或行为不当？
3. 什么可以解释这种行为？

Answer 1

这是一篇旧帖子，但我们遇到了一个非常相似的问题，让我们抓狂。当我们将 SignalR 与服务总线背板一起使用时，会发生这种情况。

在异常日志中，我们发现以下内容:

The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.

修复方法是在我们的应用程序启动中添加以下代码行。对于我们来说，那就是 global.asax.cs:

ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;

之后，我们的服务总线背板和SignalR完美运行。

要更深入地讨论正在发生的事情，check out this SO post 。