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

 本文转载至 ：  http://blog.csdn.net/justinjing0612/article/details/38322353

感谢原文做者分享

 

 

对微信、陌陌等进行了分析，发出来分享一下（时间有些久了）

有兴趣的同窗能够加入群：369511307。

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

流量：对于好多国内大部分屌丝用户来讲可能仍是包月30M，那么咱们必须站在广大用户角度来考虑问题了。一个包能够解决的就一个包。

网络：

这个也是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协议：

 

 

 

 

 

 

 

 

 

是啊发

 

 

 

 

 

 

 

 

 

阿萨德发阿发a

 

 

 

 

优化

   链接层（参见通信服务器组成）：只作消息转发，容许随时重启更新，设计原则简单/异步；单台压测试链接数70W；现状：1.5亿用户，月活5000W+，链接数1200W+；
   逻辑层（参见通信服务器组成）：用户会话验证即登录、消息存取、异步队列
   采用私有通信协议，目标：高效，弱网络快速收发；可靠：不会丢消息；易于扩展；参考协议格式：REDIS协议；参见协议格式、基于队列的消息协议、基于队列的交互、基于版本号的消息协议、基于版本号的交互等；
   核心的长链接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP链接；
            一切就绪后，最重要的就是监控，写一个APP查看全部的运营状态，天天观察；
   如何选择最优路线，即智能路由；
2、智能路由、链接策略：
多端口、双协议支持
应对移动网关代理的端口限制
         支持TCP、HTTP两种协议
         根据备选IP列表进行并发测速（IP+端口+协议）
         后端根据终端链接状况，定时更新终端的备选IP列表
         终端在链接空闲时上报测速数据，便于后端决策
         TCP协议不通，自动切换到http
         优先使用最近可用IP
        并发测速，根据终端所处的位置下发多组IP、PORT，只用IP，不用域名，手机上的DNS50%不许

负载均衡器(LVS...)的问题– 单点失效

      单点性能瓶颈
      负载均衡从客户端开始作起• 域名负载的问题

      域名系统不可靠– 更新延迟大  

WNS（wireless network services）

1解决移动互联网开发常见问题：

通道：数据交互、大数据上传、push

网络链接：大量长连接管理、连接不上、慢、多地分布

运营支撑：海量监控、简化问题定位

登陆&安全：登陆鉴权、频率控制

 

移动互联网特色：

一、高延时：  信道创建耗时（ 高RTT）

二、低宽带、高丢包

三、多运营商（电信，移动，联通等）

四、复杂网络  

    －2G，3G，4G，wifi。cmwap，cmnet。。

    －网关限制：协议，端口

五、用户流动性大，上网环境复杂

 

WNS 性能指标：

 

一、开发时间：历史一年半

二、连接成功率－99.9%

三、极端网络环境下成功率－因为常见app

四、crash率 －0.02%（crash次数／登陆用户数）

 

微信后台系统架构

背景：

A、分布式问题收敛

  后台逻辑模块专一逻辑，快速开发

可能读取到过期的数据是个痛点

须要看到一致的数据

B、内部定义

  数据拥有两个以上的副本

若是成功提交了变动，那么不会再返回旧数据

推演：

1增长一个数据

2 序列号发生器，偏序

 约束：只能有一个client操做

client有解决冲突的能力

问题转移：client如何分布？

3 修改集群中一个制定的key的value

1）覆盖他

2）根据value的内容作修改

if value ＝ 1 then value ：＝2 

通用解法：

1）paxos算法

 工程难度

一切可控

 

分布式算法设计：

 2）quorum算法（2011）

再单个key上面运算

真是系统约束

类paxos方案，简化

为每次变动选举（by key）

算法过程

 提议／变动／同步／广播

 

系统架构

写流程

 

Replication & Sharding 

 权衡点

  自治，负载均衡，扩散控制

 replication－>relation

 

容灾抵消

同城（上海）多数派存活

三园区（独立供电，独立）

 

 

Sharding

 

一组KV6 为一个单位

 

一、人工阶段

 局部扩容，影响收敛9

2均匀分布 制定分段hash32 （string）

 翻倍扩容

 

3一致性哈希

具体实现？

一、业务侧快速开发

 存储须要提供强一致性

丰富的数据模型支持（结构化、类SQL／KV）

条件读，条件写

 

2 业务增加迅速，系统要可以方便的横向扩容

3设备故障／短时节点实效便成为常态，容灾自动化，主碑可写无需人工介入

4小数据

存储模型

 纯内存

Bitcask

小表系统

LSM－tree

 

 

小表系统

一、解决放大问题

二、数据按变动汇集存储

三、Affected1

   ChangeTable

（1＋2+。。。。＋n－1+total）／n

四、分裂与合并

数据流动

一、自动化迁移

二、节点同时作代理

三、合并磁盘io

 

同步流量

一、数据vs 操做

二、幂等

三、保底策略

 

通讯包量

 一、动态合并

    100K qps

    200% －10%

三、权衡与估算

设计要点

一、吞吐量

二、异步化

三、复杂度

四、libco

自动修复系统

一、不要让错误累计

二、全量扫描

bitcask 的一些变化

一、内存限制

二、全内存