当我们谈论云计算时，往往默认指的是 AWS、 GCP、阿里云这些 hyperscaler 提供的公共服务。然而，对于追求极致控制力、隐私保护或成本优化的开发者而言，自建云基础设施正在成为一种可行且富有吸引力的选择。这一趋势的核心驱动力不仅来自对现有云服务的不满，更源于 AI 代理时代的软件产出量激增 —— 我们需要更灵活、更贴近物理硬件的计算抽象。
现有公有云的架构困境
David Crawshaw 在其关于构建云服务的博文中深刻指出了当前公有云产品的几个根本性问题。首先，虚拟机的抽象形态存在缺陷。云计算厂商将虚拟机与 CPU、内存资源紧密绑定，导致用户必须预先规划容量并为整个实例付费。而在实际场景中，一台 Linux 物理机本质上只是一个运行在 cgroup 中的进程，理论上可以承载多个隔离的运行环境。这种资源利用率的错配在开发测试场景中尤为明显 —— 开发者可能只需要短暂的计算资源，却被迫按小时甚至按月付费。
其次，存储层的抽象同样面临尴尬处境。早期的远程块设备设计基于机械硬盘的特性：机械硬盘的随机 seek 时间约为 10 毫秒，因此 1 毫秒的网络往返延迟完全可以接受。然而，随着 SSD 的普及，本地 NVMe 延迟已降至 20 微秒级别，远程存储的 IOPS 开销从原来的 10% 飙升至超过 10 倍。以 AWS EC2 为例，配置 200,000 IOPS 的存储方案每月费用高达 10,000 美元，而一台普通 MacBook 本地就能达到 500,000 IOPS。这种性能倒挂使得云存储在高性能场景下反而成为瓶颈。
网络成本则是另一个被严重低估的问题。主流云厂商的 egress 流量价格通常是自建服务器的 10 倍以上。对于中小规模的个人项目而言，每月流量费用可能轻松超过计算资源本身。更关键的是，网络抽象的受限使得跨云数据迁移和私有互联变得极为困难，实质上形成了供应商锁定。
自托管云的核心设计原则
构建个人云基础设施需要从底层重新思考抽象层次。参考前述分析，以下几个设计原则值得遵循。
计算资源池化而非实例化。传统虚拟机的粒度过粗，更好的做法是将 CPU、内存、存储视为独立池化资源，按需分配。这类似于 exa.dev 提供的思路 —— 用户购买的是原始计算能力，而非预定义的虚拟机规格。在个人环境中，可以采用轻量级虚拟化方案如 gVisor 或 Firecracker 实现隔离，同时利用容器编排层实现资源复用。
存储就近原则。除非存在跨地域冗余需求，否则应优先使用本地 NVMe 存储。对于必须使用网络存储的场景，考虑自建分布式存储系统如 Ceph 或 MinIO，而非直接依赖云厂商的块存储服务。本地存储不仅性能更优，在成本控制上也更具可预测性。
网络架构简化。对于个人和小团队使用场景，完全可以考虑采用静态 IP 加反向代理的轻量方案，避免引入 Kubernetes 带来的复杂性。Tailscale 等零信任网络工具可以有效解决远程访问和节点互联问题，同时保持相对简单的运维负担。
落地实践的关键路径
对于计划构建个人云的开发者，建议从以下步骤开始。首先评估真实负载特征：如果是开发测试环境，轻量级虚拟化加容器方案即可满足；如果是生产级应用，则需要更严肃的隔离方案和冗余设计。
硬件选型上，入门级可以采用二手服务器或高性能工作站，配合 Proxmox 或裸金属方案实现虚拟化。进阶玩家可以考虑构建小型集群，使用 etcd 或 Consul 实现状态一致性。存储方面，企业级 NVMe SSD 配合 ZFS 可以提供兼具性能和数据保护的本地方案。
自动化运维是个人云得以持续运行的关键。Ansible 或 Terraform 可以管理基础设施即代码，配合监控告警系统实现故障自愈。值得注意的是，个人云的运维投入需要与实际使用规模匹配 —— 过度工程化反而违背了自托管的初衷。
资料来源：本文核心观点参考自 David Crawshaw 的博客文章《I am building a cloud》（crawshaw.io/blog/building-a-cloud），该文详细阐述了当前公有云架构的局限性及新型云计算服务的设计理念。