选择一个异步应用程序服务器还是多阻塞服务器？

许多Rails应用程序或者只一个Vertx Play! 应用程序？

我一直在和我团队的其他成员讨论关于使用一个异步应用服务器，比如Play! Framework（建立在Netty上），相比于一个Rails应用程序服务器多实例旋转的优缺点。我知道Netty是异步/非阻塞的，意味着在一个数据区查询操作中，网络请求或者其他一些类似的东西，一个异步调用就将会允许事件循环线程从阻塞请求转换到另一个已准备好的请求去处理/服务。这将会使CPU繁忙运转而不是阻塞和等待。

我认为要赞同或者使用一些如Play！Framework 或者Vertx.io，以及一些非阻塞的…可伸缩的。在另一方面，我的团队的成员认为你可以通过使用一个Rails应用程序的多个实例来获得同样的好处，它只能有一个线程，并且没有真正的并发应用程序作用在JVM上，只要使用足够的App实例来匹配一个Play！应用的性能（或者即使我们使用多个Play！应用程序），当一个Rails应用程序阻塞了，操作系统将把流程转换至一个不同的Rails应用程序。最后，他们说CPU们将会做相同的工作量并且我们将会得到相同的性能。

你怎么认为？市场似乎改变了，以node.js、Golang、Akka甚至Java形式改变为异步服务器模式。这是否意味着这是唯一一种正确的方法？

我尝试如此回应：

两种方式都可以工作。所以，如果转换会造成高开发成本并且/或者产生进度冲突，那么这将是不值得的。当成本高得无法接受时做出转换，还是想想使用微服务逐步转换策略吧。

如果你在你开发周期的早期使用转换，那么转换会显得很有意义，重写是非常痛苦的。

或者你从来不需要转换，Rails将为你使用用例工作，它极具魅力。并且你一直如此成功地让你的客户高兴那么现金就会滚滚而来。

一个单机阻塞服务器方式的缺点：

• 增加了内存的使用。来源：多进程、内存泄露、缺乏共享的数据结构（这增加了通信成本以及带来一致性问题）；
• 缺乏并行性。这将带来两个后果：更多的盒子和更多的延迟。你可能需要一个更大的盒子来装载同样的负载。所以如果你需要规模化则需要有更多相关资金，那么这可能是个问题。如果不打算这么做则没什么问题。在服务器中这意味着增加了延迟，延迟排序将不能通过乘法提高，这可能取决于你的应用程序会使参数作废。

以下是一些使用了这些从Rails到Node.js和Golang的转换的例子：

• LinkedIn Moved From Rails To Node: 27 Servers Cut And Up To 20x Faster
• Why Timehop Chose Go to Replace Our Rails App
• How We Moved Our API From Ruby to Go and Saved Our Sanity
• How We Went from 30 Servers to 2: Go

这些文章代表的观点可能是说明你的团队正在经历着。不幸的是，这个决定并不是显而易见的。

这取决于你所构建的本质、你团队的本质、你资源的本质、你技能的本质、你目标的本质以及你如何评估你的交易。

成本真的会下降吗？不管服务器数量做不相同的计算量？这取决于完成的工作量的类型和规模。典型的Web服务是IO绑定，等待来自其他服务器如数据库、缓存等的响应。

如果你使用单线程服务器进程在IO会有大量阻塞，所以这等于什么也没做。相比之下，非阻塞服务器将能够处理相当多的请求当单进程服务器正阻塞着。你可以不断增加进程，但是只有一台机器可以运转如此多进程。一个非阻塞服务器有相同数量的进程，同时可以保持CPU尽可能忙于处理进程请求。使用非阻塞服务器通常可以在更小更便宜的机子上处理更高负载。

如果你希望请求速率可以保持在可接受范围内盒子的数量，并且不希望巨大峰值，那么你就可以使用单线程服务器。非阻塞服务器在吸收负峰载量值而不需要增加机器表现很好。

如果延迟响应并不真正影响到你的工作，那么你可以使用较少的节点。

如果你的工作量是CPU绑定的，那么你至少将需要更多盒子，因为服务器不会在IO阻塞，对于平行那不会有相同的机会。

原文链接：Ask HighScalability: Choose An Async App Server Or Multiple Blocking Servers?（译者/王苇棋 审核/朱正贵、wendy 责编/仲浩）

译者简介：王苇棋，硕士毕业于香港浸会大学，关注数据挖掘和信息安全。

本文为ImapBox编译整理，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)