背景

最近一直在做客服相关的项目,从刚进项目组做IM 到工单系统再到机器人最后兜兜转转又做IM架构升级的相关事情,因为现在做的还是比较偏业务于是现在准备写一套IM相关的系统,有助于自己进一步理解IM整个架构,于是进行了相关的调研.

本文主要是聊几个开源的IM项目.

开源项目

openIM

文档地址: https://doc.rentsoft.cn/introduce/mian_function.html

github地址:https://github.com/OpenIMSDK/Open-IM-Server

如果有go基础比较推荐学习下这个项目,这个项目是微信团队一个大佬出来搞的.目前开源大概一年的样子,比较活跃也有一些交流群,能够互相学习探讨.另外文档也算是比较全.

简介

Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包括IM服务端和客户端SDK，实现了高性能、轻量级、易扩展等重要特性。开发者通过集成Open-IM组件，并私有化部署服务端，可以将即时通讯、实时网络能力快速集成到自身应用中，并确保业务数据的安全性和私密性。

服务端架构

服务端由接入层、逻辑层和存储层组成，好处在于各个层次能够依据业务特点专注于自己的事情，提高系统复用性，降低业务间的耦合。

（1）接入层：消息通过 websocket 协议接入，其他通过 http/https 协议接入，消息是高频及核心功能，通过双协议路由，体现了轻重分离的设计思想。

（2）逻辑层：通过 rpc 实现无状态逻辑服务，易于平行扩展，消息通过 MQ 解耦。

（3）存储层：redis 存储 token 和 seq；mongodb 存储离线消息，并定时删除 14 天（可自行配置）前数据；mysql 存储全量历史消息以及用户相关资料。数据分层存储，充分利用不同存储组件的特性。

（4）Etcd：服务注册和发现、以及分布式配置中心。

消息架构介绍

Open-IM 消息模型采用经典的收件箱模型，并通过全局 seq 做消息对齐，这里带来架构的简化，体现了简单的架构设计理念。很多开发者通过网络文章，了解到收件箱模型的原理，也知道 seq 的概念，就是如何在项目中做权衡和取舍，爱因斯坦曾经说过“事情应该力求简单，不过不能过于简单”，我们看到很多技术文章对收件箱模型和 seq 的滥用，要么系统设计复杂，要么过于简单，最后的结果是系统不稳定，消息可达率无法达到要求。以下我们简单讲解消息如何发送，系统如何简单解耦，接收方如何实时收到消息，并如何利用 seq 做全局消息对齐，确保消息百分百可达。

（1）绿色箭头表示用户 A 给 B 发送消息的流程：用户 A 发送消息，msg_gateway 进行消息拆分，并落地 MQ，MQ 根据 userId 写入不同的 partition 后返回给 A 成功，消息发送流程结束。

（2）蓝色箭头表示 A 给 B 发送消息后，服务端给 B 推送消息流程：msg_transfer 通过 MQ 消费者监听消息达到，通过 redis 增加 userId 对应的 seq，并把 seq 和消息关联后写入 mongodb，并异步写入 mysql，前者用于离线消息存储，比如用户不在线或者推送失败时同步消息使用，后者主要做历史消息备份，用于管理后台或其他用途。写入成功后，再调用 pusher 推送，根据 B 所连接的 msg_gateway，进行消息推送（由于网络波动或者 B 不在线等原因，可能会推送失败）。

（3）粉色箭头表示 B 主动同步和服务端差量消息流程：客户端在任何有重连动作（包括重新登录、网络波动等）发生时，首先会获取自身在服务端最大的 seq，和本地 seq 做差值对比，把差值消息通过接口主动拉取到本地，这样完成了本地和服务端消息对齐。

消息发送、消息对齐等与服务器交互的逻辑，我们通过 Open-IM-SDK 的方式提供给大家使用，简化了开发流程。

tinode

GitHub地址:https://github.com/tinode

目前这个是我们这边正在用的一个开源项目,内部也是踩了不少坑,记得项目刚上线天天挂那叫一个悲剧,每天在告警电话中惊醒.

下面说一下对tinode的一个大概总结:

总结

• tinode整体实现了IM系统中接入层和消息系统。 （可以了解下 IM系统的一般架构）
• 没有使用其它消息中间件作为缓冲队列，而是直接使用golang的channel作为缓冲队列。

• 消息在收到并解析后如果是Data类型会进入存储库，非Data类型不会落库，只在内存保留。
• 消息同步不通过外部数据库，直接推给在线的客户端。

• 同步模型来说
• 私聊和消息通知是写扩散模式，都会发到用户自己的me topic上

• 群聊则是读扩散模式，每个群有自己的topic，要读取群消息需要去读对应的群topic

优点

• 结构简单、依赖少
• 部署简单、资源消耗少

• 单点性能好

缺点

• 只有内存channel作为缓冲，承载瞬发高压力的能力有限
• 非Data类型消息没有持久，处理节点挂了的话就会丢

• 消息同步没有持久，处理节点如果挂了会同步不正确，需要客户端重新拉取
• 集群内部代理的方式比较低效，当节点数较多时，每个节点上将近50%的流量都是要代理给其他节点的

Tinode应该是一个不错的轻量级解决方案，大集群的情况下资源浪费较多，可靠性也存在一些问题。而客服这边流量确实相对较小，场景也比较简单。

CIM

github地址:https://github.com/crossoverJie/cim

这个项目目前更像是一个IM入门的demo,对我来说的优点就是java,因为我自己就是做java的,里面的代码主要是用netty实现的一套IM通信.目前这个项目也不活跃了.

阅读这个项目有助于理解IM的一些概念,能够在代码实践中学习.

目前CIM实现了:

• 群聊
• 私聊

• 内置命令
• 聊天记录查询。

• 一键开启价值 “2 亿”的AI模式
• 使用 Google Protocol Buffer 高效编解码

• 根据实际情况灵活的水平扩容、缩容
• 服务端自动剔除离线客户端

• 客户端自动重连
• 延时消息

系统架构

• CIM 中的各个组件均采用 SpringBoot 构建。
• 采用 Netty 构建底层通信。

• Redis 存放各个客户端的路由信息、账号信息、在线状态等。
• Zookeeper 用于 IM-server 服务的注册与发现。

cim-server

IM 服务端；用于接收 client 连接、消息透传、消息推送等功能。

支持集群部署。

cim-forward-route

消息路由服务器；用于处理消息路由、消息转发、用户登录、用户下线以及一些运营工具（获取在线用户数等）。

cim-client

IM 客户端；给用户使用的消息终端，一个命令即可启动并向其他人发起通讯（群聊、私聊）。

流程图

• 客户端向 route 发起登录。
• 登录成功从 Zookeeper 中选择可用 IM-server 返回给客户端，并保存登录、路由信息到 Redis。

• 客户端向 IM-server 发起长连接，成功后保持心跳。
• 客户端下线时通过 route 清除状态信息。

希望对大家有点帮助,具体的细节大家可以讨论下,我也是在学习过程中,大家共同进步.