一家监控服务为何放弃云存储：Healthchecks.io 把 S3 搬回了自己的机房

从“上云”到“搬回来”，这不是怀旧，而是算明白了账

做监控服务的人，往往比别人更早感受到基础设施的情绪波动。Healthchecks.io 就是这样一个典型案例：它为定时任务、脚本和后台服务提供“心跳”监控，用户只要定期向它发一个 ping，它就知道你的任务还活着。这个产品本身不复杂，但它处理的场景很真实——服务器备份有没有跑完、定时任务有没有卡死、某个内部服务是不是悄悄失联。

这次 Healthchecks.io 宣布的变化，看起来只是后端架构更新：对象存储从托管服务迁移到了自建方案，S3 API 由 Versity S3 Gateway 提供，底层直接落在一台服务器上的 Btrfs 文件系统里。可如果你长期关注 SaaS 和云基础设施，会发现这背后不是“折腾”，而是一种越来越多独立开发者和中小服务商开始做出的判断：当托管云服务在关键场景里既不够稳、也不够快，所谓“省心”就不一定成立了。

Healthchecks.io 的需求其实很有代表性。用户发送 HTTP POST 请求时，请求体内容会被保存下来，小的直接进 PostgreSQL，大一点的则放进兼容 S3 的对象存储。现在它管理着大约 1400 万个对象，总量 119GB，平均每个对象只有 8KB 左右。这是个很有意思的数字：总量不算大，但文件极碎、上传删除频繁，平均每秒 30 次上传，高峰可到 150 次，而且对象一直在生成、删除、轮换。对很多云对象存储来说，这种“碎片化高频操作”远比存几百 GB 大文件更磨人。

云对象存储并不总是“又快又便宜”

过去几年，很多开发者已经把 S3 当成一种近乎默认的基础设施。要存文件？上 S3。要归档日志？上 S3。要让应用解耦？再加一个对象存储。问题在于，S3 这个概念被 AWS 教育得太成功了，以至于人们容易忽略一件事：不同厂商的“兼容 S3”，在性能、稳定性、计费方式和运维体验上差异可以非常大。

Healthchecks.io 最早没有选 AWS S3，一个重要原因是请求计费。对于它这种业务模式，每个足够大的 ping 请求都可能触发一次 PutObject，请求次数非常密集。如果按请求收费，成本会被不断放大。另一个原因也很现实：AWS 受美国 CLOUD Act 约束，涉及数据主权和隐私合规时，欧洲开发者天然会更谨慎。于是它先后选择了两家欧洲供应商：OVHcloud 和 UpCloud。

起初这两个选择都说得通。没有按请求收费，地理和法律辖区也更友好，听上去很适合一个面向全球、但又希望尽量控制复杂度的小团队产品。可问题在于，托管服务真正的考验不在宣传页，而在长时间运行后的稳定性曲线。Healthchecks.io 的作者提到，OVHcloud 后来出现越来越多的性能与可靠性问题；2024 年迁移到 UpCloud 后，服务质量一度明显改善，但时间一长，性能又开始下滑，尤其是 DeleteObjects 这样的操作，变得越来越慢，甚至会触发超时。

这恰恰是托管对象存储最让人无奈的地方：它不是坏到完全不能用，而是那种时好时坏、慢得很难预测的状态。对面向用户的应用来说，最危险的不是报错，而是“拖”。一次对象操作卡住几秒，Web 进程就可能被拖住；如果这种慢扩散到请求链路里，问题会从一个存储 API，变成全站吞吐下降。Healthchecks.io 甚至不得不加入“负载削峰”逻辑，专门防止慢 S3 操作拖垮系统。说白了，云厂商没把你服务打死，但它在不断消耗你的工程耐心。

为什么他没有选 MinIO，而是选了更“土”的方案

听到“自建对象存储”，很多工程师第一反应会是 MinIO、SeaweedFS、Garage 这些名字。Healthchecks.io 也确实都试了，但最后没选。原因不神秘：这些系统并不难启动，难的是把它们长期、稳定、可恢复地跑在生产环境里。

对于一个只有一人维护的团队来说，真正可怕的从来不是安装命令，而是后面的责任链。你要自动化集群部署，要摸清升级流程，要演练坏节点替换，要补上监控和告警，还要在凌晨三点能解释“为什么副本状态不一致”。如果团队本来就已经自托管 PostgreSQL、HAProxy，甚至连事务邮件都自己管了，再把一个完整的分布式对象存储集群背到身上，确实有点像给自己加班买会员。

最后，他选了一个思路非常“返璞归真”的方案：Versity S3 Gateway。这个工具的逻辑简单到甚至有点可爱——S3 的 PutObject 就是在文件系统上创建普通文件，GetObject 就是读文件，DeleteObject 就是删文件，没有单独的元数据数据库，不需要复杂集群，大多数备份工具都能直接工作。升级方式也很朴素：替换一个二进制文件，重启 systemd 服务。

这种设计在今天的云原生语境里，多少有点逆流而上。它不像现代分布式存储那样充满弹性、复制、纠删码、自动均衡这些高级词汇，但它有一个很实际的优点：可理解。你知道数据在哪，知道文件怎么备份，知道出了问题先看哪里。对小规模业务来说，这种“透明”本身就是可靠性的一部分。复杂系统常常不是输给故障，而是输给没人能快速解释故障。

单机不性感，但对小团队可能更诚实

当然，这套方案有明显短板，而且短板就摆在台面上：单机。对象都放在一台专用服务器上，两块 NVMe 做 RAID 1，文件系统用 Btrfs；应用服务器通过 WireGuard 内网访问这个 S3 网关。每两小时用 rsync 同步到备份服务器，备份机每天再做全量备份、加密并异地保存，保留 30 天。

这意味着什么？意味着如果这台对象存储服务器的两块盘同时出问题，最多可能丢失最近两小时还没来得及同步的 ping 请求体。放在金融核心账本、交易系统、医疗影像里，这显然不合格；但放在 Healthchecks.io 这个场景里，影响是可以接受的。因为对象存储里装的并不是主数据库，而是附加的请求体内容。它挂了，用户暂时看不到请求详情，但监控和告警主功能不会立刻瘫痪。

这里有一个很值得行业反思的点：不是所有数据都必须被同等对待。过去几年，很多团队习惯把所有系统都往“高可用、分布式、全冗余”方向堆，结果是系统越来越贵、越来越复杂，真正的风险反而变成了维护能力不足。Healthchecks.io 这次的选择，实际上是一种更成熟的分层思维——核心数据和非核心数据，应该拥有不同级别的成本结构和可靠性设计。你不需要用航天级方案去保护每一份 8KB 的调试载荷。

换个角度看，这也是独立 SaaS 经营哲学的一部分。很多中小产品不是没有技术理想，而是必须在“最好”与“能长期活下去”之间找平衡。单机听起来不酷，但如果它快、稳、好管、坏了也有备份，某种意义上比一套没人完全掌握的分布式集群更现代。真正现代的工程观，不是迷信分布式，而是知道什么时候不该分布式。

性能变快了，成本却更高：这笔账值得吗？

迁移后的结果很直接。作者给出的监控图显示，S3 操作延迟明显下降，等待上传到对象存储的请求体队列也缩短了。换句话说，过去那个会在后台悄悄拖慢整个系统的瓶颈，现在至少短期内消失了。对于监控服务来说，这种收益并不只是页面打开更快，而是尾部延迟下降、服务行为更可预测，工程师晚上能睡得更踏实。

有意思的是，成本并没有因此下降。新增一台专用服务器，租金显然高于把 100 多 GB 数据放在托管对象存储里。也就是说，这不是一个“降本故事”，而是一个“花更多钱，买更低不确定性”的故事。放在当下的科技产业语境里，这一点反而显得很真实。云计算早年卖的是弹性和免运维，后来越来越多团队发现，自己真正购买的还有另一种东西：把命运交给供应商的便利。而这种便利，一旦碰到长尾性能问题，就可能变成脆弱。

这也是为什么我觉得 Healthchecks.io 这次迁移很有象征意义。它提醒大家，云不是答案，云只是选项。对大公司而言，自建对象存储是常规操作；对小团队和独立开发者而言，过去这条路往往因为复杂度太高而不现实。现在，像 Versity S3 Gateway 这类“薄层 S3 抽象 + 传统文件系统”的工具出现后，中间地带被打开了：你不必自己造 Ceph，也不必完全依赖外部云服务。

接下来值得观察的问题是，这类轻量自建方案能走多远。两周的稳定运行当然是个好开头，但基础设施的真正考试常常发生在半年、一年以后：磁盘老化时怎样，备份恢复演练是否顺畅，文件数继续上涨后性能会不会变化，Btrfs 在这个负载模型下会不会冒出新坑。这些都还需要时间回答。

但至少现在，Healthchecks.io 给行业丢出了一句很朴素、也很有分量的话：当托管云存储开始妨碍产品体验时，把它搬回来，不丢人，甚至可能是更理性的工程决策。毕竟，用户从来不关心你是不是“云原生”，他们只关心那个告警，到底能不能准时发出来。