背景

Node.js 很简单，容易上手。但也因此缺乏不少规范，使用者水平参差不齐。

最近经常看到的一个问题是：很多新手，在部署的时候，是直接在服务器上 npm install ，这是非常不推荐的。

存在的问题

无法确定唯一性

因为安装是有较大的网络耗时的，所以你甚至无法保证集群情况下，两台服务器上 npm install`` 下来的包是一模一样的。

如果某个库刚好更新了，并且它有 BUG，然后你就是百思不得其解：一定概率出某个问题。排查起来简直想死。

当然，很多人为了解决这个问题，就选择「锁版本」这个方案。

鉴于 「锁版本」这个方案属于 「屎色自行车问题」 ，这里不想讨论。 我们的观点参见：「知乎专栏 - 死马：为什么我不使用 shrinkwrap（lock）」。

上线耗时久，无法快速回滚

上线后，发现线上故障，要快速回滚止血的时候，就懵逼了：

  1. 要等待依赖安装，万一网络有个抖动啥的，妥妥的 P4 故障变为 P0 故障，年终奖没了。

  2. 万一问题是底层依赖导致的，回滚也没用。

  3. npm cache 解决不了问题，如机器扩容的时候。

推荐方案

科普文：为什么不能在服务器上 npm install ？ - 图1

其中，关键点是：在构建期就把依赖打包进去。

优点：

  1. 解压即可立刻启动，无需等待网络耗时。

  2. 能保证肯定是可以运行的，因为此时依赖都是确定好的，且经过 CI 单测保障的。

  3. 可以快速回滚，止血。

缺点：

  1. 包体积大（但其实存储不值钱。。。）

科普文：为什么不能在服务器上 npm install ？ - 图2

如何实施？

那有同学就要问了：我是小公司，不像你们有这些基建可以服务，怎么办？

其实成本真的很低：

  • 代码仓库 GitLab 自带就有 GitLab-CI 了，你只需要写个配置文件，触发自动构建即可。

  • 然后把构建后的文件，找个地方存储，如 OSS 啥的。

  • 服务器部署的话，有运维发布系统最好，没有的话，自己写个 shell 把 OSS 文件下载解压。

  • 当然，很多云服务都支持 Docker 镜像了，那就更简单了。

广告区