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

来源:https://blog . csdn . net/justinjing 0612/article/details/38322353

我们分析了微信、陌陌等。，并把它们发出去分享(已经很久了)。

电源:移动设备最大的瓶颈是电源。因为用户不能随时携带电源和充电宝。因此，必须考虑电源问题。需要检查我们的项目是否在后台运行，心跳包的发送时间是否合理。

流量:对于很多国内用户来说，可能还是每月30M，所以一定要从广大用户的角度考虑问题。一个包只能解决一个包。

网络:这也是IM的核心内容。对于我们来说，在任何网络下等待顺畅的聊天都不是一件容易的事情。很多公司使用xmpp框架。如果是在强大的网络环境下，xmpp完全没有问题。但是xmpp在那种弱的网络环境下什么都做不了，用户体验很垃圾。

个人觉得xmpp可以拿来玩玩(参考RFC3920和RFC3921)，但远没有被当做真货使用。如果你遇到一个正在做IM的朋友，一直在说xmpp，那就不需要交流了。肯定不是好产品。微信和QQ之前都用过xmpp，但是最后放弃了xmpp，说明xmpp有很多缺点，消息太大，臃肿浪费流量。为了保证稳定性，微信采用长链接和短链接相结合的方式，例如:

1.两个域名

微信分为http模式(短链接)和tcp模式(长链接)，分别处理状态协议和数据传输协议。

short . weixin . QQ . comdnscheck(112 . 64 . 237 . 186112 . 64 . 200 . 240)

long . weixin . QQ . comdnscheck(112 . 64 . 237 . 188112 . 64 . 200 . 218)

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/micro msg-bin/auth HTTP/1.1

接受:**

用户代理:Mozilla/4.0

内容类型:应用程序

主持人:short.weixin.qq.com

内容-长度:174

3.3消息同步(新闻同步)

POST/CGI-bin/micro msg-bin/newsync HTTP/1.1

主持人:short.weixin.qq.com

用户代理:安卓QQMail HTTP客户端

缓存控制:无缓存

连接:保持活力

内容类型:应用程序/八位字节流

接受:**

内容-长度:206

3.5用户注销

POST/CGI-bin/micro msg-bin/iphone unreg HTTP/1.1

接受:*/*

用户代理:Mozilla/4.0

内容类型:应用程序

主持人:short.weixin.qq.com

内容-长度:271

3.6行为日志报告

POST /cgi-bin/stackreport？版本= 240000a7 & ampfilelength=1258&。sum = 7ed a 777 ee 26 a 76 a5 c 93 b 233 eed 504 c7d & amp；reporttype = 1 & ampusername=jolestar HTTP/1.1

内容-长度:736

内容类型:二进制/八进制流

主持人:weixin.qq.com

连接:保持活力

用户代理:Apache-Http client/INavailable(Java 1.4)

从目前互联网的发展来看，IM和视频(包括IM中的视频通话)是同一个方向，应该成为互联网的基础设施，就像浏览器一样。目前IM没有很好的解决方案，XMPP无法独立做业务逻辑。从IM的本质来说，IM其实是把一个消息从一个地方传到另一个地方，和TCP很像。为什么不实现一个高级别的TCP协议，而是用类似XMPP的唯一ID替换TCP/IP中的IP地址，还有很多其他细节可以从TCP协议中复制。使用这个协议，业务逻辑基于现有的HTTP服务器。比如发送语音和图片相当于上传一个文件，服务器在处理完文件后发送一个特殊的IM消息。客户端收到IM消息后，会根据IM消息中的url，前往HTTP服务器获取语音文件和图片文件。连接HTTP服务器和IM服务器后，很多事情都可以做。但把这两个服务器合并在一起并不是什么好事，否则腾讯不会有2005年的战略转型。从目前的情况来看，应用除了游戏赚不了多少钱，现在能承载赚钱业务的主要还是web。IM赚不到钱，但是离不开，就像一个地方不修路就发不了财一样。

协议:

除了上面介绍的XMPP，还有json和Protobuf。

JSON相信大家都知道是什么东西，如果不知道，那可就真的OUT了，GOOGLE一下去。这里就不介绍啥的了。Protobuffer是一个类似JSON的一个传输协议，其实也不能说是协议，只是一个数据传输的东西罢了。

JSON和JSON有什么区别？

跨语言，这是它的优势之一。它自带编译器protocol，可以编译成JAVA，python，C++代码。暂时只有这三个代码，其他的就先不要想了，然后就可以直接用了，不用写其他任何代码。甚至那些被分析过的也已经随之而来了。JSON当然是跨语言的，但是这种跨语言是基于编码的。

莫莫设计

在Momo开发之初，由于规模较小，30-40W连接(包括安卓后台长连接用户)也使用XMPP；由于XMPP的缺点:流量大(基于XML)、不可靠(针对传统固定网络设计，没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景)、交互复杂(登录需要5-6次，尤其是TLS握手)；XMPP消息丢失的根本原因:服务器和客户端处于“半封闭”状态，客户端处于虚假连接状态，服务器无法收到回执；服务器端连接层和逻辑层代码没有解耦分离，往往会因为重启导致不可用。

消息中继:

连接层:

逻辑层:

通信协议设计:

协议设计要求:

高效：弱网络快速的收发可靠：不会丢消息易于扩展协议格式：

XMPP/SIP协议

Redis协议:

优化

连接层（参见通讯服务器组成）：只做消息转发，允许随时重启更新，设计原则简单/异步；单台压测试连接数70W；现状：1.5亿用户，月活5000W+，连接数1200W+；逻辑层（参见通讯服务器组成）：用户会话验证即登陆、消息存取、异步队列采用私有通讯协议，目标：高效，弱网络快速收发；可靠：不会丢消息；易于扩展；参考协议格式：REDIS协议；参见协议格式、基于队列的消息协议、基于队列的交互、基于版本号的消息协议、基于版本号的交互等；核心的长连接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP连接；

一切准备就绪后，最重要的是监控，写一个APP检查所有的运行状态，每天观察。

如何选择最优路线，即智能路由。

二、智能路由和连接策略

多端口、双协议支持应对移动网关代理的端口限制支持TCP、HTTP两种协议根据备选IP列表进行并发测速（IP+端口+协议）后端根据终端连接情况，定时更新终端的备选IP列表终端在连接空闲时上报测速数据，便于后端决策TCP协议不通，自动切换到http优先使用最近可用IP并发测速，根据终端所处的位置下发多组IP、PORT，只用IP，不用域名手机上的DNS50%不准负载均衡器(LVS...)的问题– 单点失效单点性能瓶颈负载均衡从客户端开始做起• 域名负载的问题域名系统不可靠– 更新延迟大

WNS(无线网络服务)

1解决移动互联网发展中的常见问题:

渠道:数据交互、大数据上传、推送

网络连接:管理大量长链接，链接不可用，速度慢，分布在很多地方

运营支持:大规模监控和简化问题定位

登录&:安全性:登录身份验证和频率控制

移动互联网的特点:

1.高延迟:建立通道需要时间(高RTT)

2.低宽带高丢包

3.多运营商(电信、移动、联通等。)

4.复杂网络

-2G，3G，4G，wifi .cmwap，cmnet .。

-网关限制:协议、端口

5.用户流动性高，互联网环境复杂

WNS绩效指标:

1.开发时间:历史一年半

2.链接成功率-99.9%

3.极端网络环境下的成功率——由于普通应用

4.崩溃率-0.02%(崩溃次数/登录用户)

微信后台系统架构

背景:

一、分布式问题的收敛性

后台逻辑模块以逻辑为主，发展较快

读取过时的数据可能是一个痛点

需要看到一致的数据

b、内部定义

数据有两个以上的副本

如果更改成功提交，旧数据将不会返回

扣除:

1添加数据

2序列号生成器，部分序列

约束:只能有一个客户端操作

客户有能力解决冲突

问题转移:如何分发客户端？

3修改集群中某个键的值

1)掩护他

2)根据值的内容进行修改

如果值=1，则值:=2

一般解决方案:

1)paxos算法

工程难度

一切都是可控的

分布式算法设计:

2)法定算法(2011)

然后操作一个键

这是一个系统约束

类似Paxos的方案，简化

每次变更的选择(按键)

算法过程

提议/改变/同步/广播

系统结构

写过程

复制和。碎片

称重点

自主、负载平衡、扩散控制

复制->;关系

容灾偏移

同一城市(上海)的大多数人幸存了下来

三园(独立供电，独立)

碎片

一组KV6是一个单元

1.手动阶段

局部扩张，影响收敛9

2.均匀分布，制作分段hash32(字符串)

双重扩张

3一致性哈希

具体实现？

1.业务面快速发展

存储需要提供强大的一致性

丰富的数据模型支持(结构化、类似于SQL千伏)

条件阅读，条件写作

2业务增长迅速，系统应该可以方便的横向扩展

3设备故障/短期节点有效性成为常态，容灾自动化，主碑无需人工干预即可书写

4个小数据

存储模型

纯记忆

比特卡什

小桌系统

LSM树

小桌系统

1、解决放大问题

2.数据根据变化进行聚合存储

3、受影响1

ChangeTable

(1+2+。。。。+n-1+总计)/n

4.拆分和合并

数据流

1.自动迁移

2.节点同时充当代理

3.合并磁盘io

同步流量

1.数据与操作

2.幂等的

3.保证策略

通信包数量

1.动态合并

100K qps

200%-10%

3.权衡和估计

设计要点

1.吞吐量

2.非同步化

3.复杂

4、libco

自动修理系统

1.不要让错误累积

2.全扫描

比特桶的一些变化

1.存储容量极限

2.全部记忆