记得自己解决过的最复杂的一个问题就是:通过安装包的方式,为Web平台打补丁或者升级
客户的Web平台在升级的时候,一般是这样:维护人员发布一个补丁包和说明文档。用户按照说明文档进行操作,覆盖服务器上的相关目录下的文件等等(此处省略一千个字)。如果涉及到数据库更新的话,还需要用户手动执行sql更新数据库。
这样的操作非常繁琐,用户一不小心就可能弄错 。所以要求我将补丁包制作成exe(Linux下为sh)的格式,用户只要点击下一步就可以完成所有的操作。
下面我来粗略的说一下需求:
这些只是我们根据用户的描述,粗略整理出来的。(其实用户最想要的是类似360安全卫士那样的软件,自动给Web平台打补丁或者升级,什么都不用他操心)。
用户的固然想法很好,但是鉴于成本和时间,根本无法完成。
甲方虐我千百遍,我待甲方如初恋。为了尊重用户的意见,只好修改设计文档,规划了三个阶段去实现用户最终想要的那个产品。
一份详细的需求文档,改了八版才审核通过。真不知道人家是真虐着咱玩儿呢,还是时间真的很富裕。有将近一个月的时间,都在写文档。虽然繁琐了一些,不过多亏了这些文档,和用户也好,和测试也好,不会浪费更多的口舌。
附一张升级工作流程图
这里大概讲一下核心实现的思路,不涉及具体细节了。
Java本来就是跨平台的语言,所以在Win平台和Linux平台都能正常运行,只不过在处理文件路径时,需要区分一下。但是java运行需要JVM,用户的机器上不一定有。这就需要我们自带JRE。两个平台上需要不用的文件来引导,但是思路都是:使用脚本将自带的JRE设置为JavaHome,设置临时ClassPath,引导Java虚拟机到指定目录下加载入口类。
这个实现比较简单,根据用户选择的Web平台所在的目录,使用代码将该目录打包。主要使用到java.util.zip.ZipFile这个类
Web平台的文件回滚很好办,只要将已经损坏的Web平台目录删除掉,将刚刚备份的文件解包到相应目录即可。
而数据库的回滚比较麻烦,各个数据库需要不同的脚本支持。而且从安全角度出发,也不允许我们自动回滚数据库。所以如果数据库在更新过程中出错,需要用户手动回滚数据库。
软件支持多少种数据库,就需要带多少种数据库的驱动,并且包含相应的Sql脚本文件。这是软件的核心,也是比较困难的地方。不同的数据库有不同的配置界面,怎么保证扩展和灵活呢?
一般的解决思路就是使用配置文件,大致格式如下:
在配置数据库连接时,将系统支持的数据库加载到下拉列表中,根据用户选择不同的数据库,提供相应的数据库配置界面和驱动,见文章尾部效果图。
这个不用多说,使用和配置Log4j,日志利器。
补丁安装信息记录也很好办,我们在用户的web平台根目录下,放置一个记录系统安装过的补丁信息的文件。例如名字叫做SystemInfo.xml,格式如下:
这个文件可以用来描述用户的系统的名称,版本,版次,已经曾经安装过的补丁。
上面讲了补丁安装信息的记录,那么如何处理补丁间的依赖关系呢?
每一个补丁可能需要依赖一个或者多个补丁,盲目的打补丁会损坏用户的系统。这里我们同样用一个文件来描述补丁。例如名字叫PatchCfg.xml,格式如下:
<-- 如果此补丁适用多个系统版本,请用英文半角逗号分隔,如suitversion=”V3.1.1,V3.1.2” -->
……
此xml文件则描述了使用的产品名称,版本等信息,并且通过dependschain节点描述了该补丁依赖的其他补丁。只要将dependschain节点下的补丁信息与SystemInfo文件installedpatch节点下的补丁信息进行对比,如果补丁依赖的其他补丁已经安装到了系统中,则该补丁可以安装,否则不允许安装。
原理图如下:
(依赖关系检测示意图)
其余节点则描述了更新的功能清单和补丁对文件的操作。
在PatchCfg.xml上面我们用xml文件描述了补丁安装工具对于文件的操作,不知道你是否看到了ant的影子呢。没错,我基本是按照ant的风格来描述对文件的各种操作。
但是ant运行是需要配置Java环境的,补丁安装工具需要再自带一个ant工具吗,答案是否定的,用户是不会配置JavaHome的。所有的文件操作需要我们自己编写代码来实现,具体可以参考ant的源码,并不难。
此外还有一些技术细节,比如使用代码停止各种Web服务器、日志的输出,使用何种框架来配置工作的步骤 ,限于篇幅就不一一展开了。
附软件最终截图,基本实现了以安装包的形式,为Web平台升级或者打补丁。用户只需要下一步下一步即可。
开始
选择备份目录
选择手动抑或自动更新数据库
数据库配置界面
预安装摘要
文件和思路仅供参考,欢迎有相关需求的朋友留言交流。
原文链接:http://www.67tgb.com/?p=504
欢迎访问:望月听涛