6

我已经阅读了很多关于动态图像处理、存储和内容交付的内容，我工作的公司已经在他们的一些服务中使用 AWS。

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

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

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

这就是为什么图像被上传到 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 解决方案以提高图像服务器的性能。

4

1 回答 1

2

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

于 2013-11-11T09:14:17.663 回答