Web 服务器范式的差异（Apache 与反向代理 + Web 服务器）

Question

我已经开始使用 Ruby on Rails 进行开发，并且在涉及 Web 服务器时遇到了所谓的 a different paradigm。

Old paradigm (apache)
=====================

                +--- web process fork
                |
[requests] -----+--- web process fork
                |
                +--- web process fork


New paradigm (Puma + Nginx)
===========================
                                           +---> web app process 1 --> threads
                                           |
[requests] <-->  [reverse proxy server]  --+---> web app process 2 --> threads
                                           |
                                           +---> web app process 3 --> threads

在我正在阅读的文章中，它并没有试图解释这两种范式之间的差异，以及一种相对于另一种的好处。这是我感兴趣的。

在 Ruby on Rails 应用程序上使用这种新范式有什么意义？与旧的 HTTP 守护程序方式相比有什么优势？它有什么缺点？

Answer 1

应用服务器架构具有以下特点：

总的来说，我赞成将 Web 应用程序作为应用程序服务器运行并对其进行反向代理。设置起来花费最少，好处很多：您可以单独管理您的 Web 服务器和应用程序，您可以在任意数量的机器上运行任意数量的应用程序进程，而无需更多的 Web 服务器，您可以运行应用程序作为不同的用户零努力，您可以切换 Web 服务器，您可以在不接触 Web 服务器的情况下关闭应用程序，您可以通过切换 fifo 指向的位置等进行无缝部署。将您的应用程序焊接到您的 Web 服务器这是荒谬的，没有充分的理由再这样做了。

与经典模型相比：

PHP 与 Apache 有着天然的联系。单独运行它，或者与任何其他网络服务器一起运行，需要与部署任何其他语言一样多（可能更多）。 php.ini 适用于在任何地方运行的每个 PHP 应用程序。 php.ini文件只有一个，全局应用；如果您在共享服务器上并且需要更改它，或者如果您运行两个需要不同设置的应用程序，那么您就不走运了；您必须应用所有必要设置的联合，并使用 ini_set 或在 Apache 的配置文件或 .htaccess 中从应用程序本身内部削减它们。如果你可以的话。哇，还有很多地方你需要检查才能弄清楚设置是如何获得它的价值的。 同样，也没有简单的方法可以将 PHP 应用程序及其依赖项与系统的其余部分“隔离”。运行两个需要不同版本库的应用程序，甚至是 PHP 本身？首先构建 Apache 的第二个副本。 “一堆文件”方法，除了让路由非常痛苦之外，还意味着您必须仔细地将实际可用的东西列入白名单或黑名单，因为您的 URL 层次结构也是您的整个代码树。配置文件和其他“部分”需要类似 C 的保护来防止它们被直接加载。版本控制噪音（例如 .svn）需要保护。使用 mod_php，文件系统上的所有内容都是潜在的入口点；对于应用服务器，只有一个入口点，只有 URL 控制它是否被调用。 您无法无缝升级一堆运行 CGI 样式的文件，除非您希望在升级中途用户访问您的网站时出现崩溃和未定义的行为。

其他范例包括：

• Web 应用程序是一个 Web 服务器，可以直接接受 HTTP 请求。此模型的示例：

  • 几乎所有 Node.js 和 Meteor JS Web 应用程序 (https://lookback.io)。

  • Trac 错误跟踪软件，在其独立服务器中运行 (https://trac.webkit.org)。

• Web 应用程序不直接使用 HTTP，而是通过一些通信适配器直接连接到 Web 服务器。 CGI、FastCGI 和 SCGI 就是很好的例子。 (web.py, flask, sinatra)

开始（） ----------------------------------------- | | |初始化（） | 新 ->-- 初始化 | | | | | -------------------- STARTING_PREP -->- 开始 -->- 开始 -->--- | | | | | | | |销毁()| | | | -->--------- 正在停止 ------>----- 已停止 -->----- | \|/ ^ | ^ | |停止（） | | | | | -------------------------- | | | | | | | | | |销毁() 销毁() | | | |失败 ---->----- 销毁 -------------------- \|/ | |毁坏 | | | |停止（） | --->------------------------------------------>--------------- ---------------

在 Heroku 上，应用程序是完全独立的，不依赖于将网络服务器运行时注入到执行环境中来创建面向网络的服务。每个 Web 进程都简单地绑定到一个端口，并监听来自该端口的请求。 Heroku 将要绑定的端口分配为 PORT 环境变量。

参考文献

• PHP: a fractal of bad design

• Phusion Passenger: Design and Architecture

• Optimizing PHP Application Concurrency | Heroku Dev Center

• Runtime Principles | Heroku Dev Center