导读：移动时代，推送系统的重要性不言而喻。Urban Airship 是国外专注于推送服务的 SaaS 厂商。在美国大选期间，Urban Airship 的消息推送量达到 25 亿次每天。Urban Airship 的技术团队是如何支持如此巨大的消息推送量？他们使用了什么开源技术？核心系统的架构又是怎样的？本文带你一窥全豹。
Urban Airship 被大量希望通过推送实现用户增长的企业所信赖。Urban Airship 是一个七岁的 SaaS 公司，更多信息可访问官网：
Urban Airship 现在平均每天发送超过 10 亿推送通知。本文介绍 2016 年美国大选 Urban Airship 推送使用情况，为你解密 Core Delivery Pipeline 系统的架构，这个系统为各大媒体提供数十亿的实时通知。
2016 年美国大选的推送数据
在选举日的 24 小时内，Urban Airship 发送了 25 亿次通知 - 这是迄今为止最高的发送量。 这相当于美国每人收到 8 个通知或世界上每个有效智能手机收到 1 个通知。
虽然 Urban Airship 支持超过 45,000 个应用程序，但是分析选举使用数据显示超过 400 个媒体应用程序占用了60％ 的记录，即在一天内发送 15 亿通知。
总统选举结束时，通知量达到峰值。
Urban Airship API 的 HTTPS 入口流量在选举期间达到每秒近 75K 的峰值。大多数流量来自与 Urban Airship API 通信的 Urban Airship SDK。
推送量一直在快速增长。最近的主要驱动因素是英国的退欧公投 Brexit，奥运会和美国大选。到 2016 年 10 月，每月通知量年比年（YOY）同比增长 150％。
Core Delivery Pipeline 系统架构解密
Core Delivery Pipeline（CDP）是 Urban Airship 的核心系统，负责存储来自客户的设备信息并提供推送通知。 我们发送的所有通知都要求极低的延迟，无论他们同时推送数千万用户，或按定位进行多个复杂选项，或者包含个性化内容。 下面介绍下 CDP 的架构，以及我们从中学到的经验。
最初的版本：Python + Postgres
在 2009 年，最初的版本是作为 webapp 开发，逐渐一些模块转变为面向服务的架构（SOA）。当旧系统的一些部分开始发生规模问题时，我们便将它们提取为一个或多个新服务，这些服务虽然提供的是相同的功能，但可以支持更大规模，以及性能更好。
我们的许多原始 API 和 worker 是用 Python 开发，我们将这些功能逐渐移植到高并发的 Java 服务中。我们最初将设备数据存储在一组分片的（sharding）postgres 数据库中，但是访问规模的增加速度超过了我们添加新数据库分片的能力，因此我们将数据库迁移到 HBase 和 Cassandra。
CDP 是用于处理推送通知投递的一系列服务。这些服务都用于处理相同类型数据的请求，但是出于性能原因，每个服务以非常不同的方式索引数据。例如，我们有一个系统负责处理广播消息（向所有注册到同一个应用的设备推送同样的消息），此服务及数据存储的设计，与我们的个性化通知服务的设计是非常不同。
我们把所有长时间运行的进程都理解成服务。这些长时间进程在监测，配置和日志记录方面遵循我们的通用规范模板，以便部署和运维。
通常，我们的服务有两种类型：RPC 服务或队列消费者服务。
RPC服务（非常类似于 gRPC 的内部框架）提供一些功能命令和内部服务同步交互，而队列消费服务则处理来自 Kafka 的消息并且对那些消息执行服务特定操作。
数据库
为了满足我们的性能和规模要求，我们非常依赖 HBase 和 Cassandra 来满足数据存储需求。虽然 HBase 和 Cassandra 都是 NoSQL 存储，但是它们有非常不同的 tradeoff，并影响我们在什么场景该使用哪个存储。
HBase 高吞吐的扫描查找并返回较多数据，而 Cassandra 擅长较低的基数查找（返回的数据较少）。两者都允许大量的写吞吐量，这是我们的要求，因为来自用户手机的所有元数据更新都是实时的。
他们如何应对失败的策略也各不相同。HBase 在失败的情况下倾向于保证一致性和分区容错性（C + P），而 Cassandra 则有利于可用性和分区容错性（A + P）。每个 CDP 服务具有非常具体的情况，因此被设计为便于所需的访问模式。
作为一个通用规则，每个数据库仅由单个服务访问，该服务负责通过提供专用的接口来满足其他服务的数据访问的需求。
在服务及其后台数据库之间实现这种 1：1 关系，具有许多优点。
通过将服务的后端数据存储作为实现细节，而不是共享资源，我们获得了灵活性。
我们可以调整服务的数据模型，而只更改服务的代码。
使用跟踪更直接，这使得容量规划更容易。
故障排除更容易。将服务和数据库打包作为逻辑单元极大地简化了故障排除过程。我们不必想知道“还有谁可以访问这个数据库，使其以这种方式运行？”相反，我们可以依赖于来自服务本身的应用程序级监测，并且只关注一组访问模式。
因为只有一个服务与数据库交互，我们可以执行几乎所有的维护活动，而不会停机。重型维护任务成为一个服务级别的问题：数据修复，模式迁移甚至切换到完全不同的数据库，而不会中断服务。
确实，当将应用程序分解为较小的服务时，可能会有一些性能损失。但它带来的可扩展性和高可用性方面获得的灵活性，超过了性能降低带来的损失。
数据建模
我们的大多数服务处理相同的数据，只是使用不同的格式。为了保持所有这些服务的数据更新，我们非常依赖 Kafka。 Kafka 速度非常快，也牢靠。速度快来自于一些 tradeoff。 Kafka 消息只保证至少发送一次，并且不保证它们按顺序到达。
我们如何处理这个问题呢？我们已将所有可变路径建模为可交换的：操作可以按任何顺序应用，并以相同的结果结束。他们也是幂等的。这带来一个很好的副作用，我们可以重放 Kafka 流来进行数据修复工作，甚至迁移数据。
为此，我们使用了“cell version”的概念，它存在于 HBase 和 Cassandra 中，它通常是一个时间戳，但也可以使用其他数字（有一些例外，例如 MAX_LONG 可能会导致一些奇怪的行为，这取决于 HBase 或 Cassandra 的版本以及你的 schema 如何处理删除）。
对我们来说，这些单元格的一般规则是它们可以有多个版本，我们定义版本方式是通过时间戳。考虑到这种行为，我们可以将传入的消息存入为不同的列中，并通过自定义的应用程序以及合适的时间戳来取出这些数据。这样就允许对底层数据存储进行盲写，同时保持数据的完整性。
只是盲目地写更改 Cassandra 和 HBase 并非没有问题。一个很好的例子是在队列重放的情况下，系统会重复写入相同的数据。虽然由于我们保持记录幂等性的设计，使得数据的状态不会改变，但是重复的数据必须被压缩。在最极端的情况下，这些额外的记录可能导致显着的压缩延迟和备份。由于这个细节，我们密切监控我们的压缩时间和队列长度，因为在 Cassandra 和 HBase 中，压缩都会导致严重的问题。
通过确保来自数据流的消息遵循严格的规则，并且消费服务能够处理无序和重复的消息，我们可以保持大量的异步服务同步，通常仅有一到两秒更新滞后。
服务设计
我们的大部分服务使用 Java 开发，但是具有非常好的审美和现代风格。我们在开发 Java 服务时的指导原则如下：
单一责任：只做一件事，并且做好。在设计服务时，它应该有一个责任。由实施者决定什么包括在一个责任里，但她或他将需要准备好在 code review 时来说明这一点。
没有共享操作状态：在设计服务时，假设总是至少有三个实例正在运行。服务需要能够在没有任何其他实例外部协调的情况下处理相同请求。熟悉 Kafka 的人会注意到，Kafka 消费者从外部协调一个主题的分区所有权：组对（group pair）。本指南指的是特定于服务的外部协调，而不是利用可能在外部协调的库或客户端。
限制队列的长度：我们在所有服务中都使用队列，这是进行批处理请求的好方法。所有队列都应该有边界。然而，限制队列确实引发了一些问题：
当队列满时生产者会发生什么？他们应该阻塞吗？或者摘除掉？
队列有多大？要回答这个问题，它有助于假设队列总是充满。
如何优雅的停止队列？
每个服务将有不同的答案，这些问题取决于具体的用例。
命名自定义线程池，并注册一个UncaughtExceptionHandler - 如果我们最终创建自己的线程池，我们使用来自Executors的构造函数或帮助方法来允许我们提供一个ThreadFactory。有了ThreadFactory，我们可以正确命名我们的线程，设置它们的守护状态，并注册一个UncaughtExceptionHandler来处理异常。这些步骤使调试服务变得更加容易，并避免了我们在深夜沮丧（译者注：看来老外也是半晚上爬起来处理 BUG）。
优先选用不可变数据类型（immutable data objects）：在高度并发环境中，可变状态可能是危险的。一般来说，我们使用可以在内部子系统和队列之间传递的不可变数据对象。不可变对象是子系统之间的主要通信形式，它使得并发使用更加直接，并且让故障排除更容易。
未来规划
Urban Airship 有通过移动设备发送通知的能力，也支持新的 Web 通知以及 Apple News 通知，包括其他大量平台设备或营销渠道发送通知的能力，我们预计推送量将呈指数增长。 为了满足这种需求，我们将继续在我们的 CDP 系统架构，服务，数据库和基础设施方面进行大量投资。
-END-
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。
长按下方的二维码可以快速关注我们
如想加群讨论学习，请点击右下角的“加群学习”菜单入群。
2232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
