使用websocket的三种架构方式

开篇

在B/S的软件架构中，大部分场景都是浏览器主动请求服务器，服务器被动响应结果给浏览器，这种交互模式，http协议做得非常不错。可现实场景中，总有一部分业务是需要服务器主动推送数据给浏览器的。
为实现这类业务需求，人们想到了基于http协议的轮询方案（长轮询、短轮询），在小流量或者是简单业务场景下，该方案可能会满足业务需求。
随着网络的普及，流量在快速增长，业务模式在不断创新，比如弹幕啥的，主播一句：“666走起”，就可能导致服务器卡壳。在此背景下，websocket协议应运而生。下面是几个关于该协议的介绍：

1. The WebSocket Protocol
2. WebSocket 协议（RFC 6455 中文版）
3. 浏览器的WebSocket客户端

讲起来很复杂，但是使用起来却很简单，在此感谢实现该协议的大佬们。
下面介绍三种架构方式。

基于发布订阅服务器的架构

缺点：

1. 连接维护逻辑与业务逻辑耦合
2. 代码发版必定有用户掉线，不利于业务迭代
3. 发版订阅服务器是个单点
4. 只要消息接收方不在当前websocket服务器，则消息必须通过发布订阅服务器广播到其它websocket服务器，消息流转效率较低

优点：

1. 架构简单，开发一把梭
2. websocket服务器扩容方便

基于Gateway、Worker的架构

缺点：

1. gateway部署需要预估容量，如果引入服务发现则可以方便扩容
2. gateway是全双工通信的，稳定运行的难度大
3. worker与gateway维持了tcp长连接，传统php（fpm下运行的框架）框架不好实现

优点：

1. 连接维护逻辑与业务逻辑分离
2. worker的代码发版，用户不会掉线，利于业务迭代
3. worker扩容方便

基于Gateway、HttpApi的架构

缺点：

1. gateway部署需要预估容量，如果引入服务发现则可以方便扩容

优点：

1. gateway只有推送的压力，运行更稳定
2. httpApi扩容方便

本作品采用《CC 协议》，转载必须注明作者和本文链接