我们正在使用AWS cloudfront在我们的网站上呈现静态内容，其来源为S3 BUCKET。现在作为后续步骤，用户可以动态上传我们想要推送到CDN的图像。但我们需要不同大小的它，以便我们以后可以在网站中使用它。一种选择是在推送到S3 BUCKET之前实际对图像进行预处理。这最终会根据尺寸创建多个图像。我们可以对http://imageprocessor.org/imageprocessor-web/之类的内容进行后期处理，但仍然使用cloudfront。任何反馈都会有所帮助。
此致 RAGHAV
答案 0 :(得分：0)
嗯，是的，可以进行后期处理并使用CloudFront，但您需要CloudFront和S3之间的中间层。我使用以下高级实现设计了一个系统：
请求到达CloudFront，如果可用，它将从缓存中提供图像;否则CloudFront会将请求发送到源服务器。
原始服务器不 S3。原始服务器是EC2上的Varnish。
Varnish将请求发送到S3，其中存储了所有已调整大小的图像结果。如果S3返回200 OK，则图像将返回到CloudFront并返回到请求的浏览器，并且该过程已完成。由于Varnish机器在与S3存储桶相同的AWS区域中运行，因此CloudFront＆gt;＆gt;之间的性能基本上无法区分。 S3和CloudFront＆gt;＆gt;清漆＆gt;＆gt; S3。
否则，Varnish配置为通过将失败的请求发送到resizer平台来重试失败的请求，该平台也在EC2中运行。
调整器会检查请求以确定请求的图像以及大小。在我的应用程序中，所需大小在文件名的最后几个字符中，因此xxxxx_300_300_.jpg表示300 x 300.大小调整器获取源图像...调整大小...将结果存储在S3 ...并返回Varnish的新图像，它将其返回给CloudFront和请求者。调整器本身是由Mojolicious包装的Imagemagick，它使用MySQL数据库来识别可以获取原始图像的源URI。
将结果存储在后备存储中，例如S3，并首先在每个请求上进行检查，这是此过程的关键部分，因为CloudFront不像许多人想象的那样工作。根据以下断言检查您的假设：
CloudFront拥有50多个边缘位置。请求被路由到最适合（通常在地理上接近）观看者的边缘。边缘缓存都是独立的。如果我通过CloudFront请求对象，并且您请求相同的对象，并且我们的请求到达不同的边缘位置，那么我们都不会从缓存中提供服务。如果要按需生成内容，则需要将结果保存到S3，这样就不必重复处理。
CloudFront为了到期目的而尊重您的Cache-Control:标头（或配置中被覆盖的值），但不保证在缓存过期之前将其保留在缓存中。缓存是易变的，CloudFront也不例外。因此，您的结果也需要存储在S3中以避免重复处理。
这是一个比预处理更复杂的解决方案。
我拥有数百万张图片，其中很大一部分的观看次数非常低，这是一个合适的解决方案。它最初被设计为并行解决方案，以弥补设计不佳的预处理器中的缺陷，有时“忘记”正确处理所有内容，但它运行良好，现在它是提供图像的唯一服务。
但是，如果你的动机围绕避免预处理结果的存储成本，那么这个解决方案并不能完全解决这个问题。