最适合并发请求处理的节点-

那么，让我们从一个故事开始。在过去的两年里，我一直致力于JavaScript和开发web前端，我很喜欢它。后端的家伙们为我们提供了一些用Java、python编写的API（我们不在乎），我们只需编写一个AJAX调用，获取数据，然后猜一猜！我们完成了。但实际上，这并不是那么容易，如果我们获取的数据不正确或存在服务器错误，那么我们就卡住了，我们必须通过邮件或聊天联系我们的后端人员（有时也在whatsApp上：）这不酷。如果我们用JavaScript编写API并从前端调用这些API呢？是的，这很酷，因为如果我们在API中遇到任何问题，我们可以调查它。猜猜看！你现在可以这样做了，怎么做节点就在那里。

Ok同意您可以用JavaScript编写API，但如果我对上述问题没有异议，该怎么办。您还有其他理由使用node for rest API吗？

这就是魔法的开始。是的，我确实有其他理由将节点用于我们的API。

让我们回到传统的rest API系统，它基于阻塞操作或线程。假设发生两个并发请求（r1和r2），每个请求都需要数据库操作。因此，在传统系统中会发生什么：

1.等待方式：我们的服务器开始服务r1请求并等待查询响应。r1完成后，服务器开始为r2服务，并以相同的方式执行。所以等待不是一个好主意，因为我们没有那么多时间。

2.线程方式：我们的服务器将为两个请求r1和r2创建两个线程，并在查询数据库后达到它们的目的，速度非常快。但这会消耗内存，因为您可以看到，我们启动了两个线程。当两个请求都在查询同一数据时，问题也会增加，因此您必须处理死锁问题。所以这比等待要好，但问题仍然存在。

现在，节点将如何执行此操作：

3.Nodeway：当同一个并发请求进入节点时，它将使用回调注册一个事件，并继续前进，它不会等待特定请求的查询响应。因此，当r1请求到来时，节点的事件循环（是的，节点中有一个事件循环用于此目的）。)使用其回调函数注册事件，并继续服务r2请求，同样，使用回调函数注册其事件。每当任何查询完成时，它都会触发相应的事件，并在不中断的情况下执行回调以完成。

所以，无需等待，无需线程，无需内存消耗——是的，这是服务rest API的节点方式。

如果您的应用程序主要使用webapi或其他io通道，提供或接受用户界面，node.js可能是您的最佳选择，特别是如果您想最大限度地发挥可伸缩性，或者如果您的主要语言是javascript（或javascript转译器）。如果您构建微服务，node.js也可以。Node.js也适用于任何小型或简单的项目。

它的主要卖点是让前台人员负责后端工作，而不是典型的分工。另一个合理的卖点是，如果您的员工从一开始就面向javascript。

然而，超过某一点后，如果没有强制模块化、可读性和流控制的可怕技巧，就无法扩展代码。尽管有些人喜欢这些黑客，尤其是来自事件驱动的javascript背景，但他们似乎很熟悉或可以原谅。

特别是，当您的应用程序需要执行同步流时，您会开始使用半生不熟的解决方案，这会大大降低开发过程的速度。如果应用程序中有计算密集型部分，请谨慎选择（仅）node.jshttp://koajs.com/与我最初使用node.js或编写这篇文章时相比，其他新奇之处减轻了这些原本棘手的方面。

我认为Node.js最适合实时应用程序：在线游戏、协作工具、聊天室，或者任何一个用户（或机器人？或传感器？）使用应用程序所做的事情都需要立即被其他用户看到，而无需刷新页面。

我还应该提到，Socket.IO与Node.js的结合将比长轮询更进一步地减少实时延迟。作为最坏的情况，Socket.IO将退回到长轮询，而是使用web套接字甚至Flash（如果可用的话）。

但我还应该提到，Node.js可以更好地解决代码可能由于线程而阻塞的任何情况，或者需要应用程序是事件驱动的任何情况。

此外，Ryan Dahl在我曾经参加的一次演讲中表示，Node.js基准测试在常规旧HTTP请求方面与Nginx不相上下。因此，如果我们使用Node.js构建，我们可以非常有效地服务于我们的正常资源，当我们需要事件驱动的东西时，它就可以处理它了。

此外，它一直都是JavaScript。整个堆栈上都是Lingua Franca。

它可以用于

高度事件驱动且严重受I/O限制的应用程序处理与其他系统的大量连接的应用程序实时应用程序（Node.js是从一开始就为实时和简单而设计的使用。）应用程序可以处理来自其他来源的大量信息流高流量、可扩展的应用程序移动应用程序必须与平台API和数据库通信，而无需处理大量数据分析构建网络应用程序需要经常与后端通信的应用程序

在移动方面，黄金时段公司的移动解决方案依赖Node.js。看看为什么？

LinkedIn是一个杰出的用户。他们的整个移动堆栈都建立在Node.js上。他们从在每台物理机器上运行15个服务器和15个实例，到只运行4个实例，可以处理双倍的流量！

eBay推出了ql.io，这是一种用于HTTP API的web查询语言，它使用Node.js作为运行时堆栈。他们能够调整一个常规开发人员质量的Ubuntu工作站，以处理每个node.js进程超过120000个活动连接，每个连接消耗大约2kB内存！

沃尔玛将其移动应用程序重新设计为使用Node.js，并将其JavaScript处理推送到服务器。

更多信息请访问：http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

没有什么比银弹更棒的了。每件事都伴随着一些相关的成本。就好像你吃了油腻的食物，你会损害你的健康，而健康的食物不会像油腻的食物一样含有香料。无论他们想要健康还是食物中的香料，都是个人的选择。Node.js考虑在特定场景中使用的方式相同。如果你的应用程序不适合这种情况，你就不应该在你的应用开发中考虑它。我只是把我的想法放在同一点上：

何时使用Node.JS

如果服务器端代码需要很少的cpu周期。在另一个世界中，您正在执行非阻塞操作，并且没有消耗大量CPU周期的繁重算法/作业。如果您来自Javascript后台，并且能够像客户端JS一样轻松编写单线程代码。

何时不使用Node.JS

您的服务器请求取决于消耗大量CPU的算法/作业。

Node.JS的可扩展性考虑

Node.JS本身并没有利用底层系统的所有核心，默认情况下它是单线程的，您必须自己编写逻辑以利用多核心处理器并使其成为多线程的。

Node.JS替代方案

还有其他选项可以代替Node.JS，但Vert.x似乎很有前途，并且有很多其他功能，如多边形和更好的可扩展性考虑。

使用NodeJS的原因：

它运行Javascript，因此您可以在服务器和客户端上使用相同的语言，甚至可以在它们之间共享一些代码（例如，用于表单验证或在任意一端呈现视图）与传统的多线程Java或ROR框架相比，单线程事件驱动系统即使在一次处理大量请求时也很快，而且很简单。通过NPM可访问的软件包数量不断增加，包括客户端和服务器端库/模块，以及用于web开发的命令行工具。其中大多数都方便地托管在github上，有时您可以在那里报告问题并在数小时内找到解决方案！一切都在一个屋檐下，有标准化的问题报告和轻松的分叉，这很好。它已经成为运行Javascript相关工具和其他web相关工具的实际标准环境，包括任务运行器、缩小器、美化器、linter、预处理器、打包器和分析处理器。它似乎非常适合于原型设计、敏捷开发和快速产品迭代。

不使用NodeJS的原因：

它运行Javascript，没有编译时类型检查。对于大型、复杂的安全关键系统或项目，包括不同组织之间的协作，一种鼓励契约接口并提供静态类型检查的语言可能会从长远来看为您节省一些调试时间（和爆炸）。（虽然JVM被设置为null，但请为您的核反应堆使用Haskell。）除此之外，NPM中的许多软件包都有点生涩，而且仍在快速开发中。一些旧框架的库已经经历了十年的测试和错误修复，现在非常稳定。Npmjs.org没有对软件包进行评级的机制，这导致了软件包的激增，这些软件包或多或少都在做同样的事情，其中很大一部分不再被维护。嵌套回调地狱。（当然，有20种不同的解决方案……）不断增长的包池可能会使一个NodeJS项目与下一个项目截然不同。由于有大量的可用选项（例如Express/Sails.js/Metator/Deby），实现方式存在很大的差异。这有时会使新开发人员更难加入Node项目。与加入现有项目的Rails开发人员相比，他应该能够很快熟悉应用程序，因为所有Rails应用程序都被鼓励使用类似的结构。处理文件可能有点麻烦。在其他语言中很琐碎的事情，比如从文本文件中读取一行，对于Node.js来说是非常奇怪的，因此有一个StackOverflow问题，有80多个赞成票。从CSV文件中一次读取一条记录没有简单的方法。等

我喜欢NodeJS，它很快，很狂野，很有趣，但我担心它对可证明的正确性没什么兴趣。让我们希望我们最终能够将这两个世界中最好的结合起来。我很想知道未来会有什么替代Node…：）