移动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 这块也不太久，所以肯定会有一些遗漏，欢迎大家提意见呀...