近日，【PConline 资讯】携程网站因程序员登录生产网站误操作，长期无法访问。这些现象反映出我国很多大型网站的应用部署和运营还处于2005年的阶段。本文展示了2015年生产现场运行的现状。
在过去的十年里，构建和发布应用程序的方式发生了巨大的变化。本文比较了2005年和2015年Java/JVM上应用程序部署的差异。
2005 = Multi-App Containers / App Servers / Monolithic Apps
2015 = Microservices / Docker Containers / Containerless Apps
2005年，我们基本上把WAR文件作为项目结果，里面包含了Java Web应用和相关的依赖库包。这个应用程序被部署到一个单独的应用服务器上，称为容器，因为它包含一个或多个应用程序，并且这个应用服务器提供许多基本服务，如HTTP服务器、服务目录或共享库包等。不幸的是，在可伸缩性、部署和资源利用率方面，在一个容器中部署多个应用程序有许多绊脚石。应用服务器将应用与底层系统依赖分离，从而避免了“它在我的机器上工作”(它只能在我的机器上运行)的问题，但是事情并不是很顺利，因为系统依赖和配置是与应用服务器，也就是容器分离的。
在2015年，应用程序可以作为一个独立的单元来部署，应用程序本身包含了一切，因此它可以直接在标准的系统依赖项上运行。在Java世界中，无容器应用程序是一个ZIP文件，包含了基于JVM运行需求的所有依赖库包，大多数开发框架都切换到了这种无容器模式，比如Play Framework、Dropwizard、Spring Boot等等。
系统级更完整和便携的独立单元是Docker和LXC。与过去不同的是，许多应用程序被部署到一个应用程序服务器容器中，一个应用程序被添加到Docker映像中，然后被部署到一个或多个服务器中。
微服务在这里起着重要的作用，因为微服务的部署是可以分离和独立的，而传统的应用服务器在部署其中一个应用时需要重启整个服务器，这也是企业部署速度慢的原因。部署应用程序是一项非常危险的工作，必须提前几个月与许多团队协调。热部署只是一个承诺，在生产环境中从未实现。
微服务激发了独立团队部署自己的应用程序的愿望。微服务可以快速为快速部署和扩展服务的能力做好准备。这些需求可以通过在底层Docker容器中运行无容器应用程序来实现。
2005 = 手工部署
2015 = 持续提交 /持续部署
2005年手动部署，几个单体应用捆绑在一起，通过手动配置上传到生产环境。
2015年是持续提交，持续部署，一天可以部署几百次。
2005 = Persistent Servers / “祈祷它不会当机”
2015 = 不变的基础设施/ Ephemeral Servers
今天，网飞的混沌猴子可以随机关闭服务器，确保我们各自的准备就绪，然后启动，可以瞬间增加和减少应用实例。由于基础设施的不变性，我们不再需要SSH登录主机来解决生产问题(banq注：最近的携程宕机事件是由于程序员误操作登录生产环境导致的，采用微服务Docker不变的基础设施环境可以避免)，日志服务导出到外部服务，可以实时使用。
2005 = Ops Team运营团队
2015 = DevOps 开发运营合一
2005年，运营团队拿到WAR文件，负责部署、管理和监控。开发者的手机不需要24小时开机，因为在生产环境下，运营商可以在凌晨3点做一些事情来解决问题，但最大的风险是软件交接造成了很大的缓慢。
如今，开发人员将始终对投入生产的代码负责。像New Relic、VictorOps和Slack这样的服务可以帮助开发人员承担运营责任，DevOps文化正在逐渐传播。
