Node.js 技术原理分析系列——将 Node.js 内置模块外置
Node.js 是一个开源的、跨平台的JavaScript运行时环境,它允许开发者在服务器端运行JavaScript代码。Node.js 是基于Chrome V8引擎构建的,专为高性能、高并发的网络应用而设计,广泛应用于构建服务器端应用程序、网络应用、命令行工具等。
本系列将分为9篇文章为大家介绍 Node.js 技术原理:从调试能力分析到内置模块新增,从性能分析工具 perf_hooks 的用法到 Chrome DevTools 的性能问题剖析,再到 ABI 稳定的理解、基于 V8 封装 JavaScript 运行时、模块加载方式探究、内置模块外置以及 Node.js addon 的全面解读等主题,每一篇都干货满满。
在上一节中我们探讨了Node.js模块加载方式分析的相关内容,在本节中则主要分享《Node.js内置模块外置》相关内容,本文内容为本系列第8篇,由体验技术团队屈金雄原创,以下为正文内容。
前言
本人最近的工作涉及 Node.js 的定制开发,直白点说就是,需要修改 Node.js 源码。
一般来说,Node.js 源码修改后,需要重新构建才能生效。如果频繁修改,频繁构建,就很费时间。
这时,我们可以用内置模块外置这种办法,避免重新构建。
什么叫内置模块外置?
我们知道 node 源码主要是由 C++ 和 js 两部分组成。其中 js 代码都在 lib 目录下。
普通方式构建的 node,lib 代码是打包到构建产物中的。node 工程运行时,所用的 js 源码也取自构建产物。如果修改了 lib 代码,只有重新构建才能生效。
为了方便开发和调试,我们在进行 node 构建配置的时候可使用 --node-builtin-modules-path 参数。
./configure --node-builtin-modules-path "$(pwd)"
有了这个参数,构建产物不会包含 lib 代码。node 工程运行需要导入 lib 中的 js 模块时,会从构建时指定的目录查找,在示例中就是运行./configure 命令的目录(pwd)。
这样我们就将 lib 下的 js 代码外置了。
内置模块是 node 的一部分,有些是纯 js 的,有些外层是 js,底层是 C++。其 js 代码自然也都在 lib 目录下。所以本节讲的 lib 代码外置,同样适用于内置模块的 js 代码。
当我们将内置模块的 js 代码外置时,就是将内置模块外置。
构建 lib 外置的 node
关于 node 构建,请参考官方文档的 BUILDING.md 文件,这里只是简单列出主要步骤。
以 Ubuntu 操作系统为例,简明构建过程如下:
// 1.环境准备 apt install python3 g++ make python3-pip // 2.清除旧版配置(源码准备步骤已省略) make clean // 3.配置 ./configure --node-builtin-modules-path "$(pwd)" // 4.构建 make -j32
验证外置 lib 是否生效
按步骤进行如下操作:
- 准备一个待运行的 node 工程
创建一个单文件 node 工程,命名为 test.js,代码如下。
为方便起见,将 test.js 直接放在 node 源码的根目录下。
// test.js const { createServer } = require('node:http'); const hostname = '127.0.0.1'; const port = 3000; const server = createServer((req, res) => { res.statusCode = 200; res.setHeader('Content-Type', 'text/plain'); res.end('Hello World'); }); server.listen(port, hostname, async () => { console.log(`Server running at http://${hostname}:${port}/`); });
- 更改 http 模块的 createServer 方法的 js 源码,如下图!
- 运行
如图所示,先用了安装在环境中的普通版本 node,运行 test.js,没有额外的打印信息;然后用外置标准库版本的 node 运行 test.js,打印出了预期的信息,而我们上一步改过代码后,并未重新构建 node。说明此时 node 运行,使用的 lib 代码确实是外置的。
验证外置标准库是否可调试
我们首先验证的是 vscode launch 模式,有未解决报错。 之后又尝试,vscode attach 模式,结果成功了,现将流程分享给大家。如果对调试细节有疑问,请阅读Node.js 调试能力分析。1. 按《Node.js 调试能力分析》这一节中第 1 步操作2. 配置 vscode launch.json 文件
注意,要将 program 指向我们先前编译好的外置标准库版的 node。vscode 2020 年 11 月之后的版本支持了这种外置标准库的断点调试。接下来我们验证一下,调试是否能走通。按如下步骤操作:
{ "version":"0.2.0", "configurations":[ { "name":"node:attach", "port":9229, "request":"attach", "skipFiles":[ // "<node_internals>/**" ], "type":"node" }, { "type":"cppdbg", "request":"launch", "name":"cppdbg:node", "program":"${workspaceFolder}/out/Debug/node", "args":[ "--inspect-brk", "test.js" ], "cwd":"${workspaceFolder}" } ] }
- 修改一段 lib 代码
这里我们继续使用之前的 createServer 中的修改。 - 启动 test.js
选择 cppdbg:node 后,点击绿色三角,启动 test.js。
注意我们 launch.json 中配置了--inspect-brk
参数,这个参数会让我们的调试器在业务代码第一行停住。 - 连接调试服务器
选择 node:attach 后,点击绿色三角,启动 test.js。 - 结果展示
上一步操作完成后,调试器停在第一行代码处,这时点击下一步来到 createServer 处,然后点击下钻(step into),即可来到我们先前修改的 createServer 代码处,如下图所示。至此,我们验证通过了外置 lib 的调试。
下一节,将分享《Node.js addon》相关内容,请大家持续关注本系列内容~学习完本系列,你将获得:
- 提升调试与性能优化能力
- 深入理解模块化与扩展机制
- 探索底层技术与定制化能力
同时欢迎大家一起参与OpenTiny开源共建:朋友你好,一起加入OpenTiny社区吧~
关于OpenTiny
欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~
OpenTiny 官网:https://opentiny.design
OpenTiny 代码仓库:https://github.com/opentiny
TinyVue 源码:https://github.com/opentiny/tiny-vue
TinyEngine 源码:https://github.com/opentiny/tiny-engine
欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~ 如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
循序渐进搭建复杂B端系统整洁架构
作者:京东零售 赵嘉铎 前言 :信息时代技术更迭和传播速度不断加快,技术变得泛娱乐化,大数据、云计算、区块链、元宇宙、大模型,一代代技术热点在社会舆论的裹挟之下不断地吸引着资本的眼球,技术人员为了不被时代所淘汰也不得不时刻追赶潮流。在这样一个时代背景下,软件工程作为一门不起眼到有些枯燥的古老学科,似乎早已被开发者们遗忘在角落。作为一名技术人员我们自然应该时刻保持对前沿技术的追踪,然而,当发生线上问题我们却面对着成片的屎山代码毫无头绪时;当业务方提出个性化需求我们却因为不敢对系统做出修改而强迫对方做出妥协时;当一次请求处理流程中出现多达数万次重复地数据库操作而影响到整个系统的稳定性时,大家都应该沉下心来思考一下,我们是不是忘记了作为一名程序员的初心和对代码的极致追求。 还记的当年我抱着朝圣的心态从传统行业踏入京东职场时的兴奋与期待,然而这份期待很快就被四处可见的屎山代码给浇灭了,后来从朋友口中了解到其他头部互联网厂商的业务系统其实也是半斤八两。这似乎是软件行业中的一个电车难题,一边是无尽的业务需求和倒排的工期,一边是补丁摞补丁的糟糕代码,是继续泡在酱缸中缝缝补补还是向屎山代码说不,开发人...
- 下一篇
得物业务参数配置中心架构综述
一、背景 现状与痛点 在目前互联网飞速发展的今天,企业对用人的要求越来越高,尤其是后端的开发同学大部分精力都要投入在对复杂需求的处理,以及代码架构,稳定性的工作中,在对比下,简单且重复的CRUD就显得更加浪费开发资源。目前scm供应链管理页面中,存在约77%的标准页面,这些标准页面里,还存在着很多类似的参数配置页面,就是对某一个模型进行增、删、改、查、导入、导出进行类似的操作,这种开发工作技术含量较低,而且相对耗费人力。 什么是业务参数配置中心 参数配置中心,是一个能够通过配置的方式,快速生成前端页面以及配套增、删、改、查、导入、导出服务的配置平台,它与得物内部低代码前端页面平台wizard相互集成,参数配置中心提供后台增删改查服务,wizard输出对应的前端页面代码,并可以支持用户自定义修改。 使用场景 针对读多写少的简单的单表的增删改查; 业务中需要交给运营来修改的复杂ark配置(简单配置除外),可以尝试使用业务参数配置中心接入,减少人为修改JSON可能产生的错误,导致系统无法编译进而产生故障。 比如如下的JSON: [{"position":"1","red":2.49,"blu...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS关闭SELinux安全模块
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS6,CentOS7官方镜像安装Oracle11G
- Docker安装Oracle12C,快速搭建Oracle学习环境