当 David Crawshaw 在 2026 年 4 月宣布他正在构建一个新的云基础设施项目时，技术社区的反应既在意料之中，又带着一丝惊喜。作为 Tailscale 的联合创始人，Crawshaw 已经参与了行业内最具创新性的网络与安全项目。然而这一次，他的目标更加根本 —— 从头构建一个他自己真正想使用的云。
重新审视云计算的基本抽象
在讨论具体技术实现之前，有必要理解 Crawshaw 对现有云计算基础设施的根本性质疑。他认为当前云厂商提供的基础抽象存在结构性缺陷，这种缺陷并非简单的 UX 问题或 API 设计不佳，而是涉及更深层的架构选择。
虚拟机抽象的错误形态是首要问题。传统云厂商将 VM 与 CPU、内存资源紧密绑定，用户需要预先决定分配多少计算资源。然而，一个 Linux VM 本质上只是运行在另一个 Linux 进程 cgroup 中的容器，理论上可以在一台物理机上运行任意多个，前提是资源充足。当前云厂商的约束更多是商业策略而非技术必然。要突破这一限制，用户往往需要借助 gVisor 或嵌套虚拟化，但这会引入性能损失，同时还要自行处理反向代理等运维工作。
存储层的性能倒挂同样严重。云厂商倾向于推荐远程块设备，这在机械硬盘时代有一定合理性 —— 机械硬盘随机寻道需要 10ms，网络往返延迟 1ms 相对可以接受。但进入 SSD 时代，寻道时间降至 20 微秒，远程存储的 IOPS 开销从硬盘时代的 10% 跃升至超过 10 倍。一台配备 500k IOPS 的 MacBook 本地存储性能远超需要花费 $10k / 月配置的 EC2 实例，这显然是架构层面的讽刺。
网络成本的结构性压迫同样令人困扰。主流云厂商的出口带宽定价往往是自建数据中心成本的 10 倍以上，对于月支出仅数百美元的小项目而言，负担比例更加失衡。Kubernetes 等编排工具的出现部分缓解了这些问题，但其本质上是在为不可调和的抽象矛盾擦屁股 —— 试图让本质上不可移植的云服务变得可用，这本身就是一个不可能完成的任务。
VM 管理的工程实现
exe.dev 作为 Crawshaw 新项目的核心尝试，首先在 VM 管理层面实现了范式转换。与传统云厂商按 VM 实例计费不同，exe.dev 将 CPU 和内存视为可组合的资源池，用户获得的是计算能力本身，而非预先打包的虚拟机。这种设计允许更细粒度的资源调度和更低的空闲资源浪费。
在具体实现上，exe.dev 的 VM 强调快速启动能力，目标是将启动时间压缩至亚秒级。这需要精心设计镜像分层的加载策略、预热的运行时环境，以及高效的 hypervisor 调度。每个 VM 默认处于私有网络空间，通过平台提供的 TLS 代理和认证代理进行安全访问，而非直接将 VM 暴露至公网。
这种设计选择体现了「默认私有」的安全理念。新启动的 VM 不会立即获得公网 IP，所有外部访问必须通过平台的基础设施层进行身份验证和流量转发。这不仅简化了用户的安全配置工作，也降低了因配置失误导致的安全风险。
分布式存储的技术选型
在存储层面，exe.dev 做出了一个关键决策：使用本地 NVMe 存储，并通过异步复制实现数据保护。这一选择直接回应了前文所述的远程块设备性能问题。
本地 NVMe 提供了超低延迟和高 IOPS，对于现代工作负载至关重要。异步复制机制则确保了即使单节点发生故障，数据也不会丢失。与传统的同步复制相比，异步方式对写入延迟的影响更小，更适合对性能敏感的应用场景。
具体实施时需要考虑几个关键工程参数。首先是复制策略的配置，包括副本数量、复制拓扑和一致性模型。其次是快照机制的设计 —— 定期创建磁盘快照是灾难恢复的基础，需要在存储空间和恢复粒度之间找到平衡。最后是与 VM 生命周期的集成，当 VM 删除时，相关存储卷的清理策略也需要妥善处理。
对于自建云基础设施的开发者而言，ZFS 或 LVM 可以作为本地存储池的基础，配合 rsync 或专门的对象存储实现跨机器复制。关键在于避免远程块设备的延迟陷阱，同时确保数据安全不会因为本地故障而受损。
网络栈的设计哲学
网络层是 exe.dev 最能体现「云基础设施从零构建」理念的部分。项目采用 Anycast 网络技术，为全球用户提供就近接入点，显著降低访问延迟。Anycast 的核心优势在于让多个数据中心共享同一 IP 地址，路由协议自动将用户流量导向最近的节点。
在入口层面，平台负责 TLS 终止和身份验证代理。所有 HTTPS 流量首先到达边缘节点，完成加密握手和身份校验后，才通过安全隧道转发至后端 VM。这种架构不仅简化了用户的 TLS 证书管理流程，还提供了统一的身份验证入口，支持与现有身份系统的集成。
出口流量的优化同样重要。传统云厂商通过出口带宽收费牟利，而自建基础设施可以显著降低这部分成本。合理的网络架构应该尽可能利用免费或低成本的带宽来源，并对必要的出口流量进行精细化监控。
对于网络栈的工程实践，有几个可操作的关键参数值得关注：边缘节点的地理分布密度直接影响用户体验；TLS 代理的性能开销需要在加密强度和延迟之间权衡；身份验证层的扩展性决定了平台能支持的用户规模。建议将边缘节点部署在与目标用户群体地理位置接近的数据中心，并使用 HTTP/3 协议减少连接建立延迟。
实践启示与工程参数
从 Crawshaw 的实践中，我们可以提炼出构建个人云或私有云基础设施的核心工程要点。在 VM 管理方面，建议采用资源池化而非 VM 隔离的思路，最小化资源碎片；使用预热镜像实现亚秒级启动；通过 SSH API 提供程序化访问能力。
存储层面，优先选择本地 NVMe 而非网络块设备；实施异步复制保护数据；设计定期快照机制支撑恢复能力。网络的工程参数包括：使用 Anycast 实现全球低延迟接入；在边缘完成 TLS 终止和身份验证；默认私有连接，公网暴露需显式配置。
这些技术选型的核心逻辑可以归结为一句话：让基础设施回归计算本身的自由度。当云厂商的抽象成为束缚而非赋能时，从底层重新构建成为合理的选择。正如 Crawshaw 在博客中所言，他喜欢计算机，而现有的云产品让他无法尽情享受计算的乐趣 —— 这正是驱动这场基础设施革命的原始动力。