通过在 Cloudflare Containers 上重构 Browser Run，我们提高了后者的使用限制和可靠性，改善了性能。
如今，通过 Workers 绑定，用户每分钟可以启动 60 个浏览器实例并同时运行多达 120 个浏览器实例，是之前限制的 4 倍。此外，快速操作的响应时间也缩短了 50% 以上。用户无需进行任何更改：这些改进功能已在今天上线。不仅如此，我们还将以前所未有的速度发布修复程序和新增功能。请继续阅读，了解 Cloudflare 如何做到这一点，并查看相关数据。
Browser Run 让开发人员能够以编程方式控制运行在 Cloudflare 全球网络上的无头浏览器实例并与之交互。这对于 Web 应用的端到端测试、安全地调查可疑 URL 以及利用浏览器轻松渲染 PDF 文档等功能非常有用；此外，它还可以执行其他快速操作，例如捕获屏幕截图和提取内容。最近，它已成为 AI 智能体与 Web 交互的重要工具。我们正努力将 Browser Run 打造成一个首选平台，用于以负责任的态度大规模、安全使用自动化浏览器。
在采用 Cloudflare Containers 之前，我们与浏览器隔离 (BISO) 共享基础设施。虽然技术上类似，但 BISO 更大的容器镜像减缓了启动和开发速度。关键问题是，BISO 浏览器缺乏最佳的全球分布，影响了韧性和延迟。此外，常规 BISO 用户长时间、稳定的会话与 Browser Run 短时间、峰值使用模式相冲突，产生了扩展瓶颈和可用性延迟。
值得庆幸的是，经过大量的内部开发，Cloudflare 去年发布了支持 Durable Object (DO) 的 Containers 开放测试版，这意味着我们已经准备好进行初步采用，从而最终让两个产品平台都受益。与大多数成功的产品平台一样，Cloudflare 致力于尽可能在自有平台上开发，以便我们能够先于外部客户发现并解决任何痛点。
我们开始了逐步迁移，首先是在传入请求路径中插入一个 Worker，为部分用户提供容器技术提供支持的浏览器，并与 BISO 的浏览器一同使用。开发过程中的这种双重支持至关重要：这让我们能够比较性能、隔离实施中的错误，并最终增强对容器技术支持方法带来的优势的信心。
为了加快采用，我们首先在所有快速操作端点中使用容器浏览器，然后通过 Workers 浏览器绑定在免费账户中连接容器浏览器，接着在按需付费账户中使用以验证稳定性，然后再推广到所有剩余的合同客户，从而确保过渡过程无需客户执行任何操作或重新部署现有 Worker。
然而，我们自身也面临着一系列新的挑战：熟悉一个全新、不稳定的早期 Containers 平台界面，该平台文档匮乏、可观察性不足，而且同一时区的同事也很少。不过，作为零号客户，我们向团队内部提供的反馈意味着我们可以建立一个紧密的反馈循环，从而带来实质性的重大升级，这也同样惠及我们的外部客户。尽管如此，初期仍需克服很多摩擦，其中大部分是活跃开发期间封闭测试阶段常见的各种问题。需要克服的其他障碍则是新技术环境固有的问题。
例如，一旦我们的浏览器能够在全球范围内运行，我们的架构就必须进行相应的调整。支持 DO 的 Containers 会在尽可能靠近传入请求的位置创建 Durable Object，但连接的容器可能在世界的另一端启动。对于像“启动我的应用”这样的一次性消息，这种方法效果尚可，但当需要在容器之间建立 WebSocket 连接并交换数十条消息来完成屏幕截图请求时，这些跨越全球的额外毫秒延迟就会开始累积。
我们的解决方案是什么呢？创建区域性预加载 DO 支持的浏览器容器池，以限制 DO 与容器之间的最大距离（从而最大限度地减少延迟）。当请求到达后，我们会选择该区域内距离用户最近的 DO-容器对。这可以保持用户到 DO 以及 DO 到容器的两跳延迟都很低。虽然这会给我们的整体架构增加一些额外组件，但我们认为只要能够观察每个浏览器的全局状态，并根据不断变化的需求来分配和重新分配容量，那就值得这样做。在一定程度上，这是 Workers KV 的一个理想应用场景。
自去年年初以来，对我们无头浏览器的需求一直在激增。简而言之，AI 智能体构建者发现了 Browser Run，并且迅速带来了超出我们现有容量的请求量。我们很快就发现，调整资源池容量跟不上新需求的增长速度，需要采用可扩展方法来满足这一新需求。KV 的最终一致性大约是 30 秒，这成为了我们关键请求路径上的瓶颈。用户可能在 KV 中看到某容器显示“可用”，但当请求路由到该容器时（30 秒后），它已经被占用。这种延迟会导致竞争条件和浏览器资源过度分配，进而严重限制我们快速扩展以应对需求高峰的能力。
之前，我们将容器的状态存储在 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 行批量写入，这意味着现在每个位置最多可以更新 500,000 个容器。这种额外的容量表明，容量规划不再是瓶颈。
目前，我们的批量写入 P95 仅为 0.1 毫秒！
为了批量写入，我们使用 Queues：每隔 5 秒钟，每个容器会计算自身状态并将其添加到其位置队列中。然后，我们 配置一个 Worker 消费者，批量处理大小为 100，批量处理超时为 1 秒：
{
...
"queues": {
"consumers": [
{
"queue": "production-core-containers-queue-weur",
"max_batch_size": 100,
"max_batch_timeout": 1,
"max_retries": 1,
},
...
]
...
}
}
通过这种配置，我们实现了远低于 2 秒的可接受延迟时间。尽管如此，队列积压仍然可能会导致状态过时。出现这种情况时，每个区域会回退到指定的备份区域，直到主队列赶上为止。
利用专用基础设施，我们现在可以升级浏览器容器镜像，而不会对 BISO 等其他产品造成不必要的副作用或膨胀。这增加了执行快速操作的机会，例如优化屏幕截图和内容提取。以前，我们的 Workers 会与远程浏览器建立 WebSocket 连接，并依次发送指令：打开页面、导航到 URL、等待页面加载，以及进行屏幕截图。必须完成每个步骤，然后才能开始下一步。
然而，我们现在只需向容器发送一个 HTTP 请求，即可将所有参数直接发送到容器，整个流程在内部执行，无需 Worker 与浏览器之间进行任何来回通信。
我们发现平均快速响应时间显著缩短，因为用户能够更快速地从浏览器会话中获取所需信息：浏览器准备就绪的等待时间缩短，DevTools 协议消息处理速度加快。
克服这种大规模实时状态管理难题，意味着我们可以投入更多时间进行开发，探索和开发新增功能，例如我们最近推出的 /crawl 端点。
放弃共享的浏览器隔离容器后，我们还获得了另一个重要优势：更快的升级速度。
如果在共享的产品基础设施上运行我们的浏览器，升级 Chrome 意味着需要协调多个团队和产品，而每个团队和产品都有各自的路线图和优先事项。不过，现在我们运行自己的容器镜像，因此可以更快地进行升级。例如，WebGL 是一项备受需求的功能，现已支持基于浏览器的渲染，同时还支持 Web 模型上下文协议 (WebMCP)，从而实现新的智能体交互模式。这两项功能的实现得益于我们可以控制浏览器版本和标志，而不会对其他 Cloudflare 产品产生不良影响。
简而言之，我们才刚刚开始大规模释放浏览器的强大功能，尤其是在智能体开发方面。我们希望用户也能积极参与其中参与其中，欢迎查看我们的文档。
Browser Run 在所有 Workers 计划中均可使用。首先是快速入门指南，也可以探索快速操作，或尝试使用 /crawl 端点，从任何网页深入提取数据并跟踪网站上的链接。
正在构建 AI 智能体？欢迎了解我们内置 Browser Run 支持的 Agents SDK。