《阿里PUSH实践之路》.pdf

ArchSummit 全球架构师峰会 深圳站2016 阿里推送发展之道 个人介绍 var me = { name: { “真名”:”朱中明”, “阿里花名”:”泽胤” }, experience:[ “淘宝无线早期员工之一，经历无线在淘宝（阿里）的从0到1”, “提出AGOO项目，近年主要负责推送产品” ] contact:[ “mail:”: edwardpro.zhu@, “linkedin:”:”/in/edward-zhu-9b350429”, “wechat”:”edwardpro” ] } 阿里推送背景 2012.8 ~2013 2014 2015~ 启动 协议1.0 协议2.0 协议3.0 AGOO 目前的运行状况 发送总量 30亿/DAY 15T/DAY 80W/S 数据处理 发送速度 概要 • 协议之路 • 保活之路 • 服务能力之路 协议之路 PUSH 协议 V1.0 • 基于Long-Polling概念 • 只具备下行能力，上行需要依靠 旁路 • 保活依靠服务端单向心跳包 • 数据包层面加密 • 问题： – 保活上无法主动感知，因此 需要定时强制断开 PUSH 协议 V2.0 • 协议改用SPDY协议 • 具备了真正的双向通道 • 去除了链路层的SSL提升效率 • 改进： – 协议的通达能力有所提升 – 双向协议使得上报不再使用旁路，减少了协议开销 • 问题： – 看起来只是1.0的加强版，只是在传输层面改用了SPDY PUSH 协议 V3.0 • 基于HTTP 2.0 • 实现分层协议，将应用层协议和传输层 分离 协议层 • 采用积极的双向保活 • 上下行改用自定义帧 • 实现链路和内容数据双层加密（消息体 本身进行了加密，如果是用户/别名纬 传输层 度消息会使用用户的随机值） • 消息和数据（RPC ）共享链路 协议选择的因素 QoS SOCKET OR HTTP 开发成本 Based PUSH场景下 无论是HTTP还是 我们是基 无论是上行还 SPDY在应用层面的 于NGINX 是下行都是小 设计都足够强大， 成熟的IO 包，Qos的意 使用Socket 的成本 模型开发 义不大反而会 无疑是非常高的 的，成本 增加协议字 相对低， 且性能表 现好 到达率提升