陌陌发展刚开始由于规模小，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协议来描述逻辑
Read Redis Command
基于队列的消息协议
基于队列的交互
传统的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%不准