AWS 上的 Nginx/ELB/Unicorn 架构的最佳实践是什么？

Question

我们在 AWS 北京有一个 RoR 应用程序。 AWS北京没有Route 53（我们不能使用Alias将ELB应用到Apex域），所以必须在ELB前面使用一个运行Nginx的前端服务器。

现在我们的架构如下所示：

前端(Nginx)--ELB--App-(1~n)(Nginx--Unicorn)

我们注意到下面独角兽描述中的文字： “Unicorn 绝对不能暴露给慢速客户端，因为它永远不会使用诸如非阻塞套接字 I/O、线程、epoll 或 kqueue 之类的新事物。Unicorn 必须与全缓冲反向代理（例如 nginx）一起使用慢客户端。”

所以我的问题是：
1、在Unicorn之前，我们需要在App Server上使用nginx吗？
2、如果我们去掉App Server上的nginx，前端服务器上的nginx能起到独角兽描述的效果吗？

Answer 1

在这种情况下，如果您没有 Route53 的别名功能来指向您的 apex 域，我建议您将 ELB 替换为 HAProxy。将 Nginx 实例放在 ELB 前面似乎不是一个好主意，因为您添加一个新层只是因为您无法在 Route53 上引用 ELB。通过将 Nginx 实例放在 ELB 前面，您也会失去高可用性的好处。

我的建议是在 Unicorn 前面的每个应用服务器上保留一个 Nginx 实例，并使用 HAProxy 作为负载平衡器：HAProxy > [Nginx > Unicorn]。在 HAProxy 的简单设置中，您也没有 ELB 的相同可用性，但如果需要，您可以设置高可用性配置。

Answer 2

1) Nginx 必须始终在 Unicorn 前面，因为 Unicorn 无法有效处理慢速客户端，它只是被那些客户端锁定

2) 永远不要通过网络与 Unicorn 对话，这意味着每个应用服务器都需要有自己的 Nginx。 Nginx 作为负载均衡器比 ELB 黑盒更好。