IM架构方案

IM服务架构

这两天思考了一下IM系统架构,大三的时候基于网络文档实现过,时过境迁抽象思考一下

一、架构主流程

1.主要测试用例:建立连接

1. 用户负载均衡到不确定的集群节点(Pod)
2. 获取集群节点ip
3. 保存连接Session(携带集群节点ip存储至Redis)

2. 主要用例:用户A给用户B发送消息

1. 用户A发起通信B
2. 获取B的session
3. 建立TCP通信B所在的集群节点,并转发消息
4. B所在集群节点发送消息给B

二、主要功能

1. A给B发消息
2. 用户与客户端心跳,同步redis_session状态
3. 上线接收离线消息
4. 消息通信确认机制(确认消费)

三、面向对象抽象

系统定位是给指定用户发送消息而不是聊天系统;

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在集群内转发消息

五、实现难度

1. Netty组件 20%
2. 业务功能70%
3. WebSocket 10%
   技术难度不高但结合业务功能需要较多时间(具体看需要达到的功能)