一個Node.JS 的進程只會運行在單個的物理核心上，就是因為這一點，在開發(fā)可擴展的服務(wù)器的時候就需要格外的注意。

因為有一系列穩(wěn)定的API，加上原生擴展的開發(fā)來管理進程，所以有很多不同的方法來設(shè)計一個可以并行的Node.JS運用。在這篇博文里，我們就來比較下這些可能的架構(gòu)。

這篇文章同時也介紹compute-cluster 模塊：一個小型的Node.JS庫，可以用來很方便的管理進程，從來二線分布式計算。

遇到的問題

我們在Mozilla Persona的項目中需要可以處理大量不同特征的請求，所以我們嘗試用使用Node.JS。

為了不影響用戶體驗，我們設(shè)計的‘Interactive' 請求只需要輕量級的計算消耗，但是提供更快地反映時間使得UI沒有卡殼的感覺。相比之下，‘Batch'操作大概需要半秒的處理時間，而且有可能由于其他的原因，會有更長的延遲。

為了更好的設(shè)計，我們找了很多符合我們當(dāng)前需求的方法去解決。
考慮到擴展性和成本，我們列出以下關(guān)鍵需求：

•     效率：能有效的使用所有空閑的處理器
•     響應(yīng)：我們的“應(yīng)用”能實時快速的響應(yīng)
•     優(yōu)雅：當(dāng)請求量過多到不能處理的時候，我們處理我們能處理的。不能處理的要清晰的把錯誤反饋
•     簡單：我們的解決方案使用起來必須簡單方便

通過以上幾點我們可以清楚、有目標(biāo)的去篩選
 

方案一：直接在主線程中處理.

當(dāng)主線程直接處理數(shù)據(jù)的時候，結(jié)果很不好:

你不能充分利用多核CPU的優(yōu)勢，在交互式的請求/響應(yīng)中，必須等待當(dāng)前請求（或響應(yīng)）處理完畢，毫無優(yōu)雅可言。

這個方案唯一的優(yōu)點是：夠簡單
 

function myRequestHandler(request, response) [
 // Let's bring everything to a grinding halt for half a second.
 var results = doComputationWorkSync(request.somesuch);
}

在 Node.JS 程序中，希望同時處理多個請求，又想同步進行處理，那你準(zhǔn)備弄個焦頭爛額吧。

方法 2: 是否使用異步處理.

如果在后臺使用異步的方法來執(zhí)行是否一定會有很大的性能改善呢?

答案是不一定.它取決于后臺運行是否有意義

例如下面這種情況：如果在主線程上使用javascript或者本地代碼進行計算時,性能并不比同步處理更好時,就不一定需要在后臺用異步方法去處理

請閱讀以下代碼
 

function doComputationWork(input, callback) {
 // Because the internal implementation of this asynchronous
 // function is itself synchronously run on the main thread,
 // you still starve the entire process.
 var output = doComputationWorkSync(input);
 process.nextTick(function() {
  callback(null, output);
 });
}
 
function myRequestHandler(request, response) [
 // Even though this *looks* better, we're still bringing everything
 // to a grinding halt.
 doComputationWork(request.somesuch, function(err, results) {
  // ... do something with results ...
 });

}
關(guān)鍵點就在于NodeJS異步API的使用并不依賴于多進程的應(yīng)用

方案三：用線程庫來實現(xiàn)異步處理。

只要實現(xiàn)得當(dāng)，使用本地代碼實現(xiàn)的庫，在 NodeJS 調(diào)用的時候是可以突破限制從而實現(xiàn)多線程功能的。

有很多這樣的例子， Nick Campbell 編寫的 bcrypt library 就是其中優(yōu)秀的一個。

如果你在4核機器上拿這個庫來作一個測試，你將看到神奇的一幕：4倍于平時的吞吐量，并且耗盡了幾乎所有的資源！但是如果你在24核機器上測試，結(jié)果將不會有太大變化：有4個核心的使用率基本達到100%，但其他的核心基本上都處于空閑狀態(tài)。

問題出在這個庫使用了NodeJS內(nèi)部的線程池，而這個線程池并不適合用來進行此類的計算。另外，這個線程池上限寫死了，最多只能運行4個線程。

除了寫死了上限，這個問題更深層的原因是：

•     使用NodeJS內(nèi)部線程池進行大量運算的話，會妨礙其文件或網(wǎng)絡(luò)操作，使程序看起來響應(yīng)緩慢。
•     很難找到合適的方法來處理等待隊列：試想一下，如果你隊列里面已經(jīng)積壓了5分鐘計算量的線程，你還希望繼續(xù)往里面添加線程嗎?

內(nèi)建線程機制的組件庫在這種情況下并不能有效地利用多核的優(yōu)勢，這降低了程序的響應(yīng)能力，并且隨著負載的加大，程序表現(xiàn)越來越差。

方案四：使用 NodeJS 的 cluster 模塊

NodeJS 0.6.x 以上的版本提供了一個cluster模塊 ，允許創(chuàng)建“共享同一個socket”的一組進程，用來分擔(dān)負載壓力。

假如你采用了上面的方案，又同時使用 cluster 模塊，情況會怎樣呢？

這樣得出的方案將同樣具有同步處理或者內(nèi)建線程池一樣的缺點：響應(yīng)緩慢，毫無優(yōu)雅可言。

有時候，僅僅添加新運行實例并不能解決問題。
 

方案五：引入 compute-cluster 模塊

在 Persona 中，我們的解決方案是，維護一組功能單一（但各不相同）的計算進程。

在這個過程中，我們編寫了 compute-cluster 庫。

這個庫會自動按需啟動和管理子進程，這樣你就可以通過代碼的方式來使用一個本地子進程的集群來處理數(shù)據(jù)。

使用例子:
 

const computecluster = require('compute-cluster');
 
// allocate a compute cluster
var cc = new computecluster({ module: './worker.js' });
 
// run work in parallel
cc.enqueue({ input: "foo" }, function (error, result) {
 console.log("foo done", result);
});
cc.enqueue({ input: "bar" }, function (error, result) {
 console.log("bar done", result);
});

fileworker.js 中響應(yīng)了 message 事件，對傳入的請求進行處理：
 

process.on('message', function(m) {
 var output;
 // do lots of work here, and we don't care that we're blocking the
 // main thread because this process is intended to do one thing at a time.
 var output = doComputationWorkSync(m.input);
 process.send(output);
});
 

無需更改調(diào)用代碼，compute-cluster 模塊就可以和現(xiàn)有的異步API整合起來，這樣就能以最小的代碼量換來真正的多核并行處理。

我們從四個方面來看看這個方案的表現(xiàn)。

多核并行能力：子進程使用了全部的核心。

響應(yīng)能力：由于核心管理進程只負責(zé)啟動子進程和傳遞消息，大部分時間里它都是空閑的，可以處理更多的交互請求。

即使機器的負載壓力很大，我們?nèi)匀豢梢岳貌僮飨到y(tǒng)的調(diào)度器來提高核心管理進程的優(yōu)先級。

簡單性：使用了異步API來隱藏了具體實現(xiàn)的細節(jié)，我們可以輕易地將該模塊整合到現(xiàn)在項目中，甚至連調(diào)用代碼無需作改變。

現(xiàn)在我們來看看，能不能找一個方法，即使負載突然激增，系統(tǒng)的效率也不會異常下降。

當(dāng)然，最佳目標(biāo)仍然是，即使壓力激增，系統(tǒng)依然能高效運行，并處理盡量多的請求。

為了幫助實現(xiàn)優(yōu)秀的方案，compute-cluster 不僅僅只是管理子進程和傳遞消息，它還管理了其他信息。

它記錄了當(dāng)前運行的子進程數(shù)，以及每個子進程完成的平均時間。

有了這些記錄，我們可以在子進程開啟之前預(yù)測它大概需要多少時間。

據(jù)此，再加上用戶設(shè)置的參數(shù)（max_request_time），我們可以不經(jīng)過處理，直接就關(guān)閉那些可能超時的請求。
 

這個特性讓你可以很容易根據(jù)用戶體驗來確定你的代碼。比如說，“用戶登錄的時候不應(yīng)該等待超過10秒?！边@大概等價于將 max_request_time 設(shè)置為7秒（需要考慮網(wǎng)絡(luò)傳輸時間）。

我們在對 Persona 服務(wù)進行壓力測試后，得到的結(jié)果很讓人滿意。

在壓力極高的情況下，我們依然能為已認證的用戶提供服務(wù)，還阻止了一部分未認證的用戶，并顯示了相關(guān)的錯誤信息。 

最新評論