微信、陌陌等 交App，前后台整体架构设计实践分享，25页PPT

点击“技术领导力”关注?  每天早上8:30推送

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

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

消息中转：

逻辑层：

高效：弱 络快速的收发

可靠：不会丢消息

易于扩展

协议格式：

优化

• 连接层（参见通讯服务器组成）：只做消息转发，允许随时重启更新，设计原则简单/异步；单台压测试连接数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）

写流程

存储模型

纯内存

Bitcask

小表系统

LSM－tree

 -END- 

席位珍贵，至于老K加不加你，随缘吧！