大家好，我是程序员天天困。

RustFS 终于迎来了 1.0.0 正式版。对关注 MinIO 替代方案的人来说，这是个值得认真评估的节点。对象存储承载着业务数据，能不能替换现有系统，还得看接口兼容性、故障恢复能力和迁移成本。

下面先看它为什么值得关注，再看功能、性能和迁移限制，最后动手部署。

## 一、GA 发布了，意味着什么

RustFS 的 1.0.0 GA 公告 发布于 **2026 年 9 月 16 日**，GitHub 也有对应的 1.0.0 Release。GA 是 General Availability，通常表示产品正式面向用户发布。

按官方公告，项目从 2024 年 2 月开始开发，2025 年 7 月开源，2026 年 4 月进入 Beta、8 月进入 RC，最终在 9 月发布 GA。从第一行代码算起约两年零七个月，从开源算起约十四个月，两者的起点不同。

公告还列出了 32,000+ GitHub stars、1,000 万+ Docker Hub 镜像拉取和 270 万+ 部署实例。这些是公告发布时的官方统计，其中部署实例数未交代统计方法，不能直接等同于活跃用户数或生产客户数。

官方对 GA 的定位是：**核心对象存储引擎已经稳定，可用于生产负载。** 对使用者来说，这是一个重要信号，具体业务上线前仍需验证兼容性、性能和故障恢复。

## 二、为什么它会成为 MinIO 的替代候选

### 1. 许可证与维护状态，影响长期采用成本

2021 年 4 月，MinIO 服务端项目从 Apache-2.0 转向 AGPLv3。2025 年 5 月 24 日的发布说明又宣布调整内置 Console，转向 object-browser。截至本文核查日，MinIO 社区版仓库显示已于 **2026 年 4 月 25 日归档**，README 明确标注不再维护。社区版用户因此需要重新考虑从哪里获取补丁、如何升级，以及由谁负责长期维护。

这里要分清产品：归档的是社区版仓库，MinIO AIStor 的许可、功能和支持应另行评估。AIStor 产品线也提供采用免费许可的单机版本，因此社区版归档不意味着 MinIO 全线停止维护。

许可证也容易被讲偏。**AGPLv3 不等于“用了 MinIO，整个业务系统都必须开源”。** 第 13 条主要要求：修改程序后，如果用户通过网络与该修改版本交互，应向这些用户提供获取相应源代码的途径。其他代码是否受影响，要结合修改、组合和分发方式判断，不能只凭调用了 S3 API 下结论。

RustFS 使用宽松的 Apache-2.0 许可，通常更便于商业集成和再分发，也不要求因此公开独立的自有业务代码。但再分发仍需保留许可证及相关声明、标明修改，并遵守适用的 NOTICE 要求。

![AGPLv3 与 Apache-2.0 许可差异的示意图](https://developer.qcloudimg.com/http-save/yehe-11608098/14646a1d6d340c4a7623a703de2cad54.jpg)

用两条路线比喻许可证带来的采用成本差异，具体义务仍以许可证条款为准。

### 2. Rust 提供实现优势，性能仍要看负载

对象存储需要持续处理并发请求、磁盘 I/O 和大量缓冲区。安全 Rust 的所有权和借用检查可以防止多类内存错误；RustFS 也不依赖 Go 那样的追踪式垃圾回收（GC），因此没有这类 GC 带来的停顿。

不过，**没有 GC 不等于没有延迟尖峰，也不能直接推出 P99 更低。** 磁盘排队、网络抖动、锁竞争和线程调度都可能拖慢请求；Go 的 GC 也主要与程序并发运行。`unsafe`、外部库接口和依赖仍需要审计，语言优势不能代替系统设计与测试。

选型时应同时看吞吐量、错误率和尾延迟。P99 表示约 99% 的请求延迟不超过该值，有助于观察慢请求，但比较双方时必须使用相同负载与配置。

![GC 停顿、平均延迟与 P99 尾延迟的示意图](https://developer.qcloudimg.com/http-save/yehe-11608098/e8daf79b9bebff50b69ddd7f9b235662.jpg)

曲线用于概念说明，并非 RustFS 与 MinIO 的实测结果；无 GC 也可能出现延迟尖峰。

### 3. 架构是否合适，要结合存储需求判断

RustFS 与 MinIO 都主要面向 S3 对象存储，采用对等节点设计，不需要额外部署专用的中心元数据服务器。Ceph 则同时覆盖块、文件和对象存储，功能面更广，部署和运维涉及的组件也更多。

| 维度         | RustFS                      | MinIO 社区版                 | Ceph                                        |
| ------------ | --------------------------- | ---------------------------- | ------------------------------------------- |
| 主要用途     | S3 兼容对象存储             | S3 兼容对象存储              | 块、文件、对象存储                          |
| 主要实现语言 | Rust                        | Go                           | C++                                         |
| 许可证       | Apache-2.0                  | AGPLv3                       | 主体为 LGPL-2.1 或 LGPL-3，部分组件另有许可 |
| 评估重点     | 所需功能、GA 验证与迁移成本 | 现有兼容性与归档后的维护来源 | 统一存储需求与团队运维能力                  |

Ceph 的对象存储由 RGW 在 RADOS 之上提供，MDS 则用于 CephFS 文件系统，不能把 MDS 当成其对象存储的中心元数据服务。Ceph 通过 CRUSH 计算数据位置，也避免了对中心对象位置查询表的依赖。

因此，只需要 S3 服务、重视宽松许可的团队，可以重点评估 RustFS；同时需要块、文件和对象存储的团队，则更有理由考虑 Ceph。无论选择哪种系统，都要检查节点、访问入口和共享基础设施是否存在单点故障。

![So what？选型还得看业务需求](https://developer.qcloudimg.com/http-save/yehe-11608098/c65d41824459d16f58a06d0d30f63ca7.webp)

## 三、1.0.0 有哪些功能，边界在哪里

理解了许可证和架构差异，再来看实际功能。GA 公告列出的主要能力如下，具体使用时仍需核对启用条件和兼容范围：

| 类别         | 官方列出的主要能力                                           |
| ------------ | ------------------------------------------------------------ |
| 数据管理     | 桶与对象管理、分片上传、纠删码、数据分层、生命周期、S3 Tables |
| 安全与访问   | IAM、OIDC、STS 临时凭证、KMS 集成、服务端加密、审计、mTLS    |
| 可用性与扩展 | 分布式部署、存储池扩容、再平衡、自愈、站点复制与桶复制       |
| 运维         | 事件通知、OpenTelemetry、容量与健康检查、存储池退役          |

比功能名称更重要的是支持范围。**S3 兼容不代表覆盖 AWS S3 的全部行为。** 1.0.0 的兼容性说明列出了具体限制：例如不支持 ACL 授权，桶访问日志和表单上传校验和处理等方面仍有测试未通过。已有应用如果依赖这些行为，应先查对应版本的兼容性矩阵。

**S3 Tables** 是一个值得关注的扩展：RustFS 将 Apache Iceberg REST Catalog 集成到存储服务中，管理表的命名空间、元数据和快照提交，数据文件仍通过 S3 接口读写。采用这套 Catalog 时，可以少维护一个独立服务，查询和计算仍由 Spark 等引擎完成。不过，支持 Iceberg REST 协议并不意味着覆盖了 AWS S3 Tables 的全部 API 和托管能力。

![S3 Tables 架构示意：Catalog 管理表元数据，数据文件经 S3 接口读写，计算由外部引擎完成（来源：RustFS 官方，RC 阶段示意）](https://developer.qcloudimg.com/http-save/yehe-11608098/7d3058cf9d2cb1a5644f1569f7cf6a03.png)

多协议支持也需要分开看：WebDAV、FTP/FTPS 在标准构建中提供，但默认不启动相应服务；Swift 是可选编译功能；MCP（模型上下文协议）则通过独立适配组件，让 AI 应用访问 S3 存储，需要另外部署。当前 MCP 文档还提示旧构建入口可能失效，使用前应确认对应组件的位置和安装方法。

站点复制与桶复制也不同：前者涉及 RustFS 站点之间的身份、桶及元数据等状态协调，后者可将对象复制到符合要求的 S3 目标。两个系统都支持 S3，并不意味着它们能直接建立站点复制关系。实际选型时，先列出业务必需的功能，再验证接口、权限和异常处理，比单纯比较功能数量更有意义。

## 四、性能报告怎么看：写入亮眼，读取有差异

本文引用的 官方性能报告发布于 **2026 年 7 月 17 日**，比较的是 **RustFS 1.0.0-beta.10** 与 **MinIO AIStor 商业版 `RELEASE.2026-06-06T02-44-06Z`**。它不是 GA 版对 MinIO 社区版的测试。

报告使用 Azure 上的 4 节点集群，每节点 4 块 300GB 磁盘、8 核 CPU、16GB 内存，系统为 Ubuntu 24.04。测试工具为 `warp`，覆盖 11 种对象尺寸，64 并发，每轮运行 5 分钟。

按报告结果，RustFS 的 PUT（写入）在全部 11 种对象尺寸上领先，比值为 1.05～2.85；GET（读取）则有快有慢。下面选取几个代表性尺寸：

| 对象尺寸 | PUT 比值：RustFS / AIStor | GET 比值：RustFS / AIStor |
| -------- | ------------------------- | ------------------------- |
| 1KiB     | 1.49                      | 1.04                      |
| 4KiB     | 2.00                      | 1.03                      |
| 100KiB   | 2.60                      | 0.72                      |
| 1MiB     | 2.17                      | 0.23                      |
| 4MiB     | 2.85                      | 1.26                      |

**比值大于 1 表示该项测试中 RustFS 领先，小于 1 表示 AIStor 领先。** 2.85 倍表示约高出 185%，不是“提升 285%”。原表未明确标注绝对数值的计量单位，因此这里仅引用比值。

GET 的完整结果中，RustFS 在 1KiB～16KiB 各档小幅领先，在 32KiB、100KiB 和 1MiB 三档落后，在 4MiB 及以上测试档位再次领先。其中 1MiB 读取的 AIStor 原始数值约为 RustFS 的 **4.4 倍**，不能只看写入优势而略过这个差距。

这份报告说明，当时的 RustFS 写入表现值得关注，读取表现则明显受对象尺寸影响。由于测试由项目方提供，且使用的是 Beta 版本，这些结果更适合作为 GA 复测的参考，而非所有业务都会更快的依据。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/4b214bd83f750a905aa583f9f45bddeb.webp)

备份、归档场景应同时测写入与恢复读取；图片服务和训练数据场景应重视 GET、混合负载及尾延迟。**AI 训练并不天然“写多读少”**，数据准备和训练读取要分开看。对象分布、缓存、并发、纠删码参数和网络条件，都应尽量贴近实际业务。

## 五、纠删码与迁移：数据可靠性要讲清楚

### 1. “12+4”有明确前提

看完读写性能，还要考虑磁盘故障后能否恢复数据，这就涉及纠删码。RustFS 将对象拆成数据分片，并计算校验分片，再把这些分片分散存放到同一纠删码集合的磁盘上。按官方纠删码配置文档，默认校验分片数取决于**每个集合的磁盘数**：例如 4～5 盘集合默认有 2 个校验分片，8～16 盘集合默认有 4 个。

以 **16 盘组成一个集合、采用 EC:4** 为例，对应的就是“12 个数据分片 + 4 个校验分片”。在其余分片完整的前提下，可恢复最多 4 个缺失分片，理论数据容量占比为 12/16，即 75%。实际容量还要扣除文件系统和元数据开销，并预留修复空间。

如果这 16 块盘均匀分布在 4 台服务器上，一台离线就会失去 4 个分片。换一种分布，节点容错能力也会变化；能否继续读写，还取决于对应的 quorum，也就是读写所需的最少在线分片数。

单节点单磁盘没有 RustFS 层面的磁盘冗余；单节点多磁盘仍面临整机故障风险。需要节点级容错时，应规划多节点部署，并演练故障和恢复。**纠删码不能替代独立备份。**

### 2. 原地迁移有方案，加密对象尤其要注意

RustFS 在 2026 年 3 月发布过二进制替换迁移方案，示例使用的是 `1.0.0-alpha.89`，并列出站点复制、事件通知、在线配置和 LDAP/OIDC 等不能自动迁移的项目。这只能说明当时已有迁移路线，不能直接当作 1.0.0 的完整支持承诺。

更关键的是，**1.0.0 默认发布构建不能直接读取 MinIO 的服务端加密对象，包括 SSE-S3、SSE-KMS 和 SSE-C。** 对象能够列出、显示大小，不代表内容能够解密读取。特定迁移构建有额外支持，但也受源端密钥方案限制，详见1.0.0 数据格式兼容说明。

因此，原地迁移前要核对源版本、目标版本、加密方式、历史版本和权限配置。完成备份后，先在副本上演练，再停止旧服务并切换。

另一条路线是通过源端 S3 接口读取数据，复制到新集群；加密对象由源端解密、目标端按需重新加密。普通复制未必保留全部历史版本、锁定信息和管理配置，切换前还需停止或控制源端写入，完成最后的增量同步与核验。

接口兼容、磁盘格式兼容和管理配置兼容是三件事。回退方案同样需要验证，不能默认 RustFS 写入的数据还能由 MinIO 直接读取。

## 六、动手验证：1Panel 与 Docker 两种方式

明确了功能和迁移边界，就可以搭建测试实例了。下面以 Ubuntu 云服务器为例，介绍两种安装方式，任选一种即可。先验证建桶、上传、下载和客户端连接，生产集群的容错与恢复还需另行验收。

### 方式一：通过 1Panel 应用商店安装

已有 1Panel 的读者可以直接进入应用商店。尚未安装时，可按 [1Panel v2 安装文档](https://1panel.cn/docs/v2/installation/online_installation/) 下载并执行脚本：

```bash
curl -fSL https://resource.fit2cloud.com/1panel/package/v2/quick_start.sh -o quick_start.sh
sudo bash quick_start.sh
```

![1Panel 安装示例](https://developer.qcloudimg.com/http-save/yehe-11608098/10e4ec50c30a51a1aef21bfb36d740c1.png)

使用阿里云 ECS 时，也可以查看系统运维管理 OOS 的公共扩展程序。下图展示了 1Panel 安装入口，安装前确认扩展程序版本和适用系统即可。

![阿里云 OOS 中的 1Panel 安装入口](https://developer.qcloudimg.com/http-save/yehe-11608098/5235f6d3e808d24d636c70fd107cd08d.png)

在应用商店搜索 RustFS，按当前模板设置管理员凭证、端口和数据目录。官方商店条目支持 amd64、arm64；`latest` 镜像会随时间变化，安装前应确认实际版本。

![1Panel 应用商店安装 RustFS 示例，界面以当前版本为准](https://developer.qcloudimg.com/http-save/yehe-11608098/4bd5499453af7880b9835d6ab13642ec.png)

默认情况下，9000 是 S3 API，9001 是控制台。通过可信网络访问 `http://服务器IP:9001`，使用设置的凭证登录；如果修改了映射端口，就使用修改后的地址。

如果容器反复重启，日志出现 `Permission denied`，应检查挂载目录权限。1.0.0 官方镜像以 UID/GID `10001:10001` 运行，但其他镜像或面板模板可能覆盖用户设置。应先确认实际运行用户，再调整专用数据目录的属主，不要直接照搬旧教程里的 `1000`。

面板底层也是容器部署，排查时仍要回到镜像版本、运行用户和挂载配置，不能简单记成“1Panel 用 1000，Docker 用 10001”。

![](https://developer.qcloudimg.com/http-save/yehe-12591818/9083407d69d28ac0f527b42fc749ae87.webp)

### 方式二：使用 Docker 部署

以下命令依据 [RustFS Docker 文档](https://docs.rustfs.com/en/installation/container/docker) 整理，镜像固定为 `1.0.0`。准备好 Docker Engine（文档要求至少 20.10），确认 9000、9001 端口未被占用。

先拉取镜像并创建持久化数据卷：

```bash
docker pull rustfs/rustfs:1.0.0
docker volume create rustfs-data
```

**将两个凭证占位符替换为自己的值后再执行：**

```bash
docker run -d \
  --name rustfs \
  --restart unless-stopped \
  -p 127.0.0.1:9000:9000 \
  -p 127.0.0.1:9001:9001 \
  -v rustfs-data:/data \
  -e RUSTFS_ACCESS_KEY='<your-access-key>' \
  -e RUSTFS_SECRET_KEY='<your-secret-key>' \
  -e RUSTFS_ADDRESS=':9000' \
  -e RUSTFS_CONSOLE_ADDRESS=':9001' \
  -e RUSTFS_CONSOLE_ENABLE=true \
  rustfs/rustfs:1.0.0 \
  /data
```

镜像名后的 `/data` 是数据目录参数。这里将端口绑定到服务器本机，云服务器用户可在自己的电脑上建立 SSH 转发；先替换用户名、服务器地址，并确认本地端口可用：

```bash
ssh -N -o ExitOnForwardFailure=yes \
  -L 9000:127.0.0.1:9000 \
  -L 9001:127.0.0.1:9001 \
  <ssh-user>@<server-ip>
```

保持连接，在电脑浏览器打开 `http://127.0.0.1:9001`；本地客户端通过 `http://127.0.0.1:9000` 连接 S3 API。需要长期远程访问时，再配置 HTTPS 和访问范围。

如果改用主机目录挂载，可以先创建供本实例使用的目录：

```bash
sudo install -d -o 10001 -g 10001 -m 0750 /srv/rustfs-data
```

然后把 `-v rustfs-data:/data` 换成 `-v /srv/rustfs-data:/data`。已有目录还需检查内部文件权限。

在服务器上检查运行状态与健康接口：

```bash
docker ps --filter name=rustfs
curl --fail http://127.0.0.1:9000/health
```

最后创建一个桶，上传文件后再下载，比较前后内容是否一致，并在重启容器后确认数据仍可读取。这个示例只有一个数据卷，属于单节点单磁盘形态，不提供 RustFS 层面的磁盘冗余。

![RustFS 控制台的桶管理界面（来源：RustFS 1.0.0 GA 官方公告）](https://developer.qcloudimg.com/http-save/yehe-11608098/4f6e40567ddbb7cf579eb996fae486e2.png)

### 凭证配置别忽略

`rustfsadmin` / `rustfsadmin` 是公开的默认凭证，必须主动替换。1.0.0 的容器入口对缺失或默认凭证会告警，但仍可能继续启动，不能依赖它自动阻止不安全配置。

Access Key 建议使用大写字母和数字，不要直接使用可能含 `/` 的 Base64 字符串，否则会干扰 AWS SigV4 凭证作用域解析。Secret Key 应使用独立的强随机值；应用日常访问应使用限定权限的账号，而非管理员凭证。

多节点还涉及 `RUSTFS_RPC_SECRET`。未显式设置时，它由管理员凭证对派生，默认 Secret Key `rustfsadmin` 不能用于这条派生路径。各节点应使用一致的管理员凭证；若单独配置 RPC 密钥，应使用与管理员 Secret Key 不同的强随机值，并在所有节点保持一致。

## 七、我的判断：值得评估，是否替换要看验证结果

RustFS 1.0.0 已经值得进入 MinIO 替代方案的候选名单。宽松许可便于商业集成，S3 接口有助于接入现有应用，集成式 Iceberg Catalog 则为数据分析场景提供了新的选择。

真正决定能否替换的，还是三件事：现有应用能否正常工作，故障后能否按预期恢复，迁移与维护成本能否接受。对已经使用 MinIO 的团队，尤其要先清点加密对象、版本控制、权限和复制规则；对新项目，则可以从非关键数据开始验证。

GA 是一个正式的生产版本起点。把兼容性、业务负载和恢复流程测清楚，再决定替换范围，比单看语言、版本号或一张跑分表更可靠。

---

我是程序员天天困，持续分享编程干货。觉得有用的话，欢迎点赞、收藏和关注。你现在用的是什么对象存储？如果考虑换成 RustFS，最想先验证哪项能力？

RustFS 终于迎来了 1.0.0 正式版。对关注 MinIO 替代方案的人来说，这是个值得认真评估的节点。对象存储承载着业务数据，能不能替换现有系统，还得看接口兼容性、故障恢复能力和迁移成本。

RustFS 1.0.0 深度解析：GA 之后，它值得替代 MinIO 吗？

RustFS 1.0.0 于2026年9月16日正式发布。本文梳理其许可证、功能与性能，说明替代 MinIO 的兼容性和迁移限制，并介绍 1Panel、Docker 部署方式

人工智能

后端

RustFS 1.0.0正式版发布，作为MinIO替代方案值得评估。采用Apache-2.0宽松许可，写入性能亮眼，读取性能因对象尺寸而异。支持S3接口、Iceberg目录集成，默认构建不支持MinIO加密对象读取。需验证接口兼容性、故障恢复与迁移成本，建议从非关键数据开始测试。

数据分析

对象存储

代码解释

云服务器

文件系统

数据分片

数据管理

服务器

容器

GitHub

Ubuntu

Docker

Spark 

Swift

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RustFS 1.0.0 深度解析：GA 之后，它值得替代 MinIO 吗？-腾讯云开发者社区-腾讯云

RustFS 1.0.0 深度解析：GA 之后，它值得替代 MinIO 吗？

RustFS 1.0.0 深度解析：GA 之后，它值得替代 MinIO 吗？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐