使用websocket的三种架构方式
开篇
在B/S的软件架构中,大部分场景都是浏览器主动请求服务器,服务器被动响应结果给浏览器,这种交互模式,http协议做得非常不错。可现实场景中,总有一部分业务是需要服务器主动推送数据给浏览器的。
为实现这类业务需求,人们想到了基于http协议的轮询方案(长轮询、短轮询),在小流量或者是简单业务场景下,该方案可能会满足业务需求。
随着网络的普及,流量在快速增长,业务模式在不断创新,比如弹幕啥的,主播一句:“666走起”,就可能导致服务器卡壳。在此背景下,websocket协议应运而生。下面是几个关于该协议的介绍:
讲起来很复杂,但是使用起来却很简单,在此感谢实现该协议的大佬们。
下面介绍三种架构方式。
基于发布订阅服务器的架构
缺点:
- 连接维护逻辑与业务逻辑耦合
- 代码发版必定有用户掉线,不利于业务迭代
- 发版订阅服务器是个单点
- 只要消息接收方不在当前websocket服务器,则消息必须通过发布订阅服务器广播到其它websocket服务器,消息流转效率较低
优点:
- 架构简单,开发一把梭
- websocket服务器扩容方便
基于Gateway、Worker的架构
缺点:
- gateway部署需要预估容量,如果引入服务发现则可以方便扩容
- gateway是全双工通信的,稳定运行的难度大
- worker与gateway维持了tcp长连接,传统php(fpm下运行的框架)框架不好实现
优点:
- 连接维护逻辑与业务逻辑分离
- worker的代码发版,用户不会掉线,利于业务迭代
- worker扩容方便
基于Gateway、HttpApi的架构
缺点:
- gateway部署需要预估容量,如果引入服务发现则可以方便扩容
优点:
- gateway只有推送的压力,运行更稳定
- httpApi扩容方便
本作品采用《CC 协议》,转载必须注明作者和本文链接
大佬,这个图是用什么软件做的
GatewayWorker+HttpAPI :joy:
第三种才是最佳实践