异步I/O - Java

Question

我一直在寻找有关Java中异步I/O的优点的详细信息,特别是从应用程序堆栈设计.

我遇到过很多事件驱动服务器的例子,如Node.js,Tornedo等.

我无法理解的是,为什么在Java EE中使用JBoss或Weblogic应用服务器的整个应用程序堆栈迁移到事件驱动的体系结构.

甚至这些服务器也支持非阻塞I/O. 是的,他们正在为每个请求分配一个线程,但是如果有一个线程池,资源是不是在良好的性能参数范围内呢？

请按以下方式向我提供一些意见.

1. 为什么使用Apache-Tomcat/JBoss/Weblogic的传统Java EE体系结构考虑转向事件驱动的体系结构.
2. 事件驱动的体系结构是否有助于提供与设备无关的网站/应用程序.
3. 在云上设计应用程序时,我们会选择异步I/O.
4. 事件驱动的体系结构性能是否优于传统的Java EE体系结构,还是一个神话.

Answer 1

您提到的关键概念之一是：

是的，他们为每个请求分配一个线程

事实一次又一次地表明，当您的目标是支持大量并发用户时，IO 绑定应用程序的每个请求都有一个线程最终会耗尽您的线程池。事实证明，您正在谈论的框架（如 Node.js、Tornado 等）擅长处理大量并发用户，而您的应用程序很可能只是等待某些事情发生，而不执行任何 CPU 操作根本没有绑定任务。换句话说，这些工具非常适合构建在线游戏、聊天室、日志系统、通知系统等实时应用程序，这些应用程序的主要目标是尽可能快地与许多用户快速协调小消息传递。

事实上，这些工具非常适合编写基于 Websocket 的应用程序，因为它实际上是为用户提供实时或近乎实时的体验。

虽然许多公司确实从一开始就使用这些平台，但我认为对于拥有传统堆栈的公司来说，使用事件驱动工具作为其系统的补充更为常见。当您使用 Node.js 或 Tornado 之类的东西时，您可能会发现自己放弃了许多依赖的内置软件，而转而使用自己的 api 和驱动程序。Node.js 已经存在了一段时间了，实际上对于连接数据库、nosql 平台和构建系统有很多很好的支持，但它花了一段时间才到达那里。

作为一项实验，尝试编写一个简单的 TCP 聊天应用程序，每个请求使用一个线程，并查看您可以支持多少用户。最终，您将达到可以启动的操作系统线程数量的限制，这确实很昂贵。

然后看看仅使用一个线程（其默认线程）即可使用 Node.js 走多远。您会发现每秒能够支持极大量的并发请求。众所周知，它的规模可以达到数百万，因为它不受线程的限制，它只受内存、文件描述符的数量和当时的 CPU 的限制。

我能尽力回答你的问题：

1. 我认为仅仅因为您听说了 Node.js 和事件驱动架构有多么出色就简单地放弃整个平台是不可行的。您确实必须问自己，是否需要构建 IO 绑定的高并发应用程序。如果是这样，为什么不直接用它来补充您现有的堆栈呢？
2. 我不确定你的第二个问题，你所说的设备是什么意思？
3. 您可以基于传统工具在云中构建出色的应用程序，就像使用事件驱动架构一样。事实上，它可能是一个“云”应用程序，这实际上与选择平台无关。
4. 我想说的是，规模比性能更重要。您可能会发现，运行相同代码的 Node.js 应用程序比运行相同代码的 Java 应用程序运行得更慢或更快。但是 Node.js 能够做的是允许更高的吞吐量，因为它不会达到我提到的线程限制。这也意味着您已经构建了一个适当的事件驱动应用程序，您不会阻塞。如果你阻止，你就会摧毁整个系统！