这是我参与「第四届青训营」笔记创作活动的的第11天

Node.js 的应用场景_（why）

前端工程化
- Bundle ： webpack, vite, esbuild, parcel
- Uglify ： uglifyjs
- Transpile ： bablejs, typescript
- 其它语言加入竞争： esbuild, parcel, prisma
- 现状： Node.js 的地位难以替代
Web 服务端应用
- 学习曲线平缓，开发效率较高
- 运行效率接近常见的编译语言
- 社区生态丰富及工具链成熟（npm, V8 inspector）
- 与前端结合的场景会有优势（SSR ，服务端渲染）
- 现状：竞争激烈， Node.js 有自己独特的优势
Electron 跨端桌面应用
- 商业应用： vscode, slack, discord, zoom
- 大型公司内的效率工具
- 现状：大部分场景在选型时都值得考虑
Node.js 在字节跳动
- BFF 应用、 SSR 应用，举例： Modern.js
- 服务端应用，举例：头条搜索、西瓜视频、懂车帝
- Electron 应用：飞连、飞书
- 每年新增 1000+ Node.js 应用

Node.js 运行时结构_（what）

node-inspect ：调试
用户代码：自己业务的代码
V8： JavaScript Runtime ，诊断调试工具（inspector）
libuv ：封装了各种操作系统 API （syscall ，系统调用），还提供了 Node.js 核心的 eventloop （事件循环）
zlib ：压缩跟解压缩的算法
c-ares ： DNS 查询的库
llhttp ： http 协议的解析
OpenSSL ：常用在网络层面上的加密/解密工具

举例：
用 node-fetch 发起请求时，先通过 npm 安装 node-fetch 模块之后到了用户代码，我们在代码里面去调用 node-fetch 模块，这些代码都是 JavaScript 代码，所以它会到 V8 去执行， node-fetch 它在 Node.js 这块底层调用的肯定是 http 模块（它调用 Node.js Core JavaScript 里面的 http 模块）， http 模块再去调用更底层的 C++ 的 API ，它可能需要调用 llhttp 去帮我们做 HTTP 协议的序列化和反序列化，然后通过 libuv 得到的数据，这中间可能要去创建一个 TCP 连接，再把这个数据发给远端，反过来也是一样的，远端传给我们一些数据以后，我们在事件循环（eventloop）里面就会得到这个消息，再把拿到的数据给 llhttp 解析出来，接着数据给 JavaScript 代码再到用户的代码，最后我们收到整个数据。

特点：

异步 I/O 。
单线程。
跨平台。

worker_thread 可以起独立线程，但每个线程的模型都没有太大变化。

异步 I/O

当 Node.js 执行 I/O 操作时，会在响应返回后恢复操作而不是阻塞线程并占用额外内存等待。

单线程

JS 单线程（只有 JavaScript 主线程是单线程）
- 实际： JS 线程 + uv 线程池（默认四个，对 CPU 消耗比较大的底层操作） + V8任务线程池 + V8 Inspector 线程
优点：不用考虑多线程状态同步问题，也就不需要锁；同时还能比较高效地利用系统资源。
缺点：主线程阻塞会产生更多负面影响
- 解决办法：多进程或多线程

跨平台

跨平台（大部分功能、 api）
Node.js 跨平台 + JS 无需编译环境（+ Web 跨平台 + 诊断工具跨平台）
- =开发成本低（大部分场景无需担心跨平台问题），整体学习成本低

编写 Http Server_（how）

安装 Node.js

Mac, Linux 推荐使用 nvm 。多版本管理。
Windows 推荐 nvm4w 或者官方安装包。
安装慢，安装失败的情况，设置安装源： NVM_NODEJS_ORG_MIRROR=https://npmmirror.com/mirrors/node nvm install 16

编写 Http Server + Client ，收发 GET, POST 请求

编写 Http Server
用框架的好处：你可以比较好的去学习它的模式；你也可以很快找到基于这个框架封装的各种插件。
用框架的缺点：框架解决不了你的需求时，你的需求可能会得不到及时的解决。
转 json 格式：

const server = http.createServer((req, res) => {
    // res.end('hello world')
    const bufs = []
    // 绑定 data 事件，每当连接返回给我一段数据（来自 body），然后把它收集起来
    req.on('data', (buf) => {
        bufs.push(buf)
    })
    // end 事件触发代表数据传完了
    req.on('end', () => {
        let reqData = Buffer.concat(bufs).toString('utf8')
        try {
            // Buffer.concat(bufs).toString('utf8') 把 bufs 拼接起来转化成 UTF-8 字符串
            reqData = JSON.parse(reqData)
        } catch(err) {
            // res.end('invalid json')
        }
        res.setHeader('Content-Type', 'application/json')
        res.end(JSON.stringify({
            echo: reqData.msg || 'hello world'
        }))
    })
})

编写 Client

上面写的 Server 和 Client 用了很多回调函数，回调函数在很多场景下都可以直接用，但它是一种不太好去维护和管理的模式（很多时候我们不能确定回调函数什么时候被触发；有些东西想在回调函数里面做，可能导致嵌套写的非常深；每个嵌套的函数都是一个单独的函数，通过代码不容易看出函数与函数之间的关系）。

不是所有的回调函数都可以重写为 Promisify 形式，例如： createServer 内的回调函数，它会被重复调用多次， Promise 形式的回调函数只适合被调用一次的回调函数。

用 Promise + async await 重写 Server 的例子

技巧：将 callback 转化成 promise

// async 方便后面去用 await 调用
const server = http.createServer(async (req, res) => {
    const reqData = await new Promise((resolve, reject) => {
        const bufs = []
        req.on('data', (buf) => {
            bufs.push(buf)
        })
        req.on('error', (err) => {
            reject(err)
        })
        req.on('end', () => {
            let reqData = Buffer.concat(bufs).toString('utf8')
            try {
                // Buffer.concat(bufs).toString('utf8') 把 bufs 拼接起来转化成 UTF-8 字符串
                reqData = JSON.parse(reqData)
            } catch(err) {
                // res.end('invalid json')
            }
            // 返回数据
            resolve(reqData)
        })
    })
    res.setHeader('Content-Type', 'application/json')
    res.end(JSON.stringify({
        echo: reqData.msg || 'hello world'
    }))
})

编写静态文件服务器

stream 风格的 API 最大好处：因为内部做了一些处理，它可以帮你尽可能的减少占用内存空间（把所有数据都储存在 stream ，只会按需的返回给 Client ，例如： Client 消费速率高了， stream 可以多返回一部分数据）。

与高性能、可靠的服务相比缺少：

CDN ：缓存 + 加速；
分布式储存，容灾。

外部服务： cloudflare ，七牛云，阿里云，火山云，……

编写 React SSR 服务

SSR （server side rendering）的特点：

相比传统 HTML 模板引擎：避免重复编写 HTML 引擎的代码
- 早期的前端开发场景：每个请求来了都返回一段 html 代码，这段 html 代码加载一些 JavaScript 代码，然后通过这些代码把应用渲染出来。
- 现在的前端开发场景：很少直接写 html 代码，生成 html 代码逻辑都放在 JavaScript 里面，只要能运行 JavaScript 代码就可以知道要返回什么 html 代码，这样就不需要重复编写一套 HTML 模板了，也不需要模板引擎。
相比 SPA （single page application）：首屏渲染更快， SEO 友好
- SPA 应用需要等所有的 JavaScript 代码加载好以后它才可以给用户反馈一些数据，所有它的首屏会更慢一点。
缺点：通常 qps 较低，前端代码编写时需要考虑服务端渲染情况

替换成 React ：

SSR 难点：

需要处理打包代码。
需要思考前端代码在服务端运行时的逻辑。拉数据的普遍思路：React 生命周期的后面，比如： componentDidMount 以及以后去执行，因为这个生命周期在 ReactDOMServer 里面在 renderToString 的时候它是不会触发的，所以把这些前端逻辑放在 componentDidMount 这个生命周期以后可以避免在服务端渲染的时候被执行到。
移除对服务端无意义的副作用或重置环境。

使用 inspector 进行调试、诊断

V8 Inspector ：开箱即用、特性丰富强大、与前端开发一致、跨平台
- node --inspect
- open http://localhost:9229/json
场景：
- 查看 console.log 内容
- breakpoint
- 高 CPU 、死循环： cpuprofile
- 高内存占用： heapsnapshot
- 性能分析

部署简介

部署要解决的问题
- 守护进程：当进程退出时，重新拉起
- 多进程： cluster 便捷地利用多进程
- 记录进程状态，用于诊断
容器环境
- 通常有健康检查的手段，只需考虑多核 CPU 利用率即可

延伸话题

Node.js 贡献代码

快速了解 Node.js 代码
- Node.js Core 贡献入门
好处：
- 从使用者的角色逐步理解底层细节，可以解决更复杂的问题；
- 自我证明，有利于职业发展；
- 解决社区问题，促进社区发展；
难点：
- 花时间

编译 Node.js

为什么要学习编译 Node.js
- 认知：黑盒到白盒，发生问题时能有迹可循
- 贡献代码的第一步
如何编译
- 参考： Maintaining the build files
- ./configure && make install
- 演示：给 net 模块添加自定义属性

诊断/追踪

诊断是一个低频、重要同时也相当有挑战的方向。是企业衡量自己能否依赖一门语言的重要参考。
技术咨询行业中的热门角色。
难点：
- 需要了解 Node.js 底层，需要了解操作系统以及各种工具
- 需要经验

WASM, NAPI

Node.js （因为 V8）是执行 WASM 代码的天然容器，和浏览器 WASM 是同一运行时，同时 Node.js 支持 WASI 。
NAPI 执行 C 接口的代码（C/C++/Rust/……），同时能保留原生代码的性能。
不同编程语言间通信的一种方案。

Node.js 与前端开发实战|青训营笔记

Node.js 的应用场景（why）

Node.js 运行时结构（what）

编写 Http Server（how）

技巧：将 callback 转化成 promise

延伸话题

Node.js 的应用场景_（why）

Node.js 运行时结构_（what）

编写 Http Server_（how）