目录
放弃使用XMPP
陌陌发展刚开始由于规模小，30-40W的连接数（包括Android后台长连接用户），也使用XMPP；由于XMPP的缺点：
- 流量大（基于XML）
- 不可靠（为传统固定网络设计，没有考虑WIFI/2G/3G/地铁/电梯等复杂网络场景），交互复杂（登陆需5-6次，尤其是TLS握手）
- XMPP丢消息：服务端和客户端处于“半关闭”状态，客户端假连接状态，服务端有收不到回执；
- Server端连接层和逻辑层代码没有解耦分离，常常重启导致不可用。
陌陌的系统架构
消息中转：
连接层（Connector链接集群）
- 连接层的作用：只做消息转发
- 设计原则简单/异步
- 允许随时重启更新/只允许晚上重启/不允许重启断线
- 单台压测试连接数70W；现状：5亿用户，月活5000W+，连接数1200W+；
逻辑层（Logic逻辑集群）
- 用户会话验证
- 消息存取
- 异步队列
- 随时重启
通讯协议设计：
- 安全性要求
- 流量要求
- 传输要求可靠（不会丢消息）
- 高效（弱网络快速的收发）
- 易于扩展
陌陌的通讯协议
常见协议XMPP/SIP，主要缺点：流量大，不可靠，交互复杂
陌陌采用私有通讯协议，目标：
- 高效，弱网络快速收发
- 可靠,不会丢消息
- 易于扩展
- 参考协议格式：REDIS协议
Redis协议
下面都是用Redis协议来描述逻辑
基于队列的消息协议
基于队列的交互
- 传统的IM协议
- 前提是基于网线、WiFI，网络延迟极小
- 移动网络下，交互及其费时，服务器要维护每个状态容易出错
基于版本号的消息协议
基于版本号的交互
针对弱网络的优化协议
- 消息通过版本号维护顺序
- 新消息到达，Server只负责push通知
- Client收到轻量的msg-psh后发生同步请求
- Server按照版本号连续发送msg
- Client告诉Server收到的最后的版本
监控
- 核心的长连接只用于传输轻量的实时数据，图片、语音等都开新的TCP或HTTP连接
- 一切就绪后，最重要的就是监控，写一个APP查看所有的运营状态，每天观察
如何选择最优路线智能路由、连接策略：
- 多端口、双协议支持，应对移动网关代理的端口限制
- 支持TCP、HTTP两种协议
- 根据备选IP列表进行并发测速（IP+端口+协议）
- 后端根据终端连接情况，定时更新终端的备选IP列表
- 终端在连接空闲时上报测速数据，便于后端决策
- TCP协议不通，自动切换到http
- 优先使用最近可用IP
- 并发测速，根据终端所处的位置下发多组IP、PORT，只用IP，不用域名，手机上的DNS50%不准
参考资料：
