上次写了篇文章，有同学评价说讲的东西太基础了，好吧，貌似是有些基础的，不过在编程领域，“基础”这个词表达意思太模糊，在我看来，有时候技术是越基础越好，当一个技术能够完美解决问题，又能基础的每个人都能快速上手，都能理解活用的时候，它就“基础”的完美了，例如jQuery什么的。可能是不同的思考角度吧，有些同学觉得研究别人搞不懂的技术才算牛逼，而有的人则觉得不断解决别人解决不了的问题才算厉害，有些同学每天研究如何解放生产力，有些同学研究如何改进流程，有些同学研究如何让大家的开发工作变得”简单基础“，各司其职，不能够互相轻薄哈~~

   不过，有时候我想想，这系列文章好像主要是给前端转NodeJS的同学看的，的确有些基础，大家凑合看哈。

   今天这篇文章主要讲讲咱们大搜车如何部署NodeJS，可能还是有些基础，不过希望对不太清楚的同学有所帮助。

第一章：工具

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

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

1. PM2更稳定一些，forever偶尔经常会莫名其妙进程就没了，出现几率不大，但是有几率，具体原因不明。  

2. 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秒钟间隔，由于负载均衡的存在，这样可以保证部署的时候，线上服务不会访问不到，每次只有一台机器在被部署。

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

小结

   我们的应用部署方式还在不断进化中，毕竟我们在业界算起来其实玩的并不是非常好的那一批，还有很大的提升空间。而且随着公司业务飞速发展，目前很多方面都会出现很多挑战，例如多环境自动部署，IO瓶颈的优化，业务逻辑实现方式的优化等，很多事情在前面等着我们。以后我们有任何进展会及时跟大家分享哒，希望NodeJS界的风气越来越沉稳下来，落到实际业务中去，并且大家多交流分享，整个世界都会变得美美哒。

   下面还会有其他一系列文章，事先预告下：

1.    存储，缓存，云服务 方面的一些最佳实践和经验。

2.    NodeJS服务性能监测，调优，调试，监控报警，应急处理方面的话题。

3.    NodeJS MVC 基本要素（http://www.html-js.com/article/Front-team-search-car-front-team-NodeJS-in-search-car-MVC-basic-structure%202985）

   欢迎大家持续关注我们的专栏。

建议继续学习：

1. 为什么我们要从 NodeJS 迁移到 Ruby on Rails    (阅读：5449)
2. Nodejs和MongoDB初体验    (阅读：5018)
3. JavaScript，只有你想不到    (阅读：5088)
4. 使用socket.io和node.js搭建websocket应用    (阅读：4350)
5. node.js调研与服务性能测试    (阅读：3650)
6. 基于express+socket.io的nodejs聊天室    (阅读：3581)
7. nodejs教程：配置nodejs.exe的windows目录结构    (阅读：3564)
8. nodejs教程：安装及配置app.js文件    (阅读：2627)
9. Node.js中相同模块是否会被加载多次？    (阅读：2393)
10. 将你的 KISSY 程序移植到服务器端    (阅读：2081)