Browser Run：现基于 Cloudflare Containers 运行，速度更快、扩展性更强

我们基于 Cloudflare 的容器服务对 Browser Run 进行了重构，从而实现了更高的使用限制、更快的性能以及更强的可靠性。

现在，通过 Workers 绑定，您每分钟可以启动 60 个浏览器实例，并同时运行多达 120 个——这是此前限制的 4 倍。此外，快速操作的响应时间也降低了 50% 以上。您无需进行任何更改：这些改进现已生效。在此基础上，我们修复问题和推出新功能的速度也比以往更快。请继续阅读，了解我们是如何做到的，并查看相关数据。

提醒一下：什么是 Browser Run？

Browser Run 使开发者能够以编程方式控制并交互运行在 Cloudflare 全球网络上的无头浏览器实例。这对于 Web 应用的端到端测试、安全地调查可疑 URL，以及利用浏览器轻松渲染 PDF 文档等功能非常有用，此外还包括截图和内容提取等快速操作。最近，它已成为 AI 智能体与网络交互的关键赋能工具。我们正在将 Browser Run 打造成一个首选平台，以便在大规模场景下负责任且安全地使用自动化浏览器。

突破原有架构的局限

在采用 Cloudflare 容器服务之前，我们与 Browser Isolation（BISO）共享基础设施。虽然技术上相似，但 BISO 更大的容器镜像拖慢了启动速度和开发进程。关键在于，BISO 的浏览器缺乏最优的全球分布，影响了弹性和延迟。此外，BISO 用户通常长时间、稳定的会话模式与 Browser Run 短促、突发的使用模式相冲突，造成了扩展瓶颈和可用性延迟。

幸运的是，经过大量的内部开发，Cloudflare 去年发布了支持 Durable Object（DO）的容器服务的公开测试版，这意味着我们已经准备好进行尝试性采用，而这最终使两个产品平台都受益。与大多数成功的产品平台一样，我们致力于在可行的情况下尽可能基于自身平台进行构建，以便在任何外部客户遇到问题之前，我们自己就能感知并解决痛点。

迁移过程：容器服务

我们启动了一项渐进式迁移，在传入请求路径中插入一个 Worker，为少量用户提供由 Container 驱动的浏览器，同时保留 BISO 方案。开发阶段的这种双轨支持至关重要：它让我们能够对比性能、隔离实现缺陷，并最终对 Container 驱动方案的优势建立起信心。

在逐步扩大采用范围的过程中，我们首先将 Container 浏览器用于所有快速操作端点，随后用于通过免费账户的 Workers 浏览器绑定的连接，接着是即付即用账户，以验证稳定性，最后才推广至所有剩余合同客户，确保整个过渡过程无需客户采取任何操作或重新部署现有 Worker。

挑战：性能与规模瓶颈

不过，在我们这边，面对一个全新的、不稳定的早期 Containers 平台接口，我们遇到了一系列新挑战：文档匮乏、可观测性不足，且处于重叠时区的同事也很少。然而，作为零号客户，我们向自身团队提供的反馈形成了紧密的反馈闭环，推动了重大升级，这些升级同样惠及我们的外部客户。尽管如此，初期仍有许多摩擦需要克服，其中大部分对于处于积极开发中的封闭测试版来说都是意料之中的。其他障碍则源于新的技术环境本身。

例如，一旦我们的浏览器能够在全球范围内运行，我们的架构就必须随之调整。启用 DO 的 Containers 会尽可能在靠近传入请求的位置创建一个 Durable Object，但与之连接的 Container 却可能在地球另一端启动。这对于“启动我的应用”这类一次性消息来说没有问题，但当你在两者之间建立 WebSocket 连接，并为一次截图请求交换数十条消息时，那些跨越全球的额外毫秒数就会开始累积。

我们的解决方案是什么？创建区域性的预热 DO 后端浏览器容器池，以限制 DO 与容器之间的最大距离（从而限制最大延迟）。当请求到来时，我们在该区域内选择离用户最近的 DO-容器对。这样能保持两跳的延迟都很低：用户到 DO，以及 DO 到容器。这给我们的整体架构增加了几个活动部件，但我们认为只要能够观测到每个浏览器的全局状态，从而根据需求变化分配和重新分配容量，这么做就是值得的。在某种程度上，这是 Workers KV 的完美用例……

自去年年初以来，对无头浏览器的需求一直在攀升。简而言之，AI 智能体开发者发现了 Browser Run，并迅速将请求量推高到超出我们现有容量的水平。我们很快就达到了通过可扩展方式调整池容量以满足这一新需求的速度极限。KV 大约 30 秒的最终一致性成为了我们关键请求路径上的瓶颈。你可能会检查 KV，看到一个容器标记为“可用”，但当你路由到它时（30 秒后），它已经被占用了。这种延迟造成了竞态条件和浏览器的过度分配，严重限制了我们扩展以应对需求激增的速度。

从 KV 迁移到 D1 + Queues

我们之前将每个容器的状态存储在 KV 中。这意味着由于缓存 TTL（最近 KV 将最小缓存 TTL 改为 30 秒，但即便如此，这个值仍然太高），我们可能一直获取到一分钟前的旧状态。

我们决定将容器状态迁移到 D1 实例中。D1 的事务性特性非常适合这里。一旦我们将一个浏览器分配给某个用户，它就完全属于该用户。浏览器不是共享资源。SQLite 事务确保了原子性分配，并防止了两个请求可能同时认领同一个浏览器的竞态条件。

以下是我们浏览器获取查询的简化版本：

WITH candidate_pool AS (
    -- candidate pool logic to pick based on latency and other rules
)
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
    SELECT sessionId
    FROM candidate_pool
    ORDER BY RANDOM()
    LIMIT ?5
)
RETURNING data

我们在每个地点都保留 D1 分片，考虑到我们可能运行数千个容器，并且每个容器需要每 5 秒更新一次状态，我们一直遇到一个问题：数据库会过载。例如，如果每次写入需要 1 毫秒，我们最多只能写入 1000 次，按每次写入一行计算，这意味着在数据库过载之前，我们最多只能有 5000 个容器。

然而，如果我们将这些写入操作批量处理，就能获得高得多的数值，因为批量写入的时间并不会比单次写入长太多，因此我们可以将吞吐量提升数个数量级。在我们的案例中，我们使用每批 100 行的批量写入，这意味着现在每个地点最多可以更新 50 万个容器。这种余量意味着容量规划不再是瓶颈。

目前，我们批量写入的 P95 延迟是 0.1 毫秒！

为了实现批量写入，我们使用了队列：每 5 秒，每个容器计算自身状态并将其添加到其所在位置的队列中。然后，我们配置一个工作消费者，其批处理大小为 100，批处理超时时间为 1 秒：

{
    ...
    "queues": {
        "consumers": [
            {
                "queue": "production-core-containers-queue-weur",
                "max_batch_size": 100,
                "max_batch_timeout": 1,
                "max_retries": 1,
            },
            ...
        ]
        ...
    }
}

通过这种配置，我们实现了远低于 2 秒的可接受延迟时间。话虽如此，队列积压仍然可能导致状态过时。当这种情况发生时，每个区域会回退到指定的备用区域，直到主队列赶上进度。

快速操作的额外优势

有了专用基础设施，我们现在可以对浏览器容器镜像进行升级，而不会给 BISO 等其他产品带来不良副作用或臃肿。这为优化截图和内容提取等快速操作打开了大门。此前，我们的 Worker 会与远程浏览器建立一个 WebSocket，然后逐一发送指令：打开页面、导航到 URL、等待页面加载并截取屏幕截图。每一步都必须在上一步完成之后才能开始。

然而，现在我们将所有参数通过单个 HTTP 请求直接发送到容器，整个流程在内部执行，无需 Worker 和浏览器之间进行任何来回通信。

结果：性能大幅提升，限制也得以放宽。

我们观察到平均快速操作响应时间显著下降，用户现在能在更短时间内从浏览器会话中获取所需内容：等待浏览器就绪的时间缩短了，DevTools 协议消息的处理速度也更快了。

在新规模下攻克实时状态管理难题，意味着我们能有更多时间在试验场中探索和开发新功能，例如我们近期推出的 `/crawl` 端点。

更好的浏览器灵活性

我们还从另一个重要优势中受益——告别共享的浏览器隔离容器后，升级速度更快了。

当我们的浏览器运行在共享产品基础设施上时，升级 Chrome 需要协调多个团队和产品，每个团队都有自己的路线图和优先级。但现在，我们运行自己的容器镜像，可以以更快的节奏进行升级。例如，备受期待的 WebGL 功能现已可用于基于浏览器的渲染，同时 WebMCP（面向网页的模型上下文协议）也已上线，支持全新的智能体交互模式。这两项功能之所以能够实现，是因为我们可以自主控制浏览器版本和标志位，而不会对其他 Cloudflare 产品产生不良影响。

简而言之，我们才刚刚开始释放大规模浏览器的潜力，尤其是在智能体开发领域。希望您也能加入探索——欢迎查阅我们的文档。

Browser Run 适用于所有 Workers 套餐。您可以从快速入门指南开始，探索快速操作功能，或尝试使用 `/crawl` 端点，通过跟踪网站链接，从任意网页深度提取数据。

正在构建 AI 智能体？欢迎了解我们的 Agents SDK，它内置了 Browser Run 支持。