在逛QCon的时候发现黄鼎恒老师的《探究 Node.js 的服务端之路》，干货满满分享给大家。

大纲

• 1. 前端=>Node.js=>后端
• 1. V8内存简介
• 1. Node.js服务端开发的常见问题

• v8的内存释放

• 如果要需要主动触发 GC，可以在 node 启动时加上 -expose-gc 参数（不推荐）

• 内存泄漏的可能情况-引用被持有

  • 全局变量：当变量挂靠在root以及module.exports等全局变量上时，对象的内存始终不会释放
  • 闭包：闭包因为写法的问题容易使得闭包引用的作用于内存泄漏
  • 异常处理： 异常产生之后没有正确恢复状态可能导致内存泄漏
  • 事件监听：对同一事件的重复监听或者忘记移除容易导致内存泄漏
    • Node.js 中 Http.Agent可能造成的内存泄漏。当 Agent keepAlive 为true 或者短时间有大量情况的时候，都会复用之前使用过的 socket，如果此时在socket 上添加事件监听，忘记清除的话，因为 socket 的复用，将导致事件重复监听 从而产生内存泄漏。

• 异步：

  • 大量异步时：使用队列结构进行可控的异步并发
  • 了解队列限制：
    • http server socket连接数限制：
    • 数据库连接限制

• 弱计算

  • Node.js 擅长 IO 密集型应用 不擅长 CPU 密集型
  • IO 密集型：让控制器忙
  • CPU 密集型：让运算器忙
  • CPU比较忙的情况：
    • 死循环
    • 序列化对象
    • 加密解密
    • V8 GC

• 内存泄漏

  • 1. 引用问题： 不论是闭包编写，还是事件监听没注意释放。你需要知道什么情况下， 你的引用是被持有的，什么情况下又不是。所有引用问题归结到最后都是 v8 内存释放原理了解程度的问题
  • 队列问题： 一个流程调用的过程中可能经过了非常多个过程，包括通信层、业务层、数据层等，其中每一个层级对于事务的处理都存在的队列的问题，你需要避免整个流程中某个环节的负载超过其能处理的上限。
  • CPU问题： 引用的释放（GC）、队列设置的不合理（超过负载）、业务逻辑的编写问题（死循环）都可能导致 CPU 资源紧张，而 CPU 资源紧张同样会导致内存泄漏（没有足够的 CPU 执行 GC 操作，释放速度赶不上生产速度）。
  • 错误处理: 错误出现之后，如果没有对当前流程进行正确的状态恢复，可能导致错误状态下的内存始终得不到释放从而导致内存泄漏

• 部署

• 分布式

  • cluster的负载均衡：用nginx
  • 数据一致性：使用mysql，因为异步性能较差

• 维护

  • 异常处理：Node.js错误最佳实践

不适合大型应用，适合微服务，快速建站等