本文介绍 Node.js 中,关于进程、线程调试和诊断的相关内容。进程和线程的方案类似,但是也有一些不一样的地方,本文将会分开介绍,另外本文介绍的是对业务代码无侵入的方案,通过命令行开启 Inspector 端口或者在代码里通过 Inspector 模块打开端口在很多场景下并不适用,我们需要的是一种动态控制的能力。
随着前端的快速发展,Node.js 在业务中的使用场景也越来越多,如何保证 Node.js 服务的稳定也逐渐成为一个非常重要事情,传统的服务器架构大多数基于多进程、多线程的,任务的执行是隔离的,一个任务出现问题通常不会影响其他任务,比如在一个请求中执行一个死循环,服务器还能处理其他的请求。
但是 Node.js 不一样,从整体来看,Node.js 是单线程的,单个任务出现问题有可能会影响其他任务,比如在一个请求中执行了死循环,那么整个服务就没法继续工作了。所以在 Node.js 中,我们更加需要方便的调试和诊断工具,以便遇到问题时可以快速找到问题,解决问题,另外,工具不仅可以帮我们排查问题,还可以找出我们服务中的性能瓶颈,方便我们进行性能优化。
我们基于 Node.js 本身提供的调试和诊断能力,提供一个调试和诊断平台,使用方只需要引入 SDK,然后通过调试和诊断平台就可以对服务的进程和线程进行调试和诊断。
目前支持了多进程和多线程的调试和诊断,下面按照进程和线程两个方面介绍一下原理和具体实现。
在 Node.js 中,可以通过以下方式收集进程的数据。
const inspector = require('inspector');
const session = new inspector.Session();
session.connect();
// 发送命令
session.post('Profiler.enable', () => {});
使用方式很简单,通过新建一个和 V8 Inspector 通信的 Session 就可以对进程进行数据的收集,比如抓取进程的堆快照和 Profile 数据。有了这个基础后,我们就可以封装这个能力。
const http = require('http');
const inspector = require('inspector');
const fs = require('fs');
// 打开一个和 V8 Inspector 的会话
const session = new inspector.Session();
session.connect();
function getCpuprofile(req, res) {
// 向V8 Inspector 提交命令,开启 CPU Profile 并收集数据
session.post('Profiler.enable', () = >{
session.post('Profiler.start', () = >{
// 收集一段时间后提交停止收集命令
setTimeout(() = >{
session.post('Profiler.stop', (err, { profile }) = >{
// 把数据写入文件
if (!err && profile) {
fs.writeFileSync('./profile.cpuprofile', JSON.stringify(profile));
}
// 回复客户端
res.end('ok');
});
},
3000);
})
});
}
http.createServer((req, res) = >{
if (req.url == '/debug/getCpuprofile') {
getCpuprofile(req, res);
} else {
res.end('ok');
}
}).listen(80);
但是这种方式不能调试进程,调试进程需要使用另外的 api,可以通过以下方式启动调试进程的服务。
const inspector = require('inspector');
inspector.open();
console.log(inspector.url());
这时候 Node.js 进程中就会启动一个 WebSocket Server,我们可以通过 Chrome Dev Tools 连上这个 Server 进行调试,我们看看如何封装。
const inspector = require('inspector');
const http = require('http');
let isOpend = false;
function gethtml() {
return `<html>
<meta charset="utf-8" />
<body>
复制到新 Tab 打开该 URL 开始调试 devtools://devtools/bundled/js_app.html?experiments=true&v8only=true&ws=${inspector.url().replace("ws://", '')}
</body>
</html>`;
}
http.createServer((req, res) = >{
if (req.url == '/debug/open') {
// 还没开启则开启
if (!isOpend) {
isOpend = true;
// 打开调试器
inspector.open();
}
// 返回给前端的内容
const html = getHTML();
res.end(html);
} else if (req.url == '/debug/close') {
// 如果开启了则关闭
if (isOpend) {
inspector.close();
isOpend = false;
}
res.end('ok');
} else {
res.end('ok');
}
}).listen(80);
我们以 API 的方式对外提供动态控制进程调试和诊断的能力,具体的实现可以根据场景去修改,比如给前端返回一个不带 Inspector 端口的 URL,前端再通过 URL 访问服务,服务代理请求 Websocket 请求到 Inspector 对应的 WebSocket 服务。比如把收集的数据上传到云上,给前端返回一个 URL。
我们通过 API 的方式提供功能,设计上采用插件化的思想,主框架负责接收请求和路由处理,具体的逻辑交给具体的插件去做,结构如下所示。
数据收集的实现和上面的例子中类似,收到请求路由到对应的插件,插件通过 Session 和 V8 Inspector 通信完成数据的收集。调试的实现就稍微复杂些,主要的原因是我们不能把端口返回给前端,让前端直接连接该端口。这个不是因为安全问题,因为调试的 URL 是一个带有一个复杂随机值的字符串,就算端口暴露了,攻击者也很难猜对随机值,相比来说,通过提供 API 的方式更加不安全,因为只要知道服务的地址,就可以通过 API 去调试进程了,所以严格来说,这里还需要加一些校验机制。言归正传,不暴露端口的原因是通常前端无法直接连接到这个端口,原因可能有很多,比如我们的服务运行在容器中,容器只对外暴露有限的端口,我们不能期待在进程中随便起一个端口,在前端就可以直接访问,但是有一个可以肯定的是,服务至少会对外提供一个端口,那就意味着我们可以通过某个对外的端口把非业务相关的请求传递到进程内,基于上面的情况,当我们打开 Inspector 端口时,我们只会告诉前端打开成功或者失败,当前端通过调试 API 访问服务器时,我们会判断端口是否已经打开,是的话代理请求到 WebSocket Server。结构设计如下:
大致实现如下:
const client = connect(WebSocket Server地址);
client.on('connect', () = >{
// 转发协议升级的 HTTP 请求给 WebSocket Server
client.write(`GET ${req.path} HTTP/1.1\r\n` + buildHeaders(req.headers) + '\r\n');
// 透传
socket.pipe(client);
client.pipe(socket);
});
收到客户的的请求后,首先连接到 WebSocket Server,然后透传客户端的请求,接着通过管道让 WebSocket Server 和客户端通信就行。
为了利用多核,Node.js 服务通常会启动多个进程,所以支持多进程的调试和诊断也是非常必要的。但是单进程的调试诊断方案无法通过横行拓展来支持多进程的场景。
前面提到的方式看起来工作得不错,但是如果服务是单实例上多进程部署,就会存在一些限制。我们来看看这时候的结构:
假如我们只有一个对外端口:
一种解决方案是每个进程监听不同的端口,这样又回到了前面讨论到问题,但是这种方案也不是完全不可行,只需要基于这个方案做一下改进,那就是引入 Agent 进程,这时候结构如下:
Agent 进程负责收集和管理工作进程的信息(如 pid、监听地址),并接管所有调试和诊断相关的请求,收到请求后根据参数进行请求分发。具体流程如下:
确定了 Agent 进程的方案后,如何创建 Agent 进程成为一个需要解决的问题。在 Node.js 里启动多个服务器的方式是通过 Cluster 或者直接通过 child_process 模块 fork 出多个子进程,Node.js 框架/工具通常都会封装这些逻辑,但是框架不一定会提供创建 Agent 进程的方式。为了通用,我们不能假设运行在某种框架/工具中,所以我们只能寻找一种独立于框架/工具的方案。我们在每个 Worker 进程里都创建一个 Agent 进程,然后多个 Agent 进程竞争监听一个端口,监听成功的进程继续运行,监听失败的退出,最终剩下一个 Agent 进程。
线程和进程的调试、诊断类似,下面主要讲一下不一样的地方。
可以通过以下方式收集线程的数据。
const { Worker, workerData } = require('worker_threads');
const { Session } = require('inspector');
const session = new Session();
session.connect();
let id = 1;
// 给子线程发送消息
function post(sessionId, method, params, callback) {
session.post('NodeWorker.sendMessageToWorker', {
sessionId,
message: JSON.stringify({
id: id++,
method,
params
})
},
callback);
}
// 子线程连接上 V8 Inspector 后触发
session.on('NodeWorker.attachedToWorker', (data) = >{
post(data.params.sessionId, 'Profiler.enable');
post(data.params.sessionId, 'Profiler.start');
// 收集一段时间后提交停止收集命令
setTimeout(() = >{
post(data.params.sessionId, 'Profiler.stop');
},
10000)
});
// 收到子线程消息时触发
session.on('NodeWorker.receivedMessageFromWorker', ({ params: { message } }) = >{});
const worker = new Worker('./httpServer.js', { workerData: { port: 80 } });
worker.on('online', () = >{
session.post("NodeWorker.enable", { waitForDebuggerOnStart: false }, (err) = >{
console.log(err, "NodeWorker.enable");
});
});
setInterval(() = >{},100000);
类似通过 Agent 进程管理多个 Worker 进程一样,因为一个进程中可能存在多个线程,所以需要对多个线程进行管理。首先通过 NodeWorker.enable 命令开启子线程的 Inspector 能力,然后通过 NodeWorker.attachedToWorker 事件拿到线程对应的 sessionId,后续通过 sessionId 和线程进行通信。接着看一下调试的实现:
const { Worker, workerData } = require('worker_threads');
const { Session } = require('inspector');
const session = new Session();
session.connect();
let workerSessionId;
let id = 1;
function post(method, params) {
session.post('NodeWorker.sendMessageToWorker', {
sessionId: workerSessionId,
message: JSON.stringify({
id: id++,
method,
params
})
});
}
session.on('NodeWorker.receivedMessageFromWorker', ({ params: { message } }) = >{
const data = JSON.parse(message);
console.log(data);
});
session.on('NodeWorker.attachedToWorker', (data) = >{
workerSessionId = data.params.sessionId;
post("Runtime.evaluate", {
includeCommandLineAPI: true,
expression: `const inspector = process.binding('inspector');
inspector.open();
inspector.url();
`
});
});
const worker = new Worker('./httpServer.js', { workerData: { port: 80 } });
worker.on('online', () = >{
session.post("NodeWorker.enable", { waitForDebuggerOnStart: false }, (err) = >{
err && console.log("NodeWorker.enable", err);
});
});
setInterval(() = >{}, 100000);
线程的调试主要利用 Runtime.evaluate 在子线程里动态执行代码来打开子线程的 Inspector 端口。了解了基础使用后,我们看一下具体实现。
首先我们提供一个 API 获取线程列表,这样我们后续就可以选择操作某个线程,后续的每个请求都需要带上 线程对应的 id,这里以获取 Profile 为例讲一下处理过程。
const {
sessionId,
interval = INTERVAL,
duration = DURATION
} = req.query;
// 向V8 Inspector 提交命令,开启 CPU Profile 并收集数据
this.post(sessionId, { method: 'Profiler.enable' }, (err) = >{
this.post(sessionId, {
method: 'Profiler.setSamplingInterval',
params: { interval }
});
this.post(sessionId, { method: 'Profiler.start' }, (err) = >{
// 收集一段时间后提交停止收集命令
setTimeout(() = >{
this.post(sessionId, { method: 'Profiler.stop' }, (err, { profile }) => {});
}, duration);
});
})
我们看到每一个操作都需要 sessionId。通过 sessionId,我们把请求转发到对应的线程。但是和进程不一样,进程发送一个请求时传入一个回调,请求成功后就会执行对应的回调,我们不需要保存请求上下文,Node.js 会帮我们处理,但是线程不一样,存在一个嵌套的过程,因为 Inspector 命令的执行模式是一个请求命令对应一个回调,但是和线程通信时,是首选通过 NodeWorker.sendMessageToWorker 命令和主线程通信,主线程会解析出 NodeWorker.sendMessageToWorker 的参数,参数里包含了给子线程发送的命令,接着主线程通过 sessionId 把请求转发到子线程,然后这时候 NodeWorker.sendMessageToWorker 就会返回并执行对应的回调,这时候意味着 NodeWorker.sendMessageToWorker 执行结束了,但是我们请求子线程的命令还没有完成,也就是说我们需要自己维护请求子线程对应的回调。我们看看 post 的具体实现:
post(sessionId, message, callback ? ) {
// 请求对应的 id
const requestId = ++this.id;
this.session.post('NodeWorker.sendMessageToWorker', {
sessionId,
message: JSON.stringify({ ...message, id: requestId })
},
(err) = >{
/*
回调说明 NodeWorker.sendMessageToWorker 请求完成
err非空说明请求失败,直接执行回调
err为空说明请求成功,记录 post 调用方的请求回调,通过 id 关联
*/
if (typeof callback === 'function') {
// 发送失败则直接执行回调,成功则记录回调
if (err) {
callback(err);
} else {
this.sessionMap[sessionId]['requests'][requestId] = callback;
}
}
});
}
我们看到在 NodeWorker.sendMessageToWorker 回调里保存了请求子线程的回调。接下来我们看一下线程执行完命令后的回调。
this.session.on('NodeWorker.receivedMessageFromWorker', ({
params: {
sessionId,
message
}
}) = >{
const ctx = this.sessionMap[sessionId];
try {
const data = JSON.parse(message);
/**
* data 的内容格式如下:
* {
* method: string,
* params: Object
* }
* 或者
* {
* id: number,
* result: { result: Object }
* }
*/
const {
id,
method,
result
} = data;
// 有 id 说明是请求对应的响应,没有 id 说明是 Inspector 异步触发的事件
if (id) {
if (typeof ctx.requests[id] === 'function') {
const fn = ctx.requests[id];
delete ctx.requests[id];
fn(null, result);
}
} else {
ctx.emit(method, data);
}
} catch(e) {
console.warn(e);
}
});
通过 NodeWorker.receivedMessageFromWorker 事件可以接收到线程返回的请求结果,从响应的数据中我们可以知道这个响应来自的线程和请求 id,根据这些信息我们就可以从维护的上下文中找到对应的回调(某些请求在收到响应前会触发一些事件,这种情况下响应里是没有请求 id 的)。
接着看一下如何调试子线程,调试端口默认是 9229,因为存在多线程,如果我们要同时调试多个线程的话,则会失败,所以我们要允许前端来控制打开的端口,接着给子线程发送一个命令。
this.post(query.sessionId, {
method: "Runtime.evaluate",
params: {
includeCommandLineAPI: true,
expression: `let inspector;
try {
inspector = require('inspector');
inspector.open(${port}, ${host});
} catch(e) {
inspector = process.binding('inspector');
inspector.open(${port}, ${host});
}
inspector.url();`
}
},
(err, result) = >{
});
我们通过在子线程里动态执行代码来打开 Inspector 端口,这里需要处理一下不同 Node.js 版本的兼容问题,高版本(比如 16)中增加了一个判断逻辑,如果存在 session 就无法动态打开 Inspector 端口了,比如以下代码在 16 中会报错(换一下 connect 和 open 的位置就可以执行)。
const inspector = require('inspector');
const session = new inspector.Session();
session.connect();
inspector.open()
这里需要绕过 JS 层的判断,通过 C++ 模块提供的接口直接打开 Inspector 端口,这样就可以保证任何时候我们都可以动态打开 Inspector 端口。最后通过 inspector.url() 让子线程返回调试的 URL 并保存到上下文中,和进程一样,前端也是通过 API 的方式连接子线程的 WebSocket Server。最后形成的结构如下。
目前支持了多个子进程和多个线程的调试、获取 CPU Profile、获取 Heap Profile、获取 Heap Snapshot、获取内存信息(RSS、堆外内存、ArrayBuffer等信息)能力。使用方首先在业务代码里加载 SDK,部署服务后,进入调试诊断平台页面,按照以下步骤操作:
进程:
线程:
进程、线程的调试和诊断在 Node.js 中的实现非常复杂,了解了 Node.js 的实现和使用方式后,具体应用到业务里也不容易,主要是要考虑到不同的业务场景,需要设计出通用的方案,另外调试是一个比较有用但是也比较危险的操作,在安全方面也需要多多考虑。调试、诊断和安全一样,平时用不上,但是有问题的时候,能帮助我们更好地解决问题。
更多内容参考:
原文来自:https://mp.weixin.qq.com/s/frlfZ9iRNyAMMN_m1rS8Zw
关于 Node.js 里 ES6 Modules 的一次更新说明,总结来说:CommonJS 与 ES6 Modules 之间的关键不同在于代码什么时候知道一个模块的结构和使用它。
在这个教程中,我们会开发一个命令行应用,它可以接收一个 CSV 格式的用户信息文件,教程的内容大纲:“Hello,World”,处理命令行参数,运行时的用户输入,异步网络会话,美化控制台的输出,封装成 shell 命令,JavaScript 之外
首先你需要生成https证书,可以去付费的网站购买或者找一些免费的网站,可能会是key或者crt或者pem结尾的。不同格式之间可以通过OpenSSL转换
nodej项目在微信环境开发,nodejs的异步特效,会导致请求没有完成就执行下面的代码,出现错误。经过多方查找,可以使用async模块来异步转同步,只有前一个function执行callback,下一个才会执行。
3G的大文件分1500个2M二进度文件,通post方法发送给node服务,服务器全部接收到文件后,进组装生成你上文件。
JavaScript比C的开发门槛要低,尽管服务器端JavaScript存在已经很多年了,但是后端部分一直没有市场,JavaScript在浏览器中有广泛的事件驱动方面的应用,考虑到高性能、符合事件驱动、没有历史包袱这3个主要原因,JavaScript成为了Node的实现语言。
node.js的第一个基本论点是I / O的性能消耗是很昂贵。因此,使用当前编程技术的最大浪费来自于等待I / O完成。有几种方法可以处理性能影响
在前后端分离的开发中,通过 Restful API 进行数据交互时,如果没有对 API 进行保护,那么别人就可以很容易地获取并调用这些 API 进行操作。那么服务器端要如何进行鉴权呢?
我们经常跟Node.js打交道,即使你是一名前端开发人员 -- npm脚本,webpack配置,gulp任务,程序打包 或 运行测试等。即使你真的不需要深入理解这些任务,但有时候你会感到困惑,会因为缺少Node.js的一些核心概念而以非常奇怪的方式来编码。
运行在 Node.js 之上的 Webpack 是单线程模型的,也就是说 Webpack 需要处理的任务需要一件件挨着做,不能多个事情一起做。happypack把任务分解给多个子进程去并发的执行,子进程处理完后再把结果发送给主进程。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!