本地存储图像 vs cloudinary vs s3

Question

设置：

带有帖子的博客，使用 Laravel 构建，其中：

• 每个帖子最多可以有 1 个图像（可为空）。
• 博客中的最​​大帖子数为 1000。假设有 1000 个帖子用于讨论。
• 每个帖子都有评论部分。注册用户可以发表评论并在评论中包含图像。假设每个帖子的评论中都有 2 张图片。

因此总共有 3000 张图像*需要存储（我猜是调整大小）、呈现等。

从长远来看，这是理想的数量，我并不是在寻找“可扩展”的解决方案，因为不会出现疯狂的指数增长。

*实际上，目前它较少，并且我认为对于这些数量的媒体文件来说，它是 1000/1500/2000 还是 3000 并不重要。如果这是错误的，请纠正我。

需要注意的一些额外事项：

• 我将其托管在共享托管中（最多可以存储 300k 个文件）。
• 我希望它受到保护，因此不会在图像文件的封面中上传恶意文件。
• 我正在寻找一个预算解决方案（因此，如果 s3 在 12 个月后开始收费，则它变得不相关），最好是免费的（.

因此，困境在于将所有图像本地存储在 Storage 文件夹中（使用某些 Laravel 包操作图像）。另一种可能性是 cloudinary，我对此不太了解，只是它能够存储/操作/备份/使用他们的 api 来呈现我存储在那里的图像。

如果我选择在本地进行 - 在本地存储用户上传的图像是否安全？如何确保它不是伪装成图像文件的恶意软件？

如此大量的图像/内容在本地存储时是否会导致共享主机的性能问题？

使用 cloudinary 对我来说有什么好处？

谢谢。

Answer 1

Cloudinary 在这种情况下实际上可以提供很多帮助。您可以将 Cloudinary 集成到项目中，而不是在本地存储资源并编写一些东西来操作它们。

这将释放服务器空间。在本地存储图像可能会也可能不会影响性能，具体取决于架构，但释放服务器资源始终是一个很好的做法。

此外，图像的操作和交付可以在第一次请求时（或者如果您愿意的话，在请求之前急切地）通过简单的 API 调用即时完成。因此，您不需要编写新的东西，而是利用现有的 API。

Cloudinary 还有一个功能齐全的免费套餐可供您使用。如果您目前预计不会出现指数级增长，那么该级别对于该项目来说已经足够了

全面披露：我目前在 Cloudinary 工作（但上述内容仍然成立:)）。