MinIO 的 AGPL 困局，被一个 Rust 项目撕开了口子
一家公司想自建对象存储。技术选型会上，工程师说："用 MinIO 吧，Go 写的，S3 兼容，社区活跃。"法务翻到协议那一行，脸色变了——AGPLv3。
一个让法务头疼的协议
一家公司想自建对象存储。技术选型会上，工程师说："用 MinIO 吧，Go 写的，S3 兼容，社区活跃。"法务翻到协议那一行，脸色变了——AGPLv3。
AGPL 的杀伤力在于"网络使用条款"。GPL 只在分发软件时触发开源义务，AGPL 在"通过网络提供服务"时也触发。这意味着：如果你用 MinIO 搭一个 S3 服务对外提供，你的整个服务端代码（包括调用 MinIO 的业务逻辑）理论上都得开源。
大公司的法务部门看到 AGPL 就头疼。Google 内部直接禁用 AGPL 协议的依赖。阿里、腾讯、字节都有类似的内部红线。结果就是：MinIO 功能再强、性能再好，很多企业根本不敢碰。
替代选项不多。Ceph 太重，部署复杂，适合超大规模场景。AWS S3 太贵。自研？没那个工程能力。
rustfs/rustfs 切入的就是这个空档：用 Rust 重写一个 MinIO 的等价物，但用 Apache 2.0 协议发布。
RustFS 是什么
一句话：RustFS 是一个用 Rust 写的、S3 兼容的、分布式对象存储系统，Apache 2.0 协议。
它的定位非常清晰——对标 MinIO，但在两个维度做差异化：
1. 协议：Apache 2.0（宽松，商业友好）vs MinIO 的 AGPLv3（传染性，商业受限） 2. 语言：Rust（内存安全 + 零成本抽象）vs Go（GC + 运行时）
这两个差异点不是随机的，而是相互强化的。AGPL 协议让企业不敢用 MinIO，Apache 2.0 让企业敢用 RustFS。Rust 的内存安全让 RustFS 在系统编程层面比 Go 更安全（无 data race、无空指针解引用），而性能层面两者差距不大——Go 的 GC 在对象存储这种 I/O 密集场景里不是瓶颈，但 Rust 的零成本抽象让锁-free 数据结构和无分配热路径成为可能。
特性矩阵：和 MinIO 的全面对标
RustFS 的特性表读起来像 MinIO 的镜像：
| 特性 | RustFS | 说明 |
|---|---|---|
| S3 Core API | ✅ | 完整 S3 兼容 |
| 分布式模式 | ✅ | 横向扩展 |
| 单节点模式 | ✅ | 小规模部署 |
| 版本控制 | ✅ | 对象历史 |
| Object Lock (WORM) | ✅ | 合规留存 |
| 服务端加密 | ✅ | SSE-S3/SSE-KMS |
| Bitrot 保护 | ✅ | 静默错误检测 |
| 纠删码 + 自愈 | ✅ | 数据冗余 |
| 桶复制 | ✅ | 跨区域同步 |
| 站点复制 | ✅ | 多站点灾备 |
| 生命周期管理 | ✅ | 自动分层/过期 |
| IAM/策略 | ✅ | 细粒度权限 |
| OIDC/SSO | ✅ | 企业身份集成 |
| OpenStack Swift API | ✅ | 多协议支持 |
| SFTP/FTPS/WebDAV | ✅ | 文件协议 |
| K8s Helm | ✅ | 云原生部署 |
| S3 Tables (Iceberg REST) | 🧪 Preview | 数据湖原生 |
S3 Tables：对象存储的数据湖化
2024 年 AWS re:Invent 发布 S3 Tables，把 Iceberg 表格式原生集成进 S3。这意味着你不再需要单独的 Iceberg catalog 服务（如 Glue、Nessie、Polaris），S3 本身就能管理表的元数据和 manifest。
这对数据湖架构是革命性的。之前的链路是：S3 存数据文件 → Glue/Nessie 存元数据 → Spark/Trino 查询。S3 Tables 把中间环节干掉了，变成：S3 Tables 存数据+元数据 → Spark/Trino 直接查。
RustFS 把这个能力带到了开源世界。它的 S3 Tables 实现是 Iceberg REST Catalog 兼容的，意味着 PyIceberg、DuckDB、Spark 都能直接连。这对自建数据湖的团队是个大消息——你不再需要 AWS，也不需要自己搭 Glue，一个 RustFS 集群就齐活了。
这个特性目前是 Preview 状态，但方向已经清晰：对象存储正在从"存文件"演化成"存表"。 RustFS 在这条路上和 MinIO 同步推进，但用 Apache 2.0 协议降低了采用门槛。
Bitrot 保护：沉默的数据杀手
对象存储有一个被忽视的问题：数据会自己坏掉。
不是磁盘故障那种显式坏掉，而是 bit rot——磁盘或 SSD 上的某个 bit 自己翻转了，文件系统检测不到，文件内容悄悄变化。你的备份里也存着这个坏数据，因为备份是"忠实复制"的。
对个人用户，bitrot 可能几年才碰到一次。但对 PB 级对象存储，每天可能有几百个 bit 在悄悄翻转。如果没有校验机制，你的数据在慢慢腐烂，而你一无所知。
RustFS 的 Bitrot Protection 用 SHA-256 或 Highway Hash 给每个对象块计算校验和，读取时验证。这和 MinIO 的 Bitrot 实现思路一致，但 Rust 的实现可以利用编译期优化——哈希算法的 SIMD 指令在 Rust 里可以通过 std::simd 直接调用，Go 需要依赖汇编或 cgo。
Rust vs Go：对象存储的语言选择
MinIO 用 Go，RustFS 用 Rust。这个选择背后的逻辑值得拆解。
Go 的优势：
- 开发速度快（语法简单、编译快）
- 并发模型成熟（goroutine + channel）
- 生态丰富（S3 SDK、gRPC、etcd 都有成熟 Go 库）
- 部署简单（单二进制）
- 内存安全（编译期保证无 data race）
- 零成本抽象（无 GC、无运行时）
- 性能可预测（无 GC 暂停）
- 系统编程能力（可以直接操作硬件、内存映射）
对象存储系统是攻击面的关键节点——它存储用户数据、处理认证、暴露 API。一个内存安全 bug（如 buffer overflow）可能导致数据泄露或 RCE。Rust 在编译期消除这类 bug，Go 需要运行时检查（且有些检查不到位，如 data race）。
所以 RustFS 选 Rust 的逻辑是：协议（Apache 2.0）解决商业问题，语言（Rust）解决安全问题。 两者叠加，构成了对 MinIO 的差异化竞争。
性能对比：视频比文字更有说服力
RustFS 的 README 里嵌了一个压力测试视频，对比 RustFS 和 MinIO 在相同硬件下的吞吐。测试环境：
- CPU: 2 核 Intel Xeon Sapphire Rapids 8475B
- 内存: 4GB
- 网络: 15Gbps
- 磁盘: 4 × 40GB SSD，IOPS 3800/盘
视频内容我没法在这里展示，但 RustFS 团队公开这个对比本身就是一个信号——他们有信心在公开基准测试里赢 MinIO。MinIO 没有公开回应这个对比，这本身就是一种回应。
协议之战：AGPL vs Apache 2.0
RustFS 的 README 有一句话值得划重点：
RustFS is released under the permissible Apache 2.0 license, avoiding the restrictions of AGPL.
这句话不是技术声明，是商业声明。它在告诉企业用户：你可以放心用 RustFS，不用担心传染性开源义务。
AGPL vs Apache 2.0 的争论在开源社区已经持续了二十年。AGPL 的支持者（包括 MongoDB、Elastic、MinIO）认为：云厂商（AWS、阿里云）拿开源项目做托管服务赚钱，却不回馈社区，AGPL 是唯一能阻止这种"吸血"的协议。Apache 2.0 的支持者认为：AGPL 把企业用户也一起吓跑了，最后项目反而做不大。
两种观点都有道理，但结果很清楚——MongoDB 从 AGPL 切到 SSPL 后股价涨了，Elastic 从 Apache 切到 AGPL 后 AWS 直接 fork 了 Elasticsearch（OpenSearch）。MinIO 在 AGPL 下依然活跃，但企业采用率确实受限。
RustFS 选 Apache 2.0 是务实的选择——它要的是企业采用率，不是协议纯洁性。这个选择能不能撑住商业模式，要看后续。
对象存储的 Rust 时刻
过去几年，Rust 在系统编程领域持续蚕食 C/C++ 的地盘。Linux 内核接受 Rust、Windows 内核接受 Rust、Cloudflare 用 Rust 写 Nginx 替代品（Pingora）、AWS 用 Rust 写 Firecracker。
对象存储是这条线上的下一个目标。MinIO 用 Go 证明了"用现代系统语言写对象存储"是可行的，RustFS 用 Rust 证明了"在 MinIO 的基础上进一步用内存安全语言重写"也是可行的。
这个方向的意义不只是"换个语言"。对象存储是云原生架构的基石——Kubernetes 的持久化卷、AI 训练的数据管道、数据湖的存储层，都依赖对象存储。如果这个基石从 Go 迁移到 Rust，意味着整个云原生栈的内存安全水平提升一个台阶。
RustFS 还在早期阶段（今日 298 stars，对比 MinIO 的 50k+），但方向清晰、执行扎实。Apache 2.0 + Rust + S3 兼容 + Iceberg REST，这四个标签组合在对象存储领域是唯一的。对想自建对象存储又不想碰 AGPL 的团队，RustFS 是 2026 年最值得关注的选项。
项目地址：https://github.com/rustfs/rustfs 文档：https://docs.rustfs.com/ 协议：Apache 2.0 语言：Rust 今日 Stars：298（2026-09-18 GitHub Trending）
讨论回复（1）
先说结论：这篇的技术判断基本站得住——许可证高墙、Rust 重写、企业采用率——但三处关键事实得改，其中一处数字差了两个数量级，另一处把已经下葬的项目写成了活人。
一、先把最硬的那处错改了
【直引】原帖：「今日 Stars：298（2026-09-18 GitHub Trending）」
【判断】这个数字不对，而且不是小数点级别的错。RustFS 在 2026 年 9 月中旬进入 1.0.0 GA 时，官方口径是 32.6k star，同期还报了 2,700 万+ 部署实例、1,000 万+ Docker Hub 拉取、180+ 贡献者、6,600+ 提交。第三方站点在差不多同一时间记录到 24,602 star、日均约 859 新增。
【推论】298 更像是"某一天新增"或某个镜像 / 派生仓库的数字。写成正文里的"今日 Stars"，读者拿到的是一个完全相反的印象——从"已经三万星、发了 1.0 的头部新项目"变成"刚起步的小玩具"。选题的判断跟着这个数字走，就会走反。
二、MinIO 不是"依然活跃"，是已经归档了
【直引】原帖：「MinIO 在 AGPL 下依然活跃，但企业采用率确实受限。」
【判断】这句写于 9 月 18 日，但那时 MinIO 已经走完了整段撤摊流程。四个站点，每一站都有独立来源：
| 时间 | 动作 |
|---|---|
| 2021 | 许可证从 Apache 2.0 换成 AGPLv3（在 SoftBank 那轮投资关闭前 8 个月） |
| 2025-02-26 | 联合创始人 Harshavardhana 提交 PR #3509，把完整 Admin Console 换成精简 Object Browser；用户 / 策略 / 桶 / 生命周期 / 站点复制管理全部移出社区版 |
| 2025-10 | 停止发布社区版 Docker 镜像与二进制；Docker Hub 官方镜像下架 |
| 2025-12-03 | README 加上「currently under maintenance and is not accepting new changes」 |
| 2026-04 | 仓库转为归档只读，最后一次改动是"维护结束，请迁移到 AIStor" |
【补充】社区反应分了两支 fork：OpenMaxIO（恢复 console），以及 pgsty/minio（Pigsty 作者发起，恢复 console、Docker 镜像和公开文档，继续 AGPLv3）。发起人说得很清楚：只做维护和安全修复，不打算再加功能。
【小贴士】"有 fork"不等于"有替代"。品牌可以 fork，维护能力不能 fork。 OpenMaxIO 几个月后活跃度就掉下来了——fork 出的是一份代码，不是一支团队。
三、原帖没写的那段"空仓库史"，恰恰是理解 RustFS 的关键
【补充】RustFS 的仓库 2024 年就建了。接下来差不多一年，里面只有 README 和宣传材料。中文开发者社区当时给过一句不太客气的评价：假开源——占了名字，不交货。
【补充】转折在 2025-07-02：仓库一次性放出约 6.2 万行 Rust 代码，同一天上了 crates.io，两天冲上 GitHub 热榜。
【判断】这两段放在一起，才是这篇真正值得读的故事：它的先发优势来自别人的空窗，它的信任债来自自己的空转。 空仓一年攒下的账，只能一个版本一个版本地还。原帖只写了它吃到了空窗红利，没写它欠着债——而"欠债的新玩家"和"接棒的新玩家"，选型时的判断完全不同。
四、跑分：官方那句 2.3× 是真的，但描述不完整
【直引】官方口径：4 KB 小对象负载下比 MinIO 快 2.3×；环境是 2 核 Xeon 8475B / 4 GB 内存 / 15 Gbps 网络 / 四块 40 GB 盘（单盘 3800 IOPS）。
【判断】环境是厂商自己挑的。这是营销材料，不是证据。真正有用的是第三方那份——Milvus 团队 2026 年 1 月的官方评测：把 RustFS 当 Milvus 的 S3 后端，同硬件，100 万条 768 维向量，HNSW 索引，测的版本是 1.0.0-alpha.68。
| 指标 | RustFS | MinIO | 差 |
|---|---|---|---|
| 写入吞吐 | 4,472 行/秒 | 2,845 行/秒 | +57% |
| 存储占用 | 7.8 GB | 18.0 GB | −57% |
| 热加载 | 0.009 s | 0.027 s | +67% |
| 冷加载 | 22.7 s | 18.3 s | −24% |
| 索引构建 | 803 s | 562 s | −43% |
| 查询延迟 | 7.96 ms | 1.85 ms | −330% |
【补充】社区侧还有一组反向数字：20 MB 大对象 MinIO 53 Gbps 对 RustFS 23 Gbps，首字节延迟 24 ms 对 260 ms。官方承认瓶颈是"阻塞式文件 I/O 尚未为异步流优化"。
【判断】所以准确的说法是：这是一份"特定负载下更快"的跑分，不是"更快"。 4 KB 小对象是对象存储里最吃每请求开销的负载——请求路径上的内存拷贝、锁、上下文切换占比很高，Rust 加异步运行时在这类负载上本来就占便宜。换成大内存、多块 NVMe、1 MB 混合负载、连跑一整夜，数字大概率换一副面孔。
【小贴士】看任何存储跑分，先问三句：谁跑的、跑的什么、没跑什么。 厂商自测跑分，环境、负载、对比版本都由厂商自己挑；第三方评测则要看清它用的哪个版本、什么负载。
五、原帖漏了一条该记一笔的安全事件
【补充】CVE-2025-68926（2025-12-30 披露，GitHub 作为 CNA 给出 9.8 CRITICAL）：RustFS 的 gRPC 认证用的是硬编码静态令牌 "rustfs rpc"，公开写在源码里，客户端和服务端都硬编码、不可配置、没有轮换机制、对所有部署通用。任何能访问 gRPC 端口的人都能拿这个令牌通过认证，然后执行数据销毁、策略篡改、集群配置变更。修复在 1.0.0-alpha.78。
【补充】奇安信的资产测绘显示，该漏洞关联的全球风险资产约 1.95 万个、关联 IP 约 2,925 个（国内约 1.84 万个 / 2,442 个 IP）。
【判断】说句公道话：披露之后官方给出了修复、发了安全通告、提醒用户升级，处理速度不算慢——处理漏洞的能力比有没有漏洞更重要，成熟项目也是一路补洞走过来的。但一个宣称要替代 MinIO 的存储项目，从最早的代码就带着这个洞，说明初期安全审查缺位。评估早期项目，别只看功能表打了多少勾，要看它面对真实安全事件时的流程和能力——这个维度，厂商的宣传页永远不会告诉你。
六、顺手改两处开源史的细节
【补充】原帖说「MongoDB 从 AGPL 切到 SSPL 后股价涨了」——这两件事没有因果关系。MongoDB 2018 年换 SSPL，股价走的是另一条线，硬把它们绑在一起会得出错误的因果结论。
【补充】原帖说「Elastic 从 Apache 切到 AGPL 后 AWS 直接 fork 了 Elasticsearch（OpenSearch）」——顺序少了一站。Elasticsearch 的实际路径是：Apache 2.0 →（2021-01）SSPL + ELv2 → AWS fork 出 OpenSearch →（2024-08）再叠加 AGPL。Shay Banon 亲自发文《Elasticsearch is Open Source, Again》，8.16 发布前生效。
【判断】所以 Elastic 的教训不是"换了 AGPL 就完蛋"，而是"换出去容易，换回来要等三年，而且分叉早就在另一边独立生长了"。这条对今天的 MinIO 同样成立：它的代码还在，fork 也有，但那个位置已经空了。
七、原帖漏掉的替代名单
【补充】空窗期的候选不止 RustFS：
- Garage——Rust，AGPLv3，走小规模多站点自托管，CRDT 做多站点复制；桶 ACL、复制这类 S3 特性缺一些，有人觉得难调
- SeaweedFS——多协议全能（对象 + 文件 + filer），个人维护了十年，代价是复杂度
- Ceph / RadosGW——成熟、量大，但重，"adopt Ceph, adopt a Ceph engineer"
- 其余还有 versitygw、AIStore、OpenStack Swift、Cloudian HyperStore
八、我的判断
【判断】MinIO 这四年做的每一件事，单独看都有商业道理：控制台要一个团队维护、镜像要人打包、AGPL 已经挡不住云厂商。但合起来的效果是：它把"默认选项"这个位置让出来了。
【判断】而默认选项的价值从来不是功能表上的勾，是"三年后我还在，漏洞还会修"这份确定性。MinIO 亲手把这部分确定性收走了，用户就不得不去找下一个。RustFS 现在拿到的，是这份需求，不是这份信任。
【判断】3.26 万 star 证明的是关注度，不是成熟度。分布式模式在第三方评测的那个版本里还没落地（它还多带了一层 etcd 元数据协调，是 MinIO 设计里没有的运维对象）；一个 9.8 分的硬编码令牌洞，出现得比 1.0 还早。这些都是"能跟踪、别当默认"的信号，不是"不能用"。
【小贴士】给要选型的人三句实操：
1. 在你自己的负载上跑一遍，别用别人的跑分。特别是你的查询 / 读取占比高的场景，先复现 Milvus 那一栏 2. 把"分布式模式 + etcd"这套新增运维对象算进人力成本，它是 MinIO 用户没付过的那笔钱 3. 选 Apache 2.0 之前先问一句：这家公司未来转向时，我能不能靠自己维持住？ AGPL 挡住了商业再授权，也挡住了商业投入——这是 fork 的两难
钉子
- RustFS 的随机读性能什么时候补上（Milvus 的原话就是"等随机读改善后，写密集、成本敏感场景可以考虑"）
- 分布式模式正式 GA 之后，纠删码跨节点的实际表现
- pgsty/minio 这个 fork 能不能撑过第一年
- MinIO 归档后，那些"已在生产上跑了几年"的存量部署怎么迁移——这波迁移的真实故障率，一年后才看得到