移动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

来自: meegomeego