反向代理服务器云架构（AWS + nginx）

目前我使用nginx + fastcgicaching响应。我正在将我的应用程序迁移到AWS。我构build了一个水平缩放的方法，但试图确定哪里最好把nginx + fastcgicaching。

我从我自己的研究中发现了一些解决scheme，都有明显的缺点。

使用AWS Elastic Load Balancer来平衡一组Web应用程序。每个Web应用程序都运行它自己的nginx和Web服务器堆栈。 缺点：每台服务器上的caching需要加热。最坏的情况1 / n的命中率。
将nginx + fastcgi放在AWS ELB的前面，这样caching就集中在最高点。 缺点：单点故障 – 如果nginx死亡stream量不通过ELB。增加了nginx实例。

我将不胜感激任何克服上述缺陷的常见体系结构的build议。

我在AWS上多次设置了这个堆栈。选项1对我来说一直很好，而且是我通常select的选项，因为它是最简单的。我很想知道你处理的stream量是多less，而不是理想的初始caching命中是多less？我在一对m1.small实例上每月提供几百万个网页浏览量，而且几乎没有被抓到。

其他想法：

Nginx可以使用memcached作为caching存储。将其插入ElasticCache群集。这将给你一个非常快速，集中的数据存储多个实例连接到caching内容。 （我从来没有这样做，但看起来可行，如果你尝试了，请张贴结果。）
选项＃2中提到的SPoF问题可以通过设置包含单个实例的自动调节组来缓解。如果它死了，它应该在几分钟内回到网上。你将需要摆弄一个自动抓取Elastic IP的启动脚本。
请记住，将任何内容放在ELB前面都需要使用VPC。无论如何，这是一个很好的做法，但它可能有一个陡峭的学习曲线。
CloudWatch警报行动今天刚刚宣布。你可以做一些很酷的东西，这有助于最大限度地减lessSPoF问题。

看起来你正在考虑我计划实施的同样的架构。

我已经想到了这两种情况和相同的方法，然后解决这个问题。

我将使用第二个选项，在Load Balancer前设置caching解决scheme。我将要处理单点故障问题，添加一个有待机的节点，并使用类似HAProxy的东西继续检查机器的健康状况。如果第一个caching机器出现故障，HAProxy将自动移动IP并将stream量移到另一个caching备机器，从而处理单点故障。

另外，在我的场景中，我将使用像Varnish，而不是Nginx + PHP，我也会build议你，因为你的应用程序不依赖于Nginx。 Varnish将拥有自己的Load Balancer，因此您也将跳过AWS Load Balancer。

希望这将帮助您构build一个强大的可扩展基础架构。