本文主要介绍两种热部署方式:Jrebel与devtools
一、热部署与热加载
在应用运行的时升级软件,无需重新启动的方式有两种,热部署和热加载。
对于Java应用程序来说,热部署就是在服务器运行时重新部署项目,热加载即在在运行时重新加载class,从而升级应用。
二、实现原理
热加载的实现原理主要依赖java的类加载机制,在实现方式可以概括为在容器启动的时候起一条后台线程,定时的检测类文件的时间戳变化,如果类的时间戳变掉了,则将类重新载入。
对比反射机制,反射是在运行时获取类信息,通过动态的调用来改变程序行为;
热加载则是在运行时通过重新加载改变类信息,直接改变程序行为。
热部署原理类似,但它是直接重新加载整个应用,这种方式会释放内存,比热加载更加干净彻底,但同时也更费时间。
三、在java中应用
1.生产环境
热部署作为一个比较灵活的机制,在实际的生产上运用还是有,但相对很少,热加载则基本没有应用。分析如下
一、安全性
热加载这种直接修改jvm中字节码的方式是难以监控的,不同于sql等执行可以记录日志,直接字节码的修改几乎无法记录代码逻辑的变化,对既有代码行为的影响难以控制,对于越注重安全的应用,热加载带来的风险越大,这好比给飞行中的飞机更换发动机。
二、适用的情景
技术大部分是跟需求挂钩的,而需要热部署的情景很少。
频繁的部署并且启动耗时长的应用
无法停止服务的应用
在生产中,并没有需要频繁部署的应用,即使是敏捷,再快也是一周一次的迭代,并且通过业务划分和模块化编程,部署的代价完全可以忽略不计,对于现有的应用,启动耗时再长,也并非长到无法忍受,如果真的这么长,那更应该考虑的是如何进行模块拆分,分布式部署了。
对于无法停止服务的应用,比如现在的云计算平台这样分布式应用,采用分批上线也可以满足需求,类似热部署方案应该是放在最后考虑的解决方案。
四、Jrebel与devtools
1.JRebel
JRebel原理
一个javaagent监控系统中的classes和resources