异步应用服务器与多个阻塞服务器

Question

tl;dr 许多 Rails 应用程序或一个 Vertx/Play！应用？

我一直在与团队的其他成员讨论使用 Play 等异步应用服务器的利弊！框架（基于 Netty 构建）与启动 Rails 应用服务器的多个实例。

我知道 Netty 是异步/非阻塞的，这意味着在数据库查询、网络请求或类似的异步调用期间，事件循环线程将允许事件循环线程从阻塞请求切换到准备好处理/服务的另一个请求.这将使 CPU 保持忙碌而不是阻塞和等待。

我赞成或使用诸如 Play 之类的东西！框架或 Vertx.io，非阻塞的东西......可扩展。另一方面，我的团队成员说，您可以通过使用 Rails 应用程序的多个实例来获得相同的好处，开箱即用的 Rails 应用程序只有一个线程，并且不像 JVM 上的应用程序那样具有真正的并发性.他们说只要使用足够的应用程序实例来匹配一个 Play 的性能！应用程序（或我们使用的许多 Play! 应用程序），并且当 Rails 应用程序阻塞时，操作系统会将进程切换到不同的 Rails 应用程序。最后，他们说 CPU 将执行相同数量的工作，而我们将获得相同的性能。

所以这是我的问题：

• 上述论点是否存在逻辑谬误？操作系统是否会管理 Rails 应用实例，以及 Netty（也运行在 JVM 上，可以很好地将线程映射到内核）在其事件循环中管理请求？
• 操作系统是否会像 Netty 或 Vertx 之类的系统，甚至是基于 Ruby 自己的 EventMachine 构建的系统一样，在开启阻塞调用方面表现出色？
• 有足够的 Rails 应用实例来匹配性能 Play！应用程序，运行服务器是否会有明显的成本差异？在我看来，如果没有成本差异，那么使用哪种方法并不重要。如果运行一百万个 Rails 应用程序比运行一个 Play 更便宜，那就试试吧！应用程序我宁愿这样做。
• 使用这两种方法中的任何一种我可能没有问到的其他好处是什么？

Answer 1

这两种方法都可以而且已经奏效。因此，如果切换会产生高昂的开发成本和/或进度计划，那么它可能不值得付出努力......但是。当成本高得无法接受时进行转换。将微服务视为一种渐进式切换策略。

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

或者也许您永远不必切换，rails 将像魅力一样适用于您的用例。而且您在让客户满意方面非常成功，以至于现金滚滚而来。

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

• 内存使用量增加。来源：多进程、内存泄漏、缺乏共享数据结构（这会增加通信成本并带来一致性问题）。

• 缺乏并行性。这有两个后果：更多的盒子和更多的延迟。您可能需要更大的盒子数来处理相同的负载。因此，如果您需要扩展并担心资金问题，那么这可能是个问题。如果这不是一个问题，那也没关系。在服务器中，这意味着延迟增加，这种延迟无法通过增加进程来改善，这可能是取决于您的应用程序的杀手级参数。

从 rails 切换到 node.js 和 golang 的一些示例：

• LinkedIn 从 Rails 转移到 Node：减少 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 应用程序：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，因此不会有相同的并行机会。