在本地存储图像 vs cloudinary vs s3

Question

设置：

包含帖子的博客，使用 Laravel 构建，其中：

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

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

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

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

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

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

因此，难题在于将所有图像本地存储在 Storage 文件夹中（使用一些 Laravel 包操作图像）。其他可能性是云端，我不太了解，只是它可以存储/操作/备份/使用他们的 api 来呈现我存储在那里的图像。

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

在本地存储时，如果有这么多的图像/内容，会导致共享主机出现性能问题吗？

使用 cloudinary 对我有什么好处？

谢谢。

Answer 1

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

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

此外，manipulation 和图像的交付可以在第一次请求时（或者如果您愿意，可以在请求之前）通过简单的 API 调用即时完成。因此，您无需编写新内容，而是利用现有的 API。

Cloudinary 还有一个功能齐全的free tier，您可以使用它。如果您目前不期望指数级增长，那么该层对于项目来说已经绰绰有余了

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