Chinaunix首页 | 论坛 | 博客
  • 博客访问: 174416
  • 博文数量: 340
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 3405
  • 用 户 组: 普通用户
  • 注册时间: 2021-05-14 14:39
文章分类

全部博文(340)

文章存档

2023年(69)

2022年(144)

2021年(127)

我的朋友

分类: 云计算

2022-10-18 10:05:05

如果在没有太多经验可借鉴的情况下,要设计一套完整可用的移动端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投递给业务服务器。

登录授权(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为未登录状态。即时通讯聊天软件app开发可以加蔚可云的v:weikeyun24咨询

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发送信息(信息{BANNED}最佳终要发给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)在线的群友能{BANNED}中国第一时间收到消息;
    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离线,期望未来拉取到离线消息。


阅读(223) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~