在 Amazon S3 上保存图像并使用 CloudFront 分发它们的最佳方式

Question

我正在处理的应用程序（nodejs）有用户配置文件，每个配置文件可以有多个图像。我使用 S3 作为我的主要存储和 CloudFront 来分发它们。

问题是有时用户上传大图像，我想要做的是在下载图像时缩放图像（在 html img 标签或手机中查看），主要是因为性能。

我不知道我是否应该在将图像上传到 S3 之前对其进行缩放（可能使用 lwip https://github.com/EyalAr/lwip），或者是否有一种方法可以缩放图像或在下载时获得低质量的图像通过 CloudFront？。我读过 CloudFront 可以使用 Gzip 压缩文件，但也不推荐用于图像。

由于存储的原因，我也不想将缩放后的原始图像上传到 S3。

应该在客户端、服务器还是 S3 中完成？最好的方法是什么？

Answer 1

通过 CloudFront 下载图像时，是否有缩放图像或获取低质量图像的方法？

没有这样的功能。如果您希望对图像进行大小调整、重新采样、缩放、压缩等操作，则需要在将其保存到 S3 中的最终位置之前进行操作。

请注意，我说的是它在 S3 中的最终位置。

一种解决方案是将图像上传到S3 中的一个中间位置，可能是在不同的存储桶中，然后使用修改图像的代码调整其大小并将其存储在最终的 S3 位置，从那里 CloudFront 将代表下载用户获取它.

我读过 CloudFront 可以使用 Gzip 压缩文件，但也不推荐用于图像。

图像从 gzip 压缩中获益很少，但 CloudFront 文档还表明CloudFront 不会压缩任何未以某种方式格式化为 text 的内容，这往往从 gzip 压缩中获益更多。

由于存储的原因，我也不想将缩放后的原始图像上传到 S3。

我相信这是你的错误。

“压缩”图像不像压缩 zip 文件。压缩图像是有损的. 您无法从压缩版本重建原始图像，因为此处讨论的图像压缩 - 根据定义 - 是故意丢弃图像中的信息到尺寸在所需范围内且质量在可接受范围内的点. 图像压缩既是一门科学，也是一门艺术。如果您不保留原始图像，并且后来决定要修改图像压缩算法（要么是因为您后来决定尺寸仍然太大，要么因为您认为原始算法过于激进并导致无法接受的低质量），您无法通过压缩算法再次运行已经压缩的图像，而不会进一步降低质量。

使用 S3 的STANDARD_IA（“不经常访问”）存储类将原始图像的存储成本降低一半，以换取更昂贵的下载——因为这些图像很少会被再次下载，因为只有你会知道它们在存储桶中的 URL它们的存储位置。

应该在客户端、服务器还是 S3 中完成？

它不能“在”S3 中完成，因为 S3 只存储对象。它不会操纵它们。

这留下了两个选项，但在服务器上执行它有多种选择。

当您说“服务器”时，您可能会想到您的 Web 服务器。这是一种选择，但此过程可能会占用大量资源，因此您需要在可扩展性计划中考虑到这一点。

GitHub 上有一些项目，例如这个，旨在使用 AWS Lambda 来实现这一点，AWS Lambda 提供按需“无服务器”代码执行。代码在服务器上运行，但它不是您必须配置或维护的服务器，也不需要在它不活动时付费——Lambda 以 100 毫秒为增量计费。那是第二种选择。

在客户端上做这件事当然是一种选择，但似乎可能更有问题且更容易出错，更不用说某些解决方案是特定于平台的。

没有完成这项任务的“最佳”方法。

如果您不熟悉 EXIF 元数据，您也需要熟悉它。除了重新采样/调整大小之外，您可能还需要从用户提供的图像中剥离一些元数据，以避免泄露您的用户可能没有意识到附加到他们的图像的敏感数据 - 例如照片所在的 GPS 坐标采取。一些网站还为他们用户提交的图像添加水印，这也是您可能同时做的事情。