何时决定使用Node.js？

Question

何时决定使用Node.js？

javascriptnode.jsweb-applications

2191

我对这种东西很陌生，但最近我听到了很多关于Node.js的好处。考虑到我有多么喜欢使用jQuery和JavaScript，我不禁想知道何时决定使用Node.js。我心中所想的Web应用程序类似于Bitly-获取一些内容并将其存档。

在过去几天的所有家庭作业中，我获得了以下信息。 Node.js

是一个命令行工具，可以作为常规Web服务器运行，并允许运行JavaScript程序
利用了伟大的V8 JavaScript engine
非常适合需要同时执行多项任务的情况
基于事件，因此所有精彩的Ajax-like内容都可以在服务器端完成
让我们在浏览器和后端之间共享代码
让我们与MySQL通信

我找到的一些来源：

考虑到 Node.js 可以几乎无需额外配置即可在 Amazon 的 EC2 实例上运行，我正在尝试理解什么类型的问题需要使用 Node.js，而不是像 PHP、Python 和 Ruby 这样的强大语言。我知道这实际上取决于个人对语言的熟练程度，但我的问题更多地属于一般类别：何时使用特定框架，它适用于哪种类型的问题？

- Legend

4

这个问题正在 meta 上进行讨论（http://meta.stackoverflow.com/q/332386/497418）。 - zzzzBov

17个回答

409

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

我还应该提到，Socket.IO与Node.js结合使用将比长轮询可能实现的实时延迟更进一步降低。 Socket.IO将退回到长轮询，作为最坏情况下的方案，而使用Web套接字甚至Flash（如果可用）。

但是我还应该提到，任何由于线程而导致代码阻塞的情况都可以通过Node.js更好地解决。或任何需要应用程序以事件驱动方式运行的情况。

此外，Ryan Dahl在我曾经参加的演讲中表示，Node.js基准测试与常规的HTTP请求相比，与Nginx非常接近。因此，如果我们使用Node.js构建，我们可以有效地提供我们的常规资源，并在需要事件驱动的内容时准备好处理它。

另外，它使用全栈JavaScript。Lingua Franca。

- fisherwebdev

17

一个从.NET和Node之间切换的人观察到，不同的语言用于系统的不同区域，在上下文切换时非常有帮助。当我看Javascript时，我在处理客户端，C#代表应用服务器，SQL表示数据库。一直使用Javascript工作时，我发现自己经常混淆这些层次，或者花更长时间去上下文切换。这可能是因为我整天使用.NET堆栈，在晚上才开始使用Node的缘故，但它确实会产生影响。 - Michael Blackburn

1

就在前几天，我在思考如何为我的不同的.js文件分配不同的颜色。例如，客户端使用绿色，服务器端使用蓝色。我总是感到有些“迷失”。 - AJB

209

使用NodeJS的原因：

它可以运行Javascript，因此您可以在服务器和客户端上使用相同的语言，甚至可以在它们之间共享一些代码（例如用于表单验证或在两端渲染视图）。
单线程事件驱动系统即使在处理大量请求时也非常快速，并且与传统的多线程Java或ROR框架相比也很简单。
通过NPM可以访问越来越多的软件包，包括客户端和服务器端库/模块，以及用于Web开发的命令行工具。其中大部分都方便地托管在github上，有时您可以报告问题并在几小时内找到解决方法！将所有内容放在一个平台下，标准化问题报告和易于派生，这样做很好。
它已成为运行Javascript相关工具和其他Web相关工具的事实标准环境，包括任务运行器、压缩器、美化器、检查器、预处理器、打包程序和分析处理器。
它似乎非常适合原型设计、敏捷开发和快速产品迭代。

不使用NodeJS的原因：

Node.js 运行 JavaScript，它没有编译时类型检查。对于大型、复杂的安全关键系统或涉及不同组织之间协作的项目，使用一种鼓励契约接口并提供静态类型检查的语言可能会在长期运行中为您节省一些调试时间（和爆炸）。（尽管 JVM 只能使用 null，请使用 Haskell 处理核反应堆。）
此外，NPM 中许多软件包都有点原始，仍在快速发展中。一些旧框架的库经历了十年的测试和错误修复，并且现在非常稳定。Npmjs.org 没有评估软件包的机制，这导致了大量做了差不多相同事情的软件包，其中很大一部分已经不再维护。
嵌套回调地狱。（当然，有20 种不同的解决方案...）
越来越多的软件包使一个 NodeJS 项目看起来与下一个截然不同。由于可用选项的数量巨大（例如 Express/Sails.js/Meteor/Derby），实现上有很大的多样性。这有时会使新开发人员加入 Node 项目更加困难。与此相反，Rails 开发人员加入现有项目应该能够很快熟悉该应用程序，因为所有 Rails 应用程序都鼓励使用类似的结构。
处理文件可能有点麻烦。在其他语言中轻而易举的事情，例如从文本文件中读取一行，在 Node.js 中则非常奇怪，以至于 StackOverflow 上有一个问题获得了80个赞。没有简单的方法从 CSV 文件中逐条读取记录。等等。

我喜欢NodeJS，它快速、野性而有趣，但我担心它对可证明正确性的兴趣不大。希望我们能最终融合两个世界的优点。我很想看看未来将会取代Node的东西... :)

- joeytwiddle

1

@nane 是的，我认为他们可以解决这个问题，但是您必须限制自己只使用编写在类型安全语言中的库，或者接受并不是全部代码库都是静态类型的事实。但是有一个观点是：既然无论使用哪种语言，您都应该为您的代码编写良好的测试，那么您的信心水平应该相等，即使是动态类型的代码。如果我们接受这个观点，那么强类型的优势将减少到帮助开发/调试时间、可证明性和优化等方面。 - joeytwiddle

1

@kervin，我同意一些基准测试是很好的，但我对我在网上能找到的东西感到失望。有些人认为.NET性能与Node的性能相当，但实际上你所做的事情非常关键。Node可能非常擅长在许多并发连接中传递小消息，但不太适合进行重型数学计算。一个良好的性能比较需要测试各种情况。 - joeytwiddle

2

@joeytwiddle，像 TypeScript 这样的东西会在处理更大、更复杂的程序和静态类型检查方面对 Node.js 有所帮助吗？ - CodeMonkey

2

@joeytwiddle 说实话，你可以使用https://stillmaintained.com来确定一个npm包是否仍在维护（因为大多数都在github上）。此外，`npm search和npm show`命令将显示一个包的最后发布日期。 - Dan

3

将Rails与Node进行比较是混淆了平台和框架的概念。Rails是Ruby语言的一个框架，就像Sails和Meteor是JavaScript语言的框架一样。 - BonsaiOak

显示剩余3条评论

206

简而言之：

Node.js适用于具有大量并发连接且每个请求仅需要非常少的CPU周期的应用程序，因为事件循环（以及所有其他客户端）在函数执行期间被阻止。

Mixu's tech blog: Understanding the node.js event loop是一篇关于Node.js事件循环的好文章。

- stewe

127

我有一个实际的例子可以说明我如何使用Node.js。我工作的公司有一个客户想要一个简单的静态HTML网站。这个网站用于销售一种商品，使用PayPal，客户还希望有一个计数器显示已售出的商品数量。客户预计会有大量的访问者来到这个网站。我决定使用Node.js和Express.js框架来制作计数器。

Node.js应用程序很简单。从Redis数据库获取已售出的商品数量，当商品售出时增加计数器，并通过API向用户提供计数器值。

以下是我选择在这种情况下使用Node.js的一些原因：

它非常轻量级和快速。这个网站在三周内有超过20万次访问，最小的服务器资源就能够处理所有请求。
计数器很容易实现实时更新。
配置Node.js非常简单。
有很多免费的模块可用。例如，我找到了一个用于PayPal的Node.js模块。

在这种情况下，选择Node.js是一个很棒的选择。

- Joonas

105

使用Node开始下一个项目的最重要原因是...

所有最酷的人都在用，所以它一定很有趣。
你可以在“酷”的地方闲逛，并有很多关于Node的冒险故事可以炫耀。
当涉及到云主机成本时，你非常紧贴每一分钱。
已经用过Rails，没新意了。
你讨厌IIS部署。
你原来的IT工作变得相当单调，希望自己能加入一个光鲜亮丽的创业公司。

期望中会发生什么...

使用Express会让你感觉安全可靠，没有你从未需要过的服务器浮精。
运行迅速，扩展性良好。
你梦想着它，你安装了它。 node包存储库npmjs.org是世界上最大的开源库生态系统。
你的大脑将在嵌套回调的国度中遇到时间扭曲现象......
直到你学会保持你的Promise才能解决这个问题。
Sequelize 和 Passport是你的新API朋友。
调试大多数异步代码会变得嗯...有趣。
是时候让所有节点主人掌握TypeScript了。

谁在使用它？

PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
以下是他们转向Node的原因。

- Tony O'Hagan

18

是的，我也可以按传统方式回答这个问题。我认为我有资格这么做，但大部分已经被说过了，我想一些轻松愉快的内容会打破单调。我经常在其他问题上提供技术答案。 - Tony O'Hagan

1

可以通过使用ES6生成器来避免嵌套回调，以处理异步代码。 - refactor

1

@CleanCrispCode：确实如此！ES6采用了C#风格的async/await，现在我们可以推出更干净的异步Node代码，同时支持传统的try/catch。在2016/17年，JS程序员正在转向ES6。 - Tony O'Hagan

60

没有什么像银弹一样的东西。每件事都有其相关的成本。就像如果你吃油腻食物，你将会损害你的健康，而健康的食物不像油腻的食物那样有香料。这是个人的选择，他们想要健康还是香料在他们的食物中。

同样，Node.js被认为只适用于特定情况。如果你的应用程序不适合该情况，你不应该考虑将其用于你的应用程序开发。我只是在阐述我的想法:

何时使用Node.JS

如果您的服务器端代码需要很少的CPU周期。换句话说，您正在进行非阻塞操作，并且没有消耗大量CPU周期的重型算法/作业。
如果您来自JavaScript背景并且习惯于编写类似于客户端JS的单线程代码。

何时不使用Node.JS

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

使用Node.JS时的可扩展性考虑

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

Node.JS的替代方案

有其他选项可以替代Node.JS，但Vert.x似乎非常有前途，并且具有许多额外的功能，如Polyglot和更好的可扩展性考虑。

- user1619058

24

我不确定“如果您的服务器端请求包含像文件IO或套接字IO这样的阻塞操作”是否应列在“不适用时”的列表中。如果我理解正确，node.js的优势之一是它具有强大的异步处理IO的能力，可以避免阻塞。因此，Node.js可以被视为解决阻塞IO的“良药”。 - Ondrej Peterka

3

您说得对，Node.js确实解决了服务器IO阻塞的问题。但是，如果您在服务器上的请求处理程序自身中进行阻塞调用到其他网络服务/文件操作，则Node.js无法解决这个问题。它仅针对进入服务器的请求进行非阻塞IO处理，而不适用于应用程序请求处理程序的出站请求。 - Ajay Tiwari

4

@ajay，来自http://nodejs.org的消息称“非阻塞I/O”，请检查您的“When NOT” 2和3。 - Omar Al-Ithawi

可以编写并绑定 C 组件到 Node.js 应用程序中。 - Erik Reppen

5

当前版本的Node实际上通过使用cluster支持多核心，这真正提升了Node应用程序的性能，至少增加了两倍。然而，当他们稳定cluster库时，我认为性能应该超过两倍。 - Nam Nguyen

4

你可以使用node.js进行大量的计算，使用fork方法。参考链接：https://dev59.com/T2kw5IYBdhLWcg3w8fBJ。Node通过`cluster`模块很好地处理多个核心。http://nodejs.org/api/cluster.html - Jess

41

我认为还没有人提到的Node.js的另一个优点是其伟大的社区、包管理系统（npm）以及存在的模块数量，你只需在package.json文件中加入它们就可以使用。

- BoxerBucks

6

这些软件包都比较新，因此它们具有远见之明，并且趋向于符合最近的Web标准。 - joeytwiddle

3

恕我直言，npm 上很多软件包质量很差，因为 **npm 没有评价软件包的机制**。有没有感受到 CPAN 的教训？ - Dan Dascalescu

36

我的看法：Node.js非常适合制作实时系统，比如分析、聊天应用、API和广告服务器等。我甚至在考试周用Node.js和Socket.io制作了自己的第一个聊天应用，而且只用了不到两个小时。

编辑

自从我开始使用Node.js以来已经过去了几年时间，我用它制作了许多不同的东西，包括静态文件服务器、简单的分析工具、聊天应用等等。下面是我对何时使用Node.js的看法：

何时使用

当制作侧重于并发性和速度的系统时。

仅使用Sockets的服务器，例如聊天应用、IRC应用程序等。
社交网络，其强调实时资源，例如地理位置、视频流、音频流等。
快速处理小数据块，例如分析Web应用程序。
仅公开REST API。

何时不使用

尽管Node.js是一种非常通用的Web服务器，但在以下场景中可能不太适合使用：

简单的博客和静态站点。
仅作为静态文件服务器。

请记住这只是吹毛求疵而已。对于静态文件服务器，Apache更好是因为它被广泛使用。随着Node.js社区的不断壮大和成熟，可以放心地说，如果您有自己的托管选择，Node.js几乎可以在任何地方使用。

- shash7

简单的博客仍然可以从Node.js中受益。对于提供静态文件，您仍然可以使用Node.js，如果负载增加，只需按照当前最佳实践在其前面添加Nginx反向代理即可。Apache httpd服务器是一种正在消亡的恐龙-请参见此Netcraft调查。 - Endrju

我认为不同 - 看看 https://ghost.org/，它看起来很棒，是建立在 NodeJs 之上的 - 协作、实时文章编辑。此外，在 NodeJs 中创建一个简单的页面，比如使用 http://sailsjs.org/，是容易、快速的，你不需要费心学习任何服务器端编程语言。 - Bery

30

它可以在以下场景下使用：

高度事件驱动并且I/O密集型的应用程序
处理大量与其他系统的连接的应用程序
实时应用程序（Node.js从一开始就为实时和易于使用而设计）
需要处理来自其他源的大量信息流的应用程序
高流量、可扩展的应用程序
需要与平台API和数据库通信的移动应用程序，而不需要执行大量的数据分析
构建网络化应用程序
需要频繁与后端通信的应用程序

在移动前端方面，主要公司依赖Node.js构建其移动解决方案。 看看为什么？

领英是一个著名的用户。他们的整个移动堆栈都是基于Node.js构建的。他们从每台物理机上运行15个服务器，每个实例15个，到只有4个实例 - 可以处理双倍的流量！

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

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

阅读更多内容：http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

- Vinayak Bevinakatti

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Benson · Accepted Answer

你很好地总结了Node.js的优点。我的感觉是，Node.js特别适用于需要从浏览器保持持久连接到服务器的应用程序。使用一种称为"长轮询"的技术，您可以编写一个应用程序，实时向用户发送更新。在许多Web巨头上进行长轮询，如Ruby on Rails或Django，会在服务器上创建巨大的负载，因为每个活动客户端都会占用一个服务器进程。这种情况相当于一种tar阱攻击。当您使用像Node.js这样的东西时，服务器无需为每个打开的连接维护单独的线程。

这意味着您可以在Node.js中创建一个基于浏览器的聊天应用程序，几乎不需要系统资源来服务大量客户端。任何时候想要进行这种长轮询，Node.js都是一个很好的选择。

值得一提的是，Ruby和Python都有工具来做这种事情（分别是eventmachine和twisted），但Node.js在这方面表现异常出色，并且从头开始。JavaScript非常适合基于回调的并发模型，并且在这方面表现出色。此外，能够使用JSON在客户端和服务器上进行序列化和反序列化也非常方便。

我期待着在这里阅读其他答案，这是一个很棒的问题。

值得指出的是，Node.js也非常适合需要在客户端/服务器之间重用大量代码的情况。Meteor框架使这变得非常容易，很多人认为这可能是Web开发的未来。我可以从经验中说，使用Meteor编写代码非常有趣，其中一个重要原因是花费更少的时间思考如何重新组织数据，以便在浏览器中运行的代码可以轻松操作它并将其传回。

这里有一篇关于Pyramid和长轮询的文章，借助gevent的一点帮助，设置起来非常容易：TicTacToe and Long Polling with Pyramid。