微信、陌陌IM软件设计架构详解

电量:对于移动设备最大的瓶颈就是电量了 。因为用户不可能随时携带电源 , 充电宝 。所以必须考虑到电量问题 。那就要检查我们工程是不是有后台运行 , 心跳包发送时间是不是合理 。
流量:对于好多国内大部分屌丝用户来说可能还是包月30M , 那么我们必须站在广大用户角度来考虑问题了 。一个包可以解决的就一个包 。

微信、陌陌IM软件设计架构详解

文章插图
 
网络:
这个也是IM最核心的内容了 , 我们要做到在任何网络下等顺畅聊天那就不容易了 , 好多公司都用的xmpp框架 , 如果在强网络环境下 , xmpp完全没有问题 。但是那种弱网络环境下xmpp就束手无策啦 , 用户体验就很垃圾了 。
个人觉得xmpp 可以玩玩(参考看这个RFC3920和RFC3921) ,  但是用来真正的产品就差远了 。如果遇到一个做IM 的朋友张口闭口都说xmpp 的话 , 那么不用沟通了 , 肯定不是什么好产品 。微信、QQ以前也曾用过xmpp , 但是最后也放弃了xmpp , 就知道xmpp有很多弊端了 , 还有就是报文太大 , 好臃肿 , 浪费流量 。为了保证稳定 , 微信用了长链接和短链接相结合 , 例如:
1 、两个域名
微信划分了http模式(short链接)和 tcp 模式(long 链接) , 分别应对状态协议和数据传输协议
long.weixin.qq.com DNS check (112.64.237.188 112.64.200.218)
short.weixin.qq.com dns check ( 112.64.237.186 112.64.200.240)
2 说明
2.1 short.weixin.qq.com
是HTTP协议扩展 , 运行8080 端口 , http body为二进制(protobuf) 。
主要用途(接口):
用户登录验证;
好友关系(获取 , 添加);
消息sync (newsync) , 自有sync机制;
获取用户图像;
用户注销;
行为日志上报 。
朋友圈发表刷新
2.2 long.weixin.qq.com
tcp 长连接 ,  端口为8080 , 类似微软activesync的二进制协议 。
主要用途(接口):
接受/发送文本消息;
接受/发送语音;
接受/发送图片;
接受/发送视频文件等 。
所有上面请求都是基于tcp长连接 。在发送图片和视频文件等时 , 分为两个请求;第一个请求是缩略图的方式 , 第二个请求是全数据的方式 。
2.2.1 数据报文方面
增量上传策略:
每次8k左右大小数据上传 , 服务器确认;在继续传输 。
图片上传:
先传缩略图 , 传文本消息 , 再传具体文件
下载:
先下载缩略图 ,  在下载原图
下载的时候 , 全部一次推送 。
3 附录
3.1 用户登录验证
POST /cgi-bin/micromsg-bin/auth HTTP/1.1
Accept: **
User-Agent: Mozilla/4.0
Content-Type: Application/x-www-form-urlencoded<
Host: short.weixin.qq.com
Content-Length: 174
3.3 消息sync (newsync)
POST /cgi-bin/micromsg-bin/newsync HTTP/1.1>
Host: short.weixin.qq.com
User-Agent: Android QQMail HTTP Client
Cache-Control: no-cache
Connection: Keep-Alive
Content-Type: application/octet-stream
accept: **
Content-Length: 206
3.5 用户注销
POST /cgi-bin/micromsg-bin/iphoneunreg HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0
Cotent-Type: application/x-www-form-urlencoded
Host: >short.weixin.qq.com
Content-Length: 271
3.6 行为日志上报
POST /cgi-bin/stackreport?version=240000a7&filelength=1258&sum=7eda777ee26a76a5c93b233eed504c7d&reporttype=1&username=jolestar HTTP/1.1
Content-Length: 736
Content-Type: binary/octet-stream
Host: weixin.qq.com
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (JAVA 1.4)
从现在互联网的发展而言 , IM和视频(包括IM里面视频通话)是一个方向 , 这些都应该成为互联网的基础设施 , 就像浏览器一样 。现在IM还没有一个很好的解决方案 , XMPP并不能很好地做到业务逻辑独立开来 。从IM的本质来看 , IM其实就是将一条消息从一个地方传输到另外一个地方 , 这个和TCP很像 , 为什么不实现一个高级点的TCP协议了 , 只是将TCP/IP里面的IP地址换成了一个类似XMPP的唯一ID而已 , 其他的很多细节都可以照搬TCP协议 。有了这个协议之后 , 将业务逻辑在现有HTTP server的基础上做 , 例如发送语音和图片就相当于上传一个文件 , 服务器在处理完这个文件后就发一条特殊的IM消息 。客户端收到这个IM消息后 , 按照IM消息里面url去HTTP server取语音文件和图片文件 。将HTTP server和IM server打通之后 , 可以做很多事情 。但将这个两个server合并在一块并不是一个好事 , 不然腾讯也不会有2005年的战略转型了 。从现在的情况来看 , 应用除了游戏 , 都没怎么赚钱 , 现在能够承载赚钱业务的还是以web为主 。IM不可以赚钱 , 但没有却是不行的 , 就像一个地方要致富 , 不修路是不行的道理一样 。


推荐阅读