11. 11 大促,随着移动端业务量的急剧提升,像小米推送这样的基础服务也经受了巨大的考验。11 月 12 日,小米的项目总监汪轩然在微博上宣布,“小米推送服务共发出 9.65 亿条消息,平均每分钟发送 67 万条。更值得一提的是,后台监控显示,推送服务后台系统在全天运作非常平稳,没有任何卡顿拥堵现象,让各种促销、返利、订单更新消息第一时间触达用户。”

  汪轩然,2007 年毕业于清华大学计算机系,后加入微软亚洲工程院,曾参与 WP7 上的浏览器的开发。2010 年 7 月加入小米,曾担任米聊安卓团队的团队主管,现在在小米任项目总监,负责小米的开发者服务,掌管推送服务、统计服务和移动广告联盟三大业务,旨在为小米搭建一个移动 App 业务的互联网生态圈。

  我们联系了汪轩然,就小米推送服务的架构、特点、性能等问题对他进行了采访,以下内容根据本次采访整理而成。

  基础技术架构

  协议是推送服务的核心。小米推送服务所采用的协议是由之前的米聊演变过来的,而米聊从一开始就选择使用 XMPP 协议,之后开发团队对 XMPP 协议做过几轮精简和重构。现在 XMPP 部分只是作为一个数据的传输层,之上跑着各种独立的业务,每个业务称为一个“channel”;每个 channel 上跑的数据格式可以是不一样的。消息推送服务是其中一个 channel,这个 channel 上传输的数据是通过 Thrift 进行二进制化的协议格式。

  再来看一下小米推送服务的服务端架构。下图是后台服务端的一个基本架构图。整个服务端包含如下几层:

  1. XMPP 前端:用于维护跟客户端之间的长连接,使用 EJabberd 项目来处理来自客户端的 XMPP 请求,同时通过 XMQ 模块来处理推送服务特有的 XMPP 消息协议。
  2. 中间层:业务逻辑层,主要用于将消息请求异步化、创建和维护消息队列、以及处理客户端的一些命令请求(注册、设置别名、设置 topic 等)。
  3. HTTP 前端:这一层负责对接来自第三方 App 的服务器的发消息的 HTTPS 请求,以及来自客户端生成账号的 HTTPS 请求。

  再就是数据存储,这里采用了小米的统一 HBase 存储,同时还使用 MySQL 来保存一些量不大,但需要复杂过滤条件的数据(topic 等),并且为了降低对 HBase 的压力,中间还加了一层 Redis 作为缓存。

  最后看一下客户端架构。客户端 SDK 主要包含两个层次:SDK 层和 PushService 层。前者提供了面向 App 接入的接口、回调方法以及对 Thrift 的数据进行反序列化的处理逻辑;后者用于维护 XMPP 长连接和收发消息。两层之间使用 Intent 方式来传输数据。值得一提的是,在 MIUI 系统上,PushService 层是系统共用的,即 MIUI 系统提供了一个统一的 PushService 管理模块,不需要每个应用单独启动自己的 PushService。

 

  功能实现

  小米推送服务支持单发和群发消息两种推送方式。单发消息支持针对 regID 和别名两种方式,regID 是小米推送服务后台根据设备标识 +appID+ 时间戳生成,为了减少设备碰撞概率,设备标识我们采用的依据是 imei+AndroidID+build 序列号。别名是 App 在客户端设置上报的,便于应用将自己的设备/用户标识符同我们的 regID 作关联,这样 App 就不需要在后台维护 regID 跟设备/用户的对应关系了。群发消息采用打标签的方式来区分,客户端和服务端都可以给指定设备设置标签,发消息的时候,只需选取指定标签发送即可,小米推送后台会将标签所对应的设备展开。一个标签支持的设备数无上限。

  那小米推送服务的稳定性是如何保证的呢?小米推送服务采用多机房方案,平时流量均摊,一旦某个机房出现故障,流量无缝切换到其它机房,并且单个机房的容量能保证提供无损服务。目前是双机房部署,预计明年会扩展第三个机房。

  安全性也是小米推送服务重点考虑的一个因素。数据传输过程中,得益于推送服务采用的双层协议方案,消息会采取双重加密,第一重是 XMPP 传输层,保证数据在网络传输的过程中不会被篡改、监听。第二重是在 Thrift 二进制层,用以保证消息到达 Service 之后,通过 broadcast 发送给 App 进程的过程中不会被截获和伪造。第二重加密往往会被其它第三方推送服务忽略,但其风险同样很大。

  性能指标

  11. 11 大促,所面对的请求量是在小米推送服务的设计容量之内的,目前设计和机器规模可以支持峰值每分钟 1000 万条消息;平时业务量至少每分钟 40 万,峰值每分钟 600 万条消息。

  推送消息量平时波动很大,所以开发团队准备着流量随时可能忽增 200% 的情况,并在线下做好压力测试和优化;如果流量特别大,还有以下应对措施 

  1. 异步排队处理,此时消息送达时间可能会比平时稍慢,但不会对整个系统有太大冲击;
  2. 消息有优先级,广播消息会以低优先级处理;
  3. 限流,控制开发者发送消息的频率;
  4. 扩容,如果机器负载过高或者某个服务有瓶颈,可以很快速地增加机器,部署服务,增强系统处理能力。

  小米推送服务所经历的重构

  软件系统在开发和演进过程中,经常会经历较大规模的重构。小米推送服务有两次比较大的重构。

  一是开发语言从 Erlang 转为 Java。 小米原来的消息系统是使用 Erlang 开发的,所以推送系统的第一版也是基于 Erlang;但是 Erlang 的社区不够活跃,开发人员很难找,学习曲线陡,支持工具和类库少,所以后来开发团队选择了使用 Java 重新开发;迁移到 Java 后,对开发人员的要求降低,各种工具和类库较多,大大提高了开发效率。

  二是无处不在的 Cache。客户端使用小米推送服务的 SDK,开发者使用 API 的情况千变万化,很多场景是意料之外的;需要对调用频繁的业务添加 Cache,尽可能在本地进程内处理;例如,对于客户端调用 API 设置别名和订阅 topic,先检查 Cache 是否已经设置过,只有没有设置才往后端服务发送;优化后,后台服务的业务压力大大减少。

  在开发小米推送过程中的一些感悟  

  1. 服务要支持水平扩展,尽可能实现为无状态,或者使用一致性哈希进行划分;方便扩容,可以保证即使系统暂时有性能瓶颈也能通过加机器解决。
  2. 监控先行,能够很方便地采集、分析服务器的负载和业务的请求量、percentile、slow log,能够清楚了解到系统的瓶颈,有针对性地改进。
  3. 不要过早优化,先实现功能并尽快上线,根据监控数据对关键地方进行优化。
  4. 敏捷开发,快速迭代,日拱一卒,每天都有简短的站立会议,能够迅速响应变化,持续改进系统。