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

Node.js的应用场景

1、前端工程化场景

2、Web服务端应用

• 学习曲线平缓，开发效率较高
• 运行效率接近常见的编译语言
• 社区生态丰富及工具链成熟（npm,V8,inspector）
• 与前端结合的场景会有优势（SSR）
• 现状：竞争激烈，Node.js有自己独特的优势

3、Electron跨端桌面应用

• 商业应用：vscode,slack.discord,zoom
• 大型公司内的效率工具
• 现状：大部分场景在选型时，都值得考虑

4、Node.js在字节

• BFF应用、SSR应用，举例：Modem.js
• 服务端应用，举例：头条搜索，西瓜视频，懂车帝
• Electron应用：飞连，飞书
• 每年新增1000+ Node.js应用

Node.js运行时结构

特点

1、异步 I/O

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

2、单线程

• JS单线程

  • 实际：JS单线程+uv线程池+VB任务线程池+VB Inspector线程

• 优点：

  • 不再考虑多线程状态同步问题，也就不需要锁；
  • 同时还能比较高效地利用系统资源；

• 缺点：阻塞会产生更多负面影响

  • 解决方法：多进程或多线程

3、跨平台

编写Http Server

1、安装Node.js

• Mac,Linux推荐使用nvm。
• 多版本管理。
• Windows推荐nvm4w或是官方安装包。
• 安装慢，安装失败的情况，设置安装源。

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

用Promise + async await重写，技巧：将callback转换成promise

3、编写静态文件服务器

4、编写React SSR服务

• SSR（sever side rendering）的特点：

  • 相比传统HTML模板引擎：避免重复编写代码
  • 相比SPA（single page application）：首屏渲染更快，SEO友好
  • 缺点：通常qps较低，前端代码编写时需要考虑服务端渲染情况

• HTML例子

  

• 替换成React

  

• SSR难点：

  • 需要处理打包代码

    

  • 需要思考前端代码在服务端运行时的逻辑

    

  • 移除对服务端无意义的副作用，或重置环境

5、适用inspector进行调试、诊断

• V8 Inspector：开箱即用、特性丰富强大、与前端开发一致、跨平台

  • node--inspect
  • open http://localhost:9229/json

• 场景：

  • 查看console.log内容
  • breakpoint
  • 高CPU、死循环：cpuprofile
  • 高内存占用：heapsnapshot
  • 性能分析

6、部署简介

• 部署要解决的问题

  • 守护进程：当进程退出时，重新拉起
  • 多进程：cluster便捷地利用多进程
  • 记录进程状态，用于诊断

• 容器环境

  • 通常有健康检查的手段，只需考虑多核cpu利用率即可

延伸话题

1、Node.js贡献代码

• 好处：

  • 从使用者的角色逐步理解底层细节，可以解决更复杂的问题；
  • 自我证明，有助于职业发展；
  • 解决社区问题，促进社区发展；

• 难点：花时间

2、诊断/追踪

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

3、WASM,NAPI

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