Cloudflare K2：无服务器事件流

对于传统的远程过程调用 (RPC) 架构，存在一个核心挑战：生产者和消费者必须在规模和时间上保持一致。如果您的生产者发送了太多数据供您的消费者处理，或者如果您的消费者或下游服务不可用，则事件将被丢弃。由于多个消费者需要独立处理数据，这个问题变得更加复杂。例如，电子商务后端可能会在交易完成时发出事件，这些事件需要由分析系统和欺诈检测服务读取。我们可以通过将生产者和消费者解耦来解决这个问题——在中间插入一个服务来吸收写入，同时允许独立的读者按照自己的节奏消费。今天我们推出 Cloudflare K2 公测版来解决这个问题。 K2 是开发者平台上的持久事件流原语。您将事件发送到 K2 流，该流将它们存储为有序日志。消费者可以通过多种方式读取它们，例如通过一组消费者拆分读取，或者将所有消息传递给所有消费者。它完全无服务器，可扩展到大量数据，并支持长期保留，因此即使消费者长时间停机也不会丢失数据。在底层，K2 在 R2 对象存储之上实现了分区、持久的日志，这使其能够扩展到海量存储。如果您已准备好开始，则可以按照此处的指南在几秒钟内创建您的第一个流。边缘上的流我们首先构建 K2 是因为我们需要边缘上的持久缓冲区，最初用作 Basin Pipelines 的摄取层。 Pipelines 由流处理引擎提供支持，该引擎在基于拉取的模型上运行，这意味着其他一些系统必须在事件被读取、转换和写入 R2 之前存储事件。而且因为我们承诺一旦事件被接受到 Pipelines Stream 中，就永远不会删除它们，因此该存储必须在可能很长的时间内是持久的（这意味着它不会丢失数据）。这是大多数公司部署 Apache Kafka 的地方。然而，Pipelines 在 Cloudflare 边缘运行，该边缘跨越超过 335 个城市的大量服务器。我们独特的架构意味着我们通常无法运行像 Kafka 这样的传统分布式系统软件，需要重新思考这些系统的构建和运营方式。特别是对于有状态服务，Cloudflare 的全球基础设施带来了一些挑战：我们获得的机器相对较小，这些机器相对短暂，而且网络通常通过公共互联网进行。但我们的基础设施也有一些超能力：它靠近世界各地的用户，并且具有令人难以置信的水平扩展能力。在设计成为 K2 的持久缓冲系统时，我们决定依赖我们已有的强大状态原语：R2。像 R2 这样的对象存储系统将极其耐用的存储（11 个 9！）与高度一致的 API 结合起来。将复制和共识转移到存储层使我们能够使应用程序层（在本例中为 K2）变得更加简单、更便宜且性能更高。第二个好处是它将计算和存储分开，这意味着两者都可以独立扩展。这使我们能够以低成本存储大量历史数据。我们如何在对象存储之上构建日志？一个迫在眉睫的问题是，R2 与其他对象存储一样，不支持追加（日志上的标准操作）。相反，我们必须写入足够大的完整文件或段，以克服写入和读取每个文件的成本。我们首先通过在边缘服务上累积内存中的写入来实现此目的。等待一小段时间数据到达后，我们将所有事件写入段文件。我们使用 R2 的原子操作实现排序和严格递增偏移量，而不需要单独的协调服务。虽然基于 R2 构建有许多优点，但也有一个缺点：生成延迟较高。写入对象存储比本地磁盘慢，我们必须等待本地批次累积后再开始写入。在我们最初发布的 K2 中，这在响应时间的第 99 个百分位数处增加了约 1 秒的生成延迟。我们将在即将到来的技术深入探讨中分享有关 K2 设计的更多细节。流、队列还是管道？ Cloudflare 有多个现有的异步交付原语，包括 Queues 和 Basin Pipelines 。您什么时候应该选择 K2 而不是这些现有产品？队列和 K2 Streams 之间有一些表面上的相似之处：两者都接收事件，持久存储它们，并将它们传递给消费者。队列是围绕跟踪需要异步完成的昂贵或耗时工作的各个项目而设计的。例如，图像处理应用程序可以将用户请求排队以由实际图像处理服务处理。它们支持复杂的逻辑