RustFS：用 Rust 重写的 S3 兼容对象存储，接棒 MinIO 的开源候补

2024 年以来 MinIO 把许可证从 Apache 2.0 切到 AGPLv3，在商用圈引发了不小的连锁反应——不少团队开始寻找许可证更宽松的 S3 兼容替代。RustFS 就是在这个窗口期冒出来的：用 Rust 重写、主打 S3 兼容、Apache 2.0 许可，定位是”MinIO 的开源替代品”。本文基于其 GitHub 官方 README，客观拆解它的功能成熟度、授权差异与官方自己标注的边界。

一、是什么

RustFS 官方描述是”a high-performance, distributed object storage system built in Rust”，目标是”结合 MinIO 的简单易用与 Rust 的内存安全和原生性能”，面向数据湖、AI 与大数据高吞吐负载。它提供完整 S3 API 兼容（兼容度在专门的 S3 compatibility matrix 里追踪），并支持与 MinIO、Ceph 等其他 S3 平台迁移、共存。

它最鲜明的标签是许可证：Apache 2.0。README 特意强调”避免 AGPL 的限制”、“没有毒丸条款”，并在对比表里把自己的”permissive Apache 2.0、商业友好”与对手的”restrictive AGPL v3、许可陷阱风险”对立起来。配合”No Telemetry / 全合规”（GDPR、CCPA、APPI），它瞄准的正是对许可证与数据出境敏感的企业用户。

工程细节上也能看出它在刻意对齐 MinIO 的使用习惯：Docker 镜像以非 root 用户 rustfs（UID/GID 10001:10001）运行，bind-mount 数据/日志/TLS 目录时必须让该用户可写，否则会 permission denied 起不来；KMS 生产支持 Vault（KV2/Transit）与 AWS KMS 后端，Local/Static 后端仅供开发测试；扩缩池沿用 MinIO 的拓扑规则（单节点单盘只能当本地独立路径、不能原地扩成 Pool，要扩成多盘拓扑得新建部署再经 S3 迁数据），但自动 parity 选择与 MinIO 并不相同，官方要求扩容前先看 pool layout 兼容与回归测试。

二、功能成熟度：大部分已 GA，少数仍 Preview

README 用”✅ Available / 🧪 Preview”两档给功能标注成熟度。已 GA（CI 门禁覆盖） 的能力相当齐全：

• S3 核心：上传下载、版本控制、对象锁（WORM）、服务端加密、KMS、ILM 生命周期与远程 S3 分层、S3 Select；
• 分布式：分布式模式/单节点模式、bitrot 校验、自愈与扫描器（healing & scanner）、扩缩池与退役（pool expansion/decommission）、桶复制、站点复制、桶配额、事件通知；
• 接入面：IAM/策略、OIDC/SSO、OpenStack Keystone 认证、Swift API、多租户、Web 控制台、K8s Helm Chart、FTPS/WebDAV、SFTP、审计日志与可观测性。

仍处 Preview（🧪） 的两项很关键：

1. S3 Tables：以 Iceberg REST Catalog 形式交付，目前自动化覆盖 PyIceberg 与 DuckDB，其他引擎的支持是”有界声明”；
2. MinIO 磁盘格式兼容：藏在 rio-v2 feature 后、不在默认构建里，而且MinIO 加密过的对象 RustFS 读不出来。

S3 Tables 这条线值得多说一句：它说明 RustFS 不只做”存文件的桶”，而是想顺着 Iceberg 往数据湖表格式方向走——让对象存储直接当 Lakehouse 的存储层，用 SQL/分析引擎（DuckDB、PyIceberg）直接查桶里的表。这与它”优化数据湖与 AI 负载”的定位一致，但目前只有 Iceberg REST Catalog 这一条窄路，且其他引擎未做自动化覆盖，离”通用湖仓存储”还有距离。

三、关键数据与”高性能”口径

README 给出的压测环境相当克制：2 核 Intel Xeon Platinum 8475B（Sapphire Rapids，2.7/3.2GHz）、4GB 内存、15Gbps 网络、4 块 40GB 盘（单盘 3800 IOPS）。但正文里没有公布具体吞吐/IOPS 数字，性能对比只放了一个 rustfs.mp4 视频和一张定性对比表（“Rust 内存安全 vs Go/C 可能 GC 停顿”、“Apache 2.0 vs AGPL”）。

四、评测方法的偏向

• “比 MinIO 快”是主张而非数字：README 没有给出与 MinIO 在相同硬件上的 IOPS/吞吐 P50/P99 对比表，所谓”superior speed”缺乏可复现的量化证据；
• 对比表是自评：“Other Object Storage”一栏被描述成”basic console / 可能 GC 停顿 / 许可风险”，是营销话术而非中立 benchmark；
• S3 兼容是”覆盖矩阵”而非全量：官方自己都建议查 compatibility matrix，意味着并非所有 S3 API 行为都对等；
• 拓扑规则”遵循 MinIO 但自动 parity 选择不同”：README 特意警告扩容前要看 pool layout 兼容测试，说明从 MinIO 迁移不是无缝。

五、优势与局限

优势：

1. 许可证友好：Apache 2.0，无 AGPL 传染风险，对商业产品友好；
2. 功能面广：WORM、SSE、KMS、ILM、复制、Keystone/Swift、多租户、K8s Helm 都已 GA；
3. 内存安全：Rust 从语言层面减少 GC 停顿与内存泄漏风险；
4. 无遥测、合规友好。

局限（官方自认或隐含）：

1. 项目年轻：Koala 明确”不建议生产使用”，存储是长周期打磨的严肃事；
2. 性能数字不透明：无可复现的横向 benchmark；
3. MinIO 磁盘格式兼容仍 Preview，且 MinIO 加密对象读不出，迁移有坑；
4. Swift/SFTP 需 opt-in cargo feature，非默认开启；
5. 扩缩池规则与 MinIO 不完全一致，迁移需仔细核对 parity 选择。

六、谁该关注

• 受够 AGPL、需要宽松许可 S3 存储的创业团队：Apache 2.0 对商业分发友好；
• 边缘/IoT 与数据湖、AI 负载场景：Rust 内存占用与启动体积对边缘节点友好；
• 正在评估从 MinIO 迁出的团队：可先用 Preview 的磁盘格式兼容做 PoC，但要验证加密对象与 parity 差异；
• 要求生产级稳定、不能等的核心业务：建议等 GA 更成熟、社区案例更多后再上。

参考来源

• RustFS 官方 GitHub 仓库
• Koala 项目库条目：RustFS 高性能分布式对象存储