问异步I/O - Java

EN

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

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

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

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

诚然，许多公司从get开始就在使用这些平台，但我认为，使用传统堆栈的公司使用事件驱动工具作为对其系统的更多补充是更普遍的做法。当您使用类似于node.js或“旋风”之类的工具时，您可能会发现自己放弃了许多您所依赖的内置软件，而不得不使用自己的api和驱动程序。node.js已经存在了很长一段时间了，事实上，在连接到数据库、nosql平台和构建系统方面有很多很好的支持，但它需要一段时间才能实现。

作为一个实验，尝试编写一个简单的tcp聊天应用程序，该应用程序每个请求使用一个线程，并查看您可以支持多少用户。最终，您将遇到一个极限，您可以旋转多少OS线程，这确实是昂贵的。

然后看看只使用一个线程(默认线程)就可以使用node.js达到多远。您将发现，您能够支持非常多的并发请求每秒。因为它不受线程的限制，它只受内存、文件描述符的数量和cpu的限制，所以它被认为可以扩展到数百万。

尽我所能回答你的问题：

1. 我不认为仅仅因为听到node.js和事件驱动架构是多么伟大就放弃整个平台是可行的。如果您需要构建一个高度受IO约束的并发应用程序，那么您确实需要问问自己。如果是这样，为什么不直接使用它来补充现有的堆栈呢？
2. 我不确定你的第二个问题，你说的设备是什么意思？
3. 您可以基于传统工具在云中构建一个伟大的应用程序，就像使用事件驱动的体系结构一样。事实上，它可能是一个“云”应用程序，实际上与选择平台无关。
4. 我想说的是它更多的是关于规模而不是表现。您可能会发现，与运行相同代码的java应用程序相比，node.js应用程序运行得更慢或更快。但是node.js所能做的是允许更高的吞吐量，因为它不会达到我提到的线程限制。这也意味着您已经构建了一个正确的事件驱动应用程序，在那里您不阻塞。如果你封锁了，你就打倒了整个系统！

我认为它更多地是关于底层实现的，并且它产生的间接费用便宜：

旋转一个全新的专用线程来处理请求。每个线程都会阻塞I/O，但是，在线程级别处理这样的并发却是一团糟。

对比

使用一个线程，这将保持响应性，并承诺在将来的某个时间内处理这些内容。在执行I/O时不阻塞，线程级不需要并发管理。让操作系统来处理。

为什么使用Apache/JBoss/Weblogic的传统Java体系结构考虑转向事件驱动的体系结构。

也许他们厌倦了过于通用的、重量级的解决方案，并希望检查新的轻量级替代方案。这些替代方案非常容易开发和部署，而且规模非常好。

事件驱动架构是否有助于提供与设备无关的网站/应用程序？

我不认为这有多大关系。不止一种语言可以在同一个JVM上运行。这是JVM在多个主机上运行的能力，并公开了一个标准的api，它带来了与设备无关的功能。另一个例子是网页浏览器。

在云上设计应用程序时，我们会选择异步I/O吗？

更多地取决于需求。异步I/O并不能解决所有问题。但是，如果您想要创建易于创建、快速可伸缩的解决方案，它可能会有所帮助。对于有严格限制的新创业公司来说，这是个不错的选择。

是事件驱动的体系结构性能优于传统的Java体系结构，还是一个神话。

最好使用一些良好基准测试性能，并根据您的业务需求进行调整。

性能将主要取决于应用程序。有了很多请求，就像您说的，需要运行几个线程，这消耗了主内存，因为线程需要在服务其他线程之前为请求服务。我不喜欢这样说，但这是个开始:-)