有很多朋友的项目需要用到即时通讯，几年前鄙人的项目也是如此，当年没有选择，只能自建了IM服务器，几年下来跨了不少的坑，想想都甚是后怕。总结此文为后来还想自建IM的朋友提个醒，或许能找到更好的解决之路。
1, 如何应对大并发量连接
自己组建IM服务器，总是要面对大并发量连接的，有些朋友可能会说，我们用户不多，不需要考虑这个问题，但至少应该将用户控制在一个数量以内，不要让意外增加的用户影响到现有的用户吧。那么一台服务器可以支撑多少连接？又可以支撑多少用户同时发消息？
如果需要多台服务器做集群？需要怎么做？架构又是如何的？
这些课题绝对不是几个人短时间就能解决的。开发者需要根据项目的具体情况严谨地评估是否可以处理这些问题。
2, 为什么总是莫名地断线呢？
一般自建IM服务器都会使用现成的openfire等现成的开源部署，经过不少时间部署测试后正常运作。但一到了移动端这种网络相当不稳定的环境后总是会出现各种各样的奇怪问题，费尽力气才发现原来是连接不稳定，经常断线导致的。
那么又如何来解决这个问题呢？
办法不是没有，只是相当繁琐。需要很长一段时间的评估测试才能解决，甚至会更改原来的一些功能设计。
如果你没有精通开源库的专家，要想短时间解决这些问题除了花大量时间之外就是使用其它方式巧妙避开它。
3, 为什么总是会丢消息？
丢消息是自建IM服务器常遇到的问题,要解决这个问题也不容易。
移动端的丢消息大概是这个样子。A和B通讯，A发了一条消息给服务器，服务器发给B，但是B网络不好掉线了，而服务器却不知道B退出了（B正常退出会给服务器发下线通知），所以消息丢失了。XMPP中有xep-0184协议（消息回执），A给B发消息，消息体中带一行代码（要求消息回执），当B收到消息后发送一条回执，证明我收到了。后来XMPP又有了xep-0198协议（流管理），断线后快速重链，同时判断一定时间收不到消息，就把消息写离线消息，减少丢消息情况。但是可能网络情况复杂，加上各种不确定因素，还会出现丢消息的问题。
目前比较靠谱的方法就是存所有的聊天记录，由手机端根据时间点去数据库拉消息，只要别人发出的消息就不会丢。这要对即时通讯模块进行了相关改动，同时需要注意消息的顺序，拉消息时也尽可能只拉取需要的消息，这时需要一个较好的完整同步机制，这个机制推荐参考yun2win的同步机制http://console.yun2win.com/docs/server.html。
这里需要花费多少时间成本，可以感受一下。
这里只是列出了比较常出现的几个问题，自建IM服务器成本不小，不管是硬件成本还是开发成本以及运营风险上。评估自己项目是否需要自建IM服务器一般是以下几种情况：
1，拥有自主的即时通讯技术的情况下
2，项目保密性很高，需要绝对保证数据安全
不好意思，在现在PAAS盛行的时代我还真无法想出更多需要自建IM的理由了，以上两点貌似看上对比较立得住脚。
其它第2点提到的数据安全现在好像也不能算是自建IM的理由了，因为市面上已经出现数据和通讯分开物理隔离的即时通讯云，可以百度下yun2win。
总之，自建IM之路坎坷，君请三思而行。