Question

我一直在阅读很多关于动态图像处理，存储和内容交付的内容，我正在为之工作的公司已经使用AWS进行一些服务。

我正在处理的应用程序，将文档图像存储到S3存储桶（不限于此），我需要按需显示它们。

此应用程序的第一个版本，在本地存储图像并在同一服务器上按需执行图像处理。

现在，文档存储已经增加并且存储了大量图像，所有这些都通过Web应用程序存储，这意味着一个用户可以上传说100多个图像，服务器需要尽可能快地处理它们。 / p>

这就是为什么图像被上传到EC2实例并在内部流式传输到S3存储桶的原因，这就是我们首先保存原始图像的方法，这里没有缩略图来加速上传过程。

然后另一个用户可能想要预览这些图像或以原始大小查看它们，这就是为什么我需要动态重新调整它们的大小，我将在重新调整大小后实现Cloudfront以进行图像缓存，这里来了这个问题。

工作流程如下：

1. User Request CDN image
 2.a Cloudfront Serves the cached image
 2.b Cloudfront request the image to a custom origin if its not cached
  3. The origin server query S3 for the image
    4.a If the image size exists on S3
     5. Return the image to Cloudfront, Cache and return to user
    4.b If the image size does not exists on S3
     5. Generate a image size from the original S3 image
     6. Save the new size to S3
     7. Return the new size to Cloudfront, Cache and return to user

自定义源负责创建丢失的图像大小并将其保存到S3，Cloudfront可以使用缓存的图像或将此新图像大小请求为S3，因为它现在已存在。

我认为这是可能的，因为我已经阅读了很多关于它的文档，但我还没有找到之前已经做过这个的人的文档。

这看起来像处理图像处理的好方法，有人看过有关如何执行此操作的任何文档。

我是一名PHP开发人员，但我可能能够实现非PHP解决方案，以支持图像服务器上的性能。

Answer 1

如果您对基于非PHP的解决方案持开放态度https://github.com/bcoe/thumbd是一个不错的选择，因为它已经集成了S3等。但是您需要提前了解所需的大小。我建议采用这种方法，而不是动态生成大小，因为这意味着用户的响应时间更快。在生成新大小时，您的用户无需等待。 S3上的存储非常便宜，因此您不会因为创建多种尺寸而浪费任何$$。

将Cloudfront与动态图像大小调整和S3存储集成

1 个答案: