perl - nginx 和 Perl : FastCGI vs reverse proxy (PSGI/Starman)

Question

如今，运行 Perl Web 应用程序的一个非常流行的选择似乎是在 nginx 网络服务器后面，该服务器将请求代理到 FastCGI 守护程序或启用 PSGI 的网络服务器(例如 Starman)。

关于为什么通常会这样做(例如 Why use nginx with Catalyst/Plack/Starman? )有很多问题
并且答案似乎在这两种情况下都适用(例如，允许 nginx 提供静态内容、轻松重启应用程序服务器、负载平衡等)

但是，我对使用 FastCGI 与反向代理方法的优缺点特别感兴趣。似乎 Starman 被广泛认为是最快和最好的 Perl PSGI 应用程序/Web 服务器，我很难看到使用 FastCGI 的任何优势。这两种方法似乎都支持:

UNIX 域套接字以及 TCP 套接字

fork/process manager 风格的服务器以及基于事件的非阻塞(例如 AnyEvent)服务器。

信号处理/优雅重启

PSGI

同样，任一选项的 nginx 配置都非常相似。

那么为什么你会选择其中之一呢？

Answer 1

反向代理设置(例如 nginx 将 HTTP 请求转发给 Starman)具有以下优点:

调试起来更容易一些，因为您可以轻松地直接访问后端服务器；

如果您需要扩展后端服务器，您可以轻松地在前端(静态服务)HTTP 和后端之间使用 pound/haproxy 之类的东西(Zope 经常这样部署)；

如果您还使用某种面向外部的、缓存的、反向代理(如 Varnish 或 Squid)，它可能是一个不错的伙伴，因为它可以很容易地绕过它。

但是，它有以下缺点:

后端服务器必须找出真正的原始 IP，因为它所看到的只是前端服务器地址(通常是 localhost)；几乎有一种简单的方法可以在 HTTP header 中找出客户端 IP 地址，但这是需要弄清楚的额外内容；

后端服务器通常不知道原始的“Host:” HTTP 头，因此无法自动生成本地资源的绝对 URL； Zope 使用特殊的 URL 来解决这个问题，将原始协议(protocol)、主机和端口嵌入到后端的请求中，但这与 FastCGI/Plack/... 无关；

前端不能像 FastCGI 那样自动生成后端进程。

选择你最喜欢的优点/缺点并做出你的选择，我猜;-)