一、面临的挑战
1.1 极致的业务特性
（1）流畅的消息收发
（2）及时的通知
（3）省电
（4）省流量
（5）瘦客户端
1.2 困难的后台-终端同步
（1）同步多样数据：账户信息、通讯录、消息、朋友圈等
（2）及时通知与同步
（3）移动网络下的可靠同步
（4）省流量与电量
二、架构方案
2.1 极简的同步协议
（1）后台与终端只需要沟通一个数字，后台即可知道终端缺失的所有数据。
（2）变更序列号/版本号：-后台对用户数据的每项变更，都赋予一个单调递增的序列号，即用户的每项数据都有 一个全局递增序列号。-后台每次给终端发送数据都会带上所发送的所有数据的最大序列号。-终端每次请求数据时都会带上已经接受到的最大序列号。
2.2 高效的通知机制
（1）ios Apple Push Network Service
（2）Android等-长连接
（3）GPRS/EDGE信令风暴优化
（4）自适应心跳间隔调节
2.3 三层后台架构
2.4 统一的RPC框架
根据ProtocolBuffer定义生成服务器框架和客户端：
服务器：开发人员填充接口实现
客户端：应用方本地调用客户端提供的接口函数
屏蔽网络细节：
支持基于TCP/UDP的网络调用
支持长短连接
丰富的功能：
基于sharding的SET分布
基于一致性哈希的无状态存储
服务透明重定向
丰富的自动化监控：
(1)QPS；
(2)响应时间；
(3)排队时间；
(4)各个接口的调用频率与返回状态码分布；
(5)各个服务之间的调用拓扑
2.5 高并发的协程RPC
服务器同步的调用模型相较异步模型更容易学习、使用和调错。但一台服务器支撑的进程数和线程数是非常有限的。
基于用户态线程（协程）的RPC：
单机可以支撑数万甚至十万的用户态线程，仅受CPU和内存约束
提高并发性和性能
用户态线程RPC的实现：
基于makecontext/getcontext/swapcontext
Hook Network: read/write/epoll
用户态线程调度
2.6 就近访问
（1）就近访问IDC
（2）就近网络接入：覆盖各大运营商
（3）CDN：上传下载图片
2.7 多IDC分布提升用户体验
（1）国内复杂的网络环境
（2）超过1亿的海外用户-分布在全球-更为多样化的网络环境
（3）每个IDC都提供完整的功能和所需访问的所有数据
（4）每个IDC有共同的数据和独立数据-账户信息全球一致-用户数据各自独立：(1)一个用户只属于某个IDC；
(2)用户属性、关系链、消息；
(3)按需共享的SNS数据-照片、评论、红心，减少网络同步带宽消耗
2.8 IDC分布数据的高可靠最终一致性保证
（1）账户数据和SNS数据主备访问模型-用户所在的IDC是主IDC-其他IDC相对这个用户所在IDC都是备IDC-更新由主扩散到备
（2）弱实时性跨IDC更新采用基于Zookeeper仲裁的主备任务队列-收拢跨IDC访问接口-重做保证跨IDC更新的可靠性-数据序列号在重做时保证达到最终一致性
（3）关系链跨IDC更新-隐私控制要求实时性-直接跨IDC网络调用-后台批处理重试失败请求
2.9 容错和容灾机制
（1）单IDC-用户按SET分布，各个SET之间独立（2）高可用的异地容灾-每个服务的主IDC都有一个灾备IDC-挑战：终端在主备IDC切换时的无缝连接；主备间的数据一致性
