一套海量在线用户的移动端IM架构设计实践分享(含详细图文)(转)

一、写在前面

 

1.一、引言

若是在没有太多经验可借鉴的状况下，要设计一套完整可用的移动端IM架构，难度是至关大的。缘由在于，IM系统（尤为是移动端IM系统）是多种技术和领域知识的横向应用综合体：网络编程、通讯安全、高并发编程、移动端开发等，若是要包含实时音视频聊天的话，则还要加上难度更大的音视频编解码技术（内行都知道，把音视频编解码及相关技术玩透的，博士学位均可以混出来了），凡此种种，加上移动网络的特殊性、复杂性，设计和开发难度不言而喻。

本文分享了一套完整的海量在线用户的移动端IM架构设计，来自于做者的真实项目实践总结，包含了详细的算法原理图、数据结构定义、表结构定义等等。

即时通信网注：本文中的架构设计从实际应用的角度看，其实并不完美，多处设计对于高吞吐高并发的IM应用来讲也是存在单点性能瓶颈的（好比：提供消息交换逻辑的msg_logic服务、提供全局用户状态查询的单点Redis等），另外IM协议设计可能也稍显混乱（但这是仁者见仁智者见者的事了，不能一律而论）。但文章中的大部分算法原理、协议设计等都是值得借鉴的，总之不必照搬，但至少能给你自已的方案设计带来灵感，我想这也是本文或即时通信网的其它相似文章的真正价值所在。

1.二、参考资料

《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通讯协议和客户端》
《一套原创分布式即时通信(IM)系统理论架构方案》
《从零到卓越：京东客服即时通信系统的技术架构演进历程》
《蘑菇街即时通信/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

二、服务器端设计

 

2.一、整体架构设计

整体架构包括5个层级，具体内容以下图：
 

各层级的说明以下：
 

• 用户端：
  移动端重点是移动端，支持IOS/Android系统，包括IM App，嵌入消息功能的瓜子App，将来还可能接入客服系统；
• 用户端API：
  针对TCP协议，提供IOS/Android开发SDK。对于H5页面，提供WebSocket接口；
• 接入层：
  接入层主要任务是保持海量用户链接（接入）、攻击防御、将海量链接整流成少许TCP链接与逻辑层通信；
• 逻辑层：
  逻辑层负责IM系统各项功能的核心逻辑实现。包括单聊（c2c）、上报(c2s)、推送(s2c)、群聊(c2g)、离线消息、登陆受权、组织机构树等等内容；
• 存储层：
  存储层负责缓存或存储IM系统相关数据，主要包括用户状态及路由（缓存），消息数据（MySQL也可采用NoSql，如MangoDB），文件数据（文件服务器）。

 

2.二、典型算法逻辑

典型算法逻辑部分描述IM系统核心组件及其协做关系，结构图以下：
 

客户端从Iplist服务获取接入层IP地址（也可采用域名的方式解析获得接入层IP地址），创建与接入层的链接（可能为短链接），从而实现客户端与IM服务器的数据交互；业务线服务器能够经过服务器端API创建与IM服务器的联系，向客户端推送消息；客户端上报到业务服务器的消息，IM服务器会经过mq投递给业务服务器。

如下将对各子业务的工做原理进行逐一介绍。
 

2.2.1登陆受权(auth)流程原理

 
 

• 一、客户端经过统一登陆系统实现登陆，获得token。
• 二、客户端用uid和token向msg-gate发起受权验证请求。
• 三、msg-gate同步调用msg-logic的验证接口
• 四、msg-logic请求sso系统验证token合法性
• 五、msg-gate获得登陆结果后，设置session状态，并向客户端返回受权结果。

 

2.2.2登出(logout)流程原理

 
 

• 一、客户端发起logout请求，msg-gate设置对应Peer为未登陆状态。
• 二、Msg-gate给客户端一个ack响应。
• 三、Msg-gate通知msg-logic用户登出。

 

2.2.3踢人(kickout)流程原理

用户请求受权时，可能在另外一个设备（同类型设备）开着软件处于登陆状态，这种状况须要系统将那个设备踢下线，以下图：
 
 

• 1-5步，参看Auth流程。
• 六、Logic检索Redis，查看是否该用户在其余地方登陆。
• 七、若是在其余地方登陆，发起kickout命令。（若是没有登陆，整个流程结束）
• 八、Gate向用户发起kickout请求，并在短期内（确保客户端收到kickout数据）关闭socket链接。

 

2.2.4上报(c2s)流程原理

 
 

• 一、客户端向gate发送数据；
• 二、Gate回一个ack包，向客户端确认已经收到数据；
• 三、Gate将数据包传递给logic；
• 四、Logic根据数据投递目的地，选择对应的mq队列进行投递；
• 五、业务服务器获得数据。

 

2.2.5推送(s2c)流程原理

 
 

• 一、业务线调用push数据接口sendMsg
• 二、Logic向redis检索目标用户状态。若是目标用户不在线，丢弃数据（将来可根据业务场景定制化逻辑）；若是用户在线，查询到用户链接的接入层gate
• 三、Logic向用户所在的gate发送数据
• 四、Gate向用户推送数据。（若是用户不在线，通知logic用户不在线）
• 五、客户端收到数据后向gate发送ack反馈
• 六、Gate将ack信息传递给logic层，用于其余可能的逻辑处理（如日志，确认送达等）

 

2.2.6单对单聊天(c2c)流程原理

 
 

• 一、App1向gate1发送信息（信息最终要发给App2）
• 二、Gate1将信息投递给logic
• 三、Logic收到信息后，将信息进行存储
• 四、存储成功后，logic向gate1发送ack
• 五、Gate1将ack信息发给App1
• 六、Logic检索redis，查找App2状态。若是App2未登陆，流程结束
• 七、若是App2登陆到了gate2，logic将消息发往gate2
• 八、Gate2将消息发给App2（若是发现App2不在线，丢弃消息便可，这种几率极低，后续离线消息可保证消息不丢）
• 九、App2向gate2发送ack
• 十、Gate2将ack信息发给logic
• 十一、Logic将消息状态设置为已送达。

注：在第6步和第7步之间，启动计时器（DelayedQueue或哈希环，时间如5秒），计时器时间到后，探测该条消息状态，若是消息未送达，考虑经过APNS、米推、个推动行推送。
 

2.2.7群聊(c2g)流程原理

采用扩散写（而非扩散读）的方式。

群聊是多人社交的基本诉求，一个群友在群内发了一条消息：

• 1）在线的群友能第一时间收到消息；
• 2）离线的群友能在登录后收到消息。

因为“消息风暴扩散系数”的存在，群消息的复杂度要远高于单对单消息。

群基础表：用来描述一个群的基本信息
im_group_msgs(group_id, group_name,create_user, owner, announcement, create_time)

群成员表：用来描述一个群里有多少成员
im_group_users(group_id, user_id)

用户接收消息表：用来描述一个用户的全部收到群消息（与单对单消息表是同一个表）
im_message_recieve（msg_id,msg_from,msg_to, group_id，msg_seq, msg_content, send_time, msg_type, deliverd, cmd_id）

用户发送消息表：用来描述一个用户发送了哪些消息
im_message_send (msg_id,msg_from,msg_to, group_id，msg_seq, msg_content, send_time, msg_type, cmd_id)

业务场景举例：

• 1）一个群中有x,A,B,C,D共5个成员，成员x发了一个消息；
• 2）成员A与B在线，指望实时收到消息；
• 3）成员C与D离线，指望将来拉取到离线消息。

群聊流程以下图所示：
 

群聊流程详细说明：

• 一、X向gate发送信息（信息最终要发给这个群，A、B在线）
• 二、Gate将消息发给logic
• 三、存储消息到im_message_send表，按照msg_from水平分库
• 四、回ack
• 五、回ack
• 六、Logic检索数据库（须要使用缓存），得到群成员列表
• 七、存储每一个用户的消息数据（用户视图），按照msg_to水平分库(并发、批量写入)。
• 八、查询用户在线状态及位置
• 九、Logic向gate投递消息
• 十、Gate向用户投递消息
• 十一、App返回收到消息的ack信息
• 十二、Gate向logic传递ack信息
• 1三、向缓存（Hash）中更新收到ack的时间。而后在经过一个定时任务，每隔必定时间，将数据更新到数据库（注意只须要写入时间段内有变化的数据）。

 

2.2.8拉取离线消息流程原理

下图中，将gate和logic合并为im-server，拉取离线消息流程以下：
 
 

• 一、App端登陆成功后（或业务触发拉取离线消息），向IM系统发起拉离线消息请求。传递3个主要参数，uid代表用户；msgid代表当前收到的最大消息id（若是没收到过消息，或拿不到最大消息id则msgid=0）便可；size表示每次拉取条数（这个值也能够由服务器端控制）。
• 二、假设msgid==0，什么都不作。（参看第6步骤）
• 三、Im-server查询用户前10条离线消息
• 四、将离线消息推给用户。假设这10条离线消息最大msgid=110。
• 五、App获得数据，判断获得的数据不为空（代表可能没有拉完离线数据，不用<10条作判断拉完条件,由于服务端须要下下次拉离线的请求来肯定此次数据已送达），继续发起拉取操做。Msgid=110(取获得的离线消息中最大的msgid)。
• 六、Im-server删除该用户msgid<110的离线消息（或者标记为已送达）。
• 七、查询msgid>110的钱10条离线数据。
• 八、返回给App
• ……
• N-一、查询msgid>140的离线数据，0条（没有离线数据了）。
• N  、将数据返回App，App判断拉取到0条数据，结束离线拉取过程。

 

2.三、后台PUSH（推送）

ISO采用APNS，Android真后台保活，同时增长米推、个推。基本思路：push提示信息，App经过拉离线得到真实消息。

三、协议设计

 

3.一、IM协议整体定义

TCP的数据协议以下图所示，包括header和body两部分：
 

消息头总共20个字节，具体信息以下表：
 

3.二、各具体的IM协议体定义

消息体协议采用ProtocolBuffer（谷歌）协议（详见文章《Protobuf通讯协议详解：代码演示、详细原理介绍等》），版本3.0.0，该协议在序列化效率、压缩、可扩展方面都具备优点。如下为主要流程涉及的协议。

认证(auth) ：
 

登出(logout) ：
 

踢人(kickout) ：
 

心跳（keepalive,noop）：
心跳包消息体为空。

单对单聊天（c2c）：
 
 

群聊（c2g）：
 
 

拉离线（pull）：
 

控制类（ctrl）协议：
 
 

四、存储设计

 

4.一、MySQL数据库

MySQL数据库采用utf8mb4编码格式（emoji字符问题）。

4.二、主要表结构

发送消息表：
保存某个用户发送了哪些消息，用于复现用户聊天场景（消息漫游功能须要）。
 

推送消息表：
保存某个用户收到了哪些消息。
 

群基本信息表：
 

群用户关系表：
 

4.三、水平分库

 

4.四、Redis缓存

用户状态及路由信息：
Redis缓存以uid为key，检索channel(socketid)，last_packet_time等。
Gate层，session以channel(socketed)为key，检索uid，及其余信息。
交互接口：gate->logic，经过将channel转换为uid做为key。
logic->gate，将uid转换为channel做为key。

其余缓存信息：
你以为该怎么存就怎么存。

4.五、文件及图片存储

采用商用云存储。

4.六、数据归档

可考虑采用HBase,HDFS做为数据归档，或者相关云存储服务。

原文地址： https://mp.weixin.qq.com/s?__biz=MzI1ODY0NjAwMA==&mid=2247483756&idx=1&sn=a8e3303bc573b1acaf9ef3862e