Cloudflare 宣布推出 workerd 的第一个 beta 版本，这是一个 JavaScript/Wasm 运行时；基于与 Cloudflare Workers 相同的代码，并在 Apache-2.0 许可下开源。Cloudflare Workers 是一个在公司的内容交付网络上运行的无服务器平台，旨在为任何地区的用户提供低延迟。

Cloudflare Workers 的技术负责人 Kenton Varda 介绍称，workerd 与支持 Cloudflare Workers 的运行时共享大部分代码，但进行了一些更改以使其更易于移植到其他环境。名称“workerd”源自 Unix 命名服务器的传统，使用“-d”后缀代表“daemon”。该名称没有大写是因为它是一个 program name，遵循了类 Unix 环境中的小写传统。

虽然它与 Cloudflare Workers 共享代码，但 Varda 指出，完整的 Cloudflare Workers 服务涉及到 workerd 本身之外的许多技术，包括额外的安全性、部署机制、编排等等。“workerd 本身是我们运行时代码库的一部分，它本身是整个 Cloudflare Workers 服务的一小部分（尽管很关键）。但我们很高兴，这意味着我们可以在一个宽松的开源许可下发布这段代码”。

根据介绍，通过 workerd，为 Cloudflare Workers 编写代码的开发者可以在本地、或自我托管、或在其他服务上运行代码，减少被锁定的风险。workerd 旨在促进对 Workers 进行实际的本地测试；以及可以用作 Web 服务器，充当应用程序主机、代理或两者兼而有之，其支持正向和反向代理模式。

Varda 指出，“在可能的情况下，Workers（尤其是 workerd）提供与 Web 浏览器中相同的标准 API，例如 Fetch、URL、WebCrypto 等。这意味着基于 workerd 构建的代码更有可能移植到浏览器以及其他基于标准的运行时”。

此外，workerd 还是一个 nanoservice 运行时。Nanoservices 是一种新模型，它实现了独立部署的好处，其开销更接近于库调用的开销。使用 workerd，可以将许多 Worker 配置为在同一个进程中运行。每个 Worker 运行在一个单独的“isolate”中，给人一种独立于其他运行的感觉：每个 isolate 加载单独的代码并具有自己的全局范围。然而，当一个 Worker 明确向另一个 Worker 发送请求时，目标 Worker 实际上以零延迟运行在同一个线程中。因此，它更像是一个函数调用。

不过有外媒指出，虽然这一设计性能友好，但却会影响安全性。workerd worker 的设计使其无法访问其未被授予访问权限的资源，但对于 workerd 本身或 V8 引擎中的错误或漏洞而言它并不安全，因此需要额外的安全保障。Varda 也表示，Cloudflare Workers 中的安全性部分并不包含在开源版本中。

他补充称，workerd 的一个主要好处是“它允许一种新的开发模型，你可以将应用程序拆分为更小的组件。在 Workers 上部署代码也比在传统云供应商上管理服务器要容易得多”。

至于为什么是 JavaScript/Wasm 而不选择 Java、.NET 或 Python 等其他语言。Varda 则解释道，“Containers 太重了以至于无法支持 nanoservices 模型......JavaScript 和 Wasm 是我们唯一可行的、可以满足我们的 isolation 需求的较轻量级的选择。其他语言的虚拟机一般都不是为这种细粒度的 isolation 用例设计的，也没有经过实战检验”。

Varda 还在 Hacker News 回答了一些网友提问，也有开发者反馈了一些 workerd 相关的积极评价。

更多详情可查看官方博客。