互联网应用,经常会面对这样的需求:需要服务器端主动通知客户端。一般,服务器端是一直监听客户端的请求,但是,客户端并不实时监听服务端。
客户端,要想实时接收服务器端消息,得和服务器端建立一个长链接。和短连接相比,长连接得维持一个稳定的连接状态,门槛也要高不少。
移动互联网兴起,出现了一种比较有意思的方案:消息推送。
一. 手机app的消息推送
消息推送,不少人接触这概念,源于“手机app消息推送”。手机终端,接入第三方SDK,通过很简单的代码,便能接收服务端推送的消息。
不久后,不少网友发现,直接用来做即时通讯,也不是不可以。
当然,消息推送SDK爆火后,先是app滥用推送,再到后来,手机厂商对消息推送做了很多限制。
现如今,开发者对消息推送服务,并没那么喜欢了。当然,也还是会去接入SDK,虽然,客户端接收消息并不可靠,但是,对于应用来说,还是能锦上添花。
二. 服务器架构的启发
消息推送服务,让服务器开发者了解到不一样的概念。此前,服务器给客户端发消息,需要建立长链接,然后通过长链接收发消息。通过搭建消息推送服务,可以简化整个系统的开发。
1. 主业务和推送分离
客户端,一个请求一个返回,这更符合一般的通信习惯,通知消息,显得格格不入。消息推送,把通知消息划分到推送服务上,能简化整个应用系统。
请求和推送分离,分别专注于各自的功能,推送,在设计上是可以容错的,请求,出错率低。主业务通过请求实现,把不需要那么可靠的通知消息分离,能让系统更稳定。
2.主业务可选短连接,降低长链接压力
本来,使用tcp/websocket长链接,是为了接收消息。现在,服务器端和客户端,把长链接提出来,那么主业务就不一定得使用长链接,TCP短连接/HTTP都可以,怎么简单怎么来。
使用消息推送设计,可减少长链接的通信压力。除此之外,单一的接收消息,也能简化长链接的开发难度。
3.专一的服务,更方便优化
专一的服务,只做推送,优化起来能更方便。不然,通知消息和业务逻辑混在一起,优化难度大。独立的消息推送,无论是从消息可靠性,还是节约流量方面,处理起来都容易不少。
4.消息推送更灵活
消息推送,在长链接校验上,并不需要做很强的校验,除此之外,还能多客户端派发,类似订阅发布模式,灵活扩展。
提到订阅发布,不得不提下MQ,其实MQ和消息推送能很像。介于这样的背景,便出现了MQTT协议,并不建议随便使用MQTT,但是,和第三方协作,选择MQTT也很不错。
MQTT在消息处理上,还是有不少缺陷,自己实现简单的消息推送服务,难度并不大。
三. 可靠的消息推送服务,也还是有点难度
虽然,消息推送服务,能简化服务器长链接通信。但是,做好消息推送,也还是有些难度。就拿“大用户、大流量的消息下发”来说,这也是需要下一番功夫仔细研究的。
消息省流、控流、离线消息处理、消息可靠性处理等,这些想处理好,都不是非常容易。