Cloudflare K2 公测：跑在 R2 上的 Kafka 式无服务器事件流
Cloudflare 发布 K2 公测：跑在 R2 上的分区持久日志，排序靠原子操作无需协调服务；限 Workers Paid，按 GB 计费。
Cloudflare 在生日周发布 K2 公测：一个跑在 R2 上的 Kafka 式分区持久事件日志——「无服务器事件流」第一次进 Workers 生态。
事实部分
- 架构：分区持久日志存于 R2（11 个 9 的耐久性）；消息排序与偏移量由 R2 原子操作保证，无独立协调服务（无 ZooKeeper/KRaft 等价物）；写入先进内存缓冲，再刷成分段文件。
- 代价：初期生产延迟 p99 约 1 秒——不是低延迟消息队列。
- 消费模型：offsets、消费者租约（5 分钟 ack/nack/extend）、work-splitting 与 pub/sub 两种模式。
- 公测限制：仅 Workers Paid 计划，单流 10GB 存储、30MB/s；暂不计费。
- 计划定价：生产 $0.04/GB、消费 $0.04/GB、留存 $0.02/GB/月。
- 路线图：Apache Kafka 客户端兼容、多 GB/s 并行、按 key 排序、更低延迟的 Express 档。
- 出身：K2 源自 Basin Pipelines 的摄取层。
与 Kafka 的对位
K2 不打算在延迟与吞吐上打 Kafka，而是打「运维」：无集群、无 broker、无容量规划——按 GB 计费、随 R2 分布到全球。对 Workers 生态的初创与中小团队，事件流的第一公里成本大幅下降；对已有 Kafka 集群的公司，K2 是边缘侧摄取与跨区中继的补充而非替代。
给开发者的评估点
三个决定适用性的问题：你的消费者能否容忍 1 秒 p99（实时风控不行，事件溯源可以）；单流 30MB/s 上限是否够（等路线图的多 GB/s 并行）；锁进 Workers Paid 是否可接受。
与生日周其他发布的对照
同一周 Cloudflare 还开源了 Clef 决策模型并宣布公共 CA 申请——三条线分别是计算、信任与数据基础设施，共同点是「把需要自己运维的东西变成按量计费的东西」。
编辑判断
生日周三连发（公共 CA、Clef 决策模型、K2）的共同主题是把「需要自己运维的东西」变成「按量计费的东西」。K2 若如期兼容 Kafka 客户端，将直接测试企业愿意为「无运维」付多少溢价。
设计上的赌注
把日志建在 R2 而非 broker 本地盘上，意味着耐久性与排序直接继承 R2 的原子性——不用跑 quorum 协议、没有要再平衡的集群。1 秒 p99 是这个设计的代价，Cloudflare 也明说低延迟的 Express 档在路线图而非公测里。对事件溯源、审计日志、CDC 复制与 AI 智能体动作日志——这些场景排序与耐久比毫秒重要——这笔交易是划算的。
它在生日周叙事里的位置
K2 补齐了一个三件套：公共 CA 攻信任基础设施、Clef 攻模型判断层、K2 攻事件基础设施——共同点是把运维重的组件变成边缘上的按量计费原语。Kafka 客户端兼容是值得盯的那一项：它决定 K2 是 Workers 时代的配套件，还是现有管线的迁移路径。 按量计费、边缘就近、兼容 Kafka——三个词决定管线会不会搬家。
耐久性账本的注脚
R2 的 11 个 9 说的是已存储对象，不是在途写入——内存缓冲就是丢失窗口，Cloudflare 文档尚未给出故障时的刷新节奏。把 K2 当主日志的事件溯源团队，应该像等任何日志存储一样等它的耐久性白皮书；在那之前把 K2 当边缘层、后面挂一个持久汇是稳妥姿势。 消费者租约的 ack/nack/extend 语义免去了独立的追踪器。
Basin Pipelines 的出身在设计里可见：K2 是摄取优先的——所以读侧先拿到了租约，写侧的速度还在路上。 单流 10GB 对 Kafka 存量是小的，对 Workers 应用是够的。 公测反馈将决定 Express 档到底该做成什么样。 对小团队来说，按应用计流的定价比按 GB 的费率更关键。 低延迟那半边交给 Queues 补位，一个平台把事件故事讲完整。