☰

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

tag-icon • tag-icon nginx load-balancing reverse-proxy varnish haproxy
多少个反向代理（nginx、haproxy）才算太多？

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

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

另一方面，nginx 在提供静态内容方面速度更快，并会减少耗费大量 RAM 的强大 apache 的负载！

以下是我计划的设置：

负载均衡器：nginx 监听 80/443 端口，并将 proxy_forwards 转发到同一服务器上 8080 上的 haproxy，以在多个节点之间进行负载平衡。

节点：节点上的 nginx 监听来自 8080 上的 haproxy 的请求，如果内容是静态的，则提供该请求。但如果是后端脚本（在我的情况下是 PHP），则代理转发到同一节点服务器上监听不同端口号的 apache2。

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

有什么想法吗？干杯

答案1

从纯粹的性能角度来看，让基准测试为你做出这些决定，而不是假设——使用类似httperf在进行架构变更时非常有价值。

从架构哲学的角度来看，我有点好奇为什么您在应用服务器上同时安装了 nginx 和 apache。Nginx 擅长处理静态内容，并能高效处理大多数后端框架/技术（Rails、通过 FastFCGI 的 PHP 等），因此我会放弃最后的 Apache 层。再次强调，这是由于您对所用技术的了解有限，因此您可能需要它，而我没有预料到（但如果是这样，您可以随时在应用服务器上放弃 nginx，只使用 apache——如果配置正确，它在静态内容方面并没有那么糟糕）。

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

答案2

您的设置越来越普遍。您不必担心。nginx 和 haproxy 处理和转发 HTTP 请求的速度都非常快。两者结合得很好，工作也做得非常好。无需选择。安装它们并快乐着。这样，您将非常快速地交付静态文件，并确保动态服务器的平稳扩展。

不必担心代理的数量。问题通常是“我可以使用代理吗”。有时这并不实际。如果您可以有一个，那么您可以有两个或三个。许多复杂的架构涉及多达 5-6 级的代理，并且仍然可以很好地扩展。您只需注意一件事：不要在一台机器上安装比这台机器的 CPU 核心更多的此类代理，否则代理将不得不在高负载下共享其 CPU 时间，这将增加响应时间。但是对于一台机器上的 nginx 和 haproxy 来说，这意味着每秒有数万个请求的负载，这不是每个人现在都会遇到的问题。

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

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

答案3

请记住，复杂性对扩展的阻碍可能与代码/设计一样多（甚至更多）。随着您将实现细节分散到越来越多的服务和配置文件中，您将创建更难以扩展的东西，对于团队新人来说，学习曲线会更长，需要管理更多的软件/包，使故障排除更加复杂，潜在故障点更多，等等。为一个使用 just-apache 或 just-nginx 就可以正常工作的站点设置 4 代理层堆栈基本上是系统管理员版本的“过早优化”。

答案4

更新至2020年，这是您在使用 PHP 应用程序时应该遇到的标准推荐设置。

LOAD BALANCER              SERVER A
   haproxy   -+--------->   nginx   -+---> /app/ ------> PHP application
              |                      |
              |                      +---> /static/ ---> local files
              |              
              |
              |            SERVER B
              +--------->   nginx   -+---> /app/ ------> PHP application
                                     |
                                     +---> /static/ ---> local files

这为来自多个主机的应用程序和静态文件提供服务，每个主机都是相同的。nginx 可以运行 PHP 应用程序（通过 fastcgi）并提供本地文件。

如果是旧的 PHP 应用程序，则可能在设计时考虑使用 Apache 而不是 nginx。没问题。Apache 也可以运行 PHP 应用程序（cgi、fastcgi 或 mod_php）并提供本地文件。

可以从 Apache 迁移到 nginx，但对于旧系统来说，这不一定值得。Apache 的构建和配置很麻烦，但如果它已经在运行，那就不是问题了。Apache 的性能并不好，但 PHP 的速度要慢得多，瓶颈永远是应用程序。

前面需要一层负载均衡器来在服务器之间分配流量。通常是 HAProxy、AWS ALB、F5 或 CloudFlare 之一。

可以在中间添加无限数量的层，但这没有任何好处。原始问题的关注点已经过时了。所有这些软件都支持 SSL 近十年了，设置可以端到端运行 SSL。得益于不久前添加到 Linux 内核的 sendfile()，本地文件可以高效地提供。

相关内容