我对这类东西很陌生，但最近我听到了很多关于Node.js有多好的消息。考虑到我非常喜欢使用jQuery和JavaScript，我不禁想知道如何决定何时使用Node.js。
从过去几天我做的所有作业中，我得到了以下信息。节点.js
是一个命令行工具，可以作为常规web服务器运行，并允许运行JavaScript程序利用了出色的V8 JavaScript引擎当你需要同时做几件事时是基于事件的，所以所有类似Ajax的精彩内容都可以在服务器端完成让我们在浏览器和后端之间共享代码让我们谈谈MySQL
我遇到的一些来源是：
深入Node.js–介绍和安装了解NodeJS按示例列出的节点（存档.is）让我们制作一个Web应用程序：NodePad
考虑到Node.js几乎可以在Amazon的EC2实例上开箱即用，我试图了解Node.js需要什么类型的问题，而不是PHP、Python和Ruby等强大的王者。我知道这确实取决于一个人对语言的专业知识，但我的问题更多地属于一般范畴：什么时候使用特定的框架，它特别适合什么类型的问题？
当前回答
Node非常适合快速原型，但我再也不会将其用于任何复杂的事情。我花了20年时间与编译器建立了关系，我真的很怀念它。节点对于维护您已经有一段时间没有访问过的代码尤其痛苦。类型信息和编译时错误检测是好事。为什么要扔掉这些？为了什么？当有东西向南移动时，堆栈的痕迹往往完全没有用。
其他回答
没有什么比银弹更棒的了。每件事都伴随着一些相关的成本。就好像你吃了油腻的食物，你会损害你的健康，而健康的食物不会像油腻的食物一样含有香料。无论他们想要健康还是食物中的香料，都是个人的选择。Node.js考虑在特定场景中使用的方式相同。如果你的应用程序不适合这种情况，你就不应该在你的应用开发中考虑它。我只是把我的想法放在同一点上：
何时使用Node.JS
如果服务器端代码需要很少的cpu周期。在另一个世界中，您正在执行非阻塞操作，并且没有消耗大量CPU周期的繁重算法/作业。如果您来自Javascript后台，并且能够像客户端JS一样轻松编写单线程代码。
何时不使用Node.JS
您的服务器请求取决于消耗大量CPU的算法/作业。
Node.JS的可扩展性考虑
Node.JS本身并没有利用底层系统的所有核心，默认情况下它是单线程的，您必须自己编写逻辑以利用多核心处理器并使其成为多线程的。
Node.JS替代方案
还有其他选项可以代替Node.JS，但Vert.x似乎很有前途，并且有很多其他功能，如多边形和更好的可扩展性考虑。
我有一个真实世界的例子，我使用过Node.js。我所在的公司有一个客户想要一个简单的静态HTML网站。该网站用于使用PayPal销售一件物品，客户还希望有一个显示售出物品数量的柜台。客户预计会有大量访客访问本网站。我决定使用Node.js和Express.js框架制作计数器。
Node.js应用程序很简单。从Redis数据库中获取已售出物品的数量，在物品售出时增加计数器，并通过API向用户提供计数器值。
在本例中我选择使用Node.js的一些原因
它非常轻便和快速。在三个星期内，这个网站的访问量超过了200000次，服务器资源已经能够处理这一切。计数器很容易做到实时。Node.js易于配置。有很多模块可以免费使用。例如，我找到了PayPal的Node.js模块。
在本例中，Node.js是一个很棒的选择。
如果您的应用程序主要使用webapi或其他io通道，提供或接受用户界面，node.js可能是您的最佳选择，特别是如果您想最大限度地发挥可伸缩性，或者如果您的主要语言是javascript（或javascript转译器）。如果您构建微服务，node.js也可以。Node.js也适用于任何小型或简单的项目。
它的主要卖点是让前台人员负责后端工作，而不是典型的分工。另一个合理的卖点是，如果您的员工从一开始就面向javascript。
然而，超过某一点后，如果没有强制模块化、可读性和流控制的可怕技巧，就无法扩展代码。尽管有些人喜欢这些黑客，尤其是来自事件驱动的javascript背景，但他们似乎很熟悉或可以原谅。
特别是，当您的应用程序需要执行同步流时，您会开始使用半生不熟的解决方案，这会大大降低开发过程的速度。如果应用程序中有计算密集型部分，请谨慎选择（仅）node.jshttp://koajs.com/与我最初使用node.js或编写这篇文章时相比，其他新奇之处减轻了这些原本棘手的方面。
最适合并发请求处理的节点-
那么，让我们从一个故事开始。在过去的两年里，我一直致力于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的节点方式。
node提供的另一项功能是能够使用node的子进程（childProcess.f分叉（），每个进程需要10mb内存，根据文档）动态创建多个v8实例，从而不会影响运行服务器的主进程。因此，卸载需要巨大服务器负载的后台工作就成了一个孩子的游戏，我们可以在需要时轻松地杀死他们。
我一直在使用节点，在我们构建的大多数应用程序中，同时需要服务器连接，因此网络流量很大。Express.js和新的Koajs（去掉了回调地狱）等框架使节点的工作变得更加容易。
