.NetCore SignalR 踩坑记

背景

由于最近公司要做微信小程序聊天，所以.netframwork版本的signalr版本的不能用了。因为小程序里没有windows对象，导致jquery无法使用。而signalr的 js客户端是依赖jquery的。

所以看下了core版本的signarlr,经过测试，发现可以在微信中运行，不过要将js客户端中的webscoekt 改为微信自家的。如有需要改后的版本，可以楼下评论。

目的

本文的主要目的是为了介绍下使用.netcore版本signalr的一些坑，并提供了解决方式。主要是以前的大部分文章只是简单的官方demo介绍。没有真正投入使用，其中一些细小问题没有进行深入挖掘并进行处理。

跨域问题

.net frmawork版本很简单，引用相应的包，只要加上addcores()就行了，而core版本的则控制的更加精确。如下configureservices添加如下代码

services.addcors(options => options.addpolicy("signalr",
   builder =>
   {
       builder.allowanymethod() //允许任意请求方式
              .allowanyheader() //允许任意header
              .allowanyorigin() //允许任意origin
              .allowcredentials();//允许验证
            //.withorigins(domins) //指定特定域名才能访问
   }));

然后在configure使用定义好的跨域策略

app.usecors("signalr");

使用redis scale out

和.net framwork一样，.netcore版本signalr可以使用redis在多台服务器间通信。但是如果redis没有连接成功，程序不会报错，但是通讯不能正常使用。而.net framwork版本的话,signalr的地址直接404.

所以我想在启动时候就监控redis是否连接成功。但signalr的官方文档只有简单使用，连redis怎么进行配置都没有。所以只能去最大的交友网站去找。一条条翻看issue，终于发现怎么监控了。

戳我看明细

要用以下代码进行配置，就可以监控redis是否连接成功了.

services.addsignalr()
        .addmessagepackprotocol()
        .addredis(o =>
        {
            o.connectionfactory = async writer =>
            {
                var config = new configurationoptions
                {
                    abortonconnectfail = false
                };
                config.endpoints.add(ipaddress.loopback, 0);
                config.setdefaultports();
                var connection = await connectionmultiplexer.connectasync(config, writer);
                connection.connectionfailed += (_, e) =>
                {
                    console.writeline("connection redis failed.");
                };

                if (!connection.isconnected)
                {
                    console.writeline("connection did not connect.");
                }

                return connection;
            };
        });

但是发现用这种方式，redis连接了2次，按道理不应该额。加上我事情多，没空研究源代码。所以就在这条issue里直接问作者。到现在还没找到原因。详情可以看上面的链接。

websocket 负载均衡配置

使用负载均衡对请求转发的话，需要对websocket请求需要特殊配置。

找运维同学配置了下，配置完后告诉我这个链接以后只能进行get请求，不能进行post请求了。手动黑人问号。。。

这样的话只能用websocket方式了，像longpollin及sse协议都不能用了。

我去，这么坑吗？于是让运维把配置代码发我，如下

proxy_http_version   1.1;
proxy_set_header  host $host;
proxy_set_header   upgrade $http_upgrade;
proxy_set_header   connection "upgrade";
proxy_connect_timeout   300;
proxy_read_timeout   300;
proxy_send_timeout   300;

于是我把应用发布到本地虚拟机里，并用docker方式运行。然后把配置写进nginx配置文件里。

发现真的不能进行post请求了，返回400。400的意是思请求异常。肯定是这个配置有问题额。于是又去交友网站找issue，果然又让我找到了。 在一个issue里面，提供的配置如下

proxy_http_version   1.1;
proxy_set_header   upgrade $http_upgrade;
proxy_set_header connection $http_connection;

不同点在于proxy_set_header connection，没有写死，于是我把配置改了下，果然好了。

原来proxy_set_header connection 不能写死，要从请求头里面获取。这样其他请求方式也就没啥问题了。

connectionid获取

在js客户端代码里，没有再提供connectionid的获取。也就是如果要用的话，需要自己改源码加上。改是没问题，但是微软那群大神不应该犯这么低级的错误。connectionid明明在negotiate请求时候返回了，为什么不开放呢？难道是bug?不应该有这么低级的bug吧。

于是又去看issues,果然，里面也有人问，作者也有解释。

去交友网站看看

大体意思connectonid是服务端使用，客户端不应该使用这种不可控的方式进行通信。 可以采用group或者user这种可控方式通信，并且也有例子给出。

这里插一句，在使用.net framwork版本时候，我们网站是使用connectionid进行通信，经常出现重连导致connectionid变掉，进而通信失败。

所以我也调整了下设计思路，改使用group进行通信。

以上都搞定了，辛苦了这么久，按道理应该没问题了吧！那么发布上线！

大坑来了

应用我本地测试一切正常，测试机也没有问题，于是就发到生产环境，结果问题出现了。

因为本地和测试环境都是单台服务器，测试没问题。而到了生产环境，服务器有多台。 不管我js怎么设置，总会在执行完negotiate请求后，接下来的连接请求肯定404，并且返回no connection with that id。

如下图

 

看到这个错误，第一个反应，我的想法是难道是redis没连接成功，所以只能单机跑？所以我就在上面redis代码加上各种监控，发现连接成功了。代码review了n遍代码，实在没有地方可以改了。

于是官方文档一个个过。终于发现js可以进行以下配置

let connection = new signalr.hubconnectionbuilder()
    .withurl("/myhub", {
        skipnegotiation: true,
        transport: signalr.httptransporttype.websockets
    });
    .build();

上面代码意思是跳过negotiate握手操作，直接使用websocket进行连接。

按照文档配置了，我去，还真的可以。因为只发送了一条请求就建立了通信连接。

这下我就不淡定了，难道只能部署一台服务器吗？这下稳定性怎么保证？这个还是用在微信小程序里的（js客户端进行了修改），低版本不能用websocket，难道低版本就不管了吗？流量大了不加机器怎么抗的住？难道要换方案自己撸一套通讯吗？

没办法，只能上大招。把源码clone下来，花了点时间看了下，找到如下代码

private async task<httpconnectioncontext> getconnectionasync(httpcontext context)
{
    var connectionid = getconnectionid(context);

    if (stringvalues.isnullorempty(connectionid))
    {
        // there's no connection id: bad request
        context.response.statuscode = statuscodes.status400badrequest;
        context.response.contenttype = "text/plain";
        await context.response.writeasync("connection id required");
        return null;
    }

    if (!_manager.trygetconnection(connectionid, out var connection))
    {
        // no connection with that id: not found
        context.response.statuscode = statuscodes.status404notfound;
        context.response.contenttype = "text/plain";
        await context.response.writeasync("no connection with that id");
        return null;
    }

    return connection;
}

这段代码啥意思呢？就是connection在本地没找到的话，就返回404!

我去，难道是代码bug？

额外补充一下

在.net framwork版本里，源码里面会对connectionid进行验证。验证通过，但本地找不到connection的话，就会新建一个connection，从而实现多台服务器间的通讯。所以我才有上面的疑问。 但这样有个弊端，就是无法监控客户端何时断开。

所以我提了个issue问作者。 戳我看明细

得到的回复是

it's not a bug it's by design. asp.net core signalr requires sticky sessions when using scale out. this means you need to pin a connection to a particular serve

啥意思呢？就是这不是bug,就是这么设计的。使用signalr时，要进行会话保持，请求要一直落到同一台服务器上。这样更稳定，并且还可以实时监控客户端的情况。

于是找运维同学在负载上配置了下会话保持，再次测试，终于可以了。

总结

在此次使用signalr的过程中，遇到了太多的坑。花了几个小时整理并记录下来，与各位进行分享。希望能帮到那些准备或者有打算使用.net core的.neter

作者：cgyqu

出处：https://www.cnblogs.com/cgyqu/p/9563193.html

本站使用「署名 4.0 国际」创作共享协议，转载请在文章明显位置注明作者及出处。