首先要明确什么是大型应用，其实这是仁者见仁、智者见智的问题，并且它是一个哲学问题，不是一个技术问题。假如有人问你，一个可以进行线上销售的 站，比如优衣库，大不大能会说大，因为这与你平常所见的博客、企业官 等逻辑相比较确实复杂很多。或者说小，那么说明你开发过比它还复杂的系统。那么相比较淘宝而言呢小的对比是要有参照物的。

1. 应用的组成

一个完备的 Web 应用可能只由一门语言或者一种技术构成吗能。因为一个完备的 Web 应用其实是多门技术的综合体，解决某个问题有非常多的解决方案，比如后端的逻辑解决方案就非常多，Java、PHP、Python、Ruby 等都可以。

简单地概述，应用的组成内容可能包括：

• Web 界面显示逻辑；
• 后端业务逻辑；
• 缓存；
• 数据库；
• 消息队列。

其实还可以加入日志分析、数据分析等，只是上面几个最广为人知而已。

2. 应用的种类

• I/O 密集型；
• CPU 密集型。

就常见的互联 产品而言，它的瓶颈并非在后端业务的逻辑上，而是在 I/O 上，即返回给用户看的数据的读入与输出。相对于应用程序而言，读入指的是从数据库里获取数据，而输出指的是将这些数据经过一定的处理输出到用户的浏览器，那么这就是 I/O 密集型。

而 CPU 密集型是指做频繁计算任务的应用，Node.js 在这方面确实是短板。

3. 应用服务的过程

如图所示，用户通过浏览器发送请求，由 卡接收TCP 连接，通知内核，内核再去调用相对应的服务端程序。

Request 请求过程

Response 返回过程

如下图，Web 应用要返回数据，首先要获取数据，通过内核调用磁盘的驱动程序，把数据读入缓存，这样就可以在 Web 应用程序中获取数据并进行数据处理，最终调用内核，将数据通过 卡发送给客户端。

4. 应用的瓶颈

通常 I/O 密集型的瓶颈会在磁盘的读写上，所以在购买云服务器的时候可以购买 SSD 的磁盘来提升性能，一般数据库软件的数据都是存储在文件上面的。首先考虑添加内存型缓存来解决这个瓶颈，缓存经常访问的数据，看能否解决当前场景的问题，比如使用 Redis。其次才考虑搭建或扩充数据库集群来提高并发。

而 CPU 密集型的应用瓶颈则在 CPU 上，只能增加 CPU 处理核心来解决瓶颈。

5. 分布式应用

大型的普通应用与分布式应用其实是不同的概念。读者可以把分布式应用简单地理解为一个团队，每一个成员都是一个节点，一个大的项目要让成员合作完成，那么成员与成员之间就存在一些沟通成本，甚至有的成员与成员之间勾心斗角，说话阳奉阴违、推脱责任，也有可能成员生病在家休养，无法工作，等等。在面对这些问题的时候，Node.js 的优势并不能很好地显现出来（并非不可以做，只是没有完善的基础设施）。

分布式的真正定义是，在多台不同的服务器中部署不同的服务模块，以进程为基本单位，派发到服务器上，通过远程调用（RPC）通信并协同工作，最终对外提供服务。

相比较 Node.js目前的分布式基础设施，Go 语言的基础设施则完善多了，特别是在 Docker 这个项目上，充分证明了 Go 语言的优势，这也是为什么 Node.js 区“大牛”TJ Holowaychuk 转向 Go 语言，因为他要开发分布式应用。

其实没必要过分地关心分布式的问题，毕竟 JavaScript 最初只是一个运行在浏览器端的脚本语言而已，JavaScript 不是万能的，为什么一定要把它用在操作系统级别的开发上呢一个更合适的语言不是更好吗此刻我们选择 JavaScript 构建 Web 应用一样。

6. 多进程的 Node.js

了解了以上的一些知识点，现在读者应该知道，Node.js 跟大型应用关系不大。大多数学习 Node.js 的开发者是前端开发者，所以对后端的基础知识并不了解，在 络上搜寻一些资料的时候发现 Node.js 只能利用单核，而又听说 TJ Holowaychuk 转向 Go 的阵营，所以有的开发者就产生了Node.js不适合开发大型应用的疑问。

Node.js 只能利用单核的问题已经被解决了，后面使用的 Egg.js 框架中的 Egg-Cluster 模块就利用多进程非常好地解决了这个问题。

了解本书详情：https://u.jd.com/e29Uft

文章知识点与官方知识档案匹配，可进一步学习相关知识Vue入门技能树Node.js和npmNode安装与配置23419 人正在系统学习中