資訊專欄INFORMATION COLUMN
摘要：概述相信很多的人，每天在終端不止一遍的執(zhí)行著這條命令，對于很多人來說，它就像一個黑盒，并不知道背后到底發(fā)生了什么，本文將會為大家揭開這個神秘的面紗，由于本人水平有限，所以只是講一個大概其，主要關(guān)注的過程就是模塊的初始化，和的部分基本沒有深入
概述
相信很多的人，每天在終端不止一遍的執(zhí)行著node這條命令，對于很多人來說，它就像一個黑盒，并不知道背后到底發(fā)生了什么，本文將會為大家揭開這個神秘的面紗，由于本人水平有限，所以只是講一個大概其，主要關(guān)注的過程就是node模塊的初始化，event loop和v8的部分基本沒有深入，這些部分可以關(guān)注一下我以后的文章。（提示本文非常的長，希望大家不要看煩~）
node是什么？這個問題很多人都會回答就是v8 + libuv，但是除了這個兩個庫以外node還依賴許多優(yōu)秀的開源庫，可以通過process.versions來看一下：
http_parser主要用于解析http數(shù)據(jù)包的模塊，在這個庫的作者也是ry，一個純c的庫，無任何依賴
v8這個大家就非常熟悉了，一個優(yōu)秀的js引擎
uv這個就是ry實(shí)現(xiàn)的libuv，其封裝了libev和IOCP，實(shí)現(xiàn)了跨平臺，node中的i/o就是它，盡管js是單線程的，但是libuv并不是，其有一個線程池來處理這些i/o操作。
zlib主要來處理壓縮操作，諸如熟悉的gzip操作
ares是c-ares，這個庫主要用于解析dns，其也是異步的
modules就是node的模塊系統(tǒng)，其遵循的規(guī)范為commonjs，不過node也支持了ES模塊，不過需要加上參數(shù)并且文件名后綴需要為mjs，通過源碼看，node將ES模塊的名稱作為了一種url來看待，具體可以參見這里
nghttp2如其名字一樣，是一個http2的庫
napi是在node8出現(xiàn)，node10穩(wěn)定下來的，可以給編寫node原生模塊更好的體驗(yàn)（終于不用在依賴于nan，每次更換node版本還要重新編譯一次了）
openssl非常著名的庫，tls模塊依賴于這個庫，當(dāng)然還包括https
icu就是small-icu，主要用于解決跨平臺的編碼問題，versions對象中的unicode，cldr，tz也源自icu，這個的定義可以參見這里
從這里可以看出的是process對象在node中非常的重要，個人的理解，其實(shí)node與瀏覽器端最主要的區(qū)別，就在于這個process對象
注：node只是用v8來進(jìn)行js的解析，所以不一定非要依賴v8，也可以用其他的引擎來代替，比如利用微軟的ChakraCore，對應(yīng)的node倉庫
node初始化經(jīng)過上面的一通分析，對node的所有依賴有了一定的了解，下面來進(jìn)入正題，看一下node的初始化過程：
挖坑node_main.cc為入口文件，可以看到的是除了調(diào)用了node::Start之外，還做了兩件事情：
NODE_SHARED_MODE忽略SIGPIPE信號SIGPIPE信號出現(xiàn)的情況一般在socket收到RST packet之后，扔向這個socket寫數(shù)據(jù)時產(chǎn)生，簡單來說就是client想server發(fā)請求，但是這時候client已經(jīng)掛掉，這時候就會產(chǎn)生SIGPIPE信號，產(chǎn)生這個信號會使server端掛掉，其實(shí)node::PlatformInit中也做了這種操作，不過只是針對non-shared lib build
改變緩沖行為stdout的默認(rèn)緩沖行為為_IOLBF（行緩沖），但是對于這種來說交互性會非常的差，所以將其改為_IONBF（不緩沖）
探索node.cc文件中總共有三個Start函數(shù)，先從node_main.cc中掉的這個Start函數(shù)開始看：
int Start(int argc, char** argv) {
// 退出之前終止libuv的終端行為,為正常退出的情況
atexit([] () { uv_tty_reset_mode(); });
// 針對平臺進(jìn)行初始化
PlatformInit();
// ...
Init(&argc, const_cast(argv), &exec_argc, &exec_argv);
// ...
v8_platform.Initialize(v8_thread_pool_size);
// 熟悉的v8初始化函數(shù)
V8::Initialize();
// ..
const int exit_code =
Start(uv_default_loop(), argc, argv, exec_argc, exec_argv);
}
上面函數(shù)只保留了一些關(guān)鍵不走，先來看看PlatformInit
PlatfromInitunix中將一切都看作文件，進(jìn)程啟動時會默認(rèn)打開三個i/o設(shè)備文件，也就是stdin stdout stderr，默認(rèn)會分配0 1 2三個描述符出去，對應(yīng)的文件描述符常量為STDIN_FILENO STDOUT_FILENO STDERR_FILENO，而windows中沒有文件描述符的這個概念，對應(yīng)的是句柄，PlatformInit首先是檢查是否將這個三個文件描述符已經(jīng)分配出去，若沒有，則利用open("/dev/null", O_RDWR)分配出去，對于windows做了同樣的操作，分配句柄出去，而且windows只做了這一個操作；對于unix來說還會針對SIGINT（用戶調(diào)用Ctrl-C時發(fā)出）和SIGTERM（SIGTERM與SIGKILL類似,但是不同的是該信號可以被阻塞和處理,要求程序自己退出）信號來做一些特殊處理，這個處理與正常退出時一樣；另一個重要的事情就是下面這段代碼：
struct rlimit lim;
// soft limit 不等于 hard limit, 意味著可以增加
if (getrlimit(RLIMIT_NOFILE, &lim) == 0 && lim.rlim_cur != lim.rlim_max) {
// Do a binary search for the limit.
rlim_t min = lim.rlim_cur;
rlim_t max = 1 << 20;
// But if there"s a defined upper bound, don"t search, just set it.
if (lim.rlim_max != RLIM_INFINITY) {
min = lim.rlim_max;
max = lim.rlim_max;
}
do {
lim.rlim_cur = min + (max - min) / 2;
// 對于mac來說 hard limit 為unlimited
// 但是內(nèi)核有限制最大的文件描述符,超過這個限制則設(shè)置失敗
if (setrlimit(RLIMIT_NOFILE, &lim)) {
max = lim.rlim_cur;
} else {
min = lim.rlim_cur;
}
} while (min + 1 < max);
}
這個件事情也就是提高一個進(jìn)程允許打開的最大文件描述符，但是在mac上非常的奇怪，執(zhí)行ulimit -H -n得到hard limit是unlimited，所以我認(rèn)為mac上的最大文件描述符會被設(shè)置為1 << 20，但是最后經(jīng)過實(shí)驗(yàn)發(fā)現(xiàn)最大只能為24576，非常的詭異，最后經(jīng)過一頓搜索，查到了原來mac的內(nèi)核對能打開的文件描述符也有限制，可以用sysctl -A | grep kern.maxfiles進(jìn)行查看，果然這個數(shù)字就是24576
Init函數(shù)調(diào)用了RegisterBuiltinModules：
// node.cc
void RegisterBuiltinModules() {
#define V(modname) _register_##modname();
NODE_BUILTIN_MODULES(V)
#undef V
}
// node_internals.h
#define NODE_BUILTIN_MODULES(V)
NODE_BUILTIN_STANDARD_MODULES(V)
NODE_BUILTIN_OPENSSL_MODULES(V)
NODE_BUILTIN_ICU_MODULES(V)
從名字也可以看出上面的過程是進(jìn)行c++模塊的初始化，node利用了一些宏定義的方式，主要關(guān)注NODE_BUILTIN_STANDARD_MODULES這個宏：
#define NODE_BUILTIN_STANDARD_MODULES(V)
V(async_wrap)
V(buffer)
...
結(jié)合上面的定義，可以得出編譯后的代碼大概為：
void RegisterBuiltinModules() {
_register_async_wrap();
_register_buffer();
}
而這些_register又是從哪里來的呢？以buffer來說，對應(yīng)c++文件為src/node_buffer.cc，來看這個文件的最后一行，第二個參數(shù)是模塊的初始化函數(shù)：
NODE_BUILTIN_MODULE_CONTEXT_AWARE(buffer, node::Buffer::Initialize)
這個宏存在于node_internals.h中：
#define NODE_MODULE_CONTEXT_AWARE_CPP(modname, regfunc, priv, flags)
static node::node_module _module = {
NODE_MODULE_VERSION,
flags,
nullptr,
__FILE__,
nullptr,
(node::addon_context_register_func) (regfunc),// 暴露給js使用的模塊的初始化函數(shù)
NODE_STRINGIFY(modname),
priv,
nullptr
};
void _register_ ## modname() {
node_module_register(&_module);
}
#define NODE_BUILTIN_MODULE_CONTEXT_AWARE(modname, regfunc)
NODE_MODULE_CONTEXT_AWARE_CPP(modname, regfunc, nullptr, NM_F_BUILTIN)
發(fā)現(xiàn)調(diào)用的_register_buffer實(shí)質(zhì)上調(diào)用的是node_module_register(&_module)，每一個c++模塊對應(yīng)的為一個node_module結(jié)構(gòu)體，再來看看node_module_register發(fā)生了什么：
extern "C" void node_module_register(void* m) {
struct node_module* mp = reinterpret_cast(m);
if (mp->nm_flags & NM_F_BUILTIN) {
mp->nm_link = modlist_builtin;
modlist_builtin = mp;
}
...
}
由此可以見，c++模塊被存儲在了一個鏈表中，后面process.binding()本質(zhì)上就是在這個鏈表中查找對應(yīng)c++模塊，node_module是鏈表中的一個節(jié)點(diǎn)，除此之外Init還初始化了一些變量，這些變量基本上都是取決于環(huán)境變量用getenv獲得即可
v8初始化到執(zhí)行完Init為止，還沒有涉及的js與c++的交互，在將一些環(huán)境初始化之后，就要開始用v8這個大殺器了，v8_platform是一個結(jié)構(gòu)體，可以理解為是node對于v8的v8::platform一個封裝，緊接著的就是對v8進(jìn)行初始化，自此開始具備了與js進(jìn)行交互的能力，初始化v8之后，創(chuàng)建了一個libuv事件循環(huán)就進(jìn)入了下一個Start函數(shù)
第二個Start函數(shù)inline int Start(uv_loop_t* event_loop,
int argc, const char* const* argv,
int exec_argc, const char* const* exec_argv) {
std::unique_ptr
allocator(CreateArrayBufferAllocator(), &FreeArrayBufferAllocator);
Isolate* const isolate = NewIsolate(allocator.get());
// ...
{
Locker locker(isolate);
Isolate::Scope isolate_scope(isolate);
HandleScope handle_scope(isolate);
}
}
首先創(chuàng)建了一個v8的Isolate（隔離），隔離在v8中非常常見，仿佛和進(jìn)程一樣，不同隔離不共享資源，有著自己得堆棧，但是正是因?yàn)檫@個原因在多線程的情況下，要是對每一個線程都創(chuàng)建一個隔離的話，那么開銷會非常的大（可喜可賀的是node有了worker_threads），這時候可以借助Locker來進(jìn)行同步，同時也保證了一個Isolate同一時刻只能被一個線程使用；下面兩行就是v8的常規(guī)套路，下一步一般就是創(chuàng)建一個Context（最簡化的一個流程可以參見v8的hello world），HandleScope叫做句柄作用域，一般都是放在函數(shù)的開頭，來管理函數(shù)創(chuàng)建的一些句柄（水平有限，暫時不深究，先挖個坑）；第二個Start的主要流程就是這個，下面就會進(jìn)入最后一個Start函數(shù)，這個函數(shù)可以說是非常的關(guān)鍵，會揭開所有的謎題
解開謎題inline int Start(Isolate* isolate, IsolateData* isolate_data,
int argc, const char* const* argv,
int exec_argc, const char* const* exec_argv) {
HandleScope handle_scope(isolate);
// 常規(guī)套路
Local context = NewContext(isolate);
Context::Scope context_scope(context);
Environment env(isolate_data, context, v8_platform.GetTracingAgentWriter());
env.Start(argc, argv, exec_argc, exec_argv, v8_is_profiling);
// ...
可以見到v8的常見套路，創(chuàng)建了一個上下文，這個上下文就是js的執(zhí)行環(huán)境，Context::Scope是用來管理這個Context，Environment可以理解為一個node的運(yùn)行環(huán)境，記錄了isolate,event loop等，Start的過程主要是做了一些libuv的初始化以及process對象的定義：
auto process_template = FunctionTemplate::New(isolate());
process_template->SetClassName(FIXED_ONE_BYTE_STRING(isolate(), "process"));
auto process_object =
process_template->GetFunction()->NewInstance(context()).ToLocalChecked();
set_process_object(process_object);
SetupProcessObject(this, argc, argv, exec_argc, exec_argv);
SetupProcessObject生成了一個c++層面上的process對象，這個已經(jīng)基本上和平時node中的process對象一致，但是還會有一些出入，比如沒有binding等，完成了這個過程之后就開始了LoadEnvironment
LoadEnvironmentLocalloaders_name = FIXED_ONE_BYTE_STRING(env->isolate(), "internal/bootstrap/loaders.js"); MaybeLocal loaders_bootstrapper = GetBootstrapper(env, LoadersBootstrapperSource(env), loaders_name); Local node_name = FIXED_ONE_BYTE_STRING(env->isolate(), "internal/bootstrap/node.js"); MaybeLocal node_bootstrapper = GetBootstrapper(env, NodeBootstrapperSource(env), node_name);
先將lib/internal/bootstrap文件夾下的兩個文件讀進(jìn)來，然后利用GetBootstrapper來執(zhí)行js代碼分別得到了一個函數(shù)，一步步來看，先看看GetBootstrapper為什么可以執(zhí)行js代碼，查看這個函數(shù)可以發(fā)現(xiàn)主要是因?yàn)?b>ExecuteString：
