单独对websocket抽象封装，支撑了公司不同业务的消息即时通讯！

一、背景

公司之前很多涉及到后端需要主动与前端web交互的业务，代码耦合严重，新的业务场景需要即时通信的得重新接入websocket，花费很多时间和精力，因此需要将websocket（缩写为：ws）抽象为公司内部的通讯服务，可以解决业务不同需求，比如：

业务采用了轮询方式来获取服务器异步请求的结果（支付回调订单、业务订单）。
系统中有部分业务使用了即时推送功能（反扫二维码定时刷新、充电端口加载刷新）。
提高系统的响应速率，同步调用重构为异步调用方式，调用结果以websocket方式推送给前端，降低接口延迟性。
考虑未来有新的业务需要使用websocket即时通讯支撑。

二、重构目标

规范ws通讯工程项目结构和写法。
剔除业务代码，提高接入效率。
使用推送代替不合理的接口轮询。
支撑原有同步调用优化为异步调用，接口响应结果通过ws推送给前端，提高系统的整体响应效率。
使用MQ代替Redis发布订阅和微服务调用

核心设计

项目结构

三、业务流程

3.1 应用关系图

消息推送（Fanout）

消息接收处理（Topic）

3.2 业务时序图

从上到下依次为：

websocket客户端注册，连接流程
推送消息到服务端流程
推送消息到客户端流程

四、消息分类

5.1 客户端→服务端

描述

应用场景为客户端主动向服务端推送消息，在服务端执行相应的业务流程。

现有系统中有此应用场景的业务是：反扫二维码请求开始刷新，用户要请求开始刷新启动二维码

5.2 服务端→客户端

描述

应用场景为服务端触发了某个事件，需要推送相应结果到某个客户端。

现有系统中有此应用场景的业务是：支付完成后，等待第三方服务器回调，回调成功结果推送

5.3 客户端 →客户端

描述

应用场景为客户端需要向另一客户端推送消息。

现有系统中有此应用场景的业务是：C端用户发送接口请求，推送响应结果到用户H5页面中

五、Websocket API设计

5.1 请求websocket连接token

请求方式：GET

统一请求接口url：域名/xxx/websocket/token

json 复制代码

{
  "result": 0,
  "description": "无",
  "data":"wss://dws.test.com:8086/socket/asrwqgvsd" //连接url
}

5.2 使用返回的url连接websocket

连接方式: wss

连接url: wss://dws.test.com:8086/socket/{token}

六、统一消息体

json 复制代码

{
  "sendType": "",
  "messageType": "消息类型",
  "businessType": "",
  "fromUniqueId": "发送端唯一id",
  "toUniqueId": "接收端唯一id",
  "fromClientType": "发送端类型",
  "toClientType": "接收端类型",
  "timestamp": 0,
  "content": "业务数据",
  "tags": [
    "标签集"
  ],
  "businesses": [
    "业务集"
  ]
}

七、统一调用方式

7.1 Websocket API聚合封装

7.2 业务统一调用

总结

本文主要记录我基于对websocket做的抽象统一封装的整体设计思想，从项目代码设计上采用了DDD的思想建模，降低了代码的耦合程度，不同业务在需要使用ws即时通讯可以做到"即引即用"的效果，不再需要考虑websocket接入底层的配置和逻辑。好了，今天的分享就到此结束了，如果文章对你有所帮助，欢迎 点赞👍+评论💬+收藏❤，我是：austin流川枫，我们下期见~