为我的Ruby on Rails应用程序设置开发服务器的整个问题让我感到困惑。 我相信有WEBrick，Mongrel，Passenger，Apache，Nginx等等，我不太了解他们扮演的角色。
我开始使用WEBrick，现在我使用Mongrel进行开发。 这些服务器是独立的，还是坐在Apache前面？
我已阅读了关于Passenger的内容，但我并不真正了解它是什么，该网站称“可以轻松部署Ruby Web应用程序”，它是否取代了Mongrel？ 它是否像Capistrano，它也部署Web应用程序？
考虑到我想测试SSL，我相信这不被mongrel支持，什么是最好的开发服务器设置？
谢谢
取决于上下文，“部署”这个词可以有两个含义。 您还将Apache / Nginx的角色与其他组件的角色相混淆。
历史性注释：本文最初编写于2010年11月6日，当时Ruby应用服务器生态系统受到限制。 我已于2013年3月15日更新了这篇文章，其中包含生态系统中的所有最新更新。
免责声明 ：我是应用服务器之一Phusion Passenger的作者之一。
Apache与Nginx
他们都是网络服务器。 他们可以提供静态文件，但是 - 使用正确的模块 - 还可以提供动态Web应用程序，例如用PHP编写的应用程序。 Apache更受欢迎，功能更多，Nginx体积更小，速度更快，功能更少。
Apache和Nginx都不能直接为Ruby Web应用程序提供服务，因此您需要将Apache / Nginx与某种附加组件结合使用（稍后介绍）。
Apache和Nginx也可以充当反向代理，这意味着他们可以接收传入的HTTP请求并将其转发到另一个服务器，该服务器也会说HTTP。 当该服务器响应HTTP响应时，Apache / Nginx会将响应转发回客户端; 稍后您将了解为什么这是相关的。
Mongrel和其他生产应用程序服务器与WEBrick
Mongrel是一个Ruby“应用程序服务器”：具体而言，这意味着Mongrel是一个应用程序，它：
将您的Ruby应用程序加载到其自己的进程空间中。 设置一个TCP套接字，允许它与外部世界（例如互联网）进行通信。 Mongrel在此套接字上侦听HTTP请求，并将请求数据传递给Ruby Web应用程序。 Ruby web应用程序然后返回一个对象，该对象描述了HTTP响应应该是什么样子，而Mongrel负责将其转换为实际的HTTP响应（实际字节）并通过套接字将其发回。 然而，Mongrel相当过时，现在它不再被维护。 较新的替代应用程序服务器是：
Phusion乘客 独角兽 瘦 美洲狮 特立尼达（仅限JRuby） TorqueBox（仅JRuby） 我会在后面介绍他们，并描述他们与其他人以及来自Mongrel的不同之处。
WEBrick和Mongrel一样，但不同之处在于：
WEBrick不适合生产，与我之前提到的其他一切不同。 WEBrick完全是用Ruby编写的。 Mongrel（和大多数其他Ruby应用程序服务器）是Ruby的一部分，也是C的一部分（主要是Ruby），但是它的HTTP解析器是用C语言编写的，因为它的性能很好。 WEBrick速度较慢且不太健壮。 它有一些已知的内存泄漏和一些已知的HTTP解析问题。 默认情况下，WEBrick通常仅在开发过程中用作默认服务器，因为WEBrick包含在Ruby中。 Mongrel和其他应用程序服务器需要单独安装。 不建议在生产环境中使用WEBrick，但由于某些原因，Heroku选择了WEBrick作为其默认服务器。 他们之前使用Thin，所以我不知道他们为什么切换到WEBrick。 应用服务器和世界
所有当前的Ruby应用程序服务器都会使用HTTP，但有些应用程序服务器可能会直接通过端口80向Internet公开，而其他应用程序则可能不会。
可直接接触互联网的应用服务器：Phusion Passenger，Rainbows 可能不直接暴露于互联网的应用服务器：Mongrel，Unicorn，Thin，Puma。 这些应用服务器必须放在像Apache和Nginx这样的反向代理Web服务器后面。 我对特立尼达和TorqueBox不太了解，所以我省略了它们。 为什么必须将一些应用程序服务器放在反向代理之后？
一些应用程序服务器只能同时处理1个请求，每个进程。 如果你想同时处理2个请求，你需要运行多个应用服务器实例，每个实例服务于同一个Ruby应用。 这组应用服务器进程称为应用服务器集群（因此称为Mongrel集群，精简集群等）。 然后，您必须设置Apache或Nginx以将代理转换为此群集。 Apache / Nginx将负责在集群中的实例之间分配请求（关于这一部分的“I / O并发模型”部分）。 Web服务器可以缓存请求和响应，保护应用程序服务器免受“慢速客户端”的影响 - 不会很快发送或接受数据的HTTP客户端。 您不希望您的应用程序服务器在等待客户端发送完整请求或接收完整响应时不执行任何操作，因为在此期间，应用程序服务器可能无法执行其他任何操作。 Apache和Nginx在同时做很多事情方面非常擅长，因为它们或者是多线程的，或者是偶数的。 大多数应用程序服务器可以提供静态文件，但不是特别擅长。 Apache和Nginx可以更快地完成任务。 人们通常将Apache / Nginx设置为直接提供静态文件，但将不与静态文件相对应的请求转发到应用服务器，这是很好的安全措施。 Apache和Nginx非常成熟，可以屏蔽应用程序服务器（可能是恶意）损坏的请求。 为什么一些应用程序服务器可以直接暴露于互联网？
Phusion Passenger与所有其他应用服务器是完全不同的野兽。 其独特功能之一是它集成到Web服务器中。 Rainbows作者公开表示将其直接暴露给互联网是安全的。 作者相当肯定HTTP解析器（和类似的）没有漏洞。 尽管如此，作者并没有提供保证，并表示使用是有风险的。 比较应用服务器
在本节中，我将比较我提到的大多数应用程序服务器，但不是Phusion Passenger。 Phusion Passenger与其他动物是截然不同的，我给了它一个专门的章节。 我也省略了Trinidad和TorqueBox，因为我不太了解它们，但是如果您使用JRuby，它们只是相关的。
杂种是非常光秃秃的骨头。 如前所述，Mongrel纯粹是单线程的多进程，所以它只在群集中有用。 没有进程监控：如果群集中的进程崩溃（例如，由于应用程序中的错误），则需要手动重新启动。 人们倾向于使用外部流程监控工具，如Monit和上帝。 独角兽是Mongrel的分支。 它支持有限的进程监视：如果进程崩溃，它将自动由主进程重新启动。 它可以使所有进程在单个共享套接字上监听，而不是为每个进程单独分配一个套接字。 这简化了反向代理配置。 像Mongrel一样，它纯粹是单线程的多进程。 Thin通过使用EventMachine库来使用均衡的I / O模型。 除了使用Mongrel HTTP解析器外，它不以任何方式基于Mongrel。 它的集群模式没有进程监视，所以你需要监视崩溃等。没有独角兽的共享套接字，所以每个进程在它自己的套接字上侦听。 理论上，Thin的I / O模型允许高并发性，但在Thin用于大多数实际情况下，一个Thin进程只能处理1个并发请求，因此您仍然需要一个集群。 更多关于“I / O并发模型”一节中的这个特殊属性。 Puma也是从Mongrel中分出来的，但与Unicorn不同，Puma被设计为纯粹的多线程。 因此目前没有内置的集群支持。 您需要特别注意确保您可以使用多个内核（更多关于此内容的“I / O并发模型”部分）。 Rainbows通过使用不同的库支持多种并发模型。 Phusion乘客
Phusion Passenger的工作方式与其他所有工作方式大不相同。 Phusion Passenger直接集成到Apache或Nginx中，因此可以与Apache的mod_php进行比较。 就像mod_php允许Apache为PHP应用程序提供服务一样，几乎神奇地，Phusion Passenger允许Apache（也包括Nginx！）几乎神奇地为Ruby应用程序提供服务。 Phusion Passenger的目标是让尽可能少麻烦的一切正常工作（tm）。
使用Phusion Passenger，您无需为您的应用程序启动进程或集群，也无需配置Apache / Nginx以将静态文件和/或反向代理请求配置到进程/集群，只需：
您可以编辑Web服务器配置文件并指定您的Ruby应用程序的“公共”目录的位置。 没有第二步。 所有配置都在Web服务器配置文件中完成。 Phusion Passenger几乎可以自动完成所有的事情。 无需启动集群并管理进程。 启动/停止进程，在崩溃时重启进程等 - 全部自动化。 与其他应用服务器相比，Phusion Passenger的移动部件少得多。 这种易用性是人们使用Phusion Passenger的主要原因之一。
与其他应用程序服务器不同，Phusion Passenger主要使用C ++编写，因此速度非常快。
另外还有一个Phusion Passenger的Enterprise版本，它具有更多的功能，例如自动滚动重启，多线程支持，部署错误抵抗等。
由于上述原因，Phusion Passenger是目前最流行的Ruby应用程序服务器，为超过150,000个网站提供支持，其中包括纽约时报，皮克斯，Airbnb等大型网站。
Phusion Passenger vs其他应用服务器
Phusion Passenger提供了更多的功能，并提供了许多优于其他应用程序服务器的优势，例如：
根据流量动态调整流程数量。 我们在我们的资源受限服务器上运行了大量不属于公共的Rails应用程序，而且我们组织中的人员一天最多只能使用几次。 比如Gitlab，Redmine等。Phusion Passenger可以在不使用这些进程的时候降低这些进程的速度，并在他们使用时将其旋转起来，从而为更重要的应用程序提供更多资源。 使用其他应用程序服务器时，您的所有进程始终处于打开状态。 某些应用服务器在设计上并不擅长某些工作负载。 例如Unicorn专为快速运行的请求而设计：请参阅Unicorn网站部分“在某些情况下更糟糕”。 Unicorn不擅长的工作量是：
流式工作负载（例如Rails 4直播或Rails 4模板流式传输）。 应用程序执行HTTP API调用的工作负载。 Phusion Passenger Enterprise 4或更高版本中的混合I / O模型使其成为这类工作负载的理想选择。
其他应用程序服务器要求用户每个应用程序至少运行一个实例。 相比之下，Phusion Passenger在单一实例中支持多个应用程序。 这大大减少了管理开销。 自动用户切换，方便的安全功能。 Phusion Passenger支持许多MRI Ruby，JRuby和Rubinius。 Mongrel，Unicorn和Thin仅支持MRI。 彪马也支持所有3。 Phusion Passenger实际上支持的不仅仅是Ruby！ 它还支持Python WSGI，因此它也可以运行Django和Flask应用程序。 事实上，Phusion Passenger正在朝着成为多语种服务器的方向发展。 待办事项列表上的Node.js支持。 带外垃圾收集。 Phusion Passenger可以在正常的请求/响应周期之外运行Ruby垃圾收集器，这可能会将请求时间缩短数百毫秒。 独角兽也有类似的功能，但Phusion Passenger的版本更加灵活，因为1）它不限于GC，可用于任意工作。 2）Phusion Passenger的版本适用于多线程应用程序，而Unicorn则不适用。 自动滚动重启。 Unicorn和其他服务器上的滚动重启需要一些脚本工作。 Phusion乘客企业为您完全自动化这种方式。 有更多的功能和优势，但名单真的很长。 您应该参阅全面的Phusion乘客手册（Apache版本，Nginx版本）或Phusion乘客网站以获取信息。
I / O并发模型
单线程多进程。 传统上，这是Ruby应用服务器最流行的I / O模型，部分原因是Ruby生态系统中的多线程支持非常糟糕。 每个进程一次只能处理1个请求。 Web服务器在进程之间负载平衡。 这个模型非常强大，程序员很少有机会引入并发错误。 但是，它的I / O并发性非常有限（受进程数量的限制）。 该模型非常适用于快速，短期运行的工作负载。 它非常不适合缓慢，长时间运行的阻塞I / O工作负载，例如涉及调用HTTP API的工作负载。 纯粹的多线程。 现在，Ruby生态系统拥有出色的多线程支持，因此这种I / O模型已经变得非常可行。 多线程允许高I / O并发性，使其适用于短期运行和长时间运行的阻塞I / O工作负载。 程序员更可能引入并发错误，但幸运的是，大多数Web框架的设计方式仍然不太可能。 但需要注意的是，由于使用了全局解释器锁（GIL），MRI Ruby解释器即使在有多个线程时也不能利用多个CPU内核。 您可以通过使用多个多线程进程来解决此问题，因为每个进程都可以利用一个CPU内核。 JRuby和Rubinius没有GIL，所以他们可以在一个进程中充分利用多个内核。 混合多线程多进程。 主要由Phusion Passenger Enterprise 4及更高版本实施。 您可以轻松地在单线程多进程，纯多线程或甚至多个进程之间切换，每个进程都有多个线程。 这个模型给了两全其美。 事件触发。 这个模型与前面提到的模型完全不同。 它允许非常高的I / O并发性，因此非常适合长时间运行的阻塞I / O工作负载。 为了利用它，需要来自应用程序和框架的明确支持。 然而，像Rails和Sinatra这样的所有主要框架都不支持均衡代码。 这就是为什么在实践中，精简流程仍然无法同时处理超过1个请求，使其与单线程多进程模型的行为效果相同。 有专门的框架可以利用均匀的I / O，比如Cramp。 最近在Phusion博客上发布了一篇关于优化调整工作负载的进程和线程数量的文章。 请参阅调整Phusion Passenger的并发设置。
Capistrano的
卡皮斯特拉诺是完全不同的东西。 在前面的所有章节中，“部署”是指在应用程序服务器中启动Ruby应用程序的行为，以便访问者可以访问它，但在此之前，通常需要做一些准备工作，例如：
将Ruby应用程序的代码和文件上传到服务器机器。 安装你的应用依赖的库。 设置或迁移数据库。 启动和停止应用程序可能依赖的任何守护程序，例如Sidekiq / Resque工作人员或其他人员。 您在设置应用程序时需要完成的任何其他事情。 在Capistrano的情况下，“部署”是指做所有这些准备工作。 Capistrano不是应用程序服务器。 相反，它是使所有准备工作自动化的工具。 您可以告诉Capistrano您的服务器在哪里，并且每次部署新版本的应用程序时都需要运行哪些命令，Capistrano会负责将Rails应用程序上传到服务器并运行您指定的命令。
Capistrano总是与应用程序服务器结合使用。 它不会取代应用程序服务器。 反之亦然，应用服务器不会取代Capistrano，它们可以与Capistrano结合使用。
当然你不必使用Capistrano。 如果你喜欢用FTP上传你的Ruby应用程序，并且每次都手动运行相同的命令步骤，那么你可以做到这一点。 其他人对此感到厌倦，所以他们在Capistrano自动执行这些步骤。
链接地址:
http://www.djcxy.com/p/18443.html
上一篇:
Ruby on Rails Server options
下一篇:
How to send keyboard events to all kind of applications in windows?
