Nodejs API、Docker (Swarm)、可扩展性和存储

Question

我用 nodejs 编写了一个 API，并像其他数以百万计的人一样表达，它将在几周内上线。该 API 目前在单个 docker 主机上运行，​​该主机具有一个用于包含用户上传的图像的持久数据的卷。

我现在正在考虑涉及网络卷问题的可扩展性和高可用性设置。我已经阅读了很多关于 NFS 卷以及可能用于 docker swarm 的 S3 驱动程序的内容。

根据我收集到的信息，我为集群设置整理了两种可能的解决方案：

Docker 卷驱动程序

• 我可以使用 compose 文件将每个 docker 主机连接到 S3 存储桶或 EFS 存储
• 即使我移动 VPS 提供商，连接也应该可以工作
• 如果我将 NFS 存储放在网络的私有部分（无 S3 或 EFS），则安全性会更好

API Multer S3 中间件

• 不需要附加卷，因为 S3 连接是在容器内完成的
• 更轻松的 swarm 和 docker 管理
• 必须重新编程，并且需要迁移一些文件
• 在 GET 请求中，文件将由 AWS 直接提供，而不是由 API 提供

请告诉我您对此的反对意见。我做对了还是错过了什么？我应该走哪条路线？从不同主机安装时，是否需要考虑延迟或权限？ S3 上的提示，EFS 绝对是受欢迎的，因为我还不知道。

Answer 1

我不建议保存到磁盘，而是直接使用 S3 API - 创建存储桶并写入您的应用代码。

如果您正在考虑安装一个 S3 存储桶作为您的驱动器，则存在严重的限制。 5Gb 限制。每当您以任何方式修改内容时，驱动程序都会重新上传整个存储桶。如果有任何争用，它将不得不重试。几年前，当我尝试这个时，保险丝驱动器不够稳定，无法用作生产系统的一部分，它们会崩溃，你必须重新安装。这是个好主意，但只能在命令行上用作临时的东西。

就 NFS 而言，看在上帝的份上，不要对自己这样做，你要为自己承担责任。

EFS 无法真正发表评论，当它可用时，大多数人刚刚学会使用 S3，而且它更便宜。