服务器端消息推送，简化服务器长连接通信

        互联网应用，经常会面对这样的需求：需要服务器端主动通知客户端。一般，服务器端是一直监听客户端的请求，但是，客户端并不实时监听服务端。

        客户端，要想实时接收服务器端消息，得和服务器端建立一个长链接。和短连接相比，长连接得维持一个稳定的连接状态，门槛也要高不少。

        移动互联网兴起，出现了一种比较有意思的方案：消息推送。

一. 手机app的消息推送

        消息推送，不少人接触这概念，源于“手机app消息推送”。手机终端，接入第三方SDK，通过很简单的代码，便能接收服务端推送的消息。

        不久后，不少网友发现，直接用来做即时通讯，也不是不可以。

        当然，消息推送SDK爆火后，先是app滥用推送，再到后来，手机厂商对消息推送做了很多限制。

        现如今，开发者对消息推送服务，并没那么喜欢了。当然，也还是会去接入SDK，虽然，客户端接收消息并不可靠，但是，对于应用来说，还是能锦上添花。

二. 服务器架构的启发

        消息推送服务，让服务器开发者了解到不一样的概念。此前，服务器给客户端发消息，需要建立长链接，然后通过长链接收发消息。通过搭建消息推送服务，可以简化整个系统的开发。

1. 主业务和推送分离

        客户端，一个请求一个返回，这更符合一般的通信习惯，通知消息，显得格格不入。消息推送，把通知消息划分到推送服务上，能简化整个应用系统。

        请求和推送分离，分别专注于各自的功能，推送，在设计上是可以容错的，请求，出错率低。主业务通过请求实现，把不需要那么可靠的通知消息分离，能让系统更稳定。

2.主业务可选短连接，降低长链接压力

        本来，使用tcp/websocket长链接，是为了接收消息。现在，服务器端和客户端，把长链接提出来，那么主业务就不一定得使用长链接，TCP短连接/HTTP都可以，怎么简单怎么来。

        使用消息推送设计，可减少长链接的通信压力。除此之外，单一的接收消息，也能简化长链接的开发难度。

3.专一的服务，更方便优化

        专一的服务，只做推送，优化起来能更方便。不然，通知消息和业务逻辑混在一起，优化难度大。独立的消息推送，无论是从消息可靠性，还是节约流量方面，处理起来都容易不少。

4.消息推送更灵活

        消息推送，在长链接校验上，并不需要做很强的校验，除此之外，还能多客户端派发，类似订阅发布模式，灵活扩展。

        提到订阅发布，不得不提下MQ，其实MQ和消息推送能很像。介于这样的背景，便出现了MQTT协议，并不建议随便使用MQTT，但是，和第三方协作，选择MQTT也很不错。

        MQTT在消息处理上，还是有不少缺陷，自己实现简单的消息推送服务，难度并不大。

三. 可靠的消息推送服务，也还是有点难度

        虽然，消息推送服务，能简化服务器长链接通信。但是，做好消息推送，也还是有些难度。就拿“大用户、大流量的消息下发”来说，这也是需要下一番功夫仔细研究的。

        消息省流、控流、离线消息处理、消息可靠性处理等，这些想处理好，都不是非常容易。