IM服务架构
这两天思考了一下IM系统架构,大三的时候基于网络文档实现过,时过境迁抽象思考一下
一、架构主流程
1.主要测试用例:建立连接
- 用户负载均衡到不确定的集群节点(Pod)
- 获取集群节点ip
- 保存连接Session(携带集群节点ip存储至Redis)
2. 主要用例:用户A给用户B发送消息
- 用户A发起通信B
- 获取B的session
- 建立TCP通信B所在的集群节点,并转发消息
- B所在集群节点发送消息给B
二、主要功能
- A给B发消息
- 用户与客户端心跳,同步redis_session状态
- 上线接收离线消息
- 消息通信确认机制(确认消费)
三、面向对象抽象
系统定位是给指定用户发送消息而不是聊天系统;
1.获取服务节点(pod)ip地址
该标题的主要意义是采用了什么作为”注册中心”,目前我们的”注册中心”是k8s,对于用户所在集群节点ip可以通过环境变量获取,从而达到集群节点之间的通信
2.消息生命周期(面向其他类型消息兼容)
1.发送消息
2.消息确认
3.离线消息
4. …
3.TCP连接
主要屏蔽TCP连接操作
4.用户session
初始方案使用的是Redis,后续可以摈弃Redis使用本地缓存,通过集群节点之间同步的用户登入状态,但是实现比较麻烦;
四、性能预估
1.优点
优点一.扩容能力强,可以自适应容器扩容
优点二.中间件依赖基本没有,redis也可以换成本地缓存(但实现麻烦)
优点三.性能水平主要跟随容器pod数量,没有主要性能瓶颈
2.性能瓶颈
性能瓶颈一.TCP负载均衡可能会失衡
性能瓶颈二.假如集群有100个pod,它们之间的通信可能需要建立100个TCP
2.1性能瓶颈一解决方案
1.记录集群每个节点的TCP阈值
2.到达阈值拒绝连接TCP,或返回一个可用节点IP
2.2性能瓶颈二解决方案
1.可以部署专门的转发服务,统一转发至其他节点,而不在节点自己负责
2.仅转发功能改为HTTP在集群内转发消息
五、实现难度
- Netty组件 20%
- 业务功能70%
- WebSocket 10%
技术难度不高但结合业务功能需要较多时间(具体看需要达到的功能)