前言

几乎所有人都知道，包含安卓，iOS，PC等等几乎所有的软件，所有的前后端程序，都必须要面对一个问题，那就是升级。也许有一些人会问，为什么所有软件都需要升级呢？好吧，也许会有人开玩笑的说：“那肯定是开发程序的人水平不够，永远做不出来一款完美的软件。做出来软件后，需要修修补补才能趋于完善。所以才必须要升级。”这虽然是开玩笑的话，但也不是完全没有道理。如果一个程序员能够做出一个完美的程序，也许这个程序就不需要升级了。当然，这种情况几乎是不存在的。

那么这时候，你可能还是有点疑问“那么到底为什么要升级呢？”答案就是：

1. 修复编码错误、逻辑错误、设计错误等一系列存在的问题，提高安全性；
2. 与时俱进，新增一些用户需要的功能，或者删除一些用户不需要的功能；
3. 进行视觉、操作、流程、功能等一些列优化、改进，提升用户体验；

升级功能看似简单，但是对于一个想持续经营的客户端软件来讲却是一个非常重要的生命线。如果升级程序做不好，造成用户不能升级或者升级失败，就等于说失去了对所有的安装的软件的控制。软件如果想要优化、修补、更新功能只能够重新安装，这对于开发者来讲，这非常严重！！！无疑是相当于灭顶之灾。

PC软件升级发展

在windows8 之前，windows平台一直没有提供一个类似于苹果的AppStore或者Linux的包管理工具。所有在windows下软件的安装、升级、卸载都需要由软件开发者负责。这样就导致windows 下的软件的安装、升级、卸载并没有统一的方式，都是五花八门。但是总体来讲方法都是大同小异，表现方式区别不小。

我们今天主要聊一下window 软件的升级方案发展过程。在早期互联网时代，很多软件的升级都是通过发布离线安装包（升级包）的方式。一般这种包就是一个安装程序，它只负责安装程序需要更新的部分，然后做一些修改注册表之类的事情就达到了升级的功能。也有软件是直接就发布全量的安装包，通过让用户重装来达到升级到最新版本的目的。时至今日，也有很多软件使用的是这种方式，既安装包与升级包为同一个包。这样的好处就是太方便了。也有很多意想不到的坏处，我们下面会讲到。

随着互联网的普及，现在绝大多数PC软件都采用了在线升级的方式。我们先来简单的说一下在线升级.最简单的的在线升级步骤是：

1. 首先客户端发送检测消息（本地版本号）到服务器，服务器返回是否需要更新，以及如果需要更新最新更新包的下载地址。
2. 如果服务器返回需要更新，客户端就根据返回的升级包地址去下载更新包。
3. 执行更新程序的安装，或者解压替换。

上面的是版本号保存在本地，检测是否需要升级放到服务器来进行比较。当然，也可以放到客户端来进行比较，就是下面的步骤：

1. 客户端向服务器发送请求信息，服务器返回最新的版本号以及最新更新包下载地址。
2. 客户端根据返回的最新版本号与本地的版本号进行对比，如果需要升级，就下载最新安装包。
3. 执行更新程序的安装，或者解压替换。

我们还是建议使用第一种比较方式，即，判断是否需要升级放到服务器来控制，这样比较灵活。我们可以控制服务器，来应对突发、异常情况，实现对安装用户的升级控制。

但是对于上面说的在线升级方式，有一种情况，就是升级包就是安装包的情况。这种就需要用户重新安装这样不仅步骤不叫繁琐，安装包大小比较大，下载耗时等一系列缺点。

后来就有了更新包就是只包含改变的文件。这样就可以减少升级包的大小，降低下载时间等一系列问题。但这时候，如果能够使用静默升级，或者其他方式，避免用户介入。就可以方便用户，提升体验。所以，后来又可以将所有更改了的文件，压缩成一个zip包，用户下载完成就可以解压，替换就完成了升级。

再后来，随着敏捷开发方式的普及，软件的升级会变得越来越频繁。对于PC端软件每次升级时主程序以及一些重要的动态库都有可能被更新，所以我们就需求更小的安装包，以及更快捷得的升级方式。于是就产生了比较文件二进制的算法 BsDiff以及谷歌基于BsDiff算法，进一步改进的Courgette算法。这个算法可以让更新包呈数量级别的缩小。使用他们生成的更新包就极度小了，耗时也大大缩短。

另外值得一提的是，随着软件升级包的越来越大，用户更新下载的时间也会越来越长，也有软件采用了静默升级的方式，在用户不知不觉的情况下就进行了升级，给用户的体验会好一些。但是在程序运行的时候，由于文件被占用，进行文件替换可能会出现升级失败。于是谷歌就搞出来一个双目录更新的方法来应对。所谓双目录就是把原来的文件先复制到另一个新的文件夹，更新程序只在新的文件夹进行升级，升级完成后直接从新的目录启动新版本。这也是目前PC端软件比较流行的升级方式。

常见的升级方案

既然每个程序都不可避免升级，我们今天就来讨论一下PC端（本文指windows平台）软件的升级方式。我们在说常用的升级方案前，先说一下升级的大思路：

简单地解析一下：

1. 在线升级采用C/S架构；
2. 客户端只保留当前版本号；服务器保留所有版本信息，包含 版本号、安装包、更新包、md5值列表（也可以是其他计算文件唯一性的值，比如crc32等）；
3. 客户端带版本号访问服务器；服务器根据客户端的版本号进行比较，给客户端返回是否需要升级的信息，和如果需要升级，要下载的更新包地址；
4. 服务器保存各版本md5列表用以每次发版，制作更新包使用（可以是发版程序来制作）；

我们先来看一下常用的升级方式都有哪几种？

1. 全量安装更新：更新包就是安装包（.exe），下载下来安装包和重装的步骤一样，需要用户操作，比如点击下一步来完成更新。
   优点：只需要做安装包即可，无需制作更新包，发版前处理方便。
   缺点：升级包体积大、下载时间久；需要用户操作，不友好；安装过程失败率高。

2. 增量安装更新：更新包为只包含更新文件的安装包（.exe）,不能单独安装使用，只能更新使用。
   优点：体积小，下载时间短。
   缺点：发版前需要单独做一个升级包exe；需要用户操作，不友好；安装失败率高。

3. 资源热更新：对于一些程序启动过程中，不被占用的资源，比如图片、音视频、配置文件、js相关资源可以在程序运行中替换的更新方式。
   优点：更新方式灵活，体积较小；
   缺点：只能更新一些程序运行过程中非占用的资源文件、局限性较大；

4. 全量替换更新：将全量文件，压缩成zip包，更新时候下载zip包。将下载的zip包解压到新的目录中，下次启动新目录中的可执行程序，完成更新。
   优点：更新包为全量安装文件，制作zip包简单；全自动解压到新目录，无需用户干预，体验好；
   缺点：体积大、下载时间久；

5. 增量替换更新：将当前版本与最新版之间的差量文件，取最新的制作成zip压缩包。升级时将原有的目录复制到新目录，将压缩包解压替换到新的目录中，完成升级。
   优点：提交小，下载快；全自动升级，无需用户干预，体验好；
   缺点：发版前需要制作每个版本的升级包（.zip），比较耗时。

针对上面几种常见的更新方式，我们做一个表格来，绿色表示优势，红色表示劣势：

我们还是来对上面的几种更新方式进行总结一下：

1. 替换更新方式 体验上 要优于安装方式；
2. 增量升级方式更 更新包体积（新速度上） 要优于 全量更新方式；
3. 资源热更新局限性很大，不能独自承担一个软件所有的更新任务，可与其他方式配合使用；
4. 发版前后台处理的繁琐比让用户升级繁琐要好；

综上所述，在上面几种常见的方式中，我们还是增量替换升级的方式有很大优势。目前增量更新也是一种比较流行的方式。

接下来我们重点说这种比较常见的升级方式-增量替换。再说之前，我们还需要来弄清楚一个问题，就是什么时候用来检测升级、什么时候会执行升级操作，也就是升级时机。

升级时机

程序检测升级的时机一般就以下几种：

1. 程序启动时候检测一次是否升级，如果需要升级，就升完级才能够进入软件。（静默升级除外）
2. 程序运行的时候，在后台定时检测是否需要升级。程序退出时候也就停止了检测。
3. 做成一个服务，无论程序是否在运行，都会定时检测是否升级，如果升级，就偷偷的进行升级。（感觉很流氓，用的人也很少。）

其中大部分都是程序启动时候先进行检测一次是否升级，如果需要，就执行升级操作，这种方式是常用的检测时机。如果对于升级实时性要求比较高的情况，或者软件长时间运行不关闭的情况，可以考虑第二种情况，即在程序运行过程中，定时检测。

增量替换升级方案

1. 启动器

在提到替换升级方案中，我们要先引入另外一个概念，就是启动器。顾名思义，启动器就是专门负责启动程序的。启动器的原理相当简单，就是读取配置文件中配置（可执行程序的地址），然后进行打开。

为什么要用启动器呢？简单地来讲，就是为了统一程序入口，快捷方式链接到启动器，更新完成后无需更改软件的快捷方式。

具体解释起来就是：这和前面提到的双目录升级方案有关（替换升级方式）。即每一个版本一个文件夹，每一个文件夹就是全量的安装包文件，可以单独运行。这时候这就出现了一个问题，就是我们升级完成后，会出现一个新的文件夹，以后启动也应该启动新的文件夹里面的可执行程序。这时候如果没有启动器，我们就需要更改程序的快捷方式的链接。那么程序有多少快捷方式？都放到哪里？都要找出来并一一的更改，就是一个很大的工程了。所以，我们需要一个统一的程序入口，让快捷方式这些无需因升级而进行更改。

但是具体要运行哪一个版本（文件夹）里的程序呢？这个信息是放在配置文件中的。他的配置文件大概类似于这样的：

[NAME] 
name=app.exe 
[PATH]
path=D:\\soft\\path\\5.0.0.0\\

配置文件里面内容很简单，就是告诉你，要启动哪一个目录下的那个程序。比如说上面例子中的配置文件就是要告诉启动器要启动 “D:\soft\path\5.0.0.0\yapp.exe”这个可执行程序。

启动器我们也有一些要求：

1. 尽可能的简单稳定;
2. 尽量可以独立运行，无需链接其他动态库(使用纯C++，将其他库静态编译到可执行程序中);
3. 兼容性要高，对各种错误要尽可能给出planB（例如，找不到配置文件，要创建新的配置文件，写入默认的地址等）;

启动器就是调用系统函数，直接打开配置文件中的配置文件，主要代码如下：

2. 升级流程

首先，升级我们应该做成一个单独的程序，可以独立运行更好。其次，升级流程应该更可能的全面的处理各种意外情况:

1. 单独做成一个程序，可以独立运行；
2. 尽可能的全面考虑各种意外情况，处理各种意外，至少升级失败让老师有其他选择；
3. 全自动升级， 不出意外无需用户干预；
4. 一定要支持安装包完整性校验，校验通过才可以升级；
5. 升级程序可以对自身以及启动器进行升级；
6. 尽可能支持失败重试、断点续传等功能，提高体验；
7. 升级完成后，要更改配置文件，将启动地址更改为最新包；

我们先模拟一下从版本 V1.0.0.0 --> V2.0.0.0 的整个升级流程：

整个升级流程中，使用我们上面提到的，增量替换更新的在线更新方式。其中：

1. launcher.exe： 就是上面说的启动器；
2. assist.exe ：就是我们的主程序；
3. updater.exe ： 就是这次的重点-升级程序；

我们上面说了启动器launcher.exe的作用以及主要点，下面就不再赘述。简单说一下主程序在升级过程中的作用。由启动器launcher.exe启动了主程序assist.exe之后：

1. assist.exe 首先获取本地的版本号；
2. 拿着版本号去访问接口，接口会在后台进行对比，返回对比结果即：是否需要升级、升级包的地址、升级包的md5值；
3. 如果需要升级就启动升级程序 updater.exe；

接下来，我们详细说一下主角-升级程序updater.exe的流程：

1. 首先把assist.exe的 1~2步重复一遍，即，重新获取本地版本，然后访问接口是否需要更新。这一步主要是为了保证 updater.exe 的程序可以独立运行。就算用户直接双击 updater.exe 也可以正常执行升级过程。
2. 下载更新包.zip之后并校验md5值是否正确。这里如果需要断点续传，需要后台接口的支持。由md5就可以判断下载的更新包是否是完整的。损坏了的更新包需要重新下载，如果一直下载失败，则不能继续进行下一步。
3. 建立新版本的文件夹V2.0.0.0，并将当前版本V1.0.0.0目录所有文件复制到新版本V2.0.0.0目录下。必须是复制，不能剪切，就算当前目录中有文件被占用，使用复制也不会出现问题，如果使用剪切就会失败。（这也是双目录升级实现的第一步）。
4. 将第2步下载的更新包.zip 直接解压到V2.0.0.0目录下。这里如果有重复的，就会直接替换。经历完这一步，V2.0.0.0目录就包含了最新的版本更改，也可以独立运行。（如果updater.exe需要升级，这一步也将最新版本的升级程序进行了升级）。
5. 检测V2.0.0.0目录下是否有 launcher.exe 文件，如果有，就代表需要更新启动器。就需要先把launcher.exe替换掉。
6. 修改启动器的配置文件 setting.ini， 将V2.0.0.0的地址写入配置文件。
7. 启动 launcher.exe重新打开程序，这时候就是进入了V2.0.0.0目录了。完成更新！

我们来看一下下载完成后的主要流程的代码：

最后还有一点，如果上面的哪一步失败了，我们还需要给用户提供一个PlanB,也就是弹出来对话框，告知用户错误，并提供安装包的下载地址。就算升级失败了， 用户还可以选择重装。（当然，我们还是希望用户永远都用不到这个功能，这是万不得已的做法。）

最终效果是这样的：

点击下面蓝色的字，可以直接跳转到浏览器进行下载最新安装包，这就是我们的planB中的一个, 就算用户失败，也可以提供让用户重新安装的机会，而不是什么都做不了。

写在最后

本文有点标题党了，主要还是为了让大家了解一下常见的PC软件的升级原理与流程。以及详细介绍了当前比较流行的一种增量替换升级的实现方法。希望大家看到这里，知道升级的流程与原理并有所思考，就是这篇文章的意义了。

软件安装与升级——yum

yum是通过分析RPM的标头资料后，根据各软件的相关性制作出属性相依时的解决方案，自动处理软件的关联问题，实现软件安装、升级、移除。

为了方便用户软件安装、升级，distribution 会先释出软件，然后将软件放置在一个服务器上,这个服务器可以被称为yum源。目前有许多的yum源，用户在使用yum时，可以找到合适的yum源，里面有许多不同的软件。

查询

如果需要查看原版distribution所提供的软件，或想知道某软件的功能，可以使用yum来查询。

yum [option] [参数] [参数值]

选项与参数
[option]主要的选项有以下几个：

• -y：当yum要等待用户输入时，这个选项可以自动提供yes的响应
• -h：显示帮助信息
• -c：指定配置文件
• -q：安静模式
• -v：详细模式
• -d：设置调试等级（0-10）
• -e：设置错误等级（0-10）
• -R：设置yum处理一个命令的最大等待时间
• -C：完全从缓存中运行，而不去下载或者更新任何头文件
• --installroot=/some/path：将该软件安装在/some/path而不使用默认路径

[参数]的选项有以下几个：

• search：搜寻某个软件名称或是描述(discription)的重要关键字
• list：列出目前yum所管理的所有的软件名称与版本，有点类似rpm -qa
• info：同上，不过有点类似rpm -qai的运行结果
• provides：通过文件搜寻软件，类似rpm -qf的功能

安装与升级

yum [option] [参数] [参数值]

[option]可以参考上面查询的选项。
[参数]则有install/update，install用于安装软件，update用户升级软件，后面都是接对应的软件名。

移除软件

yum [option] remove 软件名称

[option]可以参考上面查询的选项。
移除软件的时候，直接在remove后面接软件名称即可。

yum源配置文件

yum的yum源配置文件一般位于/etc/yum.repos.d目录下，如文件/etc/yum.repos.d/CentOS-Base.repo就是CentOS系统下yum源的配置文件。

# 查看配置文件内容
[root@instance-d619ad0f ~]# vim /etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever - Base
# mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
baseurl=http://mirrors.baidubce.com/centos/$releasever/os/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

如上所示，配置文件中有设置一个名为base的软件库，配置的参数说明如下：

• [base]：软件库的名称，中括号必须存在，里面的名称可以随便取，但不能有两个相同名称的软件库
• name：说明该软件库的意义，只是起到说明作用。
• mirrorlist：设置这个软件库的映射站台，设置了这个映射站台，yum程序会通过该站台寻找yum源，不想用可以注释掉
• baseurl：用户设定实际的yum源，mirrorlist是由yum自动寻找yum源，baseurl是指定一个yum源。
• enabled：设置是否开启使用该软件库，1为启用，0为禁用
• gpgcheck：指定是否需要查阅RPM文件内的数字签名
• gpgkey：数字签名公钥文件的位置

我们可以通过以下指令来查看当前系统中所有软件库。

[root@instance-d619ad0f ~]# yum repolist all
Loaded plugins: langpacks, versionlock
repo id                                repo name                             status
C7.0.1406-base/x86_64                  CentOS-7.0.1406 - Base                disabled
C7.0.1406-centosplus/x86_64            CentOS-7.0.1406 - CentOSPlus          disabled
省略...
C7.4.1708-updates/x86_64               CentOS-7.4.1708 - Updates             disabled
baidu-bcm                              Baidu Cloud Monitor (BCM)             enabled:     66
base/7/x86_64                          CentOS-7 - Base                       enabled:  9,911
base-debuginfo/x86_64                  CentOS-7 - Debuginfo                  disabled
省略...
extras/7/x86_64                        CentOS-7 - Extras                     enabled:    432
extras-source/7                        CentOS-7 - Extras Sources             disabled
fasttrack/7/x86_64                     CentOS-7 - fasttrack                  disabled
updates/7/x86_64                       CentOS-7 - Updates                    enabled:  1,614
updates-source/7                       CentOS-7 - Updates Sources            disabled

修改软件库时产生的问题与解决方法

yum源配置文件都是在/etc/yum.repos.d目录下，且该目录下文件扩展名为.repo的才会被系统认为是yum源配置文件。此外，yum会生成软件库清单并保存到/var/cache/yum中，而yum生成清单时是把软件库名称(即中括号中的文字，如：base)当做一个软件库的唯一标识。所以，当我们更改了软件库的yum源却没有更改软件库名称，可能会造成本机的软件列表与yum源上的软件列表不同步，这样就会出现无法更新的问题。此时我们可以通过如下指令来清除本机上的软件清单。

yum clean [packages|headers|all]

• packages：删除已下载的软件文件
• headers：将下载的软件文件头删除
• all：将所有软件库数据都删除

针对以上问题，我们可以使用yum clean all来解决。

yum 的软件群组功能

当一个项目需要用到许多软件时，我们一个个装未免显得有点麻烦。此时，我们可以使用yum的软件群组功能。

yum [option] [参数] [参数值]

[option]可以参考yum查询中提到的选项。
[参数]有如下选项：

• grouplist：列出所有可能使用的软件群组
• groupinfo：后面接软件群组名称，可以查看软件群组中所有的软件名
• groupinstall：后面接软件群组名称，可以安装软件群组中的所有软件
• groupremove：后面接软件群组名称，可以移除软件群组中所有的软件