SignalR系列之一

        传统的http协议的工作原理是由客户端主动向服务器端发送请求，然后服务器端接收到请求后，做出响应，最后将结果返回给客户端。基于这种模式，只能客户端去找服务器端，服务器端是不可能主动的找客户端，服务器端永远都处在被访问者的角色。这种模式其实是合乎情理的，如果服务器端能够主动的去访问客户端，那就太危险了。

        但是有一些情景，这种模式就显得不是那么好用，高效。记得之前给一个企业内部的生产车间开发MES系统的时候，有这样一个需求，车间经常会出现缺料补料的情况，工人需要通过平板录入提交缺料信息，仓库在接收到信息后，将相关物料及时送到车间现场。这个简单的功能最早之前的做法是在前端使用定时器，一直刷新页面，调用后台接口，如果有缺料信息提交，仓管员通过看板页面就可以及时看到最新的缺料实时信息。这种做法的缺点，我在此就不做陈述了，这只是一个引子，说它的目的就是想引出SignalR这个微软推出的技术框架。通过SignalR可以实现从服务器端推送消息给客户端，这样就非常有效的避免了在前端使用定时器频繁调用后台接口给服务器造成的压力。

        当然，也可以使用WebSocket从服务器端推送消息给客户端，但是WebSocket对浏览器的版本有一定的要求，如果是比较老的浏览器就不支持，这也是我没有采用WebSocket的一个主要原因，因为MES系统主要是针对制造型企业，用户大部分是工厂车间，而有一些车间内用的东西比较陈旧，所以考虑到一些因素，最终选用SignalR来实现消息的推送功能。还有一个原因是，相对来说通过WebScoket来实现这个功能比较麻烦，微软提供的这个高度封装的框架SignalR大大的简化了Server push程序的编写，而且它还会自动的检测浏览器是否支持html5的WebSocket，如果不支持，在不用更改任何代码的情况下会自动的改用长连接来实现。感觉是不错，但同时这也暴漏了SignalR的一个缺点，就是它需要较高配置的服务器才可以，不然性能可能会大打折扣，这个缺陷对于我来说是可控制的，只需用一台好点的服务器即可，不需要对车间工人提各种让他们觉得不耐烦的要求。

        所以我觉得每一个技术其实都不是绝对完美的，并不是说我不用WebSocket就是觉得这个技术不好，它有它的价值，只是在当前的业务场景内，可能它不是最佳的选择。