Question

前言

本质

分类

选择

第一章：工具 简单的说，线上用 PM2，测试用 Forever，本地用 nodemon。简单分别介绍下为什么。

关于 PM2 和 forever，一个重而大，一个小而轻，为什么线上用 pm2 测试用 forever？

PM2 更稳定一些，forever 偶尔经常会莫名其妙进程就没了，出现几率不大，但是有几率，具体原因不明。 PM2 会占用端口，即使你 delete，stop 了一个进程，它的端口还是占着，除非你把所有的 list 都 kill，如果你的服务器上跑了好几个服务，那就很悲剧了。线上环境还好，不会经常重启，也不会调整端口。但是测试环境就不一样了，一台机器上跑 10 来个 node 服务，端口经常还要变一变（不同分支）。用 pm2 简直就是个大悲剧，这时候 forever 反而派上了用场，一个服务对应一个进程，更灵活易控制。 nodemon 这个东西，可能很多人也都知道，用来本地开发自动重启的，这里只是提一下，以后不需问”如何不重启进程让 node 代码生效“之类的问题额，重启还是要重启的，用个工具就方便多了。（一个原则，不要在 node 进程里保存状态，进程是可以随时被重启的）。

forever 和 pm2 的基本用法就不详述了，文档里都有，pm2 有很多强大功能，大家可以多研究下，虽然不一定用得到。

第二章：环境 我们木有搭建私有的 NPM 库，目前暂时所有模块都是在项目中的，还没有正规的服务化出来，这些都是需要人力成本的，到了一定阶段肯定要做。

关于开发环境，我们目前有测试环境，预发环境，线上环境三个部分。

测试环境只有一台机器，但是上面跑了不少 git 分支，分别对应不同的业务，也对应不同的端口。大部分分支是”开发分支“，也就是不保证稳定，用来做开发联调的时候用的，但是在测试机器上会有一个稳定的端口（通常是 8001），这个端口跑主干分支的代码，一直稳定存在，用来对接其他后台系统或者客户端的稳定分支环境。测试服务器进程用 forever 管理，工程师在开发的时候需要自己去服务器拉取代码，配置环境，暂时没有自动化部署的机制。不过公司正在研究 docker，用于 java，ruby 之类的部署，后面可以考虑引入 node 的测试部署，应该会方便很多。

预发环境，是一个真实的环境，只是没有访问入口而已，在每次发布前，把代码从分支合到主干（联调前，从主干往分支合一次），然后从主干发布到预发环境，用一个指向预发环境的客户端对各个功能进行回归，回归完毕后再发布到线上环境。这个环境连接的是线上的数据库，线上的缓存，线上的依赖服务。

正式环境，4 台机器+一台定时任务的机器。服务器是阿里云的 ECS，负载均衡用的是阿里云的 SLB，mysql 用阿里云的 RDS，缓存用阿里云的 OCS，运维基本上是都不需要担心了，现在的云服务已经非常完善了，其实我们用阿里云的服务非常多，大概有 20 多个类型的服务，感谢阿里云。

现在想起来，作为一个一边管理着前端，一边做着后端的工程师，大部分架构思维都是以前从一些接触到的后台开发项目里看到的一瞥，其实很多想法还是不够成熟的，需要不断磨练和提升。

第三章：部署方式。 这里主要是阐述我们线上服务的部署方式。

其实 PM2 也提供了一种自动部署的方式，有兴趣的可以去研究下，支持多机自动部署，写个配置文件，然后执行一个命令即可，这里就不展开啦。详见文档： https://github.com/Unitech/PM2/blob/master/ADVANCED_README.md#deployment

我们的部署脚本是自己（bash）写的，这里简单说下部署流程：

git pull -> npm install -> 整体打包成 tar 包 -> scp 上传到目标服务器 -> 解压 -> 生成一份备份 -> 覆盖线上文件 -> pm2 restart

大体就是这样，然后部署这个动作是在预发服务器上执行的。通过阿里云内网 ip，自动挨个服务器部署，每台服务器中间有 10 秒钟间隔，由于负载均衡的存在，这样可以保证部署的时候，线上服务不会访问不到，每次只有一台机器在被部署。

目前我们还没有类似于灰度发布这样的体系，这个操作其实对于大规模应用也是常见的，这里就不讲啦。

案例

亿书官网部署方案

http://www.lxway.net/15605021.html https://certsimple.com/blog/deploy-node-on-linux Node.js as a background service