JAVA运维

对于互联网产品或长期运行的产品而言，运维工作非常重要，尤其是在产品复杂了以后，在这篇blog中就来说下Java应用的运维工作。
码农按照需求开发好了一个全新的Java Web应用，该发布上线给用户用了，要把一个Java Web应用发布上线，首先需要搭建运行的环境，运行的环境需要有JDK、APPServer，在已经装好了os的机器上装上JDK和APPServer，开发好的Java Web应用可以用maven直接打成war或ear，将这个打好的包scp或其他方式到目标机器上，准备妥当，就差启动了。
应用启动后，有一个问题需要解决，就是如何确认应用启动后成功与否，对于Java web应用通常可以放一个jsp文件，在这个文件里做一些必要的检查，以确保应用启动是正常的。
应用完成了启动后，这个阶段的工作就算完成了，这个阶段完成后积累了一个应用启动的脚本，用来启动应用服务器以及在启动完毕了后检验应用是否启动成功。
只要不是一个一次性的应用，就必然会涉及修改的问题，修改完了后就得重新发布，对于Java Web应用，在修改完了后重新打应用的包，然后scp覆盖到目标机器上，重启，就可完成修改，但显然，每次修改完代码后都这么操作实在是痛苦不堪，于是喜欢“偷懒”的同学会专门搞台发布用的机器，然后写个脚本，每次需要发布时就通过脚本自动的将发布需要做的所有事情自动做好，这下以后发布爽多了。
相应的这个时候通常还要支持回滚，即应用发布失败后自动的回滚到前一版本的功能，也可以折腾到脚本里。
但如果只是为了修改个页面，就得这么折腾，显然还是麻烦了点(主要是经常重启，用户受不了)，于是需要支持仅更新页面的发布方式，为了支持这种方式，通常就要求打出的war/ear是解开了的，这样才比较方便直接覆盖页面，继续“偷懒”的本性，写些脚本，支持将需要发布的页面文件从svn或git下载，然后打成一个tgz或其他压缩包，scp到目标服务器，解包覆盖完成页面的更新(当然，对于编译jsp的运行方式这种发布方法就没法玩了)。
经过这个阶段的折腾，就积累了两个脚本，一个用来发布应用包，一个用来发布页面。
随着应用越来越受欢迎，通常应用的机器就得继续加了，这个时候对运维工作又会带来新的挑战，主要还是在发布上，这个时候应用部署在了一堆的机器上了，每次发布的时候手工输入一堆的机器地址来发布显然很麻烦，于是需要有个地方来记录应用有哪些机器(还记得我们之前搞了个地方来记录应用的运行环境信息吧，可以放一起)，除了要解决这个问题外，还需要解决的一个问题是这个时候通常对应用的发布方式会有了多种要求，例如分批发布(先发5台，再发10台，再全部发，或一半一半发等)，更高级的话会有beta发布、灰度发布等要求，这个时候显然，之前写的那个简单的发布脚本就无法支持了，于是得搞个更为复杂的脚本来支持这多种的发布方式(有些还需要应用架构上做配合改造才能实现)，做的更好的就是提供一个web版本的发布系统，来更为方便的进行发布以及发布过程的管理。
经过这个阶段后，通常可以折腾出一个web版的应用运维系统了，包括应用信息的登记(依赖的运行环境、运行的机器地址)、应用的发布、页面的发布、增加应用的机器、下线应用的机器。
通常继续发展下去，会出现一些新的状况，主要是会开始多元化，有了很多个应用，这个时候原来的web版应用运维系统就要支持多应用了，这里主要会带来的问题是为了降低运维的复杂性，需要做一些通用性的工作，例如通用的启动脚本等，这个时候会产生一些要求，例如统一的应用名等，另外会带来的问题就是开发、运维的人多了，这个时候权限上就需要有些控制了，例如某些账号可以操作某些应用等，这个时候通常需要增加一套权限系统，集成到之前的运维系统。
应用多了后，还会带来的问题是应用部署的规范性(同时也是为了降低运维的复杂性)，因为每个应用可能都会有一些特殊的配置，这个时候最好是能够通过搭建运行环境以及权限控制来保证一个应用部署后的目录控制。
经过上面的一些发展过程后，Java应用的运维工作基本就可以比较自动的去完成了，但通常其实应用运维除了上面的工作外，还有一件更重要的事，就是保障应用的稳定，应用运维人员需要能够排查大部分的应用故障问题，而不是交由后面的开发人员来解决，通常这个时候需要一套自动的故障处理系统。