nginx和Perl：FastCGI與反向代理（PSGI / Starman）

Question

如今，運行Perl Web應用程序的一個非常流行的選擇似乎是nginx webserver代理對FastCGI守護程序或PSGI啟用的Web服務器（例如Starman）的請求。

關於為什么一般會這樣做會有很多問題（例如為什么使用nginx和Catalyst / Plack / Starman？ ）並且答案似乎適用於兩種情況（例如，允許nginx提供靜態內容，輕松重啟應用程序服務器，負載均衡等）

但是，我對使用FastCGI與反向代理方法的優缺點特別感興趣。 似乎Starman被廣泛認為是最快和最好的Perl PSGI應用程序/網絡服務器，我很難看到使用FastCGI的任何優勢。 這兩種方法似乎都支持：

• UNIX域套接字以及TCP套接字
• fork / process manager樣式服務器以及非阻塞基於事件的（例如AnyEvent）服務器。
• 信號處理/正常重啟
• PSGI

同樣，任一選項的nginx配置都非常相似。

那你為什么選擇一個呢？

Answer 1

反向代理設置（例如，向Starman轉發HTTP請求的nginx）具有以下優點：

• 因為您可以輕松直接命中后端服務器，所以事情更容易調試;

• 如果你需要擴展你的后端服務器，你可以在前端（靜態服務）HTTP和你的后端之間輕松使用像pound / haproxy這樣的東西（Zope經常像那樣部署）;

• 如果你也使用某種面向外的緩存，反向代理（如Varnish或Squid），它可以是一個不錯的搭檔，因為它可以很容易地繞過它。

但是，它有以下缺點：

• 后端服務器必須找出真正的原始IP，因為它將看到的只是前端服務器地址（通常是localhost）; 幾乎有一種簡單的方法可以找到HTTP標頭中的客戶端IP地址，但這是一個額外的問題;

• 后端服務器通常不知道orignal“Host：”HTTP頭，因此，不能自動生成本地資源的絕對URL; Zope使用特殊URL解決了這個問題，將請求中的原始協議，主機和端口嵌入到后端，但這與FastCGI / Plack / ...沒有關系。

• 前端不能自動生成后端進程，就像它可以用FastCGI做的那樣。

選擇你最喜歡的優點/缺點並做出你的選擇，我猜;-)

Answer 2

大多數系統管理員都很好地理解HTTP，並且它很容易調試。 幾乎總是已經部署了某種反向代理，所以只需在其配置中添加另一個配置節，以便在幾秒鍾內啟動並運行您的應用程序，這是一塊蛋糕。 從未測試過兩種設置的速度差異，但另一方面我從未在該區域遇到過任何問題，所以它不會那么糟糕。