Jor*_*lop 4 amazon-s3 images amazon-ec2 amazon-web-services
我正在阅读与 Imgur 的创建者的问答，他详细解释了 Imgur 运行的服务器基础架构。这是他不得不说的一小段引述：
大多数集群使用 c1.xlarge 实例。上传集群处理所有上传和图像处理请求，如缩略图和调整大小，每个实例都是一个巨大的集群实例，cc1.4xlarge。
我知道图像不占用太多空间，但为什么还要走这条路？特别是，考虑到显着的成本差异。
如果你想阅读整个问答，你可以在这里查看。我觉得这很有趣。
S3 主要提供极高的耐用性和极低的管理开销。服务本身并没有那么便宜（尤其是在服务请求方面），但管理替代方案的劳动力成本最多只能抵消任何节省的成本。然而，在非常大规模的情况下，节省的成本开始超过管理开销。
例如：
S3 上的 GET 请求每 10,000 个请求的成本为 0.004 美元。
T2.micro 的速度约为 180 Mbits/s，成本为 0.013 美元/小时。假设图像大小为 500kB（4000 kbits），大约是 46 张图像/秒。假设您可以使该实例（大型图像共享服务可能可以）饱和，则大约为 165k 请求/小时。
因此，对于 T2.micro，它的成本为 0.013 美元/小时，而 S3 为 0.066 美元。在实践中，您可能会在 T2.micro 上遇到其他瓶颈，因此 S3 最终可能会在这个规模上略微领先。
但是，如果您使用 c4.8xlarge（具有 10Gbit 网络），则每小时需要花费 1.763 美元。有了它，您可以提供大约 2620 张图像/秒，或大约 9.4m/小时。在 S3 上，这将花费您 3.76 美元/小时。加上预留实例折扣等，差距会更大。
最重要的是，您无法将调整图像大小等流程卸载到 S3，您可能还希望运行 WAF 或 DDoS 保护层以降低因攻击而导致的带宽成本。
话虽如此，一个常见的架构是将原件存储在 S3 中（它们很少被访问，但耐用性很重要）并在前端服务器上缓存调整大小的版本。我相信 Netflix 已经或确实使用了这种技术（除了他们将缓存的文件存储在自己的 colo 硬件上）。如果 Imgur 也这样做，我不会感到惊讶。