如果在没有太多经验可借鉴的情况下，要设计一套完整可用的移动端IM架构，难度是相当大的。原因在于，IM系统（尤其是移动端IM系统）是多种技术和领域知识的横向应用综合体：网络编程、通信安全、高并发编程、移动端开发等，如果要包含实时音视频聊天的话，则还要加上难度更大的音视频编解码技术（内行都知道，把音视频编解码及相关技术玩透的，博士学位都可以混出来了），凡此种种，加上移动网络的特殊性、复杂性，设计和开发难度不言而喻。
总体架构设计
各层级的说明如下：
用户端：
移动端重点是移动端，支持IOS/Android系统，包括IM App，嵌入消息功能的瓜子App，未来还可能接入客服系统；
用户端API：
针对TCP协议，提供IOS/Android开发SDK。对于H5页面，提供WebSocket接口；
接入层：
接入层主要任务是保持海量用户连接（接入）、攻击防护、将海量连接整流成少量TCP连接与逻辑层通讯；
逻辑层：
逻辑层负责IM系统各项功能的核心逻辑实现。包括单聊（c2c）、上报(c2s)、推送(s2c)、群聊(c2g)、离线消息、登录授权、组织机构树等等内容；
存储层：
存储层负责缓存或存储IM系统相关数据，主要包括用户状态及路由（缓存），消息数据（MySQL也可采用NoSql，如MangoDB），文件数据（文件服务器）。
客户端从Iplist服务获取接入层IP地址（也可采用域名的方式解析得到接入层IP地址），建立与接入层的连接（可能为短连接），从而实现客户端与IM服务器的数据交互；业务线服务器可以通过服务器端API建立与IM服务器的联系，向客户端推送消息；客户端上报到业务服务器的消息，IM服务器会通过mq投递给业务服务器。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
登录授权(auth)流程原理
1、客户端通过统一登录系统实现登录，得到token。
2、客户端用uid和token向msg-gate发起授权验证请求。
3、msg-gate同步调用msg-logic的验证接口
4、msg-logic请求sso系统验证token合法性
5、msg-gate得到登录结果后，设置session状态，并向客户端返回授权结果。
登出(logout)流程原理
1、客户端发起logout请求，msg-gate设置对应Peer为未登录状态。
2、Msg-gate给客户端一个ack响应。
3、Msg-gate通知msg-logic用户登出。
踢人(kickout)流程原理
用户请求授权时，可能在另一个设备（同类型设备）开着软件处于登录状态，这种情况需要系统将那个设备踢下线
1-5步，参看Auth流程。
6、Logic检索Redis，查看是否该用户在其他地方登录。
7、如果在其他地方登录，发起kickout命令。（如果没有登录，整个流程结束）
8、Gate向用户发起kickout请求，并在短时间内（确保客户端收到kickout数据）关闭socket连接。
上报(c2s)流程原理
1、客户端向gate发送数据；
2、Gate回一个ack包，向客户端确认已经收到数据；
3、Gate将数据包传递给logic；
4、Logic根据数据投递目的地，选择对应的mq队列进行投递；
5、业务服务器得到数据。
推送(s2c)流程原理
1、业务线调用push数据接口sendMsg
2、Logic向redis检索目标用户状态。如果目标用户不在线，丢弃数据（未来可根据业务场景定制化逻辑）；如果用户在线，查询到用户连接的接入层gate
3、Logic向用户所在的gate发送数据
4、Gate向用户推送数据。（如果用户不在线，通知logic用户不在线）
5、客户端收到数据后向gate发送ack反馈
6、Gate将ack信息传递给logic层，用于其他可能的逻辑处理（如日志，确认送达等）
单对单聊天(c2c)流程原理
1、App1向gate1发送信息（信息最终要发给App2）
2、Gate1将信息投递给logic
3、Logic收到信息后，将信息进行存储
4、存储成功后，logic向gate1发送ack
5、Gate1将ack信息发给App1
6、Logic检索redis，查找App2状态。如果App2未登录，流程结束
7、如果App2登录到了gate2，logic将消息发往gate2
8、Gate2将消息发给App2（如果发现App2不在线，丢弃消息即可，这种概率极低，后续离线消息可保证消息不丢）
9、App2向gate2发送ack
10、Gate2将ack信息发给logic
11、Logic将消息状态设置为已送达。
注：在第6步和第7步之间，启动计时器（DelayedQueue或哈希环，时间如5秒），计时器时间到后，探测该条消息状态，如果消息未送达，考虑通过APNS、米推、个推进行推送。
群聊(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离线，期望未来拉取到离线消息。
网友评论