首先需要了解几个基本常识

1. CPU 运算远远快于 I/O 操作

2. Web 是典型的 I/O 密集场景

3. JavaScript 是单线程、但 JavaScript 的 runtime NodeJS 并不是，毕竟人家很多代码是 C++

很多语言是依赖的多进程、线程解决高并发，一个线程处理一条用户请求，处理完成了释放线程，在阻塞 I/O 模型下， I/O 期间该用户线程所占用的 CPU 资源（虽然十分微量，大部分交给了 DMA）什么都不做，等待 I/O，然后响应用户，而且开启多个进程/线程 CPU 切换 Context 的时间也十分可观。

就像饭店的服务员只负责点菜，如果给每个厨师都配一个服务员，服务员把客人菜单给大厨后就玩手机等着一样，你是老板你也生气，况且不同于饭店大厨工资高于服务员，在计算机世界，CPU 资源比 I/O 宝贵的多。

说 NodeJS 在高并发、I/O 密集场景性能高，也就是 Web 场景性能高主要也是解决这个问题，没必要一个厨师配一个服务员，整个饭店说不定一个服务员就够了，剩下的钱可以随便做其它事情。

用户请求来了， CPU 的部分做完不用等待 I/O，交给底层完成，然后可以接着处理下一个请求了，快就快在

1. 非阻塞 I/O

2. Web 场景 I/O 密集

3. 没那么多线程 Context 切换，多出来的开销是检查一个 EventLoop

其它场景 NodeJS 性能确实不高，甚至非常底下，其实看看 Apache 都江山稳固了，为什么 Nginx 还能异军突起就很容易理解 NodeJS优势，原理实在太像了。

Node.js是一个事件驱动I/O服务端JavaScript环境，基于Google的V8引擎，V8引擎执行Javascript的速度非常快，性能非常好。
异步发送IO操作请求后，你可以去做别的事，IO返回后会自动做下一步的，而且你可以同时发起多个IO然后一起汇总。所以只用单线程就可以了，每一步的操作可以用整体更少的资源满足要求，从而大大提高性能。

高并发的请求处理能力，解决的是请求的问题。

海量数据的分布、组织和处理形式，又事关能否快速响应的问题。

如果涉及海量数据，八成还牵扯到容灾，那事情就不简单了，什么单点故障RAID复制备份各种各样的因素都穿插其中。

首先题主说的这个情况我完全不相信，虽然我们也是NodeJS团队，但是我们从来不会跟ruby或者java去吹我们NodeJS性能多好。有意义么？Web开发的瓶颈根本不是你应用本身的性能啊，而且Nodejs的性能哪里好了。。。一个成熟的web应用，大部分性能瓶颈是在IO操作上，这个io包括 数据库操作（连接数，机器性能等）、缓存服务、网络IO、文件读写等操作。如果IO生产方的性能瓶颈了，你再分布式，再堆机器，再牛逼的语言都没啥卵用。

NodeJS的天然异步IO的确可以快速写出异步高效读取io的代码，不过就跟你去食堂吃饭一样，其实有时候100个人一拥而上打饭和100个人排着队打饭，并不是一定是一拥而上效率高。对于Nodejs线上服务，很常见的性能瓶颈就是因为他太屌了，能够一下子承接1W个异步请求，然后。。。。它挂了，他的异步机制导致应用被挂起，内存狂飙，IO堵塞，而且不可恢复，这个时候你只能重启了。而ruby，java他们正在有序的处理请求，他们处理不了的请求都在排队等着呢，虽然慢点，但是不会挂额。

而且，谁说其他语言没有异步机制呢？ruby，java，都有解决异步问题的框架方案。


对于我们团队，其实使用NodeJS的理由，反而提现在其他方面：
1. 生态活跃，解决方案众多，我们的Node服务化，架构，协作方式都很先进，因为社区活跃，有很多思路可以借鉴，架构变得越来越优，开发方式也变得越来越趋向社区规范。反观java，一直在玩老掉牙的架构，每天就是在搞环境问题，大部分开发完全不知道内部原理，而且没有什么大的技术追求。
2. 轻量，部署轻量，开发轻量。我们可以用最小的阿里云配置就部署出一个小应用来，用来做微服务化架构非常完美。想想把一个java系统拆分成十几个微服务（java）的场景，每个进程启动起来都要1G内存吧至少，high起来吧阿里云。
3. 我们公司技术栈采用多语言，多一个语言就多一种可能性，例如一些用node实现特别适合的服务，Phantomjs类的服务（图片，模拟操作等），WebSocket啊之类的。

NodeJS的天然异步IO的确可以快速写出异步高效读取io的代码，不过就跟你去食堂吃饭一样，其实有时候100个人一拥而上打饭和100个人排着队打饭，并不是一定是一拥而上效率高。对于Nodejs线上服务，很常见的性能瓶颈就是因为他太屌了，能够一下子承接1W个异步请求，然后。。。。它挂了，他的异步机制导致应用被挂起，内存狂飙，IO堵塞，而且不可恢复，这个时候你只能重启了。而ruby，java他们正在有序的处理请求，他们处理不了的请求都在排队等着呢，虽然慢点，但是不会挂额。

首先需要了解几个基本常识

1. CPU 运算远远快于 I/O 操作

2. Web 是典型的 I/O 密集场景

3. JavaScript 是单线程、但 JavaScript 的 runtime NodeJS 并不是，毕竟人家很多代码是 C++

很多语言是依赖的多进程、线程解决高并发，一个线程处理一条用户请求，处理完成了释放线程，在阻塞 I/O 模型下， I/O 期间该用户线程所占用的 CPU 资源（虽然十分微量，大部分交给了 DMA）什么都不做，等待 I/O，然后响应用户，而且开启多个进程/线程 CPU 切换 Context 的时间也十分可观。

就像饭店的服务员只负责点菜，如果给每个厨师都配一个服务员，服务员把客人菜单给大厨后就玩手机等着一样，你是老板你也生气，况且不同于饭店大厨工资高于服务员，在计算机世界，CPU 资源比 I/O 宝贵的多。

说 NodeJS 在高并发、I/O 密集场景性能高，也就是 Web 场景性能高主要也是解决这个问题，没必要一个厨师配一个服务员，整个饭店说不定一个服务员就够了，剩下的钱可以随便做其它事情。

用户请求来了， CPU 的部分做完不用等待 I/O，交给底层完成，然后可以接着处理下一个请求了，快就快在

1. 非阻塞 I/O

2. Web 场景 I/O 密集

3. 没那么多线程 Context 切换，多出来的开销是检查一个 EventLoop

其它场景 NodeJS 性能确实不高，甚至非常底下，其实看看 Apache 都江山稳固了，为什么 Nginx 还能异军突起就很容易理解 NodeJS优势，原理实在太像了。

 0人赞  添加讨论(0)

雨陵西 - 每一代青年都有自己的际遇和机缘

3楼-- · 22小时前

Node.js是一个事件驱动I/O服务端JavaScript环境，基于Google的V8引擎，V8引擎执行Javascript的速度非常快，性能非常好。
异步发送IO操作请求后，你可以去做别的事，IO返回后会自动做下一步的，而且你可以同时发起多个IO然后一起汇总。所以只用单线程就可以了，每一步的操作可以用整体更少的资源满足要求，从而大大提高性能。

 0人赞  添加讨论(0)

小猪仔

4楼-- · 6小时前

高并发的请求处理能力，解决的是请求的问题。

海量数据的分布、组织和处理形式，又事关能否快速响应的问题。

如果涉及海量数据，八成还牵扯到容灾，那事情就不简单了，什么单点故障RAID复制备份各种各样的因素都穿插其中。

 0人赞  添加讨论(0)

何大侠

5楼-- · 6小时前

首先题主说的这个情况我完全不相信，虽然我们也是NodeJS团队，但是我们从来不会跟ruby或者java去吹我们NodeJS性能多好。有意义么？Web开发的瓶颈根本不是你应用本身的性能啊，而且Nodejs的性能哪里好了。。。一个成熟的web应用，大部分性能瓶颈是在IO操作上，这个io包括 数据库操作（连接数，机器性能等）、缓存服务、网络IO、文件读写等操作。如果IO生产方的性能瓶颈了，你再分布式，再堆机器，再牛逼的语言都没啥卵用。

NodeJS的天然异步IO的确可以快速写出异步高效读取io的代码，不过就跟你去食堂吃饭一样，其实有时候100个人一拥而上打饭和100个人排着队打饭，并不是一定是一拥而上效率高。对于Nodejs线上服务，很常见的性能瓶颈就是因为他太屌了，能够一下子承接1W个异步请求，然后。。。。它挂了，他的异步机制导致应用被挂起，内存狂飙，IO堵塞，而且不可恢复，这个时候你只能重启了。而ruby，java他们正在有序的处理请求，他们处理不了的请求都在排队等着呢，虽然慢点，但是不会挂额。

而且，谁说其他语言没有异步机制呢？ruby，java，都有解决异步问题的框架方案。


对于我们团队，其实使用NodeJS的理由，反而提现在其他方面：
1. 生态活跃，解决方案众多，我们的Node服务化，架构，协作方式都很先进，因为社区活跃，有很多思路可以借鉴，架构变得越来越优，开发方式也变得越来越趋向社区规范。反观java，一直在玩老掉牙的架构，每天就是在搞环境问题，大部分开发完全不知道内部原理，而且没有什么大的技术追求。
2. 轻量，部署轻量，开发轻量。我们可以用最小的阿里云配置就部署出一个小应用来，用来做微服务化架构非常完美。想想把一个java系统拆分成十几个微服务（java）的场景，每个进程启动起来都要1G内存吧至少，high起来吧阿里云。
3. 我们公司技术栈采用多语言，多一个语言就多一种可能性，例如一些用node实现特别适合的服务，Phantomjs类的服务（图片，模拟操作等），WebSocket啊之类的。

 0人赞  添加讨论(0)

HARPPRTのIT

6楼-- · 13分钟前

NodeJS的天然异步IO的确可以快速写出异步高效读取io的代码，不过就跟你去食堂吃饭一样，其实有时候100个人一拥而上打饭和100个人排着队打饭，并不是一定是一拥而上效率高。对于Nodejs线上服务，很常见的性能瓶颈就是因为他太屌了，能够一下子承接1W个异步请求，然后。。。。它挂了，他的异步机制导致应用被挂起，内存狂飙，IO堵塞，而且不可恢复，这个时候你只能重启了。而ruby，java他们正在有序的处理请求，他们处理不了的请求都在排队等着呢，虽然慢点，但是不会挂额。

高并发的请求处理能力，解决的是请求的问题。

海量数据的分布、组织和处理形式，又事关能否快速响应的问题。

首先需要了解几个基本常识

1. CPU 运算远远快于 I/O 操作

2. Web 是典型的 I/O 密集场景

3. JavaScript 是单线程、但 JavaScript 的 runtime NodeJS 并不是，毕竟人家很多代码是 C++

很多语言是依赖的多进程、线程解决高并发，一个线程处理一条用户请求，处理完成了释放线程，在阻塞 I/O 模型下， I/O 期间该用户线程所占用的 CPU 资源（虽然十分微量，大部分交给了 DMA）什么都不做，等待 I/O，然后响应用户，而且开启多个进程/线程 CPU 切换 Context 的时间也十分可观。

就像饭店的服务员只负责点菜，如果给每个厨师都配一个服务员，服务员把客人菜单给大厨后就玩手机等着一样，你是老板你也生气，况且不同于饭店大厨工资高于服务员，在计算机世界，CPU 资源比 I/O 宝贵的多。

说 NodeJS 在高并发、I/O 密集场景性能高，也就是 Web 场景性能高主要也是解决这个问题，没必要一个厨师配一个服务员，整个饭店说不定一个服务员就够了，剩下的钱可以随便做其它事情。

用户请求来了， CPU 的部分做完不用等待 I/O，交给底层完成，然后可以接着处理下一个请求了，快就快在

1. 非阻塞 I/O

2. Web 场景 I/O 密集

3. 没那么多线程 Context 切换，多出来的开销是检查一个 EventLoop

其它场景 NodeJS 性能确实不高，甚至非常底下，其实看看 Apache 都江山稳固了，为什么 Nginx 还能异军突起就很容易理解 NodeJS优势，原理实在太像了。