Healthchecks.io 迁移至自托管对象存储：延迟降低、性能提升，但成本有所增加

Healthchecks.io 采用自托管对象存储Healthchecks.io 的 ping 端点支持 HTTP HEAD、GET 和 POST 请求方法。使用 HTTP POST 时客户端可在请求体中包含任意有效负载Healthchecks.io 会存储请求体的前 100kB 数据。若请求体小会存储在 PostgreSQL 数据库否则存储在兼容 S3 的对象存储中。最近Healthchecks.io 从托管对象存储迁移到了自托管对象存储目前其 S3 API 由 Versity S3 Gateway 提供服务并由简单的 Btrfs 文件系统作为后端。托管方案变迁2022 年在实现将 ping 请求体卸载到对象存储时就开始评估对象存储提供商。AWS S3 按请求收费对 Healthchecks.io 使用模式成本高且因受《云法案》约束需对数据加密增加复杂性。最初选择 OVHcloud它不按请求收费是欧盟公司性能起初不错但后来性能和可靠性问题增多。2024 年迁移到 UpCloud它同样不按请求收费是欧盟公司服务质量有提升但随着时间推移性能也开始下降特别是 S3 的 DeleteObjects 操作变慢于是再次寻找替代方案包括自托管方案。需求分析截至 2026 年 4 月对象使用情况为1400 万个对象共计 119GB对象大小从 100 字节到 100000 字节不等平均对象大小为 8KB平均每秒有 30 次上传操作常飙升到每秒 150 次上传上传和删除对象操作频繁。候选对象存储系统需支持这种使用情况且有扩展空间。在可用性和耐久性方面对象存储对 Healthchecks.io 不如主要数据存储PostgreSQL 数据库关键。在延迟方面越快越好使用 UpCloud 时还添加了负载均衡逻辑以防止缓慢的 S3 操作引发问题。自托管方案考量对 Minio、SeaweedFS 和 Garage 进行本地实验主要顾虑是运维复杂性。要实现生产级设置至少需要自动化集群节点设置、学习并测试更新流程、学习并测试替换故障集群节点流程、为集群特定健康问题设置监控和警报。由于是单人团队且已运行自托管的 Postgres、自托管的 HAProxy 负载均衡器和自托管电子邮件所以倾向简单方案。Versity S3 Gateway 优势Versity S3 Gateway 可将本地文件系统转换为 S3 服务器S3 的 PutObject 操作在文件系统创建普通文件GetObject 操作从文件系统读取普通文件DeleteObject 操作从文件系统删除文件。它无需单独数据库存储元数据可用任何备份工具备份升级流程简单使用 Go 语言编写且正在积极开发发现并报告的一个 bug 几天内就得到修复。不过使用它和文件系统作为后端存储存在可用性和耐久性问题对象存储在单个系统可能无预警故障需做好准备。设置详情2026 年 3 月迁移到由 Versity S3 Gateway 驱动的自托管对象存储。S3 API 运行在专用服务器监听私有 IP 地址应用服务器通过 Wireguard 隧道与它通信对象存储在服务器本地驱动器采用 RAID 1 配置的两块 NVMe 驱动器对象存储在 Btrfs 文件系统使用 Btrfs 存储大量小文件无 inode 耗尽风险每两小时rsync 进程将新增和删除的文件同步到备份服务器每天备份服务器进行一次完整备份加密并存储到异地保留最近 30 天的每日完整备份。通过这种设置若对象存储服务器上两块驱动器同时故障系统最多丢失两小时内未备份的 ping 请求体。迁移结果切换到自托管对象存储后S3 操作的延迟降低等待上传到对象存储的 ping 请求体队列也缩短。目前新系统上线几周还未出现可用性问题。数据子处理方列表少了一个条目。成本有所增加租用额外专用服务器比在托管对象存储服务中存储约 100GB 数据成本高但性能和可靠性的提升是值得的。对新系统持谨慎乐观态度认为比旧系统有所改进若找到更优方案也会考虑再次迁移。Healthchecks.io 介绍Healthchecks.io 是免费的开源定时任务监控服务为定时任务设置监控只需几分钟。