FCGI死了吗？现在有什么替代方案？

Question

我是 Perl 的初学者。

我的理解如下。

• FCGI 是一种协议
• 它是 Web 服务器和 Web 应用程序之间的网关接口
• 该进程在特定时间段内保持活动（例如5分钟）并接受多个请求，因此响应速度很快。
• 您在构建进程之前缓存了一些数据，以便您可以与所有进程共享这些缓存，并且您可以通过 Copy-on-Write 节省内存。

看起来不错。 但是，在我使用 Golang、Nginx 或其他任何东西进行现代开发的经验中，我从未见过 FCGI。

现代 Web 应用程序不再需要 FCGI 了吗？

FCGI 的缺点是什么，FCGI 的优点是什么？

Answer 1

如果我们说有更好的选择/方式将是正确的陈述，而不是说任何死的或活的。仍然在 2021 年，我已经看到在生产中使用 FCGI 运行的代码并且运行良好。最新评论发生在 2019 年 github。一切都有时间框架。老不代表坏/死，年轻不代表好/活着。

对于现代 Web 开发，现在有许多可用的框架 -

1. Catalyst
2. Mojolicious
3. Dancer2
4. Kelp
5. Raisin

前 3 个是最常见的。 Mojo是我个人的最爱。 您可以将它们与Plack/uWSGI 一起使用，您很快就可以开始使用了。他们会照顾好一切。

由于您提到“FastCGI 是一种协议”并且它不是一种实现，因此它不应该特定于任何语言。将有跨不同语言的实现（可能不流行）。您可以通过单次搜索找到它们。 Nginx的一个例子

之前还有很多其他类似的问题。看看那些。它们会让你更清楚。

Is there a speed difference between WSGI and FCGI?

Is mod_perl what I'm looking for? FastCGI? PSGI/Plack?

Perl CGI vs FastCGI

Which is better perl-CGI, mod_perl or PSGI?

Answer 2

稍微扩展Maverick's answer...

在编写 Web 应用程序时，您需要问自己两个问题：

1. 我将使用什么语言/框架编写此应用程序？
2. 我将如何部署此应用程序？

在糟糕的过去，这两个问题的答案以令人讨厌的方式交织在一起。您可能最初编写一个 CGI 程序，然后在以后希望应用程序获得更好的性能时切换到不同的部署环境（可能是 FCGI 或 mod_perl）。但是更改为不同的部署环境通常意味着对您的代码进行大量更改。该应用程序需要太多关于部署环境的知识。这让生活变得艰难。

如果您在另一个答案中使用框架，那么情况就不同了。这些框架中的大多数（也许全部）运行在称为 PSGI（Perl 服务器网关接口）的协议之上。通过使用这些框架编写应用程序，您的应用程序将使用 PSGI 协议与 Web 服务器进行交互。并且有适用于所有 Web 部署环境的 PSGI 适配器。因此，您可以先将 Dancer2 应用程序部署为 CGI 程序（很少有人这样做，但完全有可能），然后将其移至 FCGI 或 mod_perl 环境，而无需更改您的代码。

我仍然看到人们在 FCGI 中部署应用程序。如今，它肯定比使用 mod_perl 更常见。但是，老实说，我看到的最常见的部署环境是将您的应用程序设置为在高端口号上运行的独立服务，并使用像 nginx 这样的服务器来代理对您的服务的请求。这就是我的建议。