為什麼要使用 Node.js

標籤：

Node.js 是什麼

傳統意義上的 JavaScript 運行在瀏覽器上，這是因為瀏覽器核心實際上分為兩個部分:渲染引擎和 JavaScript 引擎。前者負責渲染 HTML + CSS，後者則負責運行 JavaScript。Chrome 使用的 JavaScript 引擎是 V8，它的速度非常快。

Node.js 是一個運行在服務端的架構，它的底層就使用了 V8 引擎。我們知道 Apache + PHP 以及 Java 的 Servlet 都可以用來開發動態網頁，Node.js 的作用與他們類似，只不過是使用 JavaScript 來開發。

從定義上介紹完後，舉一個簡單的例子，建立一個 app.js 檔案並輸入以下內容:

var http = require(‘http‘);http.createServer(function (request, response) {    response.writeHead(200, {‘Content-Type‘: ‘text/plain‘}); // HTTP Response 頭部    response.end(‘Hello World\n‘); // 返回資料 “Hello World”}).listen(8888); // 監聽 8888 連接埠// 終端列印如下資訊console.log(‘Server running at http://127.0.0.1:8888/‘);

這樣，一個簡單的 HTTP Server 就算是寫完了，輸入 node app.js 即可運行，隨後訪問便會看到輸出結果。

為什麼要用 Node.js

面對一個新技術，多問幾個為什麼總是好的。既然 PHP、Python、Java 都可以用來進行後端開發，為什麼還要去學習 Node.js？至少我們應該知道在什麼情境下，選擇 Node.js 更合適。

總的來說，Node.js 適合以下情境:

1. 即時性應用，比如線上多人協作工具，網頁聊天應用等。
2. 以 I/O 為主的高並發應用，比如為用戶端提供 API，讀取資料庫。
3. 流式應用，比如用戶端經常上傳檔案。
4. 前後端分離。

實際上前兩者可以歸結為一種，即用戶端廣泛使用長串連，雖然並發數較高，但其中大部分是空閑串連。

Node.js 也有它的局限性，它並不適合 CPU 密集型的任務，比如人工智慧方面的計算，視頻、圖片的處理等。

當然，以上缺點不是信口開河，或者死記硬背，更不是人云亦云，需要我們對 Node.js 的原理有一定的瞭解，才能做出正確的判斷。

基礎概念

在介紹 Node.js 之前，理清楚一些基本概念有助於更深入的理解 Node.js 。

並發

與用戶端不同，服務端開發人員非常關心的一項資料是並發數，也就是這台伺服器最多能支援多少個用戶端的並發請求。早年的 C10K 問題就是討論如何利用單台伺服器支援 10K 並發數。當然隨著軟硬體效能的提高，目前 C10K 已經不再是問題，我們開始嘗試解決 C10M 問題，即單台伺服器如何處理百萬級的並發。

在 C10K 提出時，我們還在使用 Apache 伺服器，它的工作原理是每當有一個網路請求到達，就 fork 出一個子進程並在子進程中運行 PHP 指令碼。執行完指令碼後再把結果發回用戶端。

這樣可以確保不同進程之間互不干擾，即使一個進程出問題也不影響整個伺服器，但是缺點也很明顯:進程是一個比較重的概念，擁有自己的堆和棧，佔用記憶體較多，一台伺服器能啟動並執行進程數量有上限，大約也就在幾千左右。

雖然 Apache 後來使用了 FastCGI，但本質上只是一個進程池，它減少了建立進程的開銷，但無法有效提高並發數。

Java 的 Servlet 使用了線程池，即每個 Servlet 運行在一個線程上。線程雖然比進程輕量，但也是相對的。有人測試過，每個線程獨享的棧的大小是 1M，依然不夠高效。除此以外，多線程編程會帶來各種麻煩，這一點想必程式員們都深有體會。

如果不使用線程，還有兩種解決方案，分別是使用協程(coroutine)和非阻塞 I/O。協程比線程更加輕量，多個協程可以運行在同一個線程中，並由程式員自己負責調度，這種技術在 Go 語言中被廣泛使用。而非阻塞 I/O 則被 Node.js 用來處理高並發的情境。

非阻塞 I/O

這裡所說的 I/O 可以分為兩種: 網路 I/O 和檔案 I/O，實際上兩者高度類似。 I/O 可以分為兩個步驟，首先把檔案(網路)中的內容拷貝到緩衝區，這個緩衝區位於作業系統獨佔的記憶體地區中。隨後再把緩衝區中的內容拷貝到使用者程式的記憶體地區中。

對於阻塞 I/O 來說，從發起讀請求，到緩衝區就緒，再到使用者進程擷取資料，這兩個步驟都是阻塞的。

非阻塞 I/O 實際上是向核心輪詢，緩衝區是否就緒，如果沒有則繼續執行其他動作。當緩衝區就緒時，講緩衝區內容拷貝到使用者進程，這一步實際上還是阻塞的。

I/O 多工技術是指利用單個線程處理多個網路 I/O，我們常說的 select、epoll 就是用來輪詢所有 socket 的函數。比如 Apache 採用了前者，而 Nginx 和 Node.js 使用了後者，區別在於後者效率更高。由於 I/O 多工實際上還是單線程的輪詢，因此它也是一種非阻塞 I/O 的方案。

非同步 I/O 是最理想的 I/O 模型，然而可惜的是真正的非同步 I/O 並不存在。 Linux 上的 AIO 通過訊號和回調來傳遞資料，但是存在缺陷。現有的 libeio 以及 Windows 上的 IOCP，本質上都是利用線程池與阻塞 I/O 來類比非同步 I/O。

Node.js 執行緒模式

很多文章都提到 Node.js 是單線程的，然而這樣的說法並不嚴謹，甚至可以說很不負責，因為我們至少會想到以下幾個問題:

1. Node.js 在一個線程中如何處理並發請求？
2. Node.js 在一個線程中如何進行檔案的非同步 I/O？
3. Node.js 如何重複利用伺服器上的多個 CPU 的處理能力？

網路 I/O

Node.js 確實可以在單線程中處理大量的並發請求，但這需要一定的編程技巧。我們回顧一下文章開頭的代碼，執行了 app.js 檔案後控制台立刻就會有輸出，而在我們訪問網頁時才會看到 “Hello，World”。

這是因為 Node.js 是事件驅動的，也就是說只有網路請求這一事件發生時，它的回呼函數才會執行。當有多個請求到來時，他們會排成一個隊列，依次等待執行。

這看上去理所當然，然而如果沒有深刻認識到 Node.js 運行在單線程上，而且回呼函數是同步執行，同時還按照傳統的模式來開發程式，就會導致嚴重的問題。舉個簡單的例子，這裡的 “Hello World” 字串可能是其他某個模組的運行結果。假設 “Hello World” 的產生非常耗時，就會阻塞當前網路請求的回調，導致下一次網路請求也無法被響應。

解決方案很簡單，採用非同步回調機制即可。我們可以把用來產生輸出結果的 response 參數傳遞給其他模組，並用非同步方式產生輸出結果，最後在回呼函數中執行真正的輸出。這樣的好處是，http.createServer 的回呼函數不會阻塞，因此不會出現請求無響應的情況。

舉個例子，我們改造一下 server 的入口，實際上如果要自己完成路由，大約也是這個思路:

var http = require(‘http‘);var output = require(‘./string‘) // 一個第三方模組http.createServer(function (request, response) {    output.output(response); // 調用第三方模組進行輸出}).listen(8888);

第三方模組:

function sleep(milliSeconds) {  // 類比卡頓    var startTime = new Date().getTime();    while (new Date().getTime() < startTime + milliSeconds);}function outputString(response) {    sleep(10000);  // 阻塞 10s        response.end(‘Hello World\n‘); // 先執行耗時操作，再輸出}exports.output = outputString;

總之，在利用 Node.js 編程時，任何耗時操作一定要使用非同步來完成，避免阻塞當前函數。因為你在為用戶端提供服務，而所有代碼總是單線程、順序執行。

如果初學者看到這裡還是無法理解，建議閱讀 “Nodejs 入門” 這本書，或者閱讀下文關於事件迴圈的章節。

檔案 I/O

我在之前的文章中也強調過，非同步是為了最佳化體驗，避免卡頓。而真正節省處理時間，利用 CPU 多核效能，還是要靠同步多執行緒。

實際上 Node.js 在底層維護了一個線程池。之前在基礎概念部分也提到過，不存在真正的非同步檔案 I/O，通常是通過線程池來類比。線程池中預設有四個線程，用來進行檔案 I/O。

需要注意的是，我們無法直接操作底層的線程池，實際上也不需要關心它們的存在。線程池的作用僅僅是完成 I/O 操作，而非用來執行 CPU 密集型的操作，比像、視頻處理，大規模計算等。

如果有少量 CPU 密集型的任務需要處理，我們可以啟動多個 Node.js 進程並利用 IPC 機制進行進程間通訊，或者調用外部的 C++/Java 程式。如果有大量 CPU 密集型任務，那隻能說明選擇 Node.js 是一個錯誤的決定。

榨乾 CPU

到目前為止，我們知道了 Node.js 採用 I/O 多工技術，利用單線程處理網路 I/O，利用線程池和少量線程類比非同步檔案 I/O。那在一個 32 核 CPU 上，Node.js 的單線程是否顯得雞肋呢？

答案是否定的，我們可以啟動多個 Node.js 進程。不同於上一節的是，進程之間不需要通訊，它們各自監聽一個連接埠，同時在最外層利用 Nginx 做負載平衡。

Nginx 負載平衡非常容易實現，只要編輯設定檔即可:

http{    upstream sampleapp {        // 可選配置項，如 least_conn，ip_hash        server 127.0.0.1:3000;        server 127.0.0.1:3001;        // ... 監聽更多連接埠    }    ....    server{       listen 80;       ...       location / {          proxy_pass http://sampleapp; // 監聽 80 連接埠，然後轉寄       }     }

預設的負載平衡規則是把網路請求依次分配到不同的連接埠，我們可以用 least_conn 標誌把網路請求轉寄到串連數最少的 Node.js 進程，也可以用 ip_hash 保證同一個 ip 的請求一定由同一個 Node.js 進程處理。

多個 Node.js 進程可以充分發揮多核 CPU 的處理能力，也具有很強大的拓展能力。

事件迴圈

在 Node.js 中存在一個事件迴圈(Event Loop)，有過 iOS 開發經驗的同學可能會覺得眼熟。沒錯，它和 Runloop 在一定程度上是類似的。

一次完整的 Event Loop 也可以分為多個階段(phase)，依次是 poll、check、close callbacks、timers、I/O callbacks 、Idle。

由於 Node.js 是事件驅動的，每個事件的回呼函數會被註冊到 Event Loop 的不同階段。比如fs.readFile 的回呼函數被添加到 I/O callbacks，setImmediate 的回調被添加到下一次 Loop 的 poll 階段結束後，process.nextTick() 的回調被添加到當前 phase 結束後，下一個 phase 開始前。

不同非同步方法呼叫的回調會在不同的 phase 被執行，掌握這一點很重要，否則就會因為調用順序問題產生邏輯錯誤。

Event Loop 不斷的迴圈，每一個階段內都會同步執行所有在該階段註冊的回呼函數。這也正是為什麼我在網路 I/O 部分提到，不要在回呼函數中調用阻塞方法，總是用非同步思想來進行耗時操作。一個耗時太久的回呼函數可能會讓 Event Loop 卡在某個階段很久，新來的網路請求就無法被及時響應。

由於本文的目的是對 Node.js 有一個初步的，全面的認識。就不詳細介紹 Event Loop 的每個階段了，具體細節可以查看官方文檔。

可以看出 Event Loop 還是比較偏底層的，為了方便的使用事件驅動的思想，Node.js 封裝了EventEmitter 這個類:

var EventEmitter = require(‘events‘);var util = require(‘util‘);function MyThing() {    EventEmitter.call(this);    setImmediate(function (self) {        self.emit(‘thing1‘);    }, this);    process.nextTick(function (self) {        self.emit(‘thing2‘);    }, this);}util.inherits(MyThing, EventEmitter);var mt = new MyThing();mt.on(‘thing1‘, function onThing1() {    console.log("Thing1 emitted");});mt.on(‘thing2‘, function onThing1() {    console.log("Thing2 emitted");});

根據輸出結果可知，self.emit(thing2) 雖然後定義，但先被執行，這也完全符合 Event Loop 的調用規則。

Node.js 中很多模組都繼承自 EventEmitter，比如下一節中提到的 fs.readStream，它用來建立一個可讀檔案流， 開啟檔案、讀取資料、讀取完成時都會拋出相應的事件。

資料流

使用資料流的好處很明顯，生活中也有真實寫照。舉個例子，老師布置了暑假作業，如果學生每天都做一點(作業流)，就可以比較輕鬆的完成任務。如果積壓在一起，到了最後一天，面對堆成小山的作業本，就會感到力不從心。

Server 開發也是這樣，假設使用者上傳 1G 檔案，或者讀取本地 1G 的檔案。如果沒有資料流的概念，我們需要開闢 1G 大小的緩衝區，然後在緩衝區滿後一次性集中處理。

如果是採用資料流的方式，我們可以定義很小的一塊緩衝區，比如大小是 1Mb。當緩衝區滿後就執行回呼函數，對這一小塊資料進行處理，從而避免出現積壓。

實際上 request 和 fs 模組的檔案讀取都是一個可讀資料流:

var fs = require(‘fs‘);var readableStream = fs.createReadStream(‘file.txt‘);var data = ‘‘;readableStream.setEncoding(‘utf8‘);// 每次緩衝區滿，處理一小塊資料 chunkreadableStream.on(‘data‘, function(chunk) {    data+=chunk;});// 檔案流全部讀取完成readableStream.on(‘end‘, function() {    console.log(data);});

利用管道技術，可以把一個流中的內容寫入到另一個流中:

var fs = require(‘fs‘);var readableStream = fs.createReadStream(‘file1.txt‘);var writableStream = fs.createWriteStream(‘file2.txt‘);readableStream.pipe(writableStream);

不同的流還可以串聯(Chain)起來，比如讀取一個壓縮檔，一邊讀取一邊解壓，並把解壓內容寫入到檔案中:

var fs = require(‘fs‘);var zlib = require(‘zlib‘);fs.createReadStream(‘input.txt.gz‘)  .pipe(zlib.createGunzip())  .pipe(fs.createWriteStream(‘output.txt‘));

Node.js 提供了非常簡潔的資料流操作，以上就是簡單的使用介紹。

總結

對於高並發的長串連，事件驅動模型比線程輕量得多，多個 Node.js 進程配合負載平衡可以方便的進行拓展。因此 Node.js 非常適合為 I/O 密集型應用提供服務。但這種方式的缺陷就是不擅長處理 CPU 密集型任務。

Node.js 中通常以流的方式來描述資料，也對此提供了很好的封裝。

Node.js 使用前端語言(JavaScript) 開發，同時也是一個後端伺服器，因此為前後端分離提供了一個良好的思路。我會在下一篇文章中對此進行分析。

參考資料

1. Concurrent tasks on node.js
2. 利用 Nginx 為 Nodejs 添加負載平衡
3. Understanding the node.js event loop
4. The Node.js Event Loop
5. The Basics of Node.js Streams

為什麼要使用 Node.js