websocket的三种架构方式使用优缺点浅析

框架(架构)  /  管理员 发布于 1年前   503

websocket的三种架构方式场景背景介绍在B/S的软件架构中，大部分场景都是浏览器主动请求服务器，服务器被动响应结果给浏览器，

这种交互模式，http 协议做得非常不错。

可现实场景中，总有一部分业务是需要服务器主动推送数据给浏览器的。

为实现这类业务需求，人们想到了基于 http 协议的轮询方案（长轮询、短轮询），

在小流量或者是简单业务场景下，该方案可能会满足业务需求。

随着网络的普及，流量在快速增长，业务模式在不断创新，

比如弹幕啥的，主播一句：“666 走起”，就可能导致服务器卡壳。

在此背景下，websocket 协议应运而生。

下面是几个关于该协议的介绍：

The WebSocket Protocol
https://datatracker.ietf.org/doc/html/rfc6455 

WebSocket 协议（RFC 6455 中文版）
https://websocket.xiniushu.com/ 

浏览器的 WebSocket 客户端
https://developer.mozilla.org/zh-CN/docs/Web/API/WebSocket

ps:

讲起来很复杂，但是使用起来却很简单，在此感谢实现该协议的大佬们。

下面介绍三种架构方式:

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

缺点：

连接维护逻辑与业务逻辑耦合

代码发版必定有用户掉线，不利于业务迭代

发版订阅服务器是个单点

只要消息接收方不在当前 websocket 服务器，则消息必须通过发布订阅服务器广播到其它 websocket 服务器，

消息流转效率较低

优点：

架构简单，开发一把梭

websocket 服务器扩容方便

2.基于 Gateway、Worker 的架构

缺点：

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

gateway 是全双工通信的，稳定运行的难度大

worker 与 gateway 维持了 tcp 长连接，传统 php（fpm 下运行的框架）框架不好实现

优点：

连接维护逻辑与业务逻辑分离

worker 的代码发版，用户不会掉线，利于业务迭代

worker 扩容方便

3.基于 Gateway、HttpApi 的架构

缺点：

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

优点：

gateway 只有推送的压力，运行更稳定

httpApi 扩容方便

完，如果有不对的地方可以在，评论去补充 3q!