SignalR毫无疑问是.Net中很好使的实时消息处理系统。在我之前的公司的聊天功能就是用SinglaR进行广播推送的。不过他们没有用到Group的概念。用的最多的就是All广播推送。甚至部分Client方法都是用All的形式去推送。在前端用cookie判断id选择是否展示。毫无疑问这种写代码的方式虽然可以完成功能，但是性能极其差劲。为什么我要说是之前的公司呢，因为一些原因，我和我的直系领导闹的很不愉快。在他要T我的时候，我要求合理的赔偿。他竟然把自己代码的问题甩锅到我头上，还说出了这样的事。客户都跑了没有让我赔偿就不错了。我真的是气笑了。
具体到底是什么事呢。在我公司的系统里。有多套子房间的概念。客户的需求是想要子房间的消息汇总到子房间或者全部互通。也有可能是部分汇总或者部分互通。很简单的一个需求对不对？那么为什么会出问题呢？在SignalR的扩展上，MSDN有三种推荐方式。一是用Azure的SignalR服务。二是用SQL Server的MQ。三是用Redis的做底板。由于方案1要钱。方案2则是因为我们使用的是mysql。所以我最初的时候是选择了redis方案。一开始他们的需求是子房间消息汇总到主房间。我只需要做一个很简单的配置。就可以让所有的web站点都能收到任意一个站点发出的消息。这就解决了这个问题。但是当天晚上刚开始的时候经理发现服务器的资源使用情况过高。也没有如何排插问题就把我的代码改了。选择了暴露一个接口。然后子房间去调用主房间的消息接口。再由接口调用主房间的广播已达到汇总的功能实现。当时看到这个我已经吓尿了，这是什么神仙操作？但是由于后续没什么问题，加上位卑言轻我也没再说什么了。后来客户的需求改了，想要把汇总改成互通。这按照他原先的设计。就要在子房间1发言的同时去调用所有房间的接口。再由每个房间分别去调用属于自己站点的Signalr实现广播。在这里我已经闻道了代码腐败的味道了。接着客户又改需求了。要实现部分房间互通。部分房间不互通。按照他的设计这里就需要维护一个互通列表。可惜他的做法真的是让我捧腹大笑。
值得一提的是。这里所有的房间都是公用一套资源站点的。他这里不选择后台去控制广播。反而选择让前台来控制渲染。就是说不管怎么样广播都会发出。只是前端选择是否展示而已。然后他就单独的把不互通的站点再搞了一个资源站点。专门处理不互通的。我的天啊。这都是什么和什么啊。这些操作在我改了之后。我就再也没有碰过了。后面可能是他们弄的太复杂了把自己都绕晕过去了，经常出现一些问题。然后客户跑了。他把这个问题怪在我身上，原因是这个问题本来是让我解决的。所以这以后出的问题都是在我账上的。我说你自己改掉了都没有通知我。他竟然说不放心让我改代码。我真觉得我的领导是培训出来的。然后随随便便抄一些代码。混一些年份就捞个职位出来骗钱了。
抱怨完了，进入今天的主题。