微信、陌陌等著名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端连接层和逻辑层代码没有解耦分离，常常重启导致不可用；

文章插图

链接层：

文章插图

逻辑层：

文章插图

【微信、陌陌等著名IM软件设计架构详解】通讯协议设计：

文章插图

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

文章插图

文章插图

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

文章插图

1解决移动互联网开发常见问题：
通道：数据交互、大数据上传、push
网络连接：大量长链接管理、链接不上、慢、多地分布
运营支撑：海量监控、简化问题定位
登录&安全：登录鉴权、频率控制
移动互联网特点：
1、高延时：信道建立耗时（高RTT）
2、低宽带、高丢包
3、多运营商（电信，移动，联通等）