多少个反向代理（nginx、haproxy）太多了？

Question

我正在使用 nginx、haproxy 和 apache 设置一个 HA（高可用性）集群。

我一直在阅读有关 nginx 和 haproxy 的精彩内容。人们倾向于选择其中之一，但我两者都喜欢。Haproxy 在负载均衡方面比 nginx 的简单循环更灵活（即使有上游公平补丁）。但我想保留 nginx，以便在集群入口处将非 https 重定向到 https 等。

另一方面，nginx 在提供静态内容方面要快得多，并且会减少强大的 apache 的负载，它喜欢吃大量的 RAM！

这是我计划的设置：

负载均衡器：nginx 监听 80/443 端口，proxy_forwards 到同一台服务器上 8080 上的 haproxy 来实现多个节点之间的负载均衡。

节点：节点上的nginx监听8080上haproxy的请求，如果内容是静态的，就服务它。但是如果它是一个后端脚本（在我的例子中是 PHP），代理转发到同一节点服务器上的 apache2，监听不同的端口号。

从技术上讲，此设置有效，但我担心的是，请求通过多个代理是否会减慢请求速度？大多数请求将是 PHP 请求，因为后端是服务（这意味着从 nginx -> haproxy -> nginx -> apache 进行处理）。

想法？干杯

Answer 1

从纯粹的性能角度来看，让基准测试为您做出这些决定，而不是假设——在进行架构更改时，使用像httperf这样的工具是无价的。

从架构哲学的角度来看，我有点好奇你为什么在应用服务器上同时拥有 nginx 和 apache。Nginx 在静态内容上大放异彩并有效地处理大多数后端框架/技术（Rails、通过 FastFCGI 的 PHP 等），所以我会放弃最后的 Apache 层。再一次，这源于对您使用的技术的有限理解，因此您可能需要我没有预料到的它（但如果是这种情况，您总是可以将 nginx 放在应用服务器上，然后使用 apache——如果配置正确，静态内容并没有那么糟糕）。

目前，我在负载平衡服务器上使用 nginx -> haproxy，在应用服务器上使用 nginx 并取得了很大的成功。正如 Willy Tarreau 所说，nginx 和 haproxy 是一个非常快的组合，所以我不会担心在前端同时使用两者的速度，但请记住，添加额外的层会增加复杂性以及点数失败。

Answer 2

您的设置越来越普遍。你不必担心。nginx 和 haproxy 处理和转发 HTTP 请求都非常快。两者结合得很好，可以很好地完成他们的工作。没必要选。安装它们并快乐。这样，您将非常快速地交付静态文件，并确保动态服务器的平滑扩展。

不要担心代理的数量。问题通常是“我可以使用代理吗”。有时并不实用。如果你可以拥有一个，你可以拥有两个或三个。许多复杂的架构涉及多达 5-6 个级别的代理，并且仍然可以很好地扩展。您应该注意一件事：不要在一台机器上安装比这台机器的 CPU 内核更多的此类代理，否则代理将不得不在高负载下共享它们的 CPU 时间，这会增加响应时间。但是对于机器上的 nginx 和 haproxy 发生这种情况，这将意味着每秒加载数万个请求，这不是今天每个人的问题。

此外，避免在同一系统上将单线程代理与大量多线程/多进程软件（例如 apache、java 等）混合使用。

考虑到这些规则后，只需绘制适合您需求的架构，将名称放在盒子上，以合理的方式组合它们并安装它们。

Answer 3

请记住，复杂性可能与代码/设计一样（如果不是更多）阻碍扩展。当您将实现细节分散到越来越多的服务和配置文件中时，您创建的东西更难以扩展，对团队的任何新成员都有更多的学习曲线，需要更多的软件/包来管理，使故障排除复杂化更多潜在的故障点，等等。为一个站点设置一个 4 代理层堆栈，如果使用 just-apache 或 just-nginx 就可以了，这基本上是“过早优化”的系统管理员版本。