通讯服务通用架构方案
说起IM，从最早接触，应该是2010年，当时做的项目引入腾讯通，那是刚做软件一年，多是做一些OA、数据平台的工作，完全不理解IM和通信是什么东西，以为此生都不用搭理这些玩意，没想到却与它相伴了这么多年。。。。。。
从2011年开始因为公司需要，使用基于XMPP协议的Openfire来开发IM软件，直接就把人生带入了一个神奇的国度。
Openfire说起来做的非常复杂，又非常粗糙，留了很多没有做的模块，没经验的人很难入手。比如：
1 消息握手模块
经常会有人发现，Openfire的两个客户端，在网络不稳定的情况下，会丢失消息。起初我也不知道到底发生了什么，直到后来，在测试中发现，当你用连接上通讯服务器后，直接拔了路由器，wifi异常断开，客户端与Server没办法握手告知TCP断线的事情，所以你会在一段时间内，服务器认为你在线，而实际你离线。这种情况在地铁、快速移动切换网络基站的情况下也经常有复现。此时Openfire收到关于你的消息会直接推送给你，而你此时又因为没有网络收取不到，所以消息丢失。
解决办法：消息进行握手，每条消息发给客户端，都需要客户端回复回执，否则一直保存在服务器。
2 心跳机制
因为上述问题，所以就要经常清理那些失效客户端，保证客户端和服务器状态同步。
如每15s - 60s 客户端定时发送一个小型的msg给服务器，服务器收到后回复一个callback。
如果服务器120s内没有收取到任何消息，那么close Session。
Openfire说起来十分的复杂，他们实现了安全连接、好友关系，群聊，广播，集群，S to S内部通讯，Admin Page，还有一个扩展的ConnectManager外部系统用来做连接器等等。。因为这些功能都是自己做的，所以就不多介绍了，我只是比较了解源码，但是基本没有使用过。
后期因为Openfire过多复杂无用的逻辑和XMPP的冗长的协议代码，所以被迫抛弃。
========
而现在IM大概的开发架构模型可以这样描述
Connector -- 负责管理用户连接
类似Openfire的ConnectManager项目，负责TCP连接的管理和数据管道，将数据通过TCP、Queue、RPC等方式传递到后端系统。
维护Session状态、处理心跳、NIO操作、将客户端与后端的消息进行上下行的转发。
Router
能够接收Connector的消息，然后根据消息类型转发给专项负责的Server。
MsgServer、GroupServer等
处理完毕之后得到结果，返回给Connector，Connector返回给客户端，客户端确定处理完毕。
MsgServer等后端真正处理业务的服务
消息的解析，入库，推送
数据存储方面，可以选取redis作为未读消息数据库，读取速度快，处理方便，
消息持久化保存的话，可以选取hbase作为分布式持久化存储
所有的逻辑一定充分使用缓存，命中率不能低于95%，
大数据的IM系统对于速度的要求十分的苛刻，没人会等你3秒聊一次，而缓存的更新可以使用pub/sub来处理，不能有任何延迟，否则数据出错带来无法预料的结果。
分布式相关，可以使用代码无状态，公用数据的方式来解决。而必须在意的是，要保证所有用户的处理必须是thread safe的，简单来说可以让处理某个人逻辑的线程永远唯一。
有什么疑问或者想讨论的，可以联系QQ 123766134，欢迎IM相关人士一起参与优化讨论。贴一下自己的架构实现。
