大型即时通讯系统微信、陌陌架构分析全记录！

最新推荐文章于 2024-04-11 11:02:48 发布

架构文摘

最新推荐文章于 2024-04-11 11:02:48 发布

阅读量2.3k

点赞数

原文链接： https://mp.weixin.qq.com/s/uaecXsCCZeCH5s_-UeC4xQ#rd

版权

点击蓝色“架构文摘”关注我哟

加个“星标”，每天上午 09:25，干货推送！

作者：肉眼品世界

出处：转载自微信公众号：肉眼品世界（ID：find_world_fine）

导读: 像QQ，微信，陌陌这样大的im,即时通讯量很大的，这个是长链接实现，一个长链接一个文件描述符，一台机器的长连接又有限，当然你可以一台机器划分成多个虚拟机，就让一台机器一个65535个的限制，一台机器的资源可以更好的得到复用，也可以调整一些内核参数快速释放一些同时一些wait状态的socket fd;单台机器达到物理上限，自然少不了分布式。

对微信、陌陌等进行了分析的一些资料的分析，发出来分享一下。

电量：对于移动设备最大的瓶颈就是电量了。因为用户不可能随时携带电源，充电宝。所以必须考虑到电量问题。那就要检查我们工程是不是有后台运行，心跳包发送时间是不是合理。

流量：对于好多国内大部分屌丝用户来说可能还是包月100M，现在4g，5g了虽然很多用户好几个g，在那个3g的时代，屌丝们还是很节约的，那么我们必须站在广大用户角度来考虑问题了。一个包可以解决的就一个包。

网络：

这个也是IM最核心的内容了，我们要做到在任何网络下等顺畅聊天那就不容易了，好多公司都用的xmpp框架，如果在强网络环境下，xmpp完全没有问题。但是那种弱网络环境下xmpp就束手无策啦，用户体验就很垃圾了。

个人觉得xmpp 可以玩玩，但是用来真正的产品就差远了。如果遇到一个做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不可以赚钱，但没有却是不行的，就像一个地方要致富，不修路是不行的道理一样。

上面说到了protobuf ，就简单介绍下：

JSON相信大家都知道是什么东西，如果不知道，那可就真的OUT了，GOOGLE一下去。这里就不介绍啥的了。

Protobuffer大家估计就很少听说了，但如果说到是GOOGLE搞的，相信大家都会有兴趣去试一下，毕竟GOOGLE出口，多属精品。

Protobuffer是一个类似JSON的一个传输协议，其实也不能说是协议，只是一个数据传输的东西罢了。

那它跟JSON有什么区别呢？

跨语言，这是它的一个优点。它自带了一个编译器，protoc，只需要用它进行编译，可以编译成JAVA、python、C++代码，暂时只有这三个，其他就暂时不要想了，然后就可以直接使用，不需要再写任何其他代码。连解析的那些都已经自带有的。JSON当然也是跨语言的，但这个跨语言是建立在编写代码的基础上。

陌陌设计：

陌陌发展刚开始由于规模小，30-40W的连接数（包括Android后台长连接用户），也使用XMPP；由于XMPP的缺点：流量大（基于XML），不可靠（为传统固定网络设计，没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景），交互复杂（登陆需5-6次，尤其是TLS握手）；XMPP丢消息的根本原因：服务端和客户端处于“半关闭”状态，客户端假连接状态，服务端有收不到回执；Server端连接层和逻辑层代码没有解耦分离，常常重启导致不可用；

消息中转：

连接层：

逻辑层：

通讯协议设计：

高效：弱网络快速的收发

可靠：不会丢消息

易于扩展

协议格式：

Redis协议：

优化

连接层（参见通讯服务器组成）：只做消息转发，允许随时重启更新，设计原则简单/异步；单台压测试连接数70W；现状：1.5亿用户，月活5000W+，连接数1200W+；
逻辑层（参见通讯服务器组成）：用户会话验证即登陆、消息存取、异步队列
采用私有通讯协议，目标：高效，弱网络快速收发；可靠：不会丢消息；易于扩展；参考协议格式：REDIS协议；参见协议格式、基于队列的消息协议、基于队列的交互、基于版本号的消息协议、基于版本号的交互等；
核心的长连接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP连接；一切就绪后，最重要的就是监控，写一个APP查看所有的运营状态，每天观察；
如何选择最优路线，即智能路由；

二、智能路由、连接策略：

多端口、双协议支持

应对移动网关代理的端口限制