Meta 爆款应用 Threads 背后的技术秘诀：选用 ZippyDB 和 Async 是关键

2023 年 7 月 5 日，Meta 推出了该公司应用产品线中的最新应用 Threads，并取得了前所未有的成功，在推出的前五天内就获得了超过 1 亿的注册量。

一个小规模、灵活的工程师团队仅用了五个月的技术工作就构建出了 Threads。虽然这款应用的生产环境发布计划已经考虑了一段时间，但等到 Meta 最终做出发布决定并通知基础设施团队做好发布准备时只提前了两天而已。之所以时间这么紧凑，是因为 Meta 基础设施团队过去的业绩记录优秀，基础设施也非常成熟，因此公司非常有信心。尽管如此短的交付时间带来了艰巨的挑战，基础设施团队还是为该应用的快速增长提供了出色的支持。

数百万用户注册 Threads 时，该应用的规模扩展平滑无缝，而这是过去十多年来 Meta 基础设施建设和产品开发的成果。这不是专门为 Threads 构建的基础设施，而是在 Meta 长期发展中为许多产品构建的。它生来就注重规模、增长、性能和可靠性，并且成功地超越了 Meta 的预期，支持 Threads 达到了无人能预料到的增长速度。

为 Threads 提供服务的基础设施非常多，但由于篇幅限制，本文只会挑两个发挥重要作用的现有组件来举例：ZippyDB（Meta 的分布式键 / 值数据存储）和 Async（正如其名，是 Meta 的异步无服务器函数平台）。

先来看 Threads 存储层的一个切面，其中用到了 ZippyDB，一个分布式键 / 值数据库，运行形式是一个完全托管的服务，供工程师进行构建。它是从零起步构建而成的，旨在充分利用 Meta 的基础设施，且其上托管的密钥空间可以相对轻松地缩放，并可以灵活地部署在任意数量的数据中心中。由 MySQL 支持的 TAO 则用于 Meta 的社交图存储——这样就可以直接在这个堆栈中找到 Threads 的帖子和回复。ZippyDB 是 MySQL 的键 / 值对应产品，是 Meta 在线数据栈的关系数据库组件，用于计数器、推送排名 / 状态和搜索功能。

Meta 得以高速扩展键空间容量的能力取决于两个关键特性：首先，该服务运行在一个公共硬件池上，并插入 Meta 的整体容量管理框架中。一旦有新容量分配给这个服务，服务池中就会自动添加机器，负载均衡器也会开始将数据移动到新机器。将数千台新机器添加到服务中后，系统只需几个小时内就能完成迁移。虽然这样的表现已经很好了，但还不够，因为批准容量的端到端时间（可能会从其他服务中挤出容量并添加到 ZippyDB）还有可能长达数天。由于给出的发布通知提前时间很短，基础设施团队还需要在很短时间内就完成大量机器的迁移。

实现高速迁移的秘诀是这个服务架构的多租户及强大的隔离特性，从而支持不同的键空间，还可能有共享底层主机的空闲负载需求，而不必担心当其他负载变重时自己的服务水平会受到影响。由于各个键空间以及用于处理灾难恢复事件的缓冲区都有未使用容量，主机池中也存在闲置资源。团队可以翻转腾挪，在键空间之间转移未使用的资源，从而充分利用现有的闲置空间，让主机运行在更高的利用率水平上，这样键空间就能几乎瞬时扩展并在短时间内（几天）维持这个容量水平。所有这些都只需要在围绕它们构建的各种工具和自动化操作中做简单配置更改即可，因为它们是相当常规的日常操作。

强大的多租户和吸收新硬件的能力相结合，使得 Threads 服务能基本上实现无缝扩展，即使面对突然出现的大量新需求也是如此。

ZippyDB 的重新分片协议使团队能够快速、透明地增加 ZippyDB 用例的分片因子（即水平缩放因子），同时保证客户端有零停机时间，并提供完全的一致性和正确性保障。这样基础设施团队就能够在新产品发布的关键路径上快速扩展用例，即使负载增加了 100 倍，发布过程也能实现零中断。

团队实现这一点的诀窍是让客户端将其键值散列到逻辑分片，然后将其映射到一组物理分片。当用例增长并需要重新分片时，团队会配置一组新的物理分片，并通过实时配置更改在客户端中安装新的逻辑到物理分片映射，过程无需停机。使用服务器自己的隐藏访问密钥以及重分片 Worker 中的智能数据迁移逻辑，团队就能够自动地将逻辑分片从原始映射移动到新映射。一旦所有逻辑分片都已迁移完毕，重新分片工作就完成了，工程师这时会删除原始映射。

由于扩展用例是新产品发布的关键操作，因此团队在重分片技术栈上投入了大量资源，以确保 ZippyDB 扩展过程不会成为产品发布的瓶颈。具体来说，团队基于协调器 -Worker 模型设计了重分片栈，因此它是水平可扩展的，使团队能够在需要时（例如在 Threads 发布期间）提高重分片速度。此外，团队还开发了一套紧急操作工具，可以轻松应对用例的突然增长。

这些方法结合起来，使 ZippyDB 团队能够有效应对 Threads 的快速增长势头。通常，当在 ZippyDB 中创建新用例时，团队首先从小规模开始，然后根据增长需求重新分片。这种方法可以防止过度配置并提高容量使用效率。随着 Threads 开始病毒式增长，很明显团队需要通过主动执行重分片来为该应用上百倍的增长做好准备。在过去开发的自动化工具的帮助下，当 Threads 团队在英国时间午夜打开流量闸门时，基础设施团队及时完成了重分片。这样即便 Threads 的用户数量激增，用户体验依旧令人满意。

Async（也称为 XFaaS）是一个无服务器函数平台，能够将计算推迟到非高峰时间，从而使 Meta 的工程师能够缩短从解决方案构思到生产部署的时间。现在 Async 每天在超过 100,000 台服务器上处理数万亿次函数调用，并且可以支持多种编程语言，包括 HackLang、Python、Haskell 和 Erlang。

该平台抽象了部署、排队、调度、扩展以及灾难恢复和准备的细节，这样开发人员就可以专注于他们的核心业务逻辑，并将其余繁重的工作卸载到 Async 上。开发人员的代码加入到这个平台后会自动获得大规模扩展能力。可扩展性并不是 Async 的唯一关键特性。上传到平台的代码还继承了可配置重试、交付时间、速率限制和容量责任的执行保证。

在 Async 上执行的负载一般是那种不会干扰活跃用户使用产品的体验，并且可以在用户操作后几秒钟到几个小时内随意执行的类型。在为用户提供快速建立社区的能力方面，Async 发挥了关键作用，在它的支持下用户可以把 Instagram 上关注的用户列表转移到 Threads 里面来。具体来说，当新用户加入 Threads 并选择关注他们在 Instagram 上关注的用户列表时，执行用户请求，关注 Threads 中同一社交图谱的高计算量操作是通过 Async 以可扩展的方式进行的，这样就不会打断，或者对用户的入门体验产生负面影响。

在五天内为 1 亿用户完成这样的操作需要强大的处理能力。此外，许多名人都加入了 Threads，意味着可能有数百万人排队关注他们。这种操作和对应的通知操作也都在 Async 中处理，从而能够在面对大量用户时实现强大的可扩展性。

虽然快速增长的 Threads 用户新加入时生成的 Async 作业量比团队最初的预期高出几个数量级，但 Async 优雅地吸收了增加的负载，把负载排好队列，让操作执行井然有序。具体来说，执行过程是在速率限制内管理的，这样系统就能正常发送通知，并让用户及时建立连接，而不会导致从这些 Async 作业接收流量的下游服务过载。Async 会自动调整执行流程以匹配其容量以及依赖服务（例如社交图数据库）的容量，所有这些都无需 Threads 工程师或基础设施工程师的手动干预。

Threads 在短短五个月的技术工作中迅速发展，凸显了 Meta 基础设施和工程文化的优势。Meta 的产品充分利用了经受时间考验的共享基础设施，使产品团队能够快速行动并快速扩展广受欢迎的产品。Meta 的基础设施高度自动化，这样除了在短时间内确保容量水平的工作外，重新分配、负载平衡和负载扩展都能自动化顺利、透明地完成工作。Meta 在追求快速行动的工程文化氛围中蓬勃发展，在这种文化中，工程师有着充足的所有权，并能无缝协作，共同实现同一个大目标，相应的流程也非常高效，传统组织往往需要几个月时间才能完成这种协调工作。举例来说，Meta 的 SEV 事件管理文化一直是在 Meta 团队都需要协调和快速行动的时候获得正确的可见性、焦点和行动力的关键。总的来说，这些因素结合起来确保了 Threads 的成功发布。

原文链接：

https://engineering.fb.com/2023/12/19/core-infra/how-meta-built-the-infrastructure-for-threads/

声明：本文为 InfoQ 翻译，未经许可禁止转载。