ruby-on-rails – 异步应用服务器与多个阻止服务器

如果您处于开发周期的早期阶段,那么尽早进行切换可能是有意义的.重写是一种痛苦.

或者也许你永远不必切换和rails将适用于你的用例,如魅力.而且你已经非常成功地让你的客户感到高兴,现金正在滚滚而来.

阻塞单服务器方法的一些缺点：

>增加内存使用量.来源：多个进程,内存泄漏,缺少共享数据结构(这会增加通信成本并带来一致性问题).
>缺乏并行性.这有两个结果：更多的盒子和更多的延迟.您可能需要更大的盒子数来处理相同的负载.因此,如果您需要扩展并有资金问题,那么这可能是一个问题.如果它不是一个问题,那么无关紧要.在服务器中,这意味着增加了延迟,这种延迟无法通过增加流程来提高,这可能是一个杀手级的参数,具体取决于您的应用程序.

从rails到node.js和golang进行这种切换的人的一些例子：

> LinkedIn从Rails迁移到节点：27台服务器切割速度提高了20倍：http://highscalability.com/blog/2012/10/4/linkedin-moved-from-rails-to-node-27-servers-cut-and-up-to-2.html
>为什么Timehop??选择去替换我们的Rails App：https://medium.com/building-timehop/why-timehop-chose-go-to-replace-our-rails-app-2855ea1912d
>我们如何将我们的API从Ruby转移到Go并保存我们的理智：http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-to-go-and-saved-our-sanity/
>我们如何从30台服务器到2台：Go：http://www.iron.io/blog/2013/03/how-we-went-from-30-servers-to-2-go.html

这些帖子代表了可能说明您的小组正在经历的内容的论据.遗憾的是,这一决定并不明显.

这取决于你正在建设的性质,你的团队的性质,资源的性质,你的技能的性质,你的目标的性质以及你如何重视所有不同的权衡.

成本真的会下降吗？无论服务器数量多少,计算量都不一样吗？

取决于正在进行的工作的类型和规模.通常,Web服务是IO绑定的,等待来自其他服务(如数据库,缓存等)的响应.

如果您使用的是单线程服务器,那么IO上的进程会被阻塞很多,所以它不会做很多事情.相比之下,非阻塞服务器将能够在单线程服务器被阻止时处理许多请求.您可以继续添加进程,但只有一台计算机可以运行这么多进程.非阻塞服务器可以具有相同数量的进程,同时保持CPU尽可能处理请求.在使用非阻塞服务器时,通常可以在更便宜的小型机器上处理更高的负载.

如果您的预期请求率可以通过可接受数量的方框处理,并且您不希望出现巨大的峰值,那么单线程服务器就可以了.非阻塞服务器非常适合吸收负载峰值而无需添加计算机.

如果您的工作是响应延迟并不重要,那么您可以使用更少的节点.

如果你的工作负载是CPU绑定的,那么你无论如何都需要更多的盒子,因为没有相同的并行机会,因为服务器不会阻塞IO.