弃用 MinIO 网关

MinIO 正在弃用网关，并将在六个月内完全删除。这不足为奇，我们从 2020 年开始通知社区，并稳步移除不受欢迎的网关。在过去的十个月里，MinIO 只进行了错误修复。

社区可以在该日期之后继续使用旧版本的 MinIO。我们还鼓励任何志愿者加强和维护开源分支作为独立项目。所有修改和改进也必须在 GNU AGPL v3 许可下发布。

只要有必要，MinIO 的现有商业客户将得到支持。

我们弃用网关的原因相对简单。

我们很早就引入了网关功能，以帮助使 S3 API 无处不在。从传统的基于 POSIX 的 SAN/NAS 系统到现代云存储服务，不同的 MinIO 网关模块带来了以前不存在的 S3 API 兼容性。主要目标是提供足够的时间将应用程序移植到现代云原生架构上。在网关模式下，MinIO 作为无状态代理服务运行，将对象存储功能从 S3 API 内联转换为相应的等效后端功能。在任何给定时间，MinIO 网关服务都可以关闭，唯一的损失就是 S3 兼容性。对象始终以其本机格式写入后端，无论是 NFS 或 Azure Blob，还是 HDFS。

事实证明，实施不同的网关比服务器模式更具挑战性，因为与竞争对手的产品相比，在我们的本地纠删码后端实施 S3 功能更容易。网关过去是，现在仍然是一个很好的实现。它像宣传的那样工作，重量轻且非侵入性。

那么我们为什么要贬值它呢？

答案有两部分。首先，MinIO 网关实现了推动 S3 API 普及的主要目的。目标已经实现。S3 API 是事实上的存储标准，并使对象存储成为云和 Kubernetes 的存储类。结果，网关只是延续了遗留技术。网关用户已经经历了多年的过渡；是时候放弃遗留技术了。

其次，自我们开始以来，S3 API 已经有了很大的发展，最初的内联翻译演变成更多的东西。如果不引入专有后端格式，网关模式将无法支持关键的 S3 功能，例如版本控制、存储桶复制、不变性/对象锁定、s3-select、加密和压缩。它会破坏网关模式的目的，因为如果没有网关服务的帮助，后端将无法再直接读取。后端仅充当网关的存储介质，您也可以在服务器模式下运行 MinIO。因此它成为了 MinIO 不想再参与的妥协。这意味着我们是时候放手了。

今天我们的客户面临的问题类别适合于完整的 MinIO 服务器实现的功能。事实上，在我们的商业客户中，仅网关的使用率不到 2%。因此，我们正在投资将 MinIO 服务器提升到一个新的水平，因此我们弃用了网关功能。

如果您有任何疑问，请随时访问我们的 Slack 频道并与团队互动。我们很乐意回答您的任何问题。如果问题具有商业性质，请发送电子邮件至sales@minio.org.cn，我们一定会回复。