过去一年中，OpenAI 的 Kafka 吞吐量在 30 多个集群中实现了 20 倍增长，其架构方案达到了 99.999%（五个 9）的可用性标准。本文介绍他们的实现路径。

同时，笔者认为 OpenAI 的方案实际是把 Kafka 只用作存储层，通过 Producer 和 Consumer 两端的 Proxy 层来达到存算分离的目标。而这正是 Pulsar 存算分离的优势。OpenAI 在目标收益中关注的高可用性、高扩展性、易运维性等，都和存算分离的云原生架构紧密相关，这也是原文评论中 Pulsar 被重复提及的原因。

对于企业而言，选择 Apache Pulsar 不仅能够满足当前需求，还能为未来业务增长提供更大的灵活性和可扩展性。

推荐全文阅读。

OpenAI 的 Kafka 架构

- 实现 50 倍增长与 5 个 9 的可靠性 -

OpenAI 原文

OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters.

OpenAI’s Kafka throughput grew 20x in the last year across 30+ clusters.Their setup achieves five 9s (99.999%).Here’s how they did it 👇

〰️〰️〰️〰️🟩 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗚𝗿𝗼𝘂𝗽𝘀They group clusters into groups. Each cluster lives in a separate region.Through an upstream config service, users create logical topics that live in a group.The logical topic has a physical topic in each cluster in the group.This is well abstracted so users only think in terms of topics - not clusters or brokers.

〰️〰️〰️〰️🟨 𝗣𝗿𝗶𝘀𝗺 - 𝗣𝗿𝗼𝗱𝘂𝗰𝗲𝗿 𝗣𝗿𝗼𝘅𝘆A very simple producer proxy exposes just one endpoint - a gRPC ProduceBatch API.Prism reduced their broker connections MASSIVELY. They used to get 50k connections per broker and run out of memory.It also offers cross-cluster retries - if one region’s cluster fails, the proxy re-routes to another!

〰️〰️〰️〰️🟧 𝘂𝗙𝗼𝗿𝘄𝗮𝗿𝗱𝗲𝗿 - 𝗖𝗼𝗻𝘀𝘂𝗺𝗲𝗿 𝗣𝗿𝗼𝘅𝘆OpenAI uses Uber’s open source consumer proxy - uForwarder.It changes consumption to a PUSH-based model. The proxy continuously pulls data from Kafka and pushes it to its subscribed consumers. 👌

This is also gRPC.

The proxy massively simplifies applications - they don't need to interact with a cluster, no need to configure/use a Kafka client, no need to setup complex auth and no need to manage offsets.The proxy also offers some powerful features:

• automatic retries ✨• dead letter queueing ✨• multi-cluster consumption ✨• no head of line blocking ✨• parallelism greater than the number of partitions ✨

〰️〰️〰️〰️🟥 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀

The careful reader may notice that this setup requires them to give up a few things, like:⛔️ no transactions/idempotency⛔️ no ordering⛔️ no partitioning

Ordering, transactions and partitioning can be done downstream by other systems.

They embraced this principle - "Simple things should be simple, complex things should be possible."

As a result, they saw adoption skyrocket. 🚀

OpenAI intentionally took this tradeoff in order to get:✅ vastly improved UX & integration for users✅ 99.999% availability by routing around broken cluster✅ improved scalability (efficient connections, high throughput per topic)✅ easy maintenance

Another big reason for this architecture is decoupling the clients from the infrastructure. 💡

Because of the proxies, their clients are not coupled with the underlying clusters (infra).

This makes cluster maintenance (upgrade, reconfiguration, migration, decommissioning, addition) very easy. 👌

The UX improvement also cannot be overstated. They had 30+ clusters, using different Kafka engines/vendors, diff secrets/firewalls, each configured on an ad-hoc basis. 🫠

A big question users had was - “which cluster is topic X in? which one do I use?”.

This architecture solved it all, and they did it in less than a year 👌

原文：https://www.linkedin.com/posts/stanislavkozlovski_openai-kafka-activity-7331683326195331073-cxN6/

过去一年中，OpenAI 的 Kafka 吞吐量在 30 多个集群中实现了 20 倍增长，其架构方案达到了 99.999%（五个 9）的可用性标准。以下是他们的实现路径：

集群分组策略

OpenAI 将集群按组划分，每个集群部署在独立区域。通过上游配置服务，用户可创建逻辑主题（logical topic）并关联至特定组。每个逻辑主题在组内的每个集群中对应一个物理主题（physical topic），这种设计通过高度抽象让用户只需关注主题本身，而无需关心集群或代理节点的底层细节。

Prism——生产者代理层

这是一个极简的生产者代理，仅暴露 gRPC 格式的 ProduceBatch API 端点。Prism 的核心价值在于：

• 大幅减少连接数：此前每个代理节点需处理 5 万连接，常因内存耗尽崩溃，而 Prism 将连接集中管理；

• 跨集群重试机制：当某区域集群故障时，代理会自动将请求路由至其他集群。

uForwarder——消费者代理层

OpenAI 采用 Uber 开源的消费者代理 uForwarder，将传统拉取模式转为推送（PUSH）模型：代理持续从 Kafka 拉取数据并推送给订阅的消费者（同样基于 gRPC）。这一设计让应用开发显著简化：无需直接对接集群、配置 Kafka 客户端、管理认证或偏移量（offset）。

代理还具备以下核心能力：

• 自动重试机制

• 死信队列（Dead Letter Queue）

• 多集群消费能力

• 无队首阻塞（Head-of-Line Blocking）

• 并行度超越分区数量

架构权衡与取舍

细心的读者可能注意到，这种设计需要牺牲部分功能：

• 不支持事务（Transactions）与幂等性（Idempotency）

• 不保证消息有序性

• 放弃分区特性（Partitioning） 

但排序、事务和分区等需求可由下游系统处理。OpenAI 遵循 “简单事情应极简，复杂事情需可行” 的原则，反而推动了架构的大规模落地，其核心收益包括：

• 用户体验与集成效率跃升

• 通过故障集群绕行实现 99.999%可用性

• 提升扩展性（连接效率优化、单主题高吞吐量）

• 维护成本降低

此外，架构的核心优势在于客户端与基础设施的解耦：借助代理层，客户端无需依赖底层集群（如升级、重配置、迁移或扩容操作），使集群维护变得高效。用户体验的提升尤为显著——过去 30 多个集群采用不同引擎、认证机制和防火墙策略，用户常困惑 “主题 X 在哪个集群？该连接哪个？”，而新架构在不到一年时间内彻底解决了这类问题。

值得注意的评论

“

Julien Laurenceau（资深解决方案架构师）： “当对原生工具进行如此深度的改造时，我不确定是否仍有必要继续使用它。虽然未看到完整设计，但 Apache Pulsar 原生提供了分区与客户端间的代理层，而本文提到的代理可能在牺牲事务等功能的同时，也削弱了快速写入特性。我甚至怀疑端到端流水线是否还能保证至少一次送达（at-least-once）语义。若新项目没有 Kafka 遗留代码，建议不要采用此方案！”

”

“

Nitin Rajora（DLG 资深 SRE）：“频繁的故障转移与无序消息并非所有场景都能接受。”

”

“

Ben Gamble：“这让我联想到 Aklivity，它们也通过 gRPC 从 Kafka 流式导出数据。”

”

“

Jordan Moore：“他们在全球范围复制消息？这成本恐怕不低。”

”

“

Félix GV：“能否详细说明该架构如何实现超越底层分区的并行能力？”

”

“

Fran Mendez：“我欣赏他们通过 API 抽象底层基础设施的设计，这也优化了团队协作模式——平台团队真正承担起为消费团队简化开发体验的重任。通过限制部分功能（如分区），复杂度得以降低，用户只需更少认知成本即可使用 Kafka 集群，这对其特定场景而言是明智决策。”

”

“

Penghui Li（StreamNative 流处理总监，Apache Pulsar PMC 成员）： "我同意 Nitin 的观点—这确实取决于具体的使用场景。这正是为什么 Pulsar 提供 Key_Shared 订阅模式：它允许您按键维护消息顺序，同时仍然支持消费者的可扩展性。"

”

以上中文翻译完。

为何 Apache Pulsar 被反复提及？- Why Apache Pulsar -

成就与挑战

OpenAI 实现了 Kafka 吞吐量 20 倍增长，并达到了 99.999%的可用性，这一成就令人印象深刻。然而，他们为此付出了一些代价：

1. 复杂的自定义代理层：构建和维护 Prism(生产者代理)和 uForwarder(消费者代理)需要大量工程资源

2. 功能牺牲：放弃了事务、幂等性、消息顺序和分区控制等核心功能

3. 高昂的基础设施成本：跨区域复制所有消息带来显著的存储和网络成本

4. 维护负担：多个 Kafka 之外的自定义组件增加了系统复杂性和长期维护成本

正如评论中 Julien Laurenceau 所指出："在对原始工具进行如此大规模修改的情况下，我不确定继续使用它是否是个好主意！"

Apache Pulsar 优势分析

Apache Pulsar 作为新一代分布式消息和流处理平台，能够原生解决 OpenAI 面临的挑战，同时保留关键功能：

1. 原生多租户和集群抽象

Pulsar 的设计理念与 OpenAI 的需求高度一致，无需自定义开发：

• 租户/命名空间层次结构：Pulsar 原生支持多租户，通过租户和命名空间提供逻辑抽象，用户无需关心底层集群细节

• 统一 API：统一的队列和流的访问接口

• 简化认证授权：集中化的认证和基于角色的访问控制

2. 内置代理层与连接管理

Pulsar 架构天然包含代理层，无需额外开发：

• Pulsar Proxy：原生提供可扩展的代理层

• 连接复用：高效处理大量客户端连接，避免 OpenAI 遇到的 50K 连接内存溢出问题

• 协议适配：通过 KoP 无缝支持 Kafka 协议

3. 地理复制与灾备

Pulsar 提供比 OpenAI 自建方案更强大的地理复制能力：

• Geo-replication：内置跨区域的多集群复制功能，支持多种集群复制策略

• 灾难恢复：自动故障转移和恢复机制

• 区域感知路由：智能路由请求到最近的可用区域

4. 保留关键功能的同时提供简化体验

与 OpenAI 不同，Pulsar 不需要牺牲核心功能：

• 事务支持：原生支持事务，确保跨主题的原子性操作

• 消息顺序：保证分区内消息顺序；Key-shared 模式，保证单分区并发有序

• 灵活分区：支持自定义分区策略，同时提供简单接口

• 推拉结合模型：同时支持推模式和拉模式消费

5. 运维简化与成本优化

Pulsar 架构设计显著降低运维复杂度和成本：

• 存储计算分离：BookKeeper 提供高效存储层和节点之间的对等高可用，优化资源使用

• 弹性扩展：独立扩展存储和计算资源，避免过度配置

• 分层存储：热数据保留在高性能存储层，冷数据自动迁移到对象存储，降低成本

• 统一管理界面：简化集群监控和管理

客户价值对比

迁移路径建议

对于考虑类似存算分离云原生架构的企业，笔者建议：

1. 评估现有需求：明确消息系统的核心需求，包括可用性、功能和扩展性

2. 考虑 Pulsar 原生方案：利用 Pulsar 内置功能替代自建组件

3. 渐进式迁移：利用 Pulsar 的 Kafka 协议适配器实现平滑迁移

4. 验证关键指标：测试吞吐量、延迟和可用性，确保满足业务需求

结论

OpenAI 的 Kafka 架构展示了他们在面对挑战时的创新能力，但同时也暴露了传统消息系统的局限性。Apache Pulsar 作为新一代消息和流处理平台，能够原生提供 OpenAI 所需的所有功能，同时避免功能牺牲和维护复杂性。

笔者认为， OpenAI 的方案实际是把 Kafka 只用作存储层，通过 Producer 和 Consumer 两端的 Proxy 层来达到存算分离的目标。这正是 Pulsar 存算分离的优势。OpenAI 在目标收益中关注的高可用性、高扩展性、易运维性等，都和存算分离的云原生架构紧密相关，这也是原文评论中 Pulsar 被重复提及的原因。

对于企业而言，选择 Apache Pulsar 不仅能够满足当前需求，还能为未来业务增长提供更大的灵活性和可扩展性。正如评论中所指出的："请不要将其 (OpenAI 的自定义方案) 用于没有 Kafka 遗留代码的全新项目！

对于新项目，Apache Pulsar 提供了更现代、更完整的解决方案。