漫谈IM通讯架构



  • XMPP

    XMPP(Extensible Messaging and Presence Protocol),也叫Jabber,它是基于稳定长连接网络环境所设计的,对于不够稳定和带宽小的移动网络不是非常合适。由于XMPP基于XML,所以流量大,流量问题对于移动网络来说非常敏感,然后就是消息不可靠、CMWAP兼容、开源项目对协议实现不完善等问题,也是XMPP面临的问题。当然XML可以通过精简压缩来实现流量可控,目前这也是XMPP优化的可行方案,消息的不可靠可以通过扩展XMPP来实现ACK,随着3/4G的发展,CMWAP网关毕竟是末日黄花,但是开源项目对协议只是部分实现等问题,也是使用XMPP绕不过去的坎。Openfire是XMPP领域最知名的开源项目,它简单易用,是很多团队的首选方案,这是国内使用最多的开源方案。Openfire虽然优点很多,但是缺点也不少,最致命的就是它的分布式扩展能力很弱,当用户量很大的时候,水平扩展就成为它的瓶颈所在。还有一个不得不提的项目就是Tigase,这是笔者接触的第一个XMPP开源项目,它在分布式扩展能力上和架构设计上比Openfire强了不少。由于该项目开始是一个私人项目,现在好像在商业化,所以使用者并不是很多,虽然国外有成熟案例,但是国内目前并不多,所以当时趟了Tigase的很多坑,目前平安好医生的聊天系统就是基于此搭建的。如果对Tigase感兴趣,可以阅读我之前写的一篇文章《Tigase集群方案及配置说明文档》。不论使用哪个开源项目,虽然看起来开箱即用,但是要成为稳定成熟的产品,还需要深度的二次开发才行。

    虽然XMPP有很多弊端,但是它的生态目前是最完善的,如果从成本角度来考量,XMPP是前期投入最小产出最快的。但是如果是搭建一个SAAS平台或者千万量级的IM,XMPP就不是最优的选择了。当然这是一家之言,国内外目前商业化的IM SAAS平台有好几家都是基于XMPP实现的,这个大家可以自行Google。

    MQTT

    MQTT是轻量级基于代理的发布/订阅的消息传输协议,它的最大特点就是协议开销非常小,伴随着的就是协议简单(40多页)、网络带宽要求极低和移动设备省电。有幸接触到该协议是笔者在开发Android推送系统时,对它进行了较细致的研究,虽然最终方案中没有使用该协议,但是自己定制的私有协议也参考了很多MQTT的设计。MQTT整个协议的组成,可以分为三个部分:

    固定头部:通用消息数据包格式
    可变头部:特定消息数据包格式
    消息体:有效载荷

    固定头部

    每个MQTT命令消息的消息头部都包含一个固定头部,固定头部的格式如下:

    [fixed header]

    Byte 1
    消息类型和标志字段

    Byte 2
    剩余长度字段(至少1个字节,最多4个字节),采用big-endian模式存储

    Message Type

    [mqtt-fixed-header-message1]

    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
    0:保留 1:客户端请求连接服务器 2:连接确认 3:发布消息 4:发布确认 5:发布接收(有保证的交付第1部分) 6:发布释放(有保证的交付第2部分) 7:发布完成(有保证的交付第3部分) 8:客户端订阅请求 9:订阅确认 10:客户端取消订阅请求 11:取消订阅确认 12:PING请求 13:PING回复 14:客户端断开连接 15:保留

    DUP(Duplicate delivery)

    保证消息可靠传输,默认为0,只占用一个bit,表示是否第一次发送,它不能用于检测消息重复发送。只适用于客户端或服务器端尝试重发PUBLISH, PUBREL, SUBSCRIBE 或 UNSUBSCRIBE消息,注意需要满足以下条件:

    1 2
    QoS > 0 即消息需要回复确认

    此时,在可变头部需要包含消息ID。当值为1时,表示当前消息先前已经被传送过。

    Qos(Quality of Service)

    该标志位标明 PUBLISH 消息的交付质量级别:

    [mqtt-fixed-header-message1]

    RETAIN

    仅针对PUBLISH消息。不同值,不同含义:

    1:表示发送的消息需要一直持久保存(不受服务器重启影响),不但要发送给当前的订阅者,并且以后新来的订阅了此Topic name的订阅者会马上得到推送。

    备注:新来乍到的订阅者,只会取出最新的一个RETAIN flag = 1的消息推送。

    0:仅仅为当前订阅者推送此消息。

    假如服务器收到一个空消息体(zero-length payload)、RETAIN = 1、已存在Topic name的PUBLISH消息,服务器可以删除掉对应的已被持久化的PUBLISH消息。

    Remaining Length

    这个字节包含当前消息的剩余部分,包括变量头部和负载的数据。

    可变长度的编码方式使用一个单独的字节使消息可以达到127字节的长度上限。协议限制最多4个字节,这样程序可以发送最大256M的消息。

    上面便是最核心的固定头部的内容,至于可变头部和消息体可以自己查询资料,目前有很多公司在使用MQTT实现Android的推送,但是目前笔者暂时不知道谁家的IM在使用它。

    私有协议

    一万人眼中就有一万个哈姆雷特,同样的一万人眼中就有一万个私有协议。应用场景、设计风格,都会导致协议的设计千奇百怪。例如:数据量传输大的场景,压缩方案可能也被设计到协议中,因为不同的环境可能用到不同的压缩方式;传输质量,我们可能就默认某一个级别,可能就从协议中移除,具体的设计得靠经验和应用场景来设计。

    架构

    做了好几个系统,我将我喜欢使用的一套架构抛出来供大家探讨。
    [mqtt-fixed-header-message1]

    CM-*:Connection Manager,可以分为WebSocket和Tcp两种承载方式。
    SM:Session Manager。
    Web:Rest接口,HTTP承载。历史消息,好友关系,个人信息管理等。

    一套很简单的架构,CM只负责链路的管理,链路和用户ID的关系维护在Redis中,SM负责业务逻辑和消息路由。CM和SM内部通过RPC调用,CM和SM内部全部采用事件驱动的方式,全部采用异步的方式。任何一个模块都可以水平扩展,并且SM如果达到非常复杂的地步,还可以拆分。最终的压力基本就到了Redis和Mysql,这些高可用和高并发的方案,已经非常成熟,就不用多说了。

    下图是登录流程和消息发送流程

    [login]

    [message]

    鉴于笔者经验,开发的IM最多承载用户数也就百万级别,所以架构上或者设计方案不一定完美,仅供参考!

    注意事项

    CM一定要采用多队列网卡,否者会出现服务器的一个CPU 100%,而别的CPU却很空闲,从而导致系统吞吐量上不去。因为单队列网卡的I/O中断都被分配到了一个CPU核上,大量数据包到来时,单个CPU核无法全部处理,导致LVS不断丢包连接中断。



  • 测试也不测试下图片,同样差评



  • @我本奈何
    测试文档 仅供参阅



  • 这么长 而且还不是原创 复制还偷懒不带图。
    差评!


 

Copyright © 2018 - 蜀ICP备17031673号-5