Java应用运维

标签: Java java系统运维 发布 故障处理 | 发表时间:2012-01-29 11:34 | 作者:bluedavy
出处:http://blog.bluedavy.com

对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇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应用运维的工作(还没提到开发人员其实也要仔细考虑自己写的产品的可运维性如何),而一个运维的体系还要包括机房、网络、硬件、安全等,就更加的复杂和且需要体系化的考虑,。

相关 [java 应用 运维] 推荐:

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.

Java线程池应用

- - CSDN博客架构设计推荐文章
1.减少了创建和销毁线程的次数,每个工作线程都可以被重复利用,可执行多个任务. 2.可以根据系统的承受能力,调整线程池中工作线线程的数目,防止因为消耗过多的内存,而把服务器累趴下(每个线程需要大约1MB内存,线程开的越多,消耗的内存也就越大,最后死机). Java里面线程池的顶级接口是Executor,但是严格意义上讲Executor并不是一个线程池,而只是一个执行线程的工具.

Java 应用一般架构

- - SegmentFault 最新的文章
原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications. 当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现. 现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求.

AI在运维中的应用

- - IT瘾-geek
要:随着X86分布式技术应用,服务器数量越来越多,网络拓扑结构越来越复杂,运维越来越辛苦,风险越来越高. 智能化运维AIOPS将AI技术应用在运维场景,是DevOps的运维部分,是“开发运维一体化云中心”的重要基础设施之一,其最大的价值在于缩短故障恢复时间,提高IT服务连续性. 本文描述一个运维及在这个场景下对AI的需求,目标是尝试将AI引入运维过程,提高运维效率、缩短故障恢复时间.

xssProject在java web项目中应用

- - Java - 编程语言 - ITeye博客
1.项目引入xssProtect-0.1.jar、antlr-3.0.1.jar、antlr-runtime-3.0.1.jar包. * 覆盖getParameter方法,将参数名和参数值都做xss过滤. * 如果需要获得原始的值,则通过super.getParameterValues(name)来获取
.

使用Gradle构建Java Web应用(译)

- - BlogJava-首页技术区
使用Gradle构建Java Web应用. 本文是发布在 java.net上的一篇摘自于一书中的 节选,介绍了使用 Gradle构建Java Web应用的过程. 刚刚接触Gradle,看到了这篇小文,随手译了出来:-) (2014.01.23最后更新). 在职业生涯和私人生活中,我们中间的许多人要同时管理多个项目.

Java-了解注解及其应用

- - BlogJava-qileilove
  注解就是一种标记,在程序中加了注解就等于加了标记,没加,就没有标记. java编译器、开发工具或是其他程序可以通过反射技术了解你的类或各种元素是否有标记,有什么标记就做什么. 比如:子类重写父类的方法,方法上必须有@override标记;若一个方法已过时不用了,就该方法添加注.   解@Deprecated,调用者反射时就明白这方法已过时.

消除Java应用中的Exception开销

- - 舒の随想日记
抛异常最大的消耗在于构造整个异常栈的过程,如果你的栈很深,特别是用了一些框架的话,这个开销基本是不可忽视的,之前做的一个优化显示当时应用中的一个异常使得整个应用的性能下降至少30%. 最大开销的地方在这里,当你去new一个Exception的时候,会调用父类Throwable的构造函数, Throwable的构造函数中会调用native的fillInStackTrace(),这个方法就会构造整个异常栈了.

JAVA 应用性能监控基础

- - Linux - 操作系统 - ITeye博客
       这里简单介绍了JAVA 应用程序部署linux 服务器上的一些常用监控信息,虽然现在很多自动化监控的东西,但是一些基本的东西,我们还是需要了解.        1.我习惯性先看看 CPU 和内存的使用情况,做一个简单的关注.           命令:top 可以关注运行状态.           命令:大写P:按CPU 使用排序,大写M:按内存使用排序,小写c:详细显示应用       .

Java应用线上排查总结

- - arccode
本文总结了一些常见的线上应急现象和对应排查步骤和工具. 分享的主要目的是想让对线上问题接触少的同学有个预先认知,免得在遇到实际问题时手忙脚乱. 毕竟作者自己也是从手忙脚乱时走过来的. 在线上应急过程中要记住,只有一个总体目标: 尽快恢复服务,消除影响. 不管处于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题不一定能够定位问题,也不一定有完美的解决方案,也许是通过经验判断,也许是预设开关等,但都可能让我们达到快速恢复的目的,然后 保留部分现场,再去定位问题、解决问题和复盘.