极光推送系统大规模高并发架构的技术实践分享

1、前言

2016年的双十一大促改改过去，作为国内第三方推送服务的领导者，极光（JIGUANG）采取了哪些措施来应对高并发推送服务？同时，极光基于 ICE 打造高可用云推送平台，其背后有哪些技术细节值得探索？

为此，InfoQ采访了负责极光开发者服务后台推送系统，大规模高并发分布式云计算体系架构总体设计研发的极光首席架构师王丰，他伴随着极光一路成长，见证了极光推送用户数量从0到数十亿的飞跃，经历了极光推送在架构上的重构、由 VM 全面转向容器化、微服务化等过程，在推送上有自己的见解。

2、极光推送所经历的重构

软件系统在开发和演进过程中，经常会经历较大规模的重构，极光推送服务经历过三次较大规模的重构：

• 第1次重构——从300万用户增加到500万用户的时候：
  原先的 UDP 替换成 TCP，提高消息传输的可靠性，引入 ICE 框架，减轻基础部分研发工作的压力。
• 第2次重构——用户数量达到6000万左右的时候：
  各服务模块间利用 MQ 进行解耦，模块的升级，依赖变得简单清晰。 
• 第3次重构——用户数量达到3亿左右的的时候：
  各服务模块间缓存优化，采用大规模缓存集群CB，大规模 Redis 集群，内存规模 T 级别。另外硬件架构方面也发生了很大变化，采用万兆交换机、万兆网卡、节点满配内存。
  

3、极光推送将转向容器化、微服务化

未来，极光在技术架构上由 VM 全面转向容器化、微服务化是出于什么考虑？这一步走的算不算晚呢？

对此，王丰回答说，微服务是一种新的服务设计模式，开发、测试、生产三个环境可以统一，给开发工作带来了极大的灵活性。容器封装了所有必须的库，原来的版本依赖问题不存在了，由单纯的开发、运维两阶段合并成开发运维（DevOps），各方面的效率都将得到很大的提升。

极光研发团队很早就关注容器技术了，那时版本还是0.x。没有着急使用容器技术，主要是考虑到初始版本 bug 比较多，社区反馈问题也很多，所以就一直在等待容器技术相对成熟和稳定之后再使用。推送提供的是电信级的服务，最重要的指标是稳定、及时；极光的集群规模很大，很多模块都是上百个节点，基础模块出问题将是灾难性的。对于新技术，极光以开放的心态接纳吸收，以小心谨慎的方式验证使用。

在实现推送功能的同时，安全性也是要极光重点考虑的因素。为了保证安全性，极光推送服务没有在数据传输过程中采用双层协议方案。王丰说，安全方面，API 全面切换到 HTTPS。用户接入方面，现在已经提供了对称加密版本。如果还有更高的要求，还可以提供 SSL 连接需求。

4、极光推送团队基于 ICE 打造高可用云推送平台

极光研发团队基于 ICE 来打造高可用云推送平台，在扩容缩容、系统配置集中统一、自动负载均衡等方面更加便利，那是不是云推送平台有了 ICE 就一 劳永逸了？

仅仅 ICE 是不够的。

ICE 是一个分布式的网络中间件，提供了通信层的完全封装，能自动处理网络异常，负载均衡，业务部署等基础性的工作，避免在这些地方重复发明轮子，省时省力，让研发人员的工作变得更轻松。

但是，还是需要做一些调整工作，比如负载的调度策略、计划支持客户端语言选择，以及 ICE 对象的设计。推送系统是多种技术结合的综合体系，需要 缓存、需要数据库、需要 MQ 等大量的其它技术配合。

这里可以介绍一下 ICE 的体系架构（下图），左边是通过 IDL 生成的相应平台的接口，各平台下可以直接调用；右边是对应的接口骨架类，用来容纳具体的服务端业务逻辑。



ICE 本身提供的原生服务如 Ice  Grid，它可以管理 Glacier2，极光内部服务节点很多都是在内网，如果需要跨网访问的时候要跨外网，不可能把成千上万节点都给它，可以通过这样做一个流量的转发，就是防火墙穿越。



Ice  Patch2 是一个自动化的部署，有点像交付，它提供专用的服务，把 Server 放在这样一个目录结构里面更新一下，重新计算数值后发通知，所有的节点会全部更新。在更新的过程中，节点可能会停一下或重启。正在处理的请求处理完之后，再重新启动。请求不会在启动和停止之间丢失，因为 ICE 的客户端会把这个请求正常定位到其他正在运行的节点上，客户端的调用是没有感知的。 

像 DBAgent、STC、TagAlias 等集群都用到了 ICE，在研发过程中能节省不少精力，例如不需要从 Socket 做起，通过 IDL 简化协议设计，提高效率；扩容缩容方便；不用再专门处理容灾；不同语言之间的差异由框架代劳；系统配置集中统一；自动负载均衡，连接池管理等等。

双十一大促中，为了确保推送服务后台系统平稳运作，极光在架构上主要措施如下：

• 扩容、优化网络访问、优化内部交换机、核心路由器网络路径和网络带宽。
• 测试选择一部分云平台，必要时动态扩充服务节点应对峰值，并进行相应的访问控制。
  

5、在开发极光推送服务过程中的一些感悟

极光在短短五年时间里，聚集了海量用户，目前有超过40万款 APP 正在使用极光推送服务，终端覆盖超过50亿，月活跃用户达6亿。极光推送的开发工作一直处于高速推进中，有时一个应用进来就有过亿的用户，连注册模块都需要高并发，这一点显著区别于绝大多数公司，印象尤其深刻。

王丰说，尽管业务量巨大，极光的后台架构开发团队却始终保持小规模，短小精悍。开发采用敏捷模式，快速迭代验证，灰度上线。

最后，王丰也谈了一个比较轻松的关于架构师修炼方面的问题，除了开发能力与设计能力以外，“有效沟通”也是架构师很重要的一项技能。和项目经理、销售、开发、测试人员清楚、精准地表达自己的想法，是不是需要有些技巧？

王丰说，沟通是天天在做的事情，研发团队的需求来自产品经理，和销售商务没有直接的沟通。和产品经理之间主要是反复确认有疑问的需求点，比如 A/B 测试，拿到需求之后，开会讨论、邮件、面对面的沟通业务流程。

而对于开发测试人员来说，详细讲解业务的功能点，接口为什么这么设计、服务模块划分的考虑因素、是否需要采用新的技术、用户将来如何用，不光知其然，还要知其所以然。让每个开发测试人员将自己的角色转换成用户来体验，确保准确的理解业务流程。

6、关于ZeroC公司的ICE

ICE其实是一整个技术群的合称，国内的资料都是抄来抄去也没有说明白ICE是干什么的。按照ZeroC官方的介绍，ICE其实就是“Ice is a comprehensive RPC framework with support for C++, C#, Java, JavaScript, Python, and more（ICE是一个支持C++、C#、Java、JavaScript、Python等语言的全面的RPC框架）”。

● Zeroc官方对它的定位是：

Ice is a comprehensive RPC framework that helps you network your software with minimal effort. Ice takes care of all interactions with low-level network programming interfaces and allows you to focus your efforts on your application logic. When using Ice, there is no need to worry about details such as opening network connections, serializing and deserializing data for network transmission, or retrying failed connection attempts (to name just a few of dozens of such low-level details)。

● 截止目前ICE所支持的编程语言如下：
C#、C++、Java、JavaScript、Objective-C、PHP、Python、Ruby。

● 截止目前ICE所支持的平台如下
Android、iOS、Linux、Linux on embedded devices、Node.js、OS X、Web Browser、Windows、Universal Windows。

● ICE的主要技术特征如下：

• Efficient, high-performance binary protocol
• Supports a wide range of programming languages and platforms
• Easy to use and type-safe API, with your own interfaces and types defined in a programming language neutral IDL, Slice
• Supports secure, encrypted communications by taking advantage of your platform's native SSL/TLS stack
• Familiar object-oriented programming model, with the ability to transmit proxies (references to remote objects) to remote applications
• Supports synchronous and asynchronous calls, for both client-side invocations and server-side dispatches
• Automatic discovery of remote objects through UDP multicast
• Comes with a number of optional services:
  IceGrid - a DNS-like service for Ice objects, with support for server deployment, replication, monitoring, load-balancing and more；
  IceStorm - a lightweight topic-based pub-sub service；
  Glacier2 - a sysadmin-friendly solution for routing Ice communications through firewalls。IcePatch2 - an efficient software distribution and patching service。
  

ICE的官方网站：https://zeroc.com
ICE的最新源码：https://github.com/zeroc-ice

7、关于王丰

王丰，毕业于北京航空航天大学，毕业后一直从事软件设计开发工作，曾就职于华为负责电信智能网的业务开发，目前担任极光的首席架构师，总体负责后台技术。

（原文链接：http://www.infoq.com/cn/news/2016/11/jpush-platform-arch-stablity，有改动）

8、更多分类好文

[1] 更多推送技术文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
《极光推送系统大规模高并发架构的技术实践分享》
>> 更多同类文章 ……

[2] 其它即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

自已公司用的推送，搞集群不难，但像极光这样的云方式，就比较困难了，因为各公司的APP用户可能分布于集群的各台实例了，一条推送的下发是比较容易，但性能问题并不好处理。

这个ICE  Patch2看起来很神奇。

极光推送已在项目里使用。

我们也在使用极光，不过也在开发自己的推送系统

引用：liuvsming 发表于 2019-06-18 10:36
我们也在使用极光，不过也在开发自己的推送系统

自研推送比自研im，相对来说要简单多了

极光推送好用还是友盟推送好用？现在用着友盟，经常出现收不到信息的情况。。

引用：小张 发表于 2021-09-23 22:03
极光推送好用还是友盟推送好用？现在用着友盟，经常出现收不到信息的情况。。

友盟。。。。 不评价

引用：小张 发表于 2021-09-23 22:03
极光推送好用还是友盟推送好用？现在用着友盟，经常出现收不到信息的情况。。

友盟的推送到达率很不理想，以至于我们App的推送架构组成中的「第三方平台推送」后期都放弃了友盟推送转而改用信鸽推送。

做为一名Android开发者我的直观感受就是，Android系统版本越高，友盟推送到达率表现越差。
很有可能就是友盟推送技术团队没有很好地适配Android6.0系统后对于内存、电量、网络等的限制。

这一点在友盟推送SDK的更新日志中就可以看出来，友盟推送SDK的更新频率很低，基本都在4个月以上，
并且更新内容甚少提及对Android系统版本的适配。

个人接入过友盟的推送、埋点、崩溃统计，总结起来的经验就是友盟对于很多领域都有涉猎，但都不是业内专精。
想要APP有更好的表现，还是得找专精于对应领域的平台。

引用：椎锋陷陈 发表于 2021-09-24 16:48
友盟的推送到达率很不理想，以至于我们App的推送架构组成中的「第三方平台推送」后期都放弃了友盟推送转 ...

you盟的老板已经赚到钱了，至于技术，已经不是那么重要了。。。

对于推送服务商而言，99.99%的高可用性（除去天灾、提前告知停机服务等），是不是应该很容易而且是必要保证的？

引用：小张 发表于 2021-11-23 14:44
对于推送服务商而言，99.99%的高可用性（除去天灾、提前告知停机服务等），是不是应该很容易而且是必要保证 ...

业务做的越大，责任就越大，肯定是不能出纰漏的了