Node给前端开发者打了鸡血，现在我们可以用一种语言来写前后端的程序了，但我们都要避免的一点是，当你有一把锤子，你看见什么都是钉子。

所以我们不应该为了使用js而js，也不要为了时髦而使用Node。我们应该搞清楚，Node适合哪些场景，在这些场景下，Node是否是更优的选择？比起某一门“正常”的服务器语言？

Node更擅长……

Node更擅长处理并发连接。这是由Node处理连接的方法决定的。

Node公开宣称的目标是 “旨在提供一种简单的构建可伸缩网络程序的方法”。当前的服务器程序有什么问题？我们来做个数学题。在Java™和PHP这类语言中，每个连接都会生成一个新线程，每个新线程可能需要2MB的配套内存。在一个拥有8GBRAM的系统上，理论上最大的并发连接数量是4,000个用户。随着您的客户群的增长，如果希望您的Web应用程序支持更多用户，那么，您必须添加更多服务器。当然，这会增加服务器成本、流量成本和人工成本等成本。除这些成本上升外，还有一个潜在技术问题，即用户可能针对每个请求使用不同的服务器，因此，任何共享资源都必须在所有服务器之间共享。鉴于上述所有原因，整个Web应用程序架构（包括流量、处理器速度和内存速度）中的瓶颈是：服务器能够处理的并发连接的最大数量。

Node解决这个问题的方法是：更改连接到服务器的方式。每个连接发射一个在Node引擎的进程中运行的事件，而不是为每个连接生成一个新的OS线程（并为其分配一些配套内存）。Node声称它绝不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。Node还宣称，运行它的服务器能支持数万个并发连接。

Node非常适合以下情况：在响应客户端之前，您预计可能有很高的流量，但所需的服务器端逻辑和处理不一定很多。Node表现出众的典型示例包括：

1、RESTful API

提供RESTful API的Web服务接收几个参数，解析它们，组合一个响应，并返回一个响应（通常是较少的文本）给用户。这是适合Node的理想情况，因为您可以构建它来处理数万条连接。它仍然不需要大量逻辑；它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的API需求。

2、Twitter队列

想像一下像Twitter这样的公司，它必须接收tweets并将其写入数据库。实际上，每秒几乎有数千条tweet达到，数据库不可能及时处理高峰时段所需的写入数量。Node成为这个问题的解决方案的重要一环。如您所见，Node能处理数万条入站tweet。它能快速而又轻松地将它们写入一个内存排队机制（例如memcached），另一个单独进程可以从那里将它们写入数据库。Node在这里的角色是迅速收集tweet，并将这个信息传递给另一个负责写入的进程。

3、电子游戏统计数据 如果您在线玩过《使命召唤》这款游戏，当您查看游戏统计数据时，就会立即意识到一个问题：要生成那种级别的统计数据，必须跟踪海量信息。这样，如果有数百万玩家同时在线玩游戏，而且他们处于游戏中的不同位置，那么很快就会生成海量信息。Node是这种场景的一种很好的解决方案，因为它能采集游戏生成的数据，对数据进行最少的合并，然后对数据进行排队，以便将它们写入数据库。使用整个服务器来跟踪玩家在游戏中发射了多少子弹看起来很愚蠢，如果您使用Apache这样的服务器，可能会有一些有用的限制；但相反，如果您专门使用一个服务器来跟踪一个游戏的所有统计数据，就像使用运行Node的服务器所做的那样，那看起来似乎是一种明智之举。

所以现在很多App，无论是native app还是web app，都适合使用node作为服务器端作为API。优点是：

• 可并行请求多
• 扩展容易（如果真的需要扩展的话）
• 适合服务器端小型计算

Node的学习曲线

其实对于习惯了PHP或者JAVA这种编程语言的开发者，Node是有一定的学习曲线的，首当其冲的就是函数式编程风格。

Node对于I/O操作都是异步的（比如读取文件、抓取URL、读取数据库等），所以代码中不能根据代码顺序来作为执行顺序的依赖，而应该把异步操作之后的代码放在回调函数中，当异步操作完成（无论成功还是失败）之后才执行回调函数。

习惯这种编程风格之后，你会发现编码会比以前更快。加上NPM（Node Package Manager）的模块管理系统，你可以方便地使用别人的代码。推荐在这里浏览模块：https://github.com/joyent/node/wiki/modules