项目上线流程

项目实战
现在有一个任务把线上正在运行的一个2.1版本的war包换成2.2版本的war包，当你接到这个任务后你应该这么做，下面我详细的分析一下我在项目上线时的做法
1.首先服务是不能中断的，上线不能影响到用户体验
实际上开发的包很多都是放到一起的，开发遵循MVC规则
war包的部署可以用autodeploy,也就是自动部署，自动部署之后服务是需要重启去加载的，但是重启的过程中你还要考虑到前端负载均衡的请求
实际生产中都会有一个预发环境，有些公司的预发环境也是挂载在负载均衡器上的，为了统一，就把预发环境的机器和服务器放在同等的地位，但是一般负载均衡器到搭建预发环境主机上的线路是阻塞的，没有流量放进来；当然也有些公司并没有把预发环境挂在生成环境中，还有些公司会把预发环境放到生产环境中当有服务上线时先用预发环境做一个测试然后还会有一台机器也布置预发环境进行二次测试，这里会涉及到一个概念就是灰度发布

一般会有开发环境，但是开发环境都会比较乱，比如混乱的目录结构（比如相同的小米商城源码包在不同的机器上存放于不同的目录下，这样混乱的目录结构必将给运维工作带来很大的麻烦），所以为了降低运维复杂度一般要有规则的目录结构
测试环境:一般比较稳定，测试方法一般有黑盒测试和白盒测试
线上环境：上线之前进行预发测试
–灰度发布
–全面发布
上线流程：
1.把应用从负载均衡器上摘除（mark down）
注意：利用haproxy进行mark down ,通过管理页面把服务标记成下线的状态，但是要注意这个时候正在处理的请求是还在处理的只是新的请求进不来，这一步是非常重要的，涉及到服务的可用性问题；并且mark down之后是不能立刻停止服务的，一般要等10~20秒的时间给未处理完的请求预留时间
还要注意如果你使用手动mark down是很烦人的，如果机器有很多台你还要一台台去mark down 上线好之后还要去mark up 只要是人进行的工作都是会有错误产生的，所以可以使用基于内容的状态检测页面，，当检测到某字段或内容时把服务mark up，当服务器数量较多时可使用自动化运维工具例如ansible也非常简单
2.stop service
3.deploy war 自动部署
这里还会涉及到一些问题，如何自动部署，可能目录下有很多个war包，它如何知道哪一个是哪一个呢？去修改配置文件吗？如果你有一百台呢？难道要一台台的去修改吗？这个肯定是不行的，其实解决方法是很简单的，一般在工作中是用links软链接，比如这里有war2.1 war2.2 war2.3 war2.4，我要上线的时候只需要改一下软链接（这样就不必去修改配置文件了）并且使用软链接还有一个好处是当你发现新上线的包有问题时可以快速回滚，当然还有其它方法可以实现，但是一般大公司比如腾讯，百度，阿里都采用这种上线方式
4.change new link 就是第三步中说到的内容
5.start service
6.mark up
以上就是一台机器一个项目上线过程
如果你需要给很多台机器实现上线任务，你可以写一个脚本循环，当一台机器执行完后开始另一台机器，你也可以分批上线，第一次实现几台机器共同上线，第二次实现几台机器，这需要用到自动化工具