一、背景
公司之前很多涉及到后端需要主动与前端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流川枫,我们下期见~