找回密码
 注册论坛帐号
查看: 994|回复: 0

ruby rails相关的常见服务器!

[复制链接]
发表于 2017-12-26 19:24:33 | 显示全部楼层 |阅读模式
  他们都是web服务器,都能伺服静态文件。Apache更加流行,拥有更多的功能;Nginx则相对功能少、小巧、快速。
  Apache 和 Nginx都能作为反向代理,就是说他们能够把进来的HTTP请求转发给其他服务器,接着把该服务器的响应转给客户端。

  3,Ruby app返回一个描述HTTP响应的对象,Mongrel将其转换为真正的HTTP响应字节,并发回到socket中。
  因为WEBrick是ruby默认自带的,所以WEBrick经常用于development模式下作为默认服务器,而其他服务器则需要另外安装。不建议在production模式下是用WEBrick服务器,虽然因为某些原因,Heroku选择了WEBrick作为默认服务器,他们以前是使用的Thin,但我不知道他们为什么换到了WEBrick
  当前所有的Ruby app 服务器都是http类型的,一些服务器直接将80端口暴露到internet中,另一些则没有
  一些服务器的一个进程在同一时间只能处理一个请求,如果你想同时处理两个请求,你就需要启动多个服务器实例,都伺服同一个Ruby app。这种多进程app 服务器称为app服务器集群(比如Mongrel Cluster, Thin Cluster)。你必须启动Apache 或者 Nginx,给集群做反向代理,Apache/Nginx会处理好集群中不同应用实例间的分发工作。(更多内容参见章节 I/O并发模型).
  web 服务器可以缓存请求和响应。有些客户端的发送数据、接收数据的速度缓慢,web服务器可以隔离app server和慢客户端。你当然不希望app server 在等待客户端收发数据时什么也不干。Apache 和 Nginx 擅长同时很多事情,因为他们是多线程或者基于事件的。
  大多数的app server可以伺服静态文件,但不是很擅长。Apache 和 Nginx的速度更快。
  在这一章中,我会比较我提到的大多数服务器,但不包括Phusion Passenger。Phusion Passenger和其他的不一样,我会单独开出一章。我还会忽略Trinidad 和 TorqueBox,因为我对他们不是很了解。只有你用到JRuby的时候才会涉及到他们。
  Mongrel 是块暴露的石头。像之前提到的,Mongrel仅仅是单线程、多进程,所以它只用于集群(cluster)中。没有进程监控,意味着如果集群中一个进程崩溃了,则需要手动重启。人们需要使用额外的进程来照看Mongrel,比如Monit 和 God。
  Unicorn 是从Mongrel中fork出来的。支持监控一定数量的的进程:如果一个进程崩溃了,则会被主进程自动重启。它能让所有进程都监听同一个共享的socket,而不是每个进程独自使用单独的socket。这会简化反向代理的配置。像Mongrel一样,也是单线程、多进程。
  Thin 利用EventMachine库,实现基于事件的 I/O model。它并不是使用Mongrel的HTTP解析器,没有基于Mongrel。它的集群节点没有进程监控,所以你需要去监控进程是否崩溃。每个进程监听独自的socket,不像Unicorn一样共享socket。理论上来说,Thin的I/O模式允许高并发,这也是Thin被应用的大部分场合。一个Thin的进程只能处理一个并发请求,所以你还需要集群。关于这个古怪的性质,更多内容参见“I/O并发模型”。
  单线程,多进程。 Ruby app Server中比较常见、流行的I/O模型,主要是因为Ruby生态系统多线程支持比较差。一个进程同时仅且只能同时处理一个请求,web 服务器通过多进程来进行均衡负载。这种模型比较稳定,开发者不会轻易造成并发bug。这种模型适合执行快速的短请求,不适合速度慢、长请求阻塞I/O的运算,例如 调用HTTP API。
  纯多线程 。现在Ruby生态系统已经很支持多线程了,所以这种I/O模型变得切实可行。多线程支持高I/O并发,既适合短请求也适合长请求。开发者也很容易造成并发bug,幸运的是大多数框架按照这种方式设计,所以也不太可能发生。有一个需要注意的事情是,因为使用了全局解释器锁(GIL),MRI Ruby 解释器不能均衡使用多个CPU内核,即使有多个线程。为此,你可以使用多个进程,每个进程使用一个CPU内核。JRuby 和 Rubinius没有GIL,所以他们的一个进程可以均衡负载多个CPU内核 。
  结合多线程、多进程 。Phusion Passenger Enterprise 4以后版本实现了。你可以轻易在以下模式切换:单进程多线程,纯多线程,多进程多线程。这种模式给出了最好的选择方式。
  事件。这种模式和之前提到的模式不一样。它允许极高的I/O并发,以及非常适合长请求。为实现此功能,需要从应用到框架详的详细支持。然而主要的框架(Rails和 Sinatra )并不支持事件模型。这也是实际上一个Thin进程同时不能处理多个请求的原因,就像单线程多进程模型一样。只有专门的框架才充分利用事件I/O模式,例如Cramp。
  ①本网所有内容均来自互联网或网友投稿,目的在于传递更多信息,并不代表本网赞同其观点或证实其内容的真实性,不承担此类作品侵权行为的直接责任及连带责任。其他媒体、网站或个人从本网转载时,必须保留本网注明的作品来源,并自负版权等法律责任。
  ②如相关内容涉及版权等问题,请在作品发表之日起一周内与本网联系,我们将在您联系我们之后24小时内予以删除,否则视为放弃相关权利,读者热线 。
回复

使用道具 举报

Archiver|手机版|小黑屋|玩吧256游戏论坛

GMT+8, 2024-11-21 19:53 , Processed in 0.178668 second(s), 25 queries .

Powered by Discuz! X3.5

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表