IM系统调研(那些开源的IM项目)

破局之路课程 2024-03-20 13:04:50
背景

最近一直在做客服相关的项目,从刚进项目组做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 清除状态信息。

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

0 阅读:0

破局之路课程

简介:感谢大家的关注