前言

首先要明確什么是大型應(yīng)用，其實(shí)這是仁者見仁、智者見智的問題，并且它是一個(gè)哲學(xué)問題，不是一個(gè)技術(shù)問題。假如有人問你，一個(gè)可以進(jìn)行線上銷售的網(wǎng)站，比如優(yōu)衣庫(kù)，大不大？你可能會(huì)說大，因?yàn)檫@與你平常所見的博客、企業(yè)官網(wǎng)等邏輯相比較確實(shí)復(fù)雜很多。或者說小，那么說明你開發(fā)過比它還復(fù)雜的系統(tǒng)。那么相比較淘寶而言呢？大和小的對(duì)比是要有參照物的。

1. 應(yīng)用的組成

一個(gè)完備的 Web 應(yīng)用可能只由一門語(yǔ)言或者一種技術(shù)構(gòu)成嗎？不可能。因?yàn)橐粋€(gè)完備的 Web 應(yīng)用其實(shí)是多門技術(shù)的綜合體，解決某個(gè)問題有非常多的解決方案，比如后端的邏輯解決方案就非常多，Java、php、Python、Ruby 等都可以。

簡(jiǎn)單地概述，應(yīng)用的組成內(nèi)容可能包括：

Web 界面顯示邏輯；后端業(yè)務(wù)邏輯；緩存；數(shù)據(jù)庫(kù)；消息隊(duì)列。

其實(shí)還可以加入日志分析、數(shù)據(jù)分析等，只是上面幾個(gè)最廣為人知而已。

2. 應(yīng)用的種類

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

就常見的互聯(lián)網(wǎng)產(chǎn)品而言，它的瓶頸并非在后端業(yè)務(wù)的邏輯上，而是在 I/O 上，即返回給用戶看的數(shù)據(jù)的讀入與輸出。相對(duì)于應(yīng)用程序而言，讀入指的是從數(shù)據(jù)庫(kù)里獲取數(shù)據(jù)，而輸出指的是將這些數(shù)據(jù)經(jīng)過一定的處理輸出到用戶的瀏覽器，那么這就是 I/O 密集型。

而CPU密集型是指做頻繁計(jì)算任務(wù)的應(yīng)用，Node.js在這方面確實(shí)是短板。

3. 應(yīng)用服務(wù)的過程

如圖所示，用戶通過瀏覽器發(fā)送請(qǐng)求，由網(wǎng)卡接收TCP 連接，通知內(nèi)核，內(nèi)核再去調(diào)用相對(duì)應(yīng)的服務(wù)端程序。

Request 請(qǐng)求過程

Response 返回過程

如下圖，Web 應(yīng)用要返回?cái)?shù)據(jù)，首先要獲取數(shù)據(jù)，通過內(nèi)核調(diào)用磁盤的驅(qū)動(dòng)程序，把數(shù)據(jù)讀入緩存，這樣就可以在 Web 應(yīng)用程序中獲取數(shù)據(jù)并進(jìn)行數(shù)據(jù)處理，最終調(diào)用內(nèi)核，將數(shù)據(jù)通過網(wǎng)卡發(fā)送給客戶端。

4. 應(yīng)用的瓶頸

通常 I/O 密集型的瓶頸會(huì)在磁盤的讀寫上，所以在購(gòu)買云服務(wù)器的時(shí)候可以購(gòu)買 SSD 的磁盤來(lái)提升性能，一般數(shù)據(jù)庫(kù)軟件的數(shù)據(jù)都是存儲(chǔ)在文件上面的。首先考慮添加內(nèi)存型緩存來(lái)解決這個(gè)瓶頸，緩存經(jīng)常訪問的數(shù)據(jù)，看能否解決當(dāng)前場(chǎng)景的問題，比如使用 Redis。其次才考慮搭建或擴(kuò)充數(shù)據(jù)庫(kù)集群來(lái)提高并發(fā)。

而 CPU 密集型的應(yīng)用瓶頸則在 CPU 上，只能增加 CPU 處理核心來(lái)解決瓶頸。

5. 分布式應(yīng)用

大型的普通應(yīng)用與分布式應(yīng)用其實(shí)是不同的概念。讀者可以把分布式應(yīng)用簡(jiǎn)單地理解為一個(gè)團(tuán)隊(duì)，每一個(gè)成員都是一個(gè)節(jié)點(diǎn)，一個(gè)大的項(xiàng)目要讓成員合作完成，那么成員與成員之間就存在一些溝通成本，甚至有的成員與成員之間勾心斗角，說話陽(yáng)奉陰違、推脫責(zé)任，也有可能成員生病在家休養(yǎng)，無(wú)法工作，等等。在面對(duì)這些問題的時(shí)候，Node.js的優(yōu)勢(shì)并不能很好地顯現(xiàn)出來(lái)（并非不可以做，只是沒有完善的基礎(chǔ)設(shè)施）。

分布式的真正定義是，在多臺(tái)不同的服務(wù)器中部署不同的服務(wù)模塊，以進(jìn)程為基本單位，派發(fā)到服務(wù)器上，通過遠(yuǎn)程調(diào)用（RPC）通信并協(xié)同工作，最終對(duì)外提供服務(wù)。

相比較Node.js目前的分布式基礎(chǔ)設(shè)施，Go 語(yǔ)言的基礎(chǔ)設(shè)施則完善多了，特別是在 Docker 這個(gè)項(xiàng)目上，充分證明了 Go 語(yǔ)言的優(yōu)勢(shì)，這也是為什么 Node.js 社區(qū)“大牛”TJ Holowaychuk 轉(zhuǎn)向 Go 語(yǔ)言，因?yàn)樗_發(fā)分布式應(yīng)用。

其實(shí)沒必要過分地關(guān)心分布式的問題，畢竟JavaScript最初只是一個(gè)運(yùn)行在瀏覽器端的腳本語(yǔ)言而已，JavaScript不是萬(wàn)能的，為什么一定要把它用在操作系統(tǒng)級(jí)別的開發(fā)上呢？尋找一個(gè)更合適的語(yǔ)言不是更好嗎？就像此刻我們選擇 JavaScript 構(gòu)建 Web 應(yīng)用一樣。

6. 多進(jìn)程的 Node.js

了解了以上的一些知識(shí)點(diǎn)，現(xiàn)在讀者應(yīng)該知道，Node.js 跟大型應(yīng)用關(guān)系不大。大多數(shù)學(xué)習(xí) Node.js 的開發(fā)者是前端開發(fā)者，所以對(duì)后端的基礎(chǔ)知識(shí)并不了解，在網(wǎng)絡(luò)上搜尋一些資料的時(shí)候發(fā)現(xiàn) Node.js 只能利用單核，而又聽說 TJ Holowaychuk 轉(zhuǎn)向 Go 的陣營(yíng)，所以有的開發(fā)者就產(chǎn)生了Node.js不適合開發(fā)大型應(yīng)用的疑問。

Node.js 只能利用單核的問題已經(jīng)被解決了，后面使用的 Egg.js框架中的 Egg-Cluster 模塊就利用多進(jìn)程非常好地解決了這個(gè)問題。

以上就是為什么node.js不適合大型項(xiàng)目的詳細(xì)內(nèi)容，更多關(guān)于node.js的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論