Pinterest 使用 Kubernetes 和 Helix 构建下一代异步计算平台 Pacer

Pinterest 推出其下一代异步计算平台 Pacer，用以取代旧的解决方案 Pinlater。随着公司的发展，Pinlater 在伸缩性和可靠性方面面临着挑战。新的架构使用 Kubernetes 来调度作业，使用 Apache Helix 来进行集群管理。

Pinterest 之前构建了一个异步作业执行平台Pinlater，并在几年前将其开源。Pinlater 已在生产环境中使用了多年，并支持许多关键的功能领域。Pinterest 在AWS EC2上运行了几个 Pinlater 集群，每分钟处理数百万个任务。

Pinterest 软件工程师Li Qi和Chen Zhihuang解释了促使他们构建新平台的动机：

随着 Pinterest 在过去几年的增长和 Pinlater 流量的增加，我们发现 Pinlater 存在许多局限性，包括伸缩性瓶颈、硬件效率、缺乏隔离性和可用性。我们在平台方面也遇到了新的挑战，包括那些影响我们数据存储吞吐量和可靠性的挑战。

基于他们使用 Pinlater 的经历，团队意识到他们不可能在现有架构中解决所有已知的问题，于是他们决定构建下一代平台。

新的架构 Pacer 包含了一个无状态的Thrift API 服务（与 Pinlater 兼容）、一个数据存储（MySQL）、一个有状态的脱队列代理服务（Dequeue Broker），以及在Kubernetes上运行的作业执行 Worker 池。Apache Helix（带有Zookeeper）被用来将作业队列分区分配给脱队列代理。

Pacer 架构（来源：Pinterest工程博客）

脱队列代理是一种有状态服务，负责从数据存储中预取作业队列数据并将其缓存到内存中，以减少延迟和隔离入队列和脱队列的工作负载。每个脱队列代理分配到一组作业队列分区，因此可以独占获取和执行作业，从而避免出现争用的情况。Kubernetes 为每个作业队列提供了一个专用的 Pod 池，消除因不同作业类型对资源倾斜消耗所带来的影响。

新的脱队列和执行模型缓解了 Pinlater 所遭遇的问题，包括在从热点分区获取数据时避免扫描所有分区或减少锁的争用。此外，它支持按照排队顺序（FIFO）的方式执行作业，前提是为作业队列配置单独的分区。

新的架构需要给脱队列代理实例进行独占式队列分区分配，与Kafka

消费者主题分区分配类似。Pinterest 的团队选择使用 Apache Helix 来实现这个功能。Apache Helix 提供了一个通用的集群管理框架，用于给集群内的脱队列代理进行分区分配。Helix 使用 Apache Zookeeper 实现嵌在脱队列代理实例中的 Helix 控制器和 Helix 代理之间的资源配置通信。

用 Apache Helix 和 Zookeeper 协调脱队列代理（来源：Pinterest工程博客）

Helix 控制监控加入和离开集群的脱队列代理实例，以及对已配置的作业队列做出的任何变更，如果发生变更，它将重新计算理想的队列分区与代理分布。在最新的分区分配被保存到 Zookeeper 之后，各个代理实例就会更新它们的内部状态，并从它们负责的队列分区中获取数据。

查看英文原文：https://www.infoq.com/news/2023/08/pinterest-pacer-kubernetes/