背景

相信使用 Node.js 開發過 Web 應用的同學一定苦惱過新修改的代碼必須要重啟 Node.js 進程后才能更新的問題。習慣使用 PHP 開發的同學更會非常的不適用，大呼果然還是我大PHP才是世界上最好的編程語言。手動重啟進程不僅僅是非常惱人的重復勞動，當應用規模稍大以后，啟動時間也逐漸開始不容忽視。

當然作為程序猿，無論使用哪種語言，都不會讓這樣的事情折磨自己。解決這類問題最直接和普適的手段就是監聽文件修改并重啟進程。這個方法也已經有很多成熟的解決方案提供了，比如已經被棄坑的 node-supervisor，以及現在比較火的 PM2 ，或者比較輕量級的 node-dev 等等均是這樣的思路。

本文則提供了另外一種思路，只需要很小的改造，就可以實現真正的0重啟熱更新代碼，解決 Node.js 開發 Web 應用時惱人的代碼更新問題。

總體思路

說起代碼熱更新，當下最有名的當屬 Erlang 語言的熱更新功能，這門語言的特色在于高并發和分布式編程，主要的應用場景則是類似證券交易、游戲服務端等領域。這些場景都或多或少要求服務擁有在運行中運維的手段，而代碼熱更新就是其中非常重要的一環，因此我們可以先簡單的了解一下 Erlang 的做法。

由于我也沒有使用過 Erlang ，以下內容均為道聽途說，如果希望深入和準確的了解 Erlang 的代碼熱更新實現，最好還是查閱官方文檔。

Erlang 的代碼加載由一個名為code_server的模塊管理，除了啟動時的一些必要代碼外，大部分的代碼均是由code_server加載。
當code_server發現模塊代碼被更新后，會重新加載模塊，此后的新請求會使用新模塊執行，而原有還在執行的請求則繼續使用老模塊執行。
老模塊會在新模塊加載后，被打上old標簽，新模塊則是current標簽。當下一次熱更新的時候，Erlang 會掃描還在執行老模塊的進行并殺掉，再繼續按照這個邏輯更新模塊。
Erlang 中并非所有代碼均允許熱更新，如 kernel, stdlib, compiler 等基礎模塊默認是不允許更新的
我們可以發現 Node.js 中也有與code_server類似的模塊，即 require 體系，因此 Erlang 的做法應該也可以在 Node.js 上做一些嘗試。通過了解 Erlang 的做法，我們可以大概的總結出在 Node.js 中解決代碼熱更新的關鍵問題點

如何更新模塊代碼
如何使用新模塊處理請求
如何釋放老模塊的資源

那么接下來我們就逐個的解析這些問題點。

如何更新模塊代碼

要解決模塊代碼更新的問題，我們就需要去閱讀 Node.js 的模塊管理器實現，直接上鏈接 module.js。通過簡單的閱讀，我們可以發現核心的代碼就在于 Module._load ，稍微精簡一下代碼貼出來。

// Check the cache for the requested file.// 1. If a module already exists in the cache: return its exports object.// 2. If the module is native: call `NativeModule.require()` with the// filename and return the result.// 3. Otherwise, create a new module for the file and save it to the cache.// Then have it load the file contents before returning its exports// object.Module._load = function(request, parent, isMain) { var filename = Module._resolveFilename(request, parent); var cachedModule = Module._cache[filename]; if (cachedModule) { return cachedModule.exports; } var module = new Module(filename, parent); Module._cache[filename] = module; module.load(filename); return module.exports;};require.cache = Module._cache;

可以發現其中的核心就是 Module._cache ，只要清除了這個模塊緩存，下一次 require 的時候，模塊管理器就會重新加載最新的代碼了。

寫一個小程序驗證一下

// main.jsfunction cleanCache (module) { var path = require.resolve(module); require.cache[path] = null;}setInterval(function () { cleanCache('./code.js'); var code = require('./code.js'); console.log(code);}, 5000);// code.jsmodule.exports = 'hello world';

我們執行一下 main.js ，同時取修改 code.js 的內容，就可以發現控制臺中，我們代碼成功的更新為了最新的代碼。

那么模塊管理器更新代碼的問題已經解決了，接下來再看看在 Web 應用中，我們如何讓新的模塊可以被實際執行。

如何使用新模塊處理請求

為了更符合大家的使用習慣，我們就直接以 Express 為例來展開這個問題，實際上使用類似的思路，絕大部分 Web應用 均可適用。

首先，如果我們的服務是像 Express 的 DEMO 一樣所有的代碼均在同一模塊內的話，我們是無法針對模塊進行熱加載的

var express = require('express');var app = express();app.get('/', function(req, res){ res.send('hello world');});app.listen(3000);

要實現熱加載，和 Erlang 中不允許的基礎庫一樣，我們需要一些無法進行熱更新的基礎代碼控制更新流程。而且類似 app.listen 這類操作如果重新執行了，那么和重啟 Node.js 進程也沒太大的區別了。因此我們需要一些巧妙的代碼將頻繁更新的業務代碼與不頻繁更新的基礎代碼隔離開。

// app.js 基礎代碼var express = require('express');var app = express();var router = require('./router.js');app.use(router);app.listen(3000);// router.js 業務代碼var express = require('express');var router = express .Router();// 此處加載的中間件也可以自動更新router.use(express.static('public'));router.get('/', function(req, res){ res.send('hello world');});module.exports = router;

然而很遺憾，經過這樣處理之后，雖然成功的分離了核心代碼， router.js 依然無法進行熱更新。首先，由于缺乏對更新的觸發機制，服務無法知道應該何時去更新模塊。其次， app.use 操作會一直保存老的 router.js 模塊，因此即使模塊被更新了，請求依然會使用老模塊處理而非新模塊。

那么繼續改進一下，我們需要對 app.js 稍作調整，啟動文件監聽作為觸發機制，并且通過閉包來解決 app.use 的緩存問題

// app.jsvar express = require('express');var fs = require('fs');var app = express();var router = require('./router.js');app.use(function (req, res, next) { // 利用閉包的特性獲取最新的router對象，避免app.use緩存router對象 router(req, res, next);});app.listen(3000);// 監聽文件修改重新加載代碼fs.watch(require.resolve('./router.js'), function () { cleanCache(require.resolve('./router.js')); try {  router = require('./router.js'); } catch (ex) {  console.error('module update failed'); }});function cleanCache(modulePath) { require.cache[modulePath] = null;}

再試著修改一下 router.js 就會發現我們的代碼熱更新已經初具雛形了，新的請求會使用最新的 router.js 代碼。除了修改 router.js 的返回內容外，還可以試試看修改路由功能，也會如預期一樣進行更新。

當然，要實現一個完善的熱更新方案需要更多結合自身方案做一些改進。首先，在中間件的使用上，我們可以在 app.use 處聲明一些不需要熱更新或者說每次更新不希望重復執行的中間件，而在 router.use 處則可以聲明一些希望可以靈活修改的中間件。其次，文件監聽不能僅監聽路由文件，而是要監聽所有需要熱更新的文件。除了文件監聽這種手段外，還可以結合編輯器的擴展功能，在保存時向 Node.js 進程發送信號或者訪問一個特定的 URL 等方式來觸發更新。

如何釋放老模塊的資源

要解釋清楚老模塊的資源如何釋放的問題，實際上需要先了解 Node.js 的內存回收機制，本文中并不準備詳加描述，解釋 Node.js 的內存回收機制的文章和書籍很多，感興趣的同學可以自行擴展閱讀。簡單的總結一下就是當一個對象沒有被任何對象引用的時候，這個對象就會被標記為可回收，并會在下一次GC處理的時候釋放內存。

那么我們的課題就是，如何讓老模塊的代碼更新后，確保沒有對象保持了模塊的引用。首先我們以 如何更新模塊代碼 一節中的代碼為例，看看老模塊資源不回收會出現什么問題。為了讓結果更顯著，我們修改一下 code.js

// code.jsvar array = [];for (var i = 0; i < 10000; i++) { array.push('mem_leak_when_require_cache_clean_test_item_' + i);}module.exports = array;// app.jsfunction cleanCache (module) { var path = require.resolve(module); require.cache[path] = null;}setInterval(function () { var code = require('./code.js'); cleanCache('./code.js');}, 10);

好~我們用了一個非常笨拙但是有效的方法，提高了 router.js 模塊的內存占用，那么再次啟動 main.js 后，就會發現內存出現顯著的飆升，不到一會 Node.js 就提示 process out of memory。然而實際上從 app.js 與 router.js 的代碼中觀察的話，我們并沒發現哪里保存了舊模塊的引用。

我們借助一些 profile 工具如 node-heapdump 就可以很快的定位到問題所在，在 module.js 中我們發現 Node.js 會自動為所有模塊添加一個引用

function Module(id, parent) { this.id = id; this.exports = {}; this.parent = parent; if (parent && parent.children) { parent.children.push(this); } this.filename = null; this.loaded = false; this.children = [];}

因此相應的，我們可以調整一下cleanCache函數，將這個引用在模塊更新的時候一并去除。

// app.jsfunction cleanCache(modulePath) { var module = require.cache[modulePath]; // remove reference in module.parent if (module.parent) {  module.parent.children.splice(module.parent.children.indexOf(module), 1); } require.cache[modulePath] = null;}setInterval(function () { var code = require('./code.js'); cleanCache(require.resolve('./code.js'));}, 10); 

再執行一下，這次好多了，內存只會有輕微的增長，說明老模塊占用的資源已經正確的釋放掉了。

使用了新的 cleanCache 函數后，常規的使用就沒有問題，然而并非就可以高枕無憂了。在 Node.js 中，除了 require 系統會添加引用外，通過 EventEmitter 進行事件監聽也是大家常用的功能，并且 EventEmitter 有非常大的嫌疑會出現模塊間的互相引用。那么 EventEmitter 能否正確的釋放資源呢？答案是肯定的。

// code.jsvar moduleA = require('events').EventEmitter();moduleA.on('whatever', function () {});

當 code.js 模塊被更新，并且所有引用被移出后，只要 moduleA 沒有被其他未釋放的模塊引用， moduleA 也會被自動釋放，包括我們在其內部的事件監聽。

只有一種畸形的 EventEmitter 應用場景在這套體系下無法應對，即 code.js 每次執行的時候都會去監聽一個全局對象的事件，這樣會造成全局對象上不停的掛載事件，同時 Node.js 會很快的提示檢測到過多的事件綁定，疑似內存泄露。

至此，可以看到只要處理好了 require 系統中 Node.js 為我們自動添加的引用，老模塊的資源回收并不是大問題，雖然我們無法做到像 Erlang 一樣實現下一次熱更新對還留存的老模塊進行掃描這樣細粒度的控制，但是我們可以通過合理的規避手段，解決老模塊資源釋放的問題。

在 Web 應用下，還有一個引用問題就是未釋放的模塊或者核心模塊對需要熱更新的模塊有引用，如 app.use，導致老模塊的資源無法釋放，并且新的請求無法正確的使用新模塊進行處理。解決這個問題的手段就是控制全局變量或者引用的暴露的入口，在熱更新執行的過程中手動更新入口。如 如何使用新模塊處理請求 中對 router 的封裝就是一個例子，通過這一個入口的控制，我們在 router.js 中無論如何引用其他模塊，都會隨著入口的釋放而釋放。

另一個會引起資源釋放問題的就是類似 setInterval 這類操作，會保持對象的生命周期無法釋放，不過在 Web 應用中我們極少會使用這類技術，因此方案中并未關注。

尾聲

至此，我們就解決了 Node.js 在 Web 應用下代碼熱更新的三大問題，不過由于 Node.js 本身缺乏對有效的留存對象的掃描機制，因此并不能100%的消除類似 setInterval 導致的老模塊的資源無法釋放的問題。也是由于這樣的局限性，目前我們提供的 YOG2 框架中，主要還是將此技術應用于開發調試期，通過熱更新實現快速開發。而生產環境的代碼更新依然使用重啟或者 PM2 的 hot reload 功能來保證線上服務的穩定性。

由于熱更新實際上與框架和業務架構緊密相關，因此本文并未給出一個通用的解決方案。作為參考，簡單的介紹一下在 YOG2 框架中我們是如何使用這項技術的。由于 YOG2 框架本身就支持前后端子系統 App 拆分，因此我們的更新策略是以 App 為粒度更新代碼。同時由于類似 fs.watch 這類操作會有兼容性問題，一些替代方案如 fs.watchFile 則會比較消耗性能，因此我們結合了 YOG2 的測試機部署功能，通過上傳部署新代碼的形式告知框架需要更新 App 代碼。在以 App 為粒度更新模塊緩存的同時，會更新路由緩存與模板緩存，來完成所有代碼的更新工作。

如果你使用的是類似 Express 或者 Koa 這類框架，只需要按照文中的方法結合自身業務需要，對主路由進行一些改造，就可以很好的應用這項技術。