第一次亲密接触"兑现Web平台升级的傻瓜化 _Web前端

第一次亲密接触"--实现Web平台升级的傻瓜化

记得自己解决过的最复杂的一个问题就是：通过安装包的方式，为Web平台打补丁或者升级

用户场景：

客户的Web平台在升级的时候，一般是这样：维护人员发布一个补丁包和说明文档。用户按照说明文档进行操作，覆盖服务器上的相关目录下的文件等等（此处省略一千个字）。如果涉及到数据库更新的话，还需要用户手动执行sql更新数据库。

这样的操作非常繁琐，用户一不小心就可能弄错。所以要求我将补丁包制作成exe（Linux下为sh）的格式，用户只要点击下一步就可以完成所有的操作。

粗略的需求：

下面我来粗略的说一下需求：

软件要适用于Win平台和Linux平台
自动备份用户的Web平台
更新失败要能够回滚
能够根据选择，自动更新各个常用的数据库，比如oracle，mysql，达梦，金仓等等
出错记录日志
记录补丁安装信息，并且能够进行补丁间依赖关系识别

这些只是我们根据用户的描述，粗略整理出来的。（其实用户最想要的是类似360安全卫士那样的软件，自动给Web平台打补丁或者升级，什么都不用他操心）。

用户的固然想法很好，但是鉴于成本和时间，根本无法完成。

甲方虐我千百遍，我待甲方如初恋。为了尊重用户的意见，只好修改设计文档，规划了三个阶段去实现用户最终想要的那个产品。

一份详细的需求文档，改了八版才审核通过。真不知道人家是真虐着咱玩儿呢，还是时间真的很富裕。有将近一个月的时间，都在写文档。虽然繁琐了一些，不过多亏了这些文档，和用户也好，和测试也好，不会浪费更多的口舌。

附一张升级工作流程图

思路和相关技术问题

这里大概讲一下核心实现的思路，不涉及具体细节了。

关于适用Win平台和Linux平台的问题

Java本来就是跨平台的语言，所以在Win平台和Linux平台都能正常运行，只不过在处理文件路径时，需要区分一下。但是java运行需要JVM，用户的机器上不一定有。这就需要我们自带JRE。两个平台上需要不用的文件来引导，但是思路都是：使用脚本将自带的JRE设置为JavaHome，设置临时ClassPath，引导Java虚拟机到指定目录下加载入口类。

自动备份用户的Web平台

这个实现比较简单，根据用户选择的Web平台所在的目录，使用代码将该目录打包。主要使用到java.util.zip.ZipFile这个类

更新失败后的回滚

Web平台的文件回滚很好办，只要将已经损坏的Web平台目录删除掉，将刚刚备份的文件解包到相应目录即可。

而数据库的回滚比较麻烦，各个数据库需要不同的脚本支持。而且从安全角度出发，也不允许我们自动回滚数据库。所以如果数据库在更新过程中出错，需要用户手动回滚数据库。

自动更新数据库库

软件支持多少种数据库，就需要带多少种数据库的驱动，并且包含相应的Sql脚本文件。这是软件的核心，也是比较困难的地方。不同的数据库有不同的配置界面，怎么保证扩展和灵活呢？

一般的解决思路就是使用配置文件，大致格式如下：

<servers>
<server name="Oracle" version="9g/10g" editorPanel="com.yourpackage.gui.db.OracleEditorPanel" jars="ojdbc14-10.2.0.2.0.jar"/>
<server name="KingBase" version="V6.1.1" editorPanel="com.yourpackage.gui.db.KingbaseEditorPanel" jars="kingbasejdbc3.jar"/>
<server name="Mysql" version="V5.1.1" editorPanel="com.yourpackage.gui.db.MySqlEditorPanel" jars="mysql-connector-java-5.1.7-bin.jar"/>
<server name="Dameng" version="V6.0.10.08.27" editorPanel="com.yourpackage.gui.db.DamengEditorPanel" jars="DmJdbcDriver.jar"/> 
<server name="sybase" version="V5.5" editorPanel="com.yourpackage.gui.db.SybaseEditorPanel" jars="sybase_jconn.jar"/>
</servers>

注： name= 名称，version=版本，editorPanel=数据库配置界面，jars=使用的数据库驱动jar包。

在配置数据库连接时，将系统支持的数据库加载到下拉列表中，根据用户选择不同的数据库，提供相应的数据库配置界面和驱动，见文章尾部效果图。

记录出错日志

这个不用多说，使用和配置Log4j，日志利器。

补丁安装信息记录

补丁安装信息记录也很好办，我们在用户的web平台根目录下，放置一个记录系统安装过的补丁信息的文件。例如名字叫做SystemInfo.xml，格式如下：

<?xml version="1.0" encoding="UTF-8"?>
<!-- 系统名称， 当前版本， 版次 -->
<systeminfo name="Your Product Name" version="V3.1.2" edition="workspace">
<!--安装的补丁信息-->
<installedpatch>
<patch name="Product Name_V3.1.1_201101101745_integrator" publishtime="2011-01-10 00:00:00" installtime="2011-01-15 00:00:00"/>
<patch name="Product Name_V3.1.1_201103101030_integrator" publishtime="2011-03-10 00:00:00" installtime="2011-10-17 00:00:00"/>
</installedpatch>
</systeminfo>

这个文件可以用来描述用户的系统的名称，版本，版次，已经曾经安装过的补丁。

依赖关系识别

上面讲了补丁安装信息的记录，那么如何处理补丁间的依赖关系呢？

每一个补丁可能需要依赖一个或者多个补丁，盲目的打补丁会损坏用户的系统。这里我们同样用一个文件来描述补丁。例如名字叫PatchCfg.xml,格式如下：

<?xml version="1.0" encoding="UTF-8"?>
<-- 如果此补丁适用多个系统版本，请用英文半角逗号分隔，如suitversion=”V3.1.1,V3.1.2” -->
<patchinfo name="PatchName_V3.1.1_201110111530_integrator" suitproduct="Your Product" suitversion="V3.1.1" suitedition="workspace" publishtime="2011-10-11 00:00:00">
<!--依赖的补丁包链，按照发布时间，从早到晚排列，表示当前的补丁包所依赖的全部补丁。如果当前补丁不需要依赖其他补丁，此节点置空即可-->
<dependschain>
<patch name="PatchName_V3.1.1_201101101745_integrator" publishtime="2011-01-10"/>
<patch name="PatchName_V3.1.1_201103101030_integrator" publishtime="2011-03-10"/>
……
</dependschain>
<!--更新的功能列表-->
<functionlist>
<function namekey="FUNCTION01" desc="修复了xxxx不能正常显示的bug"/>
<function namekey="FUNCTION02" desc="在ProductName_V3.1.1版本的基础上支持webservice调用及回调"/>
<function namekey="FUNCTION03" desc="在ProductName_V3.1.1版本的基础上支持根据当前活动计算将要流转到的后继活动api"/>
<function namekey="FUNCTION04" desc="完善ProductName_V3.1.1版本不能创建wsdl文件的问题"/>
<function namekey="FUNCTION05" desc="完善ProductName_V3.1.1版本不能创建wsdl文件的问题"/>
<function namekey="FUNCTION06" desc="在ProductName_V3.1.1版本的基础上增加支持多数据库"/>
</functionlist>
<!--更新的文件列表-->
<filelist>
<!--文件夹覆盖-->
<overwritedir dir="E:\TestOverwrite01\install" todir="E:\TestOverwrite02\install"/>
<overwritedir dir="E:\TestOverwrite03\temp" todir="E:\TestOverwrite04\temp"/>
<!--需要覆盖的文件示例-->
<overwritefile file="E:\TestOverwrite01\install\build.xml" tofile="E:\TestOverwrite02\install\build.xml"/>
<overwritefile file="E:\testOverwrite03\temp\META-INF\log4j-contribution.xml" tofile="E:\testOverwrite04\temp\META-INF\log4j-contribution.xml"/>
<!--需要删除的文件夹示例，目录不存在继续执行-->
<delete dir="E:\TestOverwrite02\install\temp"/>
<!--需要删除的文件示例，文件不存在继续执行-->
<delete file="E:\testOverwrite03\temp\.ess"/>
<!--需要增加的文件示例-->
<addfile="E:\testOverwrite04\temp\.ess" todir="E:\testOverwrite03"/>
<add file="E:\testOverwrite04\temp\META-INF\definitions.xml" todir="E:\testOverwrite03"/>
<!--需要增加的文件夹示例-->
<add dir="E:\testPatch" todir="E:\testOverwrite04"/>
</filelist>
<!--数据库更新脚本，没有配置此节点则默认不升级数据库-->
<updatesql>
<sqlscript dir="${updatedir}\${userDBType}\update.sql"/>
</updatesql>
<!--标识此补丁是否升级系统版本,没有配置此节点则默认不升级-->
<updatesystemversion to="3.1.2"/>
</patchinfo>

此xml文件则描述了使用的产品名称，版本等信息，并且通过dependschain节点描述了该补丁依赖的其他补丁。只要将dependschain节点下的补丁信息与SystemInfo文件installedpatch节点下的补丁信息进行对比，如果补丁依赖的其他补丁已经安装到了系统中，则该补丁可以安装，否则不允许安装。

原理图如下：