如何决定何时使用 Node.js？

你在总结 Node.js 的优点方面做得很好。我的感觉是，Node.js 特别适合您希望保持从浏览器到服务器的持久连接的应用程序。使用一种称为“长轮询”的技术，您可以编写一个应用程序，将更新实时发送给用户。在许多 Web 巨头（如 Ruby on Rails 或 Django）上进行长时间轮询会给服务器带来巨大的负载，因为每个活动客户端都会占用一个服务器进程。这种情况相当于防水布攻击。当您使用 Node.js 之类的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在 Node.js 中创建一个基于浏览器的聊天应用程序，该应用程序几乎不需要系统资源即可为大量客户提供服务。每当你想做这种长轮询时，Node.js 都是一个不错的选择。

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

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

值得指出的是，Node.js 也非常适合在客户端/服务器间隙中重用大量代码的情况。Meteor 框架使这变得非常容易，很多人认为这可能是 Web 开发的未来。根据经验，我可以说，在 Meteor 中编写代码非常有趣，其中很大一部分是花更少的时间思考如何重构数据，因此在浏览器中运行的代码可以很容易地操作它并将其传递回去。

这是一篇关于金字塔和长轮询的文章，事实证明，在gevent的帮助下，它非常容易设置：TicTacToe和金字塔长轮询。

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

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

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

此外，Ryan Dahl在我曾经参加过的一次演讲中说，Node.js基准测试在常规的旧HTTP请求方面与Nginx非常接近。因此，如果我们使用 Node.js 进行构建，我们可以非常有效地为我们的正常资源提供服务，并且当我们需要事件驱动的东西时，它已经准备好处理它。

此外，它一直都是 JavaScript。通用语在整个堆栈上。

简而言之：

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

关于 Node.js 中的事件循环的一篇好文章是 Mixu 的技术博客：了解 node.js 事件循环。

没有什么能比得上银弹了。一切都伴随着一些与之相关的成本。这就像如果你吃油腻的食物，你会损害你的健康，而健康的食物不像油腻的食物那样含有香料。这是个人选择，他们是否想要健康或香料，就像他们的食物一样。 Node.js 考虑在特定场景中使用的方式相同。如果你的应用不适合该方案，则不应将其考虑用于应用开发。我只是把我的想法放在同一个地方：

何时使用 Node.JS

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

何时不使用 Node.JS

1. 您的服务器请求依赖于占用大量 CPU 的算法/作业。

Node.JS 的可伸缩性注意事项

1. Node.JS本身并没有利用底层系统的所有核心，它默认是单线程的，你必须自己编写逻辑才能利用多核处理器并使其多线程。

Node.JS 备择方案

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

我的作品：nodejs 非常适合制作实时系统，如分析、聊天应用程序、api、广告服务器等。 见鬼，我使用 nodejs 制作了我的第一个聊天应用程序，socket.io 不到 2 小时，而且在考试期间也是如此 周！

编辑

自从我开始使用 nodejs 以来已经有好几年了，我已经用它来制作许多不同的东西，包括静态文件服务器、简单的分析、聊天应用程序等等。 这是我对何时使用 nodejs 的看法

何时使用

在制作强调并发性和速度的系统时。

• 仅套接字服务器，如聊天应用程序、irc 应用程序等。
• 强调实时资源（如地理位置、视频流、音频流等）的社交网络。
• 像分析 Web 应用程序一样快速处理小块数据。
• 作为公开仅 REST 的 api。

何时不使用

它是一个非常通用的网络服务器，因此您可以在任何您想要的地方使用它，但可能不是这些地方。

• 简单的博客和静态网站。
• 就像静态文件服务器一样。

请记住，我只是吹毛求疵。对于静态文件服务器，apache 更好，主要是因为它广泛可用。多年来，nodejs 社区变得越来越大和成熟，可以肯定地说，如果您有自己的托管选择，nodejs 几乎可以在任何地方使用。

我有一个使用Node.js的真实示例。我工作的公司有一个客户，他想拥有一个简单的静态HTML网站。该网站用于使用 PayPal 销售一件商品，客户还希望有一个显示已售商品数量的计数器。客户希望有大量的访问者访问这个网站。我决定使用 Node.js 和 Express.js 框架制作计数器。

Node.js 应用程序很简单。从 Redis 数据库中获取已售商品金额，在商品售出时增加计数器，并通过 API 将计数器值提供给用户。

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

1. 它非常轻巧和快速。在三周内，该网站的访问量已超过 200000 次，而最少的服务器资源已经能够处理这一切。
2. 计数器真的很容易做到实时。
3. Node.js 易于配置。
4. 有很多模块是免费提供的。例如，我找到了一个用于 PayPal 的 Node.js 模块。

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

我认为没有人提到过 Node 的另一件好事.js是令人惊叹的社区、包管理系统 （npm） 以及现有的模块数量，您只需将它们包含在 package.json 文件中即可包含这些模块。

我为新项目选择 Node.js 的另一个原因是：

能够进行纯基于云的开发

我使用 Cloud9 IDE 已经有一段时间了，现在我无法想象没有它，它涵盖了所有的开发生命周期。您只需要一个浏览器，就可以随时随地在任何设备上编写代码。您无需在一台计算机（如在家中）签入代码，然后在另一台计算机（如在工作场所）签出。

当然，可能还有其他语言或平台的基于云的IDE（Cloud 9 IDE也增加了对其他语言的支持），但是使用Cloud 9进行Node.js开发对我来说真的是一次很棒的体验。

使用 NodeJS 的原因：

• 它运行 Javascript，因此您可以在服务器和客户端上使用相同的语言，甚至可以在它们之间共享一些代码（例如，用于表单验证，或在任一端呈现视图）。

• 与传统的多线程 Java 或 ROR 框架相比，单线程事件驱动系统即使在一次处理大量请求时也很快，而且也很简单。

• 可通过 NPM 访问的不断增长的软件包池，包括客户端和服务器端库/模块，以及用于 Web 开发的命令行工具。其中大多数都方便地托管在 github 上，有时您可以在其中报告问题并在数小时内找到修复！将所有内容都放在一个屋檐下，具有标准化的问题报告和轻松的分叉，这真是太好了。

• 它已成为运行 Javascript 相关工具和其他 Web 相关工具（包括任务运行程序、缩小器、美化器、linter、预处理器、打包器和分析处理器）的事实上的标准环境。

• 它似乎非常适合原型设计、敏捷开发和快速产品迭代。

不使用 NodeJS 的原因：

• 它运行 Javascript，它没有编译时类型检查。对于大型、复杂的安全关键系统，或包括不同组织之间协作的项目，从长远来看，鼓励合同接口并提供静态类型检查的语言可以为您节省一些调试时间（和爆炸）。（虽然 JVM 被卡住了，所以请将 Haskell 用于您的核反应堆。null

• 除此之外，NPM 中的许多包都有点原始，并且仍在快速开发中。一些用于旧框架的库已经经历了十年的测试和错误修复，现在已经非常稳定。Npmjs.org 没有对软件包进行评级的机制，这导致了或多或少做同样事情的软件包的激增，其中很大一部分不再被维护。

• 嵌套回调地狱。（当然，有 20 种不同的解决方案......

• 不断增长的包池可能会使一个 NodeJS 项目看起来与下一个项目截然不同。由于可用的选项数量众多（例如Express/Sails.js/Meteor/Derby），实现方式非常多样化。这有时会使新开发人员更难参与 Node 项目。与此形成鲜明对比的是，一个 Rails 开发人员加入了一个现有的项目：他应该能够很快熟悉这个应用，因为所有 Rails 应用都被鼓励使用类似的结构。

• 处理文件可能有点痛苦。在其他语言中微不足道的事情，比如从文本文件中读取一行，与 Node.js 有关，以至于有一个 StackOverflow 问题，有 80+ 个赞成票。没有简单的方法可以从 CSV 文件中一次读取一条记录。等。

我喜欢 NodeJS，它快速、狂野、有趣，但我担心它对可证明的正确性兴趣不大。让我们希望我们最终能够将两全其美的东西融合在一起。我迫不及待地想看看未来什么会取代 Node...... :)

节点提供的另一件事是能够使用节点的子进程（childProcess.fork（）每个需要 10mb 内存）动态创建多个 v8 节点实例，从而不会影响运行服务器的主进程。因此，卸载需要大量服务器负载的后台作业变得轻而易举，我们可以在需要时轻松杀死它们。

我一直在使用node，在我们构建的大多数应用程序中，需要同时连接服务器，因此网络流量很大。像Express.js和新的Koajs（它删除了回调地狱）这样的框架使在节点上的工作变得更加容易。

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

• 所有最酷的家伙都喜欢它......所以它一定很有趣。
• 您可以在冷却器上闲逛，并有很多 Node 冒险可以吹嘘。
• 在云托管成本方面，您是一分钱的捏子。
• 有没有用 Rails 做到这一点
• 您讨厌 IIS 部署
• 你原来的IT工作变得相当枯燥，你希望你在一个闪亮的新创业公司。

期待什么......

• 使用 Express，您会感到安全可靠，而无需使用您从未需要的所有服务器膨胀软件。
• 像火箭一样运行，扩展性好。
• 你做梦。你安装了它。节点包存储库 npmjs.org 是世界上最大的开源库生态系统。
• 你的大脑会在嵌套回调的土地上扭曲时间......
• ...直到你学会信守诺言。
• Sequelize 和 Passport 是你的新 API 好友。
• 调试大部分异步代码会得到嗯......有趣的.
• 是时候让所有 Noders 掌握 Typescript 了。

谁使用它？

• PayPal、Netflix、沃尔玛、LinkedIn、Groupon、Uber、GoDaddy、道琼斯
• 这就是他们切换到 Node 的原因。

它可以用于

• 高度事件驱动且受 I/O 限制的应用程序
• 处理大量与其他系统连接的应用程序
• 实时应用程序（Node.js 从头开始设计，用于实时且简单 使用。
• 处理大量信息流传入和流出其他来源的应用程序
• 高流量、可扩展应用程序
• 必须与平台API和数据库对话的移动应用程序，而无需执行大量数据 分析学
• 构建网络应用程序
• 需要经常与后端通信的应用程序

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

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

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

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

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

如果您的应用程序主要绑定 Web API 或其他 io 通道，提供或采用用户界面，node.js 可能是您的公平选择，特别是如果您想挤出最大的可扩展性，或者，如果您生活中的主要语言是 javascript（或各种 javascript 转译器）。如果你构建微服务，node.js 也可以。Node.js 也适用于任何小型或简单的项目。

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

然而，超过某个点，你就无法扩展你的代码，除非有可怕的黑客来强制模块化、可读性和流量控制。不过，有些人喜欢这些黑客，尤其是来自事件驱动的 javascript 背景，它们似乎很熟悉或可以原谅。

特别是，当您的应用程序需要执行同步流时，您开始因半生不熟的解决方案而流血，这会大大减慢您的开发过程。如果您的应用程序中有计算密集型部分，请谨慎选择（仅）节点.js。也许 http://koajs.com/ 或其他新奇事物可以缓解那些最初棘手的方面，与我最初使用 node.js 或写这篇文章时相比。

1. Node 非常适合快速原型，但我再也不会将它用于任何复杂的事情。 我花了 20 年时间与编译器建立关系，我当然很想念它。

2. Node 对于维护您有一段时间没有访问过的代码尤其痛苦。类型信息和编译时错误检测是好事。为什么要把这些都扔掉？为什么？的，当有东西向南移动时，堆栈痕迹往往完全无用。

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

所以，让我们从一个故事开始。从过去 2 年开始，我正在研究 JavaScript 和开发 Web 前端，我很喜欢它。后端人员为我们提供了一些用 Java、python 编写的 API（我们不在乎），我们只是编写一个 AJAX 调用，获取我们的数据，猜猜怎么着！我们完成了。但实际上，这并不容易，如果我们获得的数据不正确或存在一些服务器错误，那么我们就会卡住，我们必须通过邮件或聊天（有时在whatsApp上太:)）联系我们的后端人员。这并不酷。如果我们用 JavaScript 编写 API 并从前端调用这些 API 会怎样？是的，这很酷，因为如果我们在 API 中遇到任何问题，我们可以调查它。你猜怎么着 ！你现在可以这样做了，怎么样？– 节点就在你身边。

好的，同意你可以用JavaScript编写你的API，但如果我对上述问题感到满意怎么办。您还有其他理由将节点用于rest API吗？

所以魔术开始了。是的，我确实有其他原因将节点用于我们的 API。

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

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

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

现在这里是，节点将如何做到这一点：

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

因此，无需等待，无需线程，无需内存消耗 - 是的，这是提供rest API的节点方式。

穿上石棉长裤......

昨天我在Packt Publications的标题是《使用JavaScript进行反应式编程》。它并不是一个真正以 Node.js 为中心的标题;前几章旨在涵盖理论，后面的代码繁重的章节涵盖实践。因为我真的不认为不给读者一个网络服务器是合适的，所以 Node.js 似乎是显而易见的选择。这个案子甚至在打开之前就已经结案了。

我本可以对我的 Node.js 体验给出一个非常乐观的看法。相反，我对我遇到的好点和坏点都很诚实。

让我在这里引用一些相关的引述：

警告：Node.js 及其生态系统很热——热到足以让你严重燃烧！

当我担任数学老师的助理时，我被告知的一个不明显的建议是不要告诉学生某件事“容易”。回想起来，原因有些明显：如果你告诉人们某件事很容易，那些看不到解决方案的人最终可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决问题，而且他们太愚蠢而无法理解的问题很容易！

有些陷阱不仅会惹恼来自 Python / Django 的人，如果您更改任何内容，它会立即重新加载源代码。使用 Node.js 时，默认行为是，如果进行一次更改，旧版本将继续处于活动状态，直到时间结束或手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了 Pythonistas;它还激怒了提供各种解决方法的原生 Node.js 用户。在撰写本文时，StackOverflow 问题“自动重新加载 Node.js 中的文件”已获得超过 200 个赞成票和 19 个答案;编辑将用户定向到一个保姆脚本 node-supervisor，主页位于 http://tinyurl.com/reactjs-node-supervisor。这个问题为新用户提供了很大的机会感到愚蠢，因为他们认为他们已经解决了问题，但旧的错误行为完全没有改变。而且很容易忘记退回服务器;我已经做过很多次了。我想传达的信息是，“不，你并不愚蠢，因为 Node.js 的这种行为让你背锅;只是 Node.js 的设计者认为没有理由在这里提供适当的行为。试着应对它，也许从节点主管或其他解决方案那里获得一点帮助，但请不要觉得自己很愚蠢。你不是有问题的人;问题出在 Node.js 的默认行为上。

经过一番辩论后，这一部分被保留了下来，正是因为我不想给人一种“很容易”的印象。我在让事情正常工作时反复割伤我的手，我不想克服困难，让你相信让 Node.js 及其生态系统正常运行是一件简单的事情，如果它对你来说也不简单，你不知道你在做什么。如果你在使用 Node.js 时没有遇到令人讨厌的困难，那就太好了。如果你这样做了，我希望你不要离开时觉得，“我很愚蠢——我一定有什么问题。如果您在处理 Node.js 时遇到令人讨厌的意外，您并不愚蠢。不是你！这是Node.js及其生态系统！

附录，在最后几章和结论的上升之后，我并不真正想要，它谈到了我能够在生态系统中找到的东西，并为愚蠢的文字主义提供了一种解决方法：

另一个看起来非常合适，但可能还可赎回的数据库是 HTML5 键值存储的服务器端实现。这种方法具有 API 的主要优势，大多数优秀的前端开发人员都非常了解它。就此而言，它也是一个大多数不太好的前端开发人员都非常了解的 API。但是使用 node-localstorage 包，虽然不提供字典语法访问（您希望使用 localStorage.setItem（key， value） 或 localStorage.getItem（key），而不是 localStorage[key]），但实现了完整的 localStorage 语义，包括默认的 5MB 配额——为什么？服务器端 JavaScript 开发人员是否需要受到保护？

对于客户端数据库功能，每个网站 5MB 的配额确实是一个慷慨而有用的喘息空间，可以让开发人员使用它。您可以设置一个低得多的配额，并且仍然为开发人员提供比跛行和 cookie 管理不可估量的改进。5MB 的限制并不能很快用于大数据客户端处理，但足智多谋的开发人员可以利用非常慷慨的限额来做很多事情。但另一方面，在最近购买的大多数磁盘中，5MB并不是特别大的一部分，这意味着如果您和网站对磁盘空间的合理使用存在分歧，或者某些网站只是笨拙，它实际上不会花费您太多，除非您的硬盘驱动器已经太满，否则您不会有硬盘被淹没的危险。如果平衡少一点或多一点，也许我们会更好，但总的来说，这是一个不错的解决方案，可以解决客户端上下文的内在紧张关系。

但是，可以温和地指出，当您是为服务器编写代码的人时，您不需要任何额外的保护来使数据库的大小超过可容忍的 5MB。大多数开发人员既不需要也不想要充当保姆的工具，并保护他们免于存储超过 5MB 的服务器端数据。5MB的配额在客户端是一个黄金平衡行为，在Node.js服务器上有点愚蠢。（而且，对于本附录中介绍的多个用户的数据库，可能会略带痛苦地指出，除非在磁盘上为每个用户帐户创建一个单独的数据库，否则每个用户帐户不是 5MB;这是所有用户帐户之间共享的 5MB。如果你走红，那可能会很痛苦！文档指出配额是可自定义的，但一周前发给开发人员的一封电子邮件询问如何更改配额没有得到答复，StackOverflow 问题也是如此。我能够找到的唯一答案是在 Github CoffeeScript 源代码中，它被列为构造函数的可选第二个整数参数。因此，这很简单，您可以指定等于磁盘或分区大小的配额。但是，除了移植一个没有意义的功能之外，该工具的作者还没有完全遵循一个非常标准的约定，即将 0 解释为变量或函数的“无限”含义，其中整数指定某些资源使用的最大限制。处理此错误功能的最好办法可能是指定配额为 Infinity：

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

按顺序交换两条评论：

人们不必要地不断使用JavaScript作为一个整体来搬起石头砸自己的脚，而JavaScript之所以成为受人尊敬的语言，本质上是道格拉斯·克罗克福德（Douglas Crockford）的一句话，“JavaScript作为一种语言，有一些非常好的部分，也有一些非常坏的部分。这是好的部分。只是忘记了那里还有别的东西。也许炙手可热的 Node.js 生态系统会发展出自己的“Douglas Crockford”，他会说：“Node.js 生态系统是一个编码狂野的西部，但有一些真正的宝石有待发现。这是一个路线图。以下是几乎不惜一切代价避免的区域。这里有一些在任何语言或环境中都能找到的最丰富的收入区域。

也许其他人可以把这些话当作一个挑战，跟随Crockford的脚步，为Node.js及其生态系统写下“好的部分”和/或“更好的部分”。我会买一本！

考虑到所有项目的热情程度和纯粹的工作时间，在一年、两年或三年内，可能需要对在撰写本文时对不成熟生态系统的任何评论进行严厉的缓和。五年后，说“2015年的Node.js生态系统有几个雷区”可能真的是有道理的。2020年的Node.js生态系统有多个天堂。

我可以分享几点在哪里以及为什么使用node js。

1. 对于聊天、协作编辑等实时应用程序，我们最好使用 nodejs，因为它是事件库，从服务器向客户端触发事件和数据。
2. 简单易懂，因为它是大多数人有想法的 javascript 基础。
3. 目前大多数 Web 应用程序都朝着 angular js&backbone 的方向发展，使用 node 很容易与客户端代码交互，因为两者都将使用 json 数据。
4. 很多插件可用。

缺点：-

1. Node 将支持大多数数据库，但最好的是 mongodb，它不支持复杂的连接和其他数据库。
2. 编译错误...开发人员应该明智地处理每一个异常，如果任何错误协议应用程序将停止工作，我们需要再次手动或使用任何自动化工具启动它。

结论：- Nodejs 最适合用于简单和实时的应用程序。如果你有非常大的业务逻辑和复杂的功能，最好不要使用 nodejs。 如果您想构建一个应用程序以及聊天和任何协作功能..节点可用于特定部分，并应与您的便利技术保持一致。