MinIO 网关弃用

MinIO 正在弃用网关功能，并将 6 个月后彻底移除。这并不意外，我们从 2020 年就开始通知社区，并逐步淘汰不受欢迎的网关。在过去 10 个月里，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 频道 并与团队互动。我们很乐意回答您可能遇到的任何问题。如果问题涉及商业性质，请发送电子邮件到 hello@min.io，我们一定会回复您。