移动IM开源框架对比

最近在看移动IM相关的资料, 然后发现网上有很多的资料,所以在学习过程中,整理了一些笔记, 供那些 想了解 移动IM的童鞋一些参考。

移动IM技术选型要点

1、协议选型
2、IM 服务器选型
3、协议和IM服务器改造
4、移动IM常见问题以及一些解决方案 
5、一些第三方服务

一、常用的IM协议

二、IM 服务器的选择

经过这几天在网上的调研, 发现目前比较流行的几个IM 服务器 也就是 Openfire、Tigase, Ejabberd:

备注: 
详解Zoosk千万用户实时通信背后的开源技术

三、XMPP协议的问题及改进

1、登录握手部分改进

Xmpp QuickStart

2、心跳改进

原先Xmpp使用的Ping/Pong 40+字节, 改进为单向 white space ping, 4字节。

备注: 心跳单向四个字节,在Xmpp协议下,估计应该是极限了吧。在私有协议协议下,一来一往两个字节足够。

3、文件传输
- Xmpp 的文件传输采用的点对点的传输; 改进为http 上传到server

- 语音、视频压缩上传

- 图片默认下载缩略图

4、Presense

移动互联网环境下,不管用户是否在线, 都会假设 用户永远在线。

这是因为移动网络环境导致, 比如从wifi 切换到 3G、处于地铁、WIFI边缘地带等, 如果还采用PC端 类似QQ那种方式, 很可能会造成重连风暴。

5、Muc 聊天室

Muc 是聊天室协议,在业务层面进行改进, 发送消息时 发送给所有用户,不管他在不在线

四、基于Openfire 服务器的改进

1、发送消息回执

在server端维护一个消息队列, 当收到client发送会的消息回执时, 将这个消息删掉

2、性能改进

不要使用内置的数据库, 对于Vcard或者好友列表信息 可以考虑放到Redis

3、如果是消息量很大的话, 消息存储可以使用Kafka(和数据库集群之间存定时拉取关系),分布式锁基于Zookeeper,前端LVS做负载均衡。

五、移动IM的那些坑点

1、长连接

android 平台 维护client 到server的长连接

IM或推送,建立长连接是必须的,可以节省TCP来回创建的开销,但断线之后,是否需要即刻重连,尤其是处于地铁、WIFI边缘地带,可能会造成重连风暴,需要添加稍加延迟连接机制。

2、心跳包 GGSN

维护移动网GGSN

3、消息回执处理Ack

移动网络很容易丢包, 发送、接受应加入回执处理

4、语音、图片的收发优化

大数据拆分成多个包, 一个包大概10字节

六、第三方的IM服务

1、环信(个人感觉选他不错), 大概是从2013年4月创立, 到目前为止号称 有6000万注册用户, 有1000+ app使用

2、leancloud 2013 年 9 月发布以来,已经吸引了近万移动应用和开发者加入。

七、结论

如果说自己搭建一套IM框架的:
- 基本能用需要3个月
- 做的比较好需要9月到1年时间
- 做的像微信一样,那么需要2年时间

如果说基于现有的IM服务器搭建的话, 个人觉得 从IMserver性能以及后期维护和招人成本上来看, 应该是 Tigase > Openfire > Ejabberd

八、写在最后

如果你也对IM感兴趣的话,可以看一看 环信的一个讲座, 对应的ppt

当然了, 由于我本人接触IM 这块也不太久, 所以肯定会有一些遗漏, 欢迎大家提意见呀...

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页