升级平台设计思路

升级平台是将要升级的程序放在互联网上一定的位置，然后通过一定的手段（如ftp等）将数据下载到要升级的系统中来，并实现升级。
升级过程一般如下：

升级时应该注意以下问题：
1. 需要升级哪些文件
2. 需要删除哪些文件
3. 是否需要对用户的数据进行备份
4. 是否需要对用户的数据进行升级（如数据库升级）
5. 是否需要修改用户配置信息
6. 是否需要修改注册表信息
最简单而有效的升级方法就是从服务器上下载一些文件，下载完成后，运行其中的一个文件，由这个可运行文件实现升级。这样的升级比较彻底，设计起来也比较简单。但是这种升级每次都要把所有的最新的程序下载到本机上来，这对网络资源是一种损害，因为其无法实现增量升级。
增量升级是升级程序最大的困难，所以在这探讨一下增量升级的原理，以及设计方案。
首先来说明一下文件增量升级。
假设原来的版本是1.0，里面有10个文件，分别为a01、a02、a03…a10。而版本1.1需要增加两上文件b01,b02,同时删除原来的文件a06，而版本1.2需要增加c01,c02,c03，同时删除a02和b01。（注：这里不考虑更新原来已经存在的文件的问题，这个可以当做增加一个文件来处理，只是这在升级时会覆盖原来的文件而已）如下图所示。
版本 内容
1.0 a01,a02,a03,a04,a05,a06,a07,a08,a09,a10
1.1 a01,a02,a03,a04,a05, ,a07,a08,a09,a10,b01,b02
1.2 a01, ,a03,a04,a05, ,a07,a08,a09,a10, ,b02,c01,c02,c03

方案1：
因为会有跨版本升级的问题，而且还要兼顾升级平台操作的简便性。每次记录只记录这个版本和上一个版本的更新情况，对于跨版本的长级，可以通过程序的自动记算而得到。
文件 内容
1.0—1.1 -a06+b01+b02
1.1—1.2 -a02-b01+c01+c02+c03
上面是记录内容，对于1.0升级到1.3，升级自动通过对1.0—1.1和1.1—1.2两个文件进行解释，自动得到升级的内容为“-a02-a06+b02+c01+c02+c03”，这里面没有对b01进行操作，因为b01在两次升级后刚好抵消。
通过上种升级方式，对于升级平台管理端的设计会相对容易，但是在升级进跨版的计算将是一个很复杂的工作，所以要进行优化，以加速解释速度。

方案2：
如果要减轻升级程序的计算压力，还可以采用如下的升级方案：每有一个新的版本时，会对以前所有的版本进行便历，更新期升级内容。
文件 内容
1.0—1.2 -a02-a06+b02+c01+c02+c03
1.1—1.2 -a02-b01+c01+c02+c03这种升级方案对于管理平台的要求较高，因为每次升级版本时，都要对以前所有的版进行便历，并对其进行修正。而对于升级程序来讲这样设计就很简单。只为其只要取得其相应版本的升级文件进行解释即可得到要升级的内容。