对于互联网产品或长期运行的产品而言，运维工作非常重要，尤其是在产品复杂了以后，在这篇blog中就来说下Java应用的运维工作（ps：虽然看起来各种语言做的系统的运维工作都差不多，但细节上还是会有很多不同，so本文还是只讲Java的）。

苦逼的码农按照需求开发好了一个全新的Java Web应用，该发布上线给用户用了，要把一个Java Web应用发布上线，首先需要搭建运行的环境，运行的环境需要有JDK、APPServer，在已经装好了os的机器上装上JDK和APPServer，开发好的Java Web应用可以用maven直接打成war或ear，将这个打好的包scp或其他方式到目标机器上，准备妥当，就差启动了。
通常APPServer都带有启动脚本，在做好了上述准备后，直接运行启动脚本，通常就OK了（maybe需要修改appserver的一些配置文件，例如修改监听端口等）。
应用启动后，有一个问题需要解决，就是如何确认应用启动后成功与否，对于Java web应用通常可以放一个jsp文件，在这个文件里做一些必要的检查，以确保应用启动是正常的，例如通常Java web应用会基于spring之类的框架来写，为了确保spring的BeanFactory初始成功，可以在jsp文件里去获取下spring里的bean调用下。
应用完成了启动后，这个阶段的工作就算完成了，这个阶段完成后积累了一个应用启动的脚本，用来启动应用服务器以及在启动完毕了后检验应用是否启动成功。

只要不是一个一次性的应用，就必然会涉及修改的问题，修改完了后就得重新发布，对于Java Web应用，在修改完了后重新打应用的包，然后scp覆盖到目标机器上，重启，就可完成修改，但显然，每次修改完代码后都这么操作实在是痛苦不堪，于是喜欢“偷懒”的同学会专门搞台发布用的机器（或者就是运行应用的那台机器），然后写个脚本，每次需要发布时就通过脚本自动的将发布需要做的所有事情自动做好，:)，这下以后发布爽多了。
相应的这个时候通常还要支持回滚，即应用发布失败后自动的回滚到前一版本的功能，也可以折腾到脚本里。
但如果只是为了修改个页面，就得这么折腾，显然还是麻烦了点（主要是经常重启，用户受不了），于是需要支持仅更新页面的发布方式，为了支持这种方式，通常就要求打出的war/ear是解开了的，这样才比较方便直接覆盖页面，继续“偷懒”的本性，写些脚本，支持将需要发布的页面文件从svn或git下载，然后打成一个tgz或其他压缩包，scp到目标服务器，解包覆盖完成页面的更新（当然，对于编译jsp的运行方式这种发布方法就没法玩了）。
经过这个阶段的折腾，就积累了两个脚本，一个用来发布应用包，一个用来发布页面。

每次发布应用包的时候都会有短暂的不可用，这样总折腾下去用户受不了（如果哪天这唯一的一台服务器挂掉的话，就更糟糕了），于是就把应用的机器数从一台变成两台，通常这里对应用是有些技术要求的，这篇blog中只谈运维，通常情况下从部署在一台变成两台后，要做这些事：
1、可能会增加一台机器用来部署nginx/apache来做负载均衡，这个规模的情况下应该很少有会采用lb设备或lvs的（某些国企除外…），于是就得折腾下这台机器的环境等了；
2、增加了一台应用的机器后，就得又来搭建一次应用的运行环境了，通常这个时候“偷懒”的本性会发作，干脆折腾个脚本吧，来支持从另外一台运行的应用机器clone运行环境，做的更好点的话，就会把应用的运行环境记录在某个地方、然后把应用运行需要的软件也放在某个地方（例如yum），这样，当要搭建应用的运行环境时，就可通过记录的信息以及yum源等直接完成运行环境的搭建。
3、但这样还没完，为了避免发布的时候应用完全不能用，除了技术上要做的那点事外，在发布应用时就会多加一步，就是要先发一台，再发另外一台，由于之前有发布脚本，通常这也不是问题，:)。
经过这个阶段，就又积累了两个脚本，一个用来管理负载均衡的那台机器，另一个脚本用来搭建应用的运行环境。

随着应用越来越受欢迎，通常应用的机器就得继续加了，这个时候对运维工作又会带来新的挑战，主要还是在发布上，这个时候应用部署在了一堆的机器上了，每次发布的时候手工输入一堆的机器地址来发布显然很麻烦，于是需要有个地方来记录应用有哪些机器（还记得我们之前搞了个地方来记录应用的运行环境信息吧，可以放一起），除了要解决这个问题外，还需要解决的一个问题是这个时候通常对应用的发布方式会有了多种要求，例如分批发布（先发5台，再发10台，再全部发，或一半一半发等），更高级的话会有beta发布、灰度发布等要求，这个具体可以见facebook的大牛@魏小亮 写的《代码和产品发布的几种方式》，这个时候显然，之前写的那个简单的发布脚本就无法支持了，于是得搞个更为复杂的脚本来支持这多种的发布方式（有些还需要应用架构上做配合改造才能实现），做的更好的就是提供一个web版本的发布系统，来更为方便的进行发布以及发布过程的管理。
经过这个阶段后，通常可以折腾出一个web版的应用运维系统了，包括应用信息的登记（依赖的运行环境、运行的机器地址）、应用的发布、页面的发布、增加应用的机器、下线应用的机器。

通常继续发展下去，会出现一些新的状况，主要是会开始多元化，有了很多个应用，这个时候原来的web版应用运维系统就要支持多应用了，这里主要会带来的问题是为了降低运维的复杂性，需要做一些通用性的工作，例如通用的启动脚本等，这个时候会产生一些要求，例如统一的应用名等，另外会带来的问题就是开发、运维的人多了，这个时候权限上就需要有些控制了，例如某些账号可以操作某些应用等，这个时候通常需要增加一套权限系统，集成到之前的运维系统。
应用多了后，还会带来的问题是应用部署的规范性（同时也是为了降低运维的复杂性），因为每个应用可能都会有一些特殊的配置，这个时候最好是能够通过搭建运行环境以及权限控制来保证一个应用部署后的目录控制。

经过上面的一些发展过程后，Java应用的运维工作基本就可以比较自动的去完成了，但通常其实应用运维除了上面的工作外，还有一件更重要的事，就是保障应用的稳定，应用运维人员需要能够排查大部分的应用故障问题，而不是交由后面的开发人员来解决，通常这个时候需要一套自动的故障处理系统，感兴趣的同学可以参与下facebook的FBAR。

发展到更大后，还可能会碰到例如一个负载设备无法支撑整个网络的请求，需要划分vlan，这个时候在做应用机器的扩容时就需要考虑vlan因素了，还有可能会碰到机器利用率不够高，需要引入虚拟机，更高级的就是引入弹性计算，这些对运维体系都会产生较大的冲击，:)。

从上面对一个Java应用运维的演变描述可以看到，大方向上来说是朝自动化、web化、智能化发展，但最最重要的都是如何和现有运行体系无缝的结合，而且这里谈到的还仅仅是Java应用运维的工作（还没提到开发人员其实也要仔细考虑自己写的产品的可运维性如何），而一个运维的体系还要包括机房、网络、硬件、安全等，就更加的复杂和且需要体系化的考虑，。

 

 

 

 

----------------------------------------------------------------------------------------------------------