极光推送-高并发大容量消息推送后台系统架构演进

•
• •
auto-scaling, HA, Failover, auto-sharding
Json，Memory-first Sync/async, sub-document
长连接调度中心
•
根据运营商，区域，应用， 负载，权值，动态调度 SDK 接入 支持接入模块动态上下线 提升 SDK 接入质量
自研替代开源
架构不是设计出来， 是演进出来
不要过早优化
能并行就不要串行
能异步就不要同步
推送后台 1.0
•
•
mysql 增加主从，读写分离
无 cache 层，数据直接读写 mysql
Mysql M
Mysql S
业务服务器 长连接服务器
•
长连接服务器保存所有在线数据
SDK
• • • •
极光推送是什么？
十万级在线到百万级在线
千万级用户在线 亿级用户在线
•
总结
1.0 架构难以支撑百万级在线推送
•
•
Amdahl's law
限流和快速失败
•
SDK 与外围模块增加限流机制
一定时间范围内：请求频率和请求数据量
•
快速失败
模块间请求数据包中包含时间戳，超过阈值，直接丢弃
告警监控
•
系统层
•
•
业务层
推送生命周期层
总结
高性能/低成本 快速迭代
大系统小做
高可用性
高可运维性
只使用验证过的开源组件 保持简单
• • •
在线用户达到百万级时，IO 瓶颈大量出现 数据读写占用 mysql 主从大量的 IO 基础类开发占用大量时间
•
CPU/网卡包量和流量/交换机流量等瓶颈
推送后台 2.0
• •
Mysql M Mysql M 在线状态 节点
Mysql S Mysql S
接入与业务服务器集群化 接入层与逻辑层分离
• •
多数据中心支持，用户数据同步最终一致性 定制化用户维度数据存储（标签/别名，活跃）
•
• • • •
SDK 和外围模块增加限流机制，fail-fast
核心数据存储服务化 并行化，协程 自研&&定制化开源组件 灰度上线
多数据中心
•
所有数据通过 MQ 同步，最终 一致性
Conn A Conn B Conn C
海量服务经验是长期积累的结果
月活用户
9.25亿
1.6亿同时 3000+
在线用户
服务器
覆盖超过 130 亿移动终端
每日千亿级服务请求 消息毫秒级送达
78.4万app 200亿条消息
注册用户超过
每日推送超过
7×24 服务
130亿
百亿级用户维度数据
技术团队经历了用户数
从0到百亿的整个过程，吸取了很多经验教训
高并发大容量消息推送 后台系统架构演进
极光JIGUANG
• • • •
极光推送是什么？
十万级在线到百万级在线
千万级用户在线 亿级用户在线
•
总结
极光推送是什么？
•
极光推送是一个产品
极光推送官网 ( http://www.jiguang.cn )
帮助开发者向用户传递消息
•
标签，别名，注册ID，分组推送，自动定时推送
• •
ICE
•
IceGrid
•
•
IceStorm
Glacier2
• • • •
极光推送是什么？
十万级在线到百万级在线
千万级用户在线 亿级用户在线
•
总结
2.0 架构难以支撑千万级在线推送
• • •
在线状态中心遇到单点性能瓶颈，一个节点难以存储所有在线状态数据 内网数据流量暴增 物理机上线周期长
•
•
• • •
增加独立在线状态节点
引入 ICE 框架，tcp --- RPC mysql 分库分表多实例 LocalCache
业务服务器
业务服务器
长连接服务器
长连接服务器
SDK
SDK
ICE
• •
Internet Communications Engine 中间件 有效利用带宽、内存, CPU, LBS, Failover, TCP, UDP, SSL, WebSocket AMI, AMD, 多线程 IDL （类似 protobuf）
•
业务逻辑实现 all in
接入不均衡，不支持动态调度策略
推送后台 3.0
• • • • • • • •
在线状态节点重构为多节点+分片+多副本架构，采用 ICE 封装服务接口 引入 RabbitMQ，请求数据消息化，模块间采用 MQ 交换数据 引入 Couchbase，Redis，业务与数据分离 引入 ES，解决用户多维度信息查询和存储 业务进程模块化，垂直/水平拆分业务模块，最小化原则 增加全局长连接调度中心 物理机 ---> KVM 业务监控
支持 Android, iOS, WinPhone 三大主流平台
极光推送是什么？
•
极光推送是一个平台
独立的第三方云推送平台 服务
78.4 万 app，高效稳定的毫秒级送达移动消息推送解决方案
总用户数超过
130 亿，覆盖 9.25 亿 Android 和 iOS 终端
200 亿条
日推送消息超过
高级用户提供 VIP 服务
路由层
业务服务器
业务服务器
•
ICE 存储服务
ICE 存储服务
•
•
db
pika
redis
并行
• •
引入 goroutine 用户态，相比线程切换代价小，理 论上一个进程可支持 routine 数据 量只受资源限制，同时执行 routine 受 cpu 数量限制 开启 100 个 goroutine 成本远远 小于开启 100 个 thread 的成本
IDC1
MQ IDC3 MQ
•
调度 App 到任意 IDC 提供服务
北京
Conn A Conn B Conn C
来自百度文库IDC2
深圳
标签/别名自研存储服务
• • •
存储用户标签/别名数据 基于 ICE, RabbitMQ, redis, pika, zk 支持按 key 或者 value 分片
•
• •
定制 redis 与 pika
AutoScale，Failover，AutoRecover Redis 实例 1000+, 存储数据 10+T
数据存储服务化
•
基于 ICE 框架，服务化，内 部逻辑对使用方透明
支持 redis，mysql，pika， etc... Autoscale，failover， AutoRecover 灰度上线
调度中心
Conn A Conn B
管理中心
SDK
Conn C
• •
北京
Conn A Conn B Conn C
健康检测 服务
深圳
系统层面优化
•
RSS
•
• •
BBR
cpu affinity NUMA
• • • •
极光推送是什么？
十万级在线到百万级在线
千万级用户在线 亿级用户在线
•
总结
3.0 架构难以支撑亿级在线推送
为何选择 RabbitMQ
•
请求异步化、模块间解耦
•
• • •
AMQP
HA, produce/Confirm, Consume/Ack， Flow Control 消息持久化， limited by disk + memory
Kafka 消费延迟
为何选择 Couchbase
•
多语言支持，兼容 memcached 协议
• • • • • •
单数据中心，不支持容灾
推送业务量越来越大，尤其节假日高峰期业务量十倍于平时 用户推送需求越来越复杂，需要存储海量复杂维度的用户数据 服务质量要求越来越高，系统可用性要求 99.9% 以上 开源组件自身处理能力瓶颈开始显现 服务器数量暴增，管理成本几何增长，单节点的效率亟待提升
推送后台 4.0