漫谈IM通信架构.docxVIP

PAGE 1 PAGE 1 漫谈IM通信架构  前前后后做的IM和推送系统已经有好几个了，一直都想好好总结下，因此就有了这篇文章。在我刚学编程的那会儿，觉得网络通信是一个很牛逼和门槛很高的一门技术，但是随着开源技术的发展和互联网学问的共享，现在要写出高质量的网络通信程序已经变得简单多了。  前前后后做的IM和推送系统已经有好几个了，一直都想好好总结下，因此就有了这篇文章。在我刚学编程的那会儿，觉得网络通信是一个很牛逼和门槛很高的一门技术，但是随着开源技术的发展和互联网学问的共享，现在要写出高质量的网络通信程序已经变得简单多了。  只要谈通讯确定绕不开协议，鉴于本人经验下面只谈本人撸过的三种协议：  ·XMPP  ·MQTT  ·私有协议  XMPP  XMPP(ExtensibleMessagingandPresenceProtocol)，也叫Jabber，它是基于稳定长连接网络环境所设计的，对于不够稳定和带宽小的移动网络不是特别合适。由于XMPP基于XML，所以流量大，流量问题对于移动网络来说特别敏感，然后就是消息不牢靠、CMWAP兼容、开源项目对协议实现不完善等问题，也是XMPP面临的问题。当然XML可以通过精简压缩来实现流量可控，目前这也是XMPP优化的可行方案，消息的不牢靠可以通过扩展XMPP来实现ACK，随着3/4G的发展，CMWAP网关究竟是末日黄花，但是开源项目对协议只是部分实现等问题，也是使用XMPP绕不过去的坎。Openfire是XMPP领域最知名的开源项目，它简洁易用，是许多团队的首选方案，这是国内使用最多的开源方案。Openfire虽然优点许多，但是缺点也不少，最致命的就是它的分布式扩展能力很弱，当用户量很大的时候，水平扩展就成为它的瓶颈所在。还有一个不得不提的项目就是Tigase，这是笔者接触的第一个XMPP开源项目，它在分布式扩展能力上和架构设计上比Openfire强了不少。由于该项目开始是一个私人项目，现在似乎在商业化，所以使用者并不是许多，虽然国外有成熟案例，但是国内目前并不多，所以当时趟了Tigase的许多坑，目前平安好医生的谈天系统就是基于此搭建的。假如对Tigase感兴趣，可以阅读我之前写的一篇文章《Tigase集群方案及配置说明文档》。不论使用哪个开源项目，虽然看起来开箱即用，但是要成为稳定成熟的产品，还需要深度的二次开发才行。  虽然XMPP有许多弊端，但是它的生态目前是最完善的，假如从成本角度来考量，XMPP是前期投入最小产出最快的。但是假如是搭建一个SAAS平台或者千万量级的IM，XMPP就不是最优的选择了。当然这是一家之言，国外目前商业化的IMSAAS平台有好几家都是基于XMPP实现的，这个大家可以自行Google。  MQTT  MQTT是轻量级基于代理的发布/订阅的消息传输协议，它的最大特点就是协议开销特别小，伴随着的就是协议简洁（40多页）、网络带宽要求极低和移动设备省电。有幸接触到该协议是笔者在开发Android推送系统时，对它进行了较细致的研究，虽然最终方案中没有使用该协议，但是自己定制的私有协议也参考了许多MQTT的设计。MQTT整个协议的组成，可以分为三个部分：  1.固定头部：通用消息数据包格式  2.可变头部：特定消息数据包格式  3.消息体：有效载荷  固定头部  每个MQTT命令消息的消息头部都包含一个固定头部，固定头部的格式如下：  漫谈IM通信架构 图1固定头部的格式 Byte1  消息类型和标志字段  Byte2  剩余长度字段（至少1个字节，最多4个字节），采用big-endian模式存储  MessageType 图2MessageType 0：保留1：客户端恳求连接服务器2：连接确认3：发布消息4：发布确认5：发布接收（有保证的交付第1部分）6：发布释放（有保证的交付第2部分）7：发布完成（有保证的交付第3部分）8：客户端订阅恳求9：订阅确认10：客户端取消订阅恳求11：取消订阅确认12：PING恳求13：PING回复14：客户端断开连接15：保留  DUP(Duplicatedelivery)  保证消息牢靠传输，默认为0，只占用一个bit，表示是否第一次发送，它不能用于检测消息重复发送。只适用于客户端或服务器端尝试重发PUBLISH，PUBREL，SUBSCRIBE或UNSUBSCRIBE消息，留意需要满意以下条件：  QoS0即消息需要回复确认  此时，在可变头部需要包含消息ID。当值为1时，表示当前消息从前已经