为我的RubyonRails应用程序设置开发服务器的整个问题让我困惑。有Webrick、Mongrel、Passenger、Apache、Nginx等等，我确信，我不太了解他们扮演的不同角色。

我开始使用Webrick，现在使用Mongrel进行开发。这些服务器是独立的，还是位于Apache前面？

我读过关于passenger的文章，但我不太明白它是什么，该网站说"让RubyWeb应用程序的部署变得轻而易举"，它是否取代了Mongrel？它是否像Capistrano一样，也部署Web应用程序？

记住，我想测试SSL，我相信Mongrel不支持它，什么是最好的开发服务器设置？

谢谢

根据上下文，"部署"一词有两种含义。您还混淆了apache/nginx的角色和其他组件的角色。好的。

历史记录：本文最初写于2010年11月6日，当时Ruby应用服务器生态系统受到限制。我已经在2013年3月15日用生态系统中的所有最新更新更新了这篇文章。好的。

免责声明：我是应用程序服务器之一phusion passenger的作者之一。好的。阿帕奇vs nginx

它们都是网络服务器。它们可以提供静态文件，但使用正确的模块也可以提供动态Web应用程序，例如用PHP编写的应用程序。Apache更受欢迎，功能更多，nginx更小更快，功能更少。好的。

Apache和nginx都不能提供现成的Ruby Web应用程序，要做到这一点，您需要将Apache/nginx与某种附加组件结合使用，稍后将介绍。好的。

Apache和nginx还可以充当反向代理，这意味着它们可以接受一个传入的HTTP请求，并将其转发到另一个服务器，该服务器也会说HTTP。当服务器用HTTP响应响应时，apache/nginx将把响应转发回客户机；稍后您将了解为什么这是相关的。好的。Mongrel和其他生产应用服务器与Webrick

Mongrel是一个Ruby"应用服务器"：具体来说，这意味着Mongrel是一个应用程序，它：好的。

然而，混血儿已经很过时了，现在已经不复存在了。更新的替代应用程序服务器包括：好的。

• 乘客
• 独角兽
• 薄的
• 彪马
• 特立尼达(仅限JRuby)
• 扭矩箱(仅限JRuby)

稍后我将介绍它们，并描述它们之间以及与杂种之间的区别。好的。

Webrick和Mongrel做的一样，但区别在于：好的。

• Webrick不适合制作，不像我之前提到的所有其他内容。Webrick完全是用Ruby编写的。Mongrel(和大多数其他Ruby应用服务器)是Ruby和C部分(主要是Ruby)，但它的HTTP解析器是用C编写的以提高性能。
• Webrick速度较慢，不那么健壮。它有一些已知的内存泄漏和一些已知的HTTP解析问题。
• Webrick通常只在开发期间用作默认服务器，因为默认情况下Webrick包含在Ruby中。Mongrel和其他应用服务器需要单独安装。虽然出于某种原因Heroku选择Webrick作为其默认服务器，但不建议在生产环境中使用Webrick。他们以前用过Thin，所以我不知道他们为什么换成Webrick。

应用服务器和世界

所有当前的Ruby应用服务器都使用HTTP，但是某些应用服务器可能在端口80上直接暴露在Internet上，而其他应用服务器则可能不会。好的。

• 可直接接触互联网的应用服务器：phulsion乘客、彩虹
• 可能不会直接暴露在互联网上的应用服务器：Mongrel、Unicorn、Thin、Puma。这些应用服务器必须放在反向代理Web服务器(如Apache和nginx)后面。
• 我对特立尼达和扭矩箱的了解不够，所以我忽略了它们。

为什么某些应用服务器必须放在反向代理之后？好的。

• 有些应用程序服务器每个进程只能同时处理1个请求。如果要同时处理2个请求，则需要运行多个应用服务器实例，每个实例为同一个Ruby应用程序提供服务。这组应用服务器进程称为应用服务器集群(因此命名为mongrel cluster、thin cluster等)。然后必须设置apache或nginx，以将代理反向到此集群。Apache/nginx将负责在集群中的实例之间分发请求(更多信息请参见"I/O并发模型"一节)。
• Web服务器可以缓冲请求和响应，保护应用服务器不受"慢速客户端"的影响——HTTP客户端不能很快地发送或接受数据。在等待客户端发送完整请求或接收完整响应时，您不希望应用服务器什么也不做，因为在此期间，应用服务器可能无法执行任何其他操作。Apache和nginx非常擅长同时做许多事情，因为它们要么是多线程的，要么是事件的。
• 大多数应用服务器可以服务于静态文件，但并不擅长于此。Apache和nginx可以更快地完成任务。
• 人们通常设置apache/nginx来直接服务静态文件，但是将与静态文件不对应的请求转发到应用服务器，这是一种很好的安全实践。Apache和nginx非常成熟，可以保护应用服务器免受(可能是恶意的)损坏的请求。

为什么有些应用服务器可以直接暴露在互联网上？好的。

• 与其他所有应用服务器相比，phusion乘客是一种非常不同的野兽。它的一个独特功能是集成到Web服务器中。
• 彩虹的作者公开表示，直接将其暴露在互联网上是安全的。作者相当肯定HTTP解析器中没有漏洞(和类似的漏洞)。尽管如此，作者没有提供任何保证，并说使用是有风险的。

已比较应用程序服务器

在这一部分中，我将比较我提到的大多数应用服务器，但不比较phusion passenger。乘客是如此不同的野兽，我给它一个专门的部分。我也省略了特立尼达和扭矩箱，因为我对它们不太了解，但是它们只与使用JRuby相关。好的。

• 混血儿是非常赤裸裸的。如前所述，Mongrel是纯单线程多进程的，因此它只在集群中有用。没有进程监控：如果集群中的进程崩溃(例如，由于应用程序中的错误)，则需要手动重新启动该进程。人们倾向于使用外部过程监控工具，如monit和god。
• 独角兽是杂种的叉。它支持有限的进程监控：如果进程崩溃，则由主进程自动重新启动。它可以使所有进程在一个共享套接字上侦听，而不是为每个进程使用单独的套接字。这简化了反向代理配置。和Mongrel一样，它是纯单线程多进程的。
• thin通过使用eventmachine库使用evented I/O模型。除了使用MongrelHTTP解析器之外，它不以任何方式基于Mongrel。它的集群模式没有进程监控，因此需要监控崩溃等。没有像独角兽一样的共享套接字，因此每个进程都在自己的套接字上侦听。理论上，瘦的I/O模型允许高并发性，但在使用瘦的大多数实际情况下，一个瘦进程只能处理1个并发请求，所以您仍然需要一个集群。在"I/O并发模型"一节中，我们将详细介绍这个特殊的属性。
• 美洲狮也来自杂种，但与独角兽不同，美洲狮的设计是纯多线程的。因此，目前没有内置集群支持。您需要特别注意以确保可以使用多个核心(更多信息请参见"I/O并发模型"一节)。
• 彩虹通过使用不同的库支持多个并发模型。

乘客

乘客的工作方式与其他乘客截然不同。phulsion乘客直接集成到apache或nginx中，因此可以与mod_php for apache进行比较。就像mod_php允许apache为php应用程序提供服务一样，phulsion passenger也允许apache(以及nginx！)为Ruby应用服务，几乎是神奇的。乘客的目的是使一切工作(tm)尽可能少的麻烦。好的。

不必为应用程序启动进程或集群，也不必配置apache/nginx为静态文件和/或使用phulsion passenger将请求反向代理到进程/集群，只需：好的。

所有配置都在Web服务器配置文件中完成。普华永道的乘客几乎能使一切自动化。不需要启动集群和管理进程。启动/停止进程，在它们崩溃时重新启动它们，等等。—全部是自动化的。与其他应用服务器相比，phulsion乘客的移动部件要少得多。这种易用性是人们使用豪华轿车的主要原因之一。好的。

同样不像其他的应用服务器，Puffic乘客主要是用C++编写的，使得它非常快。好的。

此外，还有一种具有更多功能的企业版Fusion Passenger，如自动滚动重启、多线程支持、部署防错等。好的。

基于以上原因，phulsion passenger目前是最受欢迎的Ruby应用服务器，拥有超过15万个网站，其中包括纽约时报、皮克斯、Airbnb等大型网站。好的。乘客与其他应用服务器

与其他应用服务器相比，phulsion passenger提供了更多的功能和许多优势，例如：好的。

• 根据流量动态调整进程数。我们在资源受限的服务器上运行大量的Rails应用程序，这些应用程序不是面向公众的，而且我们组织中的人员一天最多只能使用几次。例如Gitlab、Redmine等。phulsion乘客可以在不使用时降低这些流程的速度，并在使用时将其加速，从而为更重要的应用程序提供更多的资源。对于其他应用服务器，所有进程都会一直打开。
• 根据设计，有些应用服务器在某些工作负载上不好。例如，独角兽是专为快速运行的请求而设计的：请参阅独角兽网站部分"在某些情况下更糟"。

独角兽不擅长的工作负荷有：好的。

• 流工作负载(例如，Rails 4实时流或Rails 4模板流)。
• 应用程序执行HTTP API调用的工作负载。

Fusion Passenger Enterprise 4或更高版本中的混合I/O模型使其成为此类工作负载的最佳选择。好的。

• 其他应用程序服务器要求用户通过至少一个实例可以运行应用程序。通过对比，phusion客运支持多应用在单实例。这大大降低了管理开销。
• 自动切换用户，一个方便的安全特征。
• 在MRI phusion客运支持JRuby和rubinius红宝石。杂种，独角兽和瘦的只支持核磁共振。所以所有的美洲狮的支持3。
• 乘客是支持phusion不止红宝石！它也支持WSGI的Python，所以它可以运行Django的瓶，例如应用程序。事实上phusion乘客是移动到A方向成为通晓多种语言的服务器。node.js支持在待办事项列表。
• 带垃圾出去。乘客可以phusion红宝石垃圾收集器运行都是正常的请求/响应周期，减少潜在的milliseconds时代学习的请求。所以有一独角兽相似的特征，但phusion乘客的版本是更灵活的，因为1)它不限于气相色谱可以用于任意的工作。2)phusion客运和多线程应用程序的版本的作品好，而独角兽的不。
• restarts自动滚动。滚动restarts独角兽和其他服务器上的脚本需要一些工作。phusion客运企业完全automates这样的你。

有更多的特点和优势，但战略是非常长的。你应该到客运综合phusion参考手册(Apache的版本，版本phusion客运Nginx)或网站的信息。

I/O并发模型

• 单线程多进程。这是传统上Ruby应用服务器最流行的I/O模型，部分原因是Ruby生态系统中的多线程支持非常糟糕。每个进程一次只能处理一个请求。Web服务器在进程之间进行负载平衡。这个模型非常健壮，程序员几乎没有机会引入并发错误。但是，它的I/O并发性非常有限(受进程数量的限制)。此模型非常适合于快速、短时间运行的工作负载。它非常不适合于缓慢、长时间运行的阻塞I/O工作负载，例如涉及HTTP API调用的工作负载。
• 纯多线程。目前Ruby生态系统具有良好的多线程支持，因此这个I/O模型变得非常可行。多线程允许高I/O并发性，使其适用于短运行和长运行的阻塞I/O工作负载。程序员更可能引入并发性错误，但幸运的是，大多数Web框架的设计方式仍然不太可能。然而，需要注意的一点是，由于使用了全局解释器锁(gil)，即使存在多个线程，mri ruby解释器也无法利用多个CPU核心。您可以通过使用多个多线程进程来解决这个问题，因为每个进程都可以利用一个CPU核心。JRuby和Rubinius没有gil，因此它们可以在一个流程中充分利用多个核心。
• 混合多线程多进程。主要由普锐斯客运企业4及以后实施。您可以轻松地在单线程多进程、纯多线程、甚至可能是多个进程之间切换，每个进程都有多个线程。这个模型提供了两个世界中最好的。
• 事件。这个模型与前面提到的模型完全不同。它允许非常高的I/O并发性，因此非常适合长时间运行的阻塞I/O工作负载。要利用它，需要应用程序和框架的明确支持。然而，像Rails和Sinatra这样的所有主要框架都不支持事件代码。这就是为什么在实践中，一个瘦进程仍然不能一次处理多于一个请求，从而使其有效地表现为与单线程多进程模型相同的行为。有一些专门的框架可以利用事件I/O，比如crmp。

最近，一篇文章发表在phusion博客上，关于根据您的工作负载优化进程和线程的数量。请参见调优乘客并发设置。好的。卡皮斯特拉诺

卡皮斯特拉诺完全不同。在前面的所有部分中，"部署"是指在应用服务器中启动Ruby应用程序，以便访问者可以访问它，但在这之前，通常需要做一些准备工作，例如：好的。

• 将Ruby应用程序的代码和文件上载到服务器计算机。
• 安装应用程序所依赖的库。
• 设置或迁移数据库。
• 启动和停止应用程序可能依赖的任何守护进程，如Sidekiq/Resque Workers或其他。
• 设置应用程序时需要做的任何其他事情。

在Capistrano的上下文中，"部署"是指完成所有这些准备工作。Capistrano不是应用服务器。相反，它是一个自动化所有准备工作的工具。每次部署新版本的应用程序时，您都会告诉Capistrano您的服务器在哪里以及需要运行哪些命令，Capistrano将负责为您将Rails应用程序上载到服务器并运行指定的命令。好的。

Capistrano总是与应用服务器结合使用。它不会取代应用服务器。反之亦然，应用服务器不会取代Capistrano，它们可以与Capistrano结合使用。好的。

当然，你不必使用Capistrano。如果你喜欢用ftp上传你的Ruby应用程序，并且每次都手动运行相同的命令步骤，那么你可以这样做。其他人对此感到厌倦，所以他们在Capistrano中自动执行这些步骤。好的。好啊.