FastCGI仍然是一个正确的答案吗？

Question

FastCGI已经过时但在某些情况下它似乎仍然是正确答案.

看起来Perl/Catalyst Web应用程序的首选部署是使用FastCGI.

FastCGI在Rails中很受欢迎,但似乎不再适用.(为什么？)

Java世界似乎与FastCGI没有任何关系.像Tomcat这样的东西比Apache + FastCGI更好吗？

选择FastCGI仍然是一个好主意还是仅仅是一种挥之不去的技术？

摊晒

Answer 1

由于它很大程度上取决于您的设置和要求,我会让"X仍然是正确答案吗？" 由你决定.但是,通过查看不同的体系结构,您可以提出一个问题列表,以确定在特定情况下它是否仍然是正确的答案.

关注频繁的兴趣

您想要问的问题通常与安全性和灵活性有关.为了安全起见,您需要遵循最小特权原则.为了灵活性,您需要知道是否可以运行多个框架,多个版本的框架以及将工作委托给其他任务的容易程度.

其他问题

对于数据库支持的应用程序的简单Web前端,并非所有这些问题都很重要.您还需要记住,一些建议与此处概述的内容无关.许多Web框架将推荐最容易使用其框架设置的架构.他们这样做是因为它有助于让新用户轻松地尝试框架并且不会充斥邮件列表.此外,Java社区倾向于坚持共同点,而不是充分利用手头的平台,因此他们通常会推荐全Java解决方案.

流行的建筑

单进程架构

从纯粹的性能角度来看,具有嵌入式框架的单个进程(可能是线程化的)可能提供大多数性能,因为它减少了接收请求和产生响应之间的大部分通信开销.

安全性:单个进程必须具有执行每个任务所需的所有权限.在简单的应用程序中,这可能不是问题.但是,它可能会提供多种服务

灵活性:可能无法运行同一框架的多个版本(例如,网站不同部分的代码需要不同版本的Java,Rails,Python等).此外,更改您的设置以在不同的计算机上执行某些工作会变得很痛苦(在虚拟主机上拆分时不那么困难).

基于子流程的体系结构

在CGI模型下,您必须为每个请求支付产生新流程的代价.即使在生成进程被认为是便宜的UNIX机器上,如果为每个进程生成一个进程,每秒600个请求将终止服务器.

安全性:为了在不同的用户帐户下生成子进程,您的网关可能在相当高的权限下运行.

灵活性:多个框架,多个版本,多种语言方法的额外灵活性,但您仍然停留在同一台机器上.

分布式架构

FastCGI/SCGI方法试图以干净的方式解决CGI流程管理问题.只是让这个过程保持活力.让网关与该进程通信以提供请求.

安全性:由于网关不会产生为请求提供服务的进程,因此网关可以在启用的权限较少的情况下运行.实际上,如果它只作为一个网关并且本身不做任何工作,它几乎不会有任何特权.

灵活性:您可以获得比CGI模型更好的灵活性,因为您可以将请求转发到网络上的任何计算机.

结论

我喜欢FastCGI,因为它给我带来了很高的灵活性(即通过套接字转发的请求)我能负担得起.管理系统不是我的全职工作.我没有开发我托管的所有应用程序.这意味着我寻找最简单的解决方案来托管我尝试托管的任何东西.FastCGI足以受到主要Web服务器和流行Web框架的支持.添加另一个应用程序通常只是归结为通过FastCGI安装并将所需的URL映射到应用程序.