有过几款IM系统开发经历，目前有一款还在线上跑着。准备简单地介绍一下大型商业应用的IM系统的架构。设计这种架构比较重要的一点是低耦合，把整个系统设计成多个相互分离的子系统。我把整个系统分成下面几个部分：（1）状态消息系统 （2）好友系统 （3）P2P系统 （4）其他扩展业务系统
先看状态消息系统
connd
client接入服务器，可以支持UDP，也可以支持TCP，一般建议优先选择TCP。connd可以布置多台，client接入时，可以用简单的DNS轮询的方式实现负载均衡。connd功能是维护连接和转发消息包。
pconnd
proxy connd, 代理接入服务器，是connd的扩展，除了有connd的功能外，支持服务器的接入，比如web server。
msgd
消息处理服务器，主要功能是用户状态管理，消息转发(包括合理性验证)以及离线消息保存。
说一个用户登录成功后，对所有好友的状态通知过程。我设计的系统中，把用户状态也简单看成类似文本聊天消息。下面用户U的上线过程，他有好友F1, F2。
(1) connd收到U上线消息，将消息发给U所在的msgd。
(2) msgd获取U的好友，F1, F2；如果F1, F2和U不在同一个msgd上，msgd将消息通过connd转给F1, F2所在的msgd。
(3) 最终的msgd把上线通知通过connd发给F1, F2。
msgd的U是通过什么方式获取最新的好友呢？ 这个问题我要着重描述一下。
用户的好友数据都在另外一个子系统中：好友子系统。 msgd通过TCP的方式（为什么用TCP呢？）主动从好友系统获取。同时，msgd也缓存一份好友数据。msgd获取用户好友时，如果cache是最新的，直接从cache取，否则要从好友子系统那边取。现在重点问题出来了，如何确定用户的好友是最新的？这类问题我们要根据不同的业务不同的特点灵活采用不同的方法。请看一种高效的处理方式：
(1) 好友子系统为每个用户的好友算个hash值（可以用MD5）。
(2) client获取好友时，同时也拿到这个hash值；发和好友相关的消息时，把hash值带给msgd。
(3) msgd第一次从好友子系统获取某个用户好友时，也获取这个hash值；像要转发状态消息，获取好友时，把client带过来的hash1和自身的hash2比较一下。。。
像IM这种业务特点是，对好友数据的写很少，读很多，相对于读的消耗，写基本可以忽略的。用上面的方法，基本上每次两者的hash值是相等的，直接从cache拿好友数据。这种处理方法也可以引入到其他应用业务中。建议不要每次都粗暴地跨进程获取类似好友数据。
好了，上面是对IM系统状态消息子系统的简单介绍。
另外，像好友子系统就很简洁，启几个tcp接入server，根据不同用户，去不同的好友逻辑服务器上取好友。好友逻辑服务器，可以考虑采用LRU淘汰算法(发现老用这种算法)。如果你很有钱，也可以对好友数据做全cache，不用淘汰。
P2P系统和网上介绍的架构都差不多，大家搜一把吧。
