如今运行 Perl Web 应用程序的一个非常流行的选择似乎是在 nginx Web 服务器后面将请求代理到 FastCGI 守护程序或启用 PSGI 的 Web 服务器（例如 Starman）。
关于为什么人们会这样做有很多疑问（例如为什么将 nginx 与 Catalyst/Plack/Starman 一起使用？ https://stackoverflow.com/questions/2939393/why-use-nginx-with-catalyst-plack-starman）
答案似乎适用于这两种情况（例如允许 nginx 提供静态内容、轻松重新启动应用程序服务器、负载平衡等）
然而，我对使用 FastCGI 与反向代理方法的优缺点特别感兴趣。 Starman 似乎被广泛认为是最快、最好的 Perl PSGI 应用程序/Web 服务器，而我正在努力寻找使用 FastCGI 的任何优势。两种方法似乎都支持：
- UNIX 域套接字以及 TCP 套接字
- fork/进程管理器风格的服务器以及非阻塞基于事件（例如 AnyEvent）的服务器。
- 信号处理/优雅重启
- PSGI
同样，任一选项的 nginx 配置都非常相似。
那么为什么你会选择其中之一而不是另一个呢？
反向代理设置（例如 nginx 将 HTTP 请求转发给 Starman）具有以下优点：
事情更容易调试，因为您可以轻松地直接访问后端服务器；
如果您需要扩展后端服务器，您可以轻松地在前端（静态服务）HTTP 和后端之间使用 pound/haproxy 之类的东西（Zope 通常是这样部署的）；
如果您还使用某种面向外的、缓存的、反向代理（如 Varnish 或 Squid），它可能是一个很好的助手，因为它可以很容易地绕过它。
然而，它有以下缺点：
后端服务器必须找出真正的始发IP，因为它看到的只是前端服务器地址（通常是localhost）；几乎有一种简单的方法可以找出 HTTP 标头中的客户端 IP 地址，但这需要额外的了解；
后端服务器通常不知道原始的“Host:”HTTP header，因此无法自动生成本地资源的绝对URL； Zope 使用特殊的 URL 来解决这个问题，将原始协议、主机和端口嵌入到后端的请求中，但使用 FastCGI/Plack/... 则不需要这样做；
前端无法自动生成后端进程，就像 FastCGI 那样。
我想，选择你最喜欢的优点/缺点并做出选择;-)
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
