RPM文件维护方法、设备及计算机可读介质与流程

rpm文件维护方法、设备及计算机可读介质
技术领域
1.本技术涉及信息技术领域，尤其涉及一种rpm文件维护方法、设备及计算机可读介质。


背景技术：

2.在软件产品开发的过程中，会通过公网源发布软件产品的软件包。以 centos仓库为例，其对外提供的公网源中会提供不同版本的软件产品的软件包。例如，当前版本的iso基础的软件包放到base目录、当前版本的iso后续更新维护的软件包放到updates目录。此外，针对某些特定场景维护的软件包也单独起一个目录，例如涉及到存储部分的，也可以单独创建一个storage目录进行维护所涉及的软件包。
3.不仅如此，在以上针对特定场景的所创建的目录下的软件包也有他们的特点，但总体上是一样的。随着软件产品的迭代可能会出现某两个不同的版本使用了一部分不同的rpm(red-hat package manager，红帽软件包管理器)文件，但是这两个版本的软件产品中也有很多其它的rpm文件是一样的。以updates目录下的libvirt(一种用于虚拟化平台的管理工具) 为例，这个目录对应于后续用于维护软件包迭代的仓库，其中，当前发行的版本中支持的libvirt是5.8的版本，客户所需要的某些功能在该版本的 libvirt中没有，需要升级来解决。此时，centos的公网源后续就会在updates 目录下提供该版本的软件包。
4.为了支持下载不同的rpm文件，目前大部分所采用的方式是针对该软件产品不同的版本都对应生成一个mirror，各个mirror使用不同的 mirror路径对外提供服务。如果同一个rpm文件无法在多个mirror上复用，将会造成mirror的存储占用量成倍增长。例如，若已知将发布三个版本软件产品，分别是1.0、2.0、3.0，这三个版本需要的rpm文件大部分都是相同的，只有少量文件不同，若一个版本的软件的文件数量为1000+，那么三个版本的软件将需要3000+的文件。而在实际场景中，公司内部研发的过程中产品往往不会只有三个版本，可能是数十个、数百个、甚至数千个等，那么此时的所有版本的软件的文件数量合计将是一个十分庞大的数字，如果无法在不同路径的mirror上复用同一个rpm文件，那么对应的存储空间将是十分庞大，造成存储资源紧张。
5.在此前提下上，公司内部研发因为一些原因(如发现bug需要修复，新功能需要支持等)需要对软件中使用的rpm进行替换、新增、删除时，如果直接对mirror里面的文件进行更新，当文件数量较大的情况下，往往容易出现纰漏。并且，在实际情况中，往往是多个开发人员发同时针对当前一个软件产品进行研发，所以在此过程中就更加容易出现问题，比如两个研发在同一mirror路径下添加了同一个rpm的不同版本，在实际使用的时候，只会有一个人的更改生效，有比如意外删除了另一个研发的rpm 文件等等，并且出现问题之后也没有难以进行溯源，不容易找出是哪一位开发修改了文件。


技术实现要素：

6.本技术的一个目的是提供一种rpm文件维护方法、设备及计算机可读介质，用以解
决现有技术中需要占用的存储空间较大、不易维护的问题。
7.为实现上述目的，本技术提供了一种rpm文件维护方法，所述方法应用于代码管理服务器和后端服务器，包括：
8.代码管理服务器根据开发者向代码管理服务器提交的内容，在软件包源仓库(rpm repo)仓库中添加rpm文件和/或软件包清单(package list) 文件，并生成提交信息，其中，所述package list文件用于标记repo中所包含的rpm文件；
9.代码管理服务器向后端服务器同步最新的rpm repo仓库，并向所述后端服务器提供对应的提交信息；
10.后端服务器根据提交信息以及同步得到的rpm repo仓库执行更新对外提供软件包源服务(mirror)操作，根据package list文件及其所标记的rpm文件向用户提供对应的mirror。
11.进一步地，在rpm repo仓库中添加rpm文件和/或package list文件，包括：
12.对待添加的文件进行类型判断；
13.若所述待添加的文件为rpm文件，创建所述rpm文件的存放目录，并将所述rpm文件存储于所述存放目录下；
14.若所述待添加的文件为非rpm文件，判断所述待添加的文件是否为 package list文件；
15.若所述待添加的文件为package list文件，判断所述package list文件是否符合预设规则；
16.若满足预设规则，添加所述package list文件。
17.进一步地，创建所述rpm文件的存放目录，并将所述rpm文件存储于所述存放目录下，包括：
18.获取所述rpm文件的首字母作为一级目录；
19.获取所述rpm文件的首个分隔符之前的字符作为所述一级目录下的二级目录；
20.将所述rpm文件存储于所述二级目录下，其中，不同版本的同名rpm 文件的首个分隔符之前的字符相同、且首个分隔符之后的字符不同。
21.进一步地，所述预设规则包括：
22.package list文件的命名格式满足规定的格式；
23.package list文件所声明的rpm文件中不存在重复的rpm文件；
24.package list文件所声明的rpm文件已全部存储于rpm repo仓库中。
25.进一步地，在代码管理服务器向后端服务器同步最新的rpm repo 仓库，并向所述后端服务器提供对应的提交信息之前，还包括：
26.在后端服务器执行rpm repo仓库的初始化操作，以使所述后端服务器中的rpm repo仓库从所述代码管理服务器同步获取开发者提交的内容。
27.进一步地，所述提交信息为版本编号(commit id)；
28.向所述后端服务器提供对应的提交信息，包括：
29.将commit id写入到后端服务器的记录版本编号文件(commit file) 文件中。
30.进一步地，后端服务器根据提交信息以及同步得到的rpm repo仓库执行更新mirror操作，包括：
31.后端服务器判断commit file文件是否为空；
32.若所述commit file文件不为空，读取commit file文件中的commit id，并根据所述commit id所对应的所述rpm repo仓库中的rpm文件和 package list文件执行更新mirror操作。
33.进一步地，根据所述commit id所对应的所述rpm repo仓库中的 rpm文件和package list文件执行更新mirror操作，包括：
34.比较当前的package list文件的摘要信息与原mirror的package list文件的摘要信息是否相同；
35.若不相同，则根据所述commit id所对应的所述rpm repo仓库中的rpm文件和package list文件执行更新mirror操作。
36.进一步地，所述代码管理服务器为基于git的代码管理服务器。
37.进一步地，所述后端服务器有多个，并通过负载均衡转发来自用户的请求。
38.进一步地，所述代码管理服务器和所述后端服务器配置由钩子程序，并通过所述钩子程序实现所述rpm文件维护方法。
39.基于本技术的另一方面，还提供了一种rpm文件维护设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述的rpm文件维护方法。
40.本技术实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机程序指令可被处理器执行以实现所述的rpm文件维护方法。
41.与现有技术相比，本技术提供的rpm文件维护方法中，代码管理服务器根据开发者向代码管理服务器提交的内容，在rpm repo仓库中添加rpm文件和/或package list文件，并生成提交信息，代码管理服务器向后端服务器同步最新的rpm repo仓库，并向所述后端服务器提供对应的提交信息，后端服务器根据提交信息以及同步得到的rpm repo仓库执行更新mirror操作。由于所述package list文件能够标记repo中所包含的rpm文件，可以自动化地生成mirror与各个rpm文件之间的对应关系，后端服务器执行更新操作后可以根据package list文件及其所标记的rpm文件向用户提供对应的mirror，从而实现多个mirror对同一rpm 文件的复用，由此，可以在减少整个rpm repo仓库的存储占用的同时，使得软件产品的维护更加便捷、高效。
附图说明
42.通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本技术的其它特征、目的和优点将会变得更明显：
43.图1为本技术实施例提供的一种rpm文件维护方法的处理流程图；
44.图2为本技术实施例中allocaterpms的处理流程图；
45.图3为本技术实施例中deployrepo的处理流程图；
46.图4为本技术实施例中initrepo的处理流程图；
47.图5为本技术实施例中post-receive和sync-repo的处理流程图；
48.附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
49.下面结合附图对本技术作进一步详细描述。
50.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
51.在本技术一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
52.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器 (ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
53.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器 (dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
54.图1示出了本技术实施例提供的一种rpm文件维护方法的处理流程，该方法应用于代码管理服务器和后端服务器，通过代码管理服务器和后端服务器之间的交互配合实现rpm文件的维护。所述方法至少包括以下的处理步骤：
55.步骤s101，代码管理服务器根据开发者向代码管理服务器提交的内容，在rpm repo仓库中添加rpm文件和/或package list文件，并生成提交信息。
56.其中，所述代码管理服务器用于对开发者的软件代码进行版本管理，开发者可以在代码开发的过程中将新的代码提交至代码管理服务器，以便于各个开发者之间实现开发过程的协同。在本技术实施例的方案中，所述代码管理服务器可以是基于git的代码管理服务器，其中，git是一个开源的分布式版本控制系统，可以有效、高速的在代码开发过程中进行版本管理。由此，可以支持rpm文件，package list文件的更改历史版本查询，使得用户可以便捷的了解这些文件的历史修改情况，此外也可以快速地回溯mirror上的rpm文件的历史版本。
57.本实施例中，添加的rpm文件以rpm为扩展名的文件，而所述packagelist文件是一种用于标记rpm文件的软链接，用于标记repo中所包含的 rpm文件，只有在package list文件中声明了的rpm文件才会出现在最终的repo中。
58.本技术实施例中添加rpm文件和/或package list文件时的处理流程至少包括以下的处理步骤：
59.步骤s201，对待添加的文件进行类型判断。
60.步骤s202，若所述待添加的文件为rpm文件，创建所述rpm文件的存放目录，并将所述rpm文件存储于所述存放目录下。
61.步骤s203，若所述待添加的文件为非rpm文件，判断所述待添加的文件是否为
package list文件。
62.步骤s204，若所述待添加的文件为package list文件，判断所述packagelist文件是否符合预设规则。
63.步骤s205，若满足预设规则，添加所述package list文件。
64.在添加rpm文件时，可以先创建与rpm文件的文件名相关的存放目录，然后将所述rpm文件存储于所述存放目录下。具体地，在创建存放目录时，可以先获取所述rpm文件的首字母作为一级目录。例如，若rpm 文件的文件名为abrt-2.4.1.x86_64.rpm，则此时会基于该rpm文件创建名为a的一级目录。然后，继续获取所述rpm文件的首个分隔符之前的字符作为所述一级目录下的二级目录，以前述的rpm文件为例，其分隔符
“‑”
之前的字符为abrt，则对应的二级目录是abrt。由此，可以将所述 rpm文件存储于所述二级目录下，对于前述的rpm文件 abrt-2.4.1.x86_64.rpm，将会存储于rpm repo仓库的a/abrt目录下。
65.本技术实施例中，可以根据预先设定的命名规则，使得不同版本的同名rpm文件的首个分隔符之前的字符相同、且首个分隔符之后的字符不同，由此可以通过添加rpm文件的方式，自动化的将同名且不同版本的 rpm文件存储于合适的存储位置，便于后续在更新mirror时快速找到对应的rpm文件。例如，对于另一个rpm文件abrt-2.5.2.x86_64.rpm，将会同样存储于a/abrt目录下。
66.在添加package list文件时，可以在添加之前先判断所述package list 文件是否符合预设规则，若满足预设规则，则添加所述package list文件，若不满足预设规则，则可以不添加package list文件，可以向用户反馈添加失败的提示信息。
67.在本技术实施例中，所述预设规则可以至少包括以下几项：packagelist文件的命名格式满足规定的格式；package list文件所声明的rpm文件中不存在重复的rpm文件；package list文件所声明的rpm文件已全部存储于rpm repo仓库中。在判断时，可以依次判断是否同时满足这几项，例如，可以先判断package list文件的命名格式是否满足规定的格式，满足规定的格式时，再判断package list文件所声明的rpm文件中是否不存在重复的rpm文件，若不存在重复的rpm文件，则继续判断package list 文件所声明的rpm文件是否已全部存储于rpm repo仓库中，若为是，则可以成功添加该package list文件，否则添加失败。通过上述预设规则的限制，可以使得添加完成的package list文件符合后续在更新mirror时的要求，避免更新时出现错误，导致无法对外提供服务。
68.在实际场景中，若需要添加的是除了rpm文件、package list文件之外的其它文件，则可以向用户发送提示信息，由用户确认是否添加。
69.在实际场景中，还可以删除已有的rpm文件及package list文件，其对应的处理流程可以包括以下的处理步骤：
70.步骤s301，判断是否连接到后端服务器；若连接成功，则执行步骤 s302，若连接失败，则结束本次删除操作。
71.步骤s302，删除队列中待删除的repo及其对应的软链接。
72.步骤s303，判断队列中是否还存在未删除的repo；若存在，则再次执行步骤s302，若不存在，则技术本次删除操作。
73.通过上述的处理，可以对rpm repo仓库中包含的内容进行调整更新，以便于提供不同版本的软件包。
74.步骤s102，代码管理服务器向后端服务器同步最新的rpm repo仓库，并向所述后端服务器提供对应的提交信息。
75.在实际场景中，在代码管理服务器向后端服务器同步最新的rpmrepo仓库，并向所述后端服务器提供对应的提交信息之前，还可以在后端服务器执行rpm repo仓库的初始化操作，以使所述后端服务器中的 rpm repo仓库从所述代码管理服务器同步获取开发者提交的内容。其中，所述rpm repo仓库的初始化操作可以包括根据实际场景的需要创建或复制相关rpm repo仓库，以及安装相关操作所必需的软件工具包等，在完成初始化操作之后，后端服务器可以与代码管理服务器配合，完成相关的处理。
76.在本技术的一些实施例中，所述提交信息为commit id，该commit id 为开发者在每次提交新的代码时所产生的标识信息，对应于本次提交的代码的内容，每次提交时都会产生唯一的commit id。在向所述后端服务器提供对应的提交信息时，可以将commit id写入到后端服务器的commitfile文件中。在实际场景中，若后端服务器中不存在commit file文件，则可以在需要时创建一个新的commit file文件，并将commit id写入到该 commit file文件，若已存在commit file文件，则将commit id直接写入 commit file文件即可。
77.步骤s103，后端服务器根据提交信息以及同步得到的rpm repo仓库执行更新mirror操作，根据package list文件及其所标记的rpm文件向用户提供对应的mirror。其中，mirror是指基于package list文件和对应 rpm文件所构建的repo所对应的访问路径，用户可以通过访问mirror 来获取repo的内容。
78.该方法中所述package list文件能够标记repo中所包含的rpm文件，可以自动化地生成mirror与各个rpm文件之间的对应关系，后端服务器执行更新操作后可以根据package list文件及其所标记的rpm文件向用户提供对应的mirror，从而实现多个mirror对同一rpm文件的复用，由此，可以在减少整个rpm repo仓库的存储占用的同时，保持较低的维护成本，同时兼顾资源占用和维护成本，便于实现多构架的软件开发，针对不同构架，仅需要将不同架构的rpm repo仓库创建一个源，后端服务器的指定目录下，从而实现对外的统一访问。
79.后端服务器根据提交信息以及同步得到的rpm repo仓库执行更新 mirror操作时，可以先判断commit file文件是否为空，若所述commit file 文件不为空，则表示开发者提交了新的代码内容，需要对mirror所对应的 rpm包进行更新，此时可以读取commit file文件中的commit id，并根据所述commit id所对应的所述rpm repo仓库中的rpm文件和packagelist文件执行更新mirror操作，在完成后将commit file文件中的commit id 清空。若所述commit file文件为空，则表示没有新的代码提交，无需执行更新mirror操作。
80.在本技术的一些实施例中，还可能存在开发者先后两次提交了重复的内容的情况，此时虽然commit file文件中会写入新的commit id，但是实际上是无需执行更新mirror操作的。因此为了解决此种情况下可能执行无效的更新mirror操作的问题，可以在执行更新mirror操作时，先基于 package list文件先基于package list文件进行一次判断，即比较当前的 package list文件的摘要信息与原mirror的package list文件的摘要信息是否相同，若不相同，则根据所述commit id所对应的所述rpm repo仓库中的rpm文件和package list文件执行更新mirror操作，若相同，则表示新的mirror与原mirror对应的
rpm文件完全相同，无需执行更新mirror 操作。其中，所述摘要信息基于package list文件的内容获得，摘要信息相同，则表示package list文件中的内容也相同，在实际场景中，摘要信息可以是任意基于哈希算法所计算得到的内容，如md5(message-digestalgorithm 5，信息摘要算法第5版)值等。
81.在本技术的一些实施例中，所述后端服务器有多个，并通过负载均衡转发来自用户的请求，实现了多副本的服务方式。当任意一个或多个后端服务器出现故障而无法对外提供服务时，只要有至少一个后端服务器能够正常运行，用户也能够正常访问到需要的mirror。而当存在多个后端服务器能够正常运行时，通过负载均衡的方式也可以平衡各个后端服务器的负载，避免一部分后端服务器的负载过高而影响服务质量。
82.在本技术的另一些实施例中，所述代码管理服务器和所述后端服务器 (backend server)配置由钩子程序(hook)，并通过所述钩子程序实现所述rpm文件维护方法。例如，在本实施例中可以分别采用以下的五个钩子程序(hook)，包括：下发软件包及文件装置(allocaterpms)、部署软件源装置(deployrepo)、后端服务器初始化装置(initrepo)、代码服务器监听后端服务器装置(post-receive)和同步软件源装置(sync-repo)，所述代码管理服务器可以是gitlab代码管理服务器(gitlab server)。
83.其中，allocaterpms负责rpm文件和package list文件的添加，其一种具体的处理流程可以如图4所示，包括以下的处理步骤：
84.步骤s401，针对处理的文件进行类型判断，若是rpm文件，则执行步骤s402，若非rpm文件，则执行步骤s412。
85.步骤s402，判断是否是添加一个新的rpm文件，若是，则执行步骤 s403，若否，则执行步骤s406。
86.步骤s403，针对rpm文件的名称，按照预设规则生成存放rpm文件的目录。
87.步骤s404，将rpm文件存放到先前创建的目录下。
88.步骤s405，将文件的修改提交到代码管理仓库(git仓库)中，结束本次处理。
89.步骤s406，判断是否是替换一个已经存在的rpm文件，若是，则执行步骤s405，若否，则执行步骤s407。
90.步骤s407,判断是否是删除一个已经添加的rpm文件，若是，则执行步骤s408，若否，则结束本次处理。
91.步骤s408，判断该rpm文件是否在系统中存在；若是，则执行步骤 s409，若否，则结束本次处理。
92.步骤s409，获取系统中的package list文件。
93.步骤s410，判断需要删除的rpm文件是否在package list文件中被引用，若是，则结束本次处理，若否，则执行步骤s411。
94.步骤s411，判断是否所有的package list文件都已经检查完毕，若是，则执行步骤s405，若否，则执行步骤s409。
95.步骤s412，判断是否是package list文件，若是，则执行步骤s413，若否，则结束本次处理。
96.步骤s413，判断该package list文件是否已经被锁定，若是，则执行步骤s414，若否，则执行步骤s415。
97.步骤s414，提示使用者，对应的package list文件已经锁定，无法更新，然后结束本次处理。
98.步骤s415，获取package list文件中定义的rpm文件的名称。
99.步骤s416，判断package list文件中声明的rpm文件是否存在于指定的目录中，若是，则执行步骤s417，若否，则执行步骤s418。
100.步骤s417，判断package list文件中定义的rpm文件是否全部检查完毕，若是，则执行步骤s405。
101.步骤s418，提示使用者需要添加对应的rpm到系统中。
102.deployrepo，用于实现rpm repo仓库的部署和软件源的创建 (createrepo)。在实际场景中，可以针对package list文件通过比较当前 mirror与mirror的md5是否相等来看有无更新，最后来判断是否需要执行更新操作。图5示出了deployrepo所执行的一种具体处理流程，包括：
103.步骤s501，等待更新源标记被触发。
104.步骤s502，查看是否有进程正在更新源；若是，则执行步骤s503，若否，则执行步骤s504。
105.步骤s503，等待一段时间，然后执行步骤s502。
106.步骤s504，查看版本标记文件。
107.步骤s505，判断版本标记文件是否被修改；若是，则执行步骤s506。
108.步骤s506，更新本地rpm文件与源描述文件，与控制节点保持一致。
109.步骤s507，获取源描述文件。
110.步骤s508，判断源描述文件是否有更新；若是，则执行步骤s509，若否，则执行步骤s513。
111.步骤s509，生成临时的新的源目录。
112.步骤s510，将原描述文件中声明的rpm文件，创建软链接，并将软链接放到新的源目录中。
113.步骤s511，生成新的源。
114.步骤s512，将公共链接目录链接到新生成的源目录上。
115.步骤s513，判断是否所有的源描述文件都已经处理完成；若是，则执行步骤s501，若否，则执行步骤s507。
116.initrepo，负责在后端服务器上初始化rpm repo仓库，deployrepo 所执行的一种具体处理流程，包括：
117.步骤s601，针对git仓库进行初始化配置。
118.步骤s602，禁用当前后端服务器的防火墙配置，并关闭开机启动。
119.步骤s603，安装该git仓库所需的必要软件包。
120.步骤s604，创建后端服务器上用于同步repo的服务(service)。
121.步骤s605，配置相关服务开机自启动。
122.步骤s606，针对当前的后端服务器进行公钥上传，用于配置免密。
123.步骤s607，重新加载系统配置，并启动相关服务。
124.post-receive，负责在代码管理服务器中与后端服务器进行数据的同步。首先，可
以登陆到各个后端服务器上，然后执行不同架构rpm repo仓库的初始化操作，例如复制相关rpm repo仓库以及安装相关所必需的软件工具包等。
125.在每次开发人员提交最新的代码改动到指定rpm repo仓库后，代码管理服务器会通过post-receive及时同步相关仓库的改动到所有的后端服务器上，同步完成之后，各个后端服务器可以监听到commit file文件有新写入的commit id，从而触发更新mirror操作，其处理流程如图5所示。
126.sync-repo，负责在后端服务器上同步最新的记录信息(commit)，发现有新的commit就开始执行deployrepo。
127.post-receive以及sync-repo所执行的一种具体处理流程，包括了以下的处理步骤：
128.步骤s701，检查rpm文件和package list文件版本。
129.步骤s702，判断rpm文件和package list文件是否有更新；若是，执行步骤s704，若否，则执行步骤s703。
130.步骤s703，等待若干时间，然后执行步骤s701。
131.步骤s704，从配置文件获取所有的源代理节点信息。
132.步骤s705，触发源代理节点根据package list文件(即源描述文件) 生成新的源。
133.步骤s706，判断是否所有的源代理节点都已经完成更新；若是，则结束本次处理，若否，则执行步骤s704。
134.基于同一发明构思，本技术实施例中还提供了一种rpm文件维护设备，该设备对应的方法是前述实施例中的rpm文件维护方法，并且其解决问题的原理与该方法相似。本技术实施例提供的异构数据库的数据迁移设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备实现前述本技术的多个实施例的方法和/或技术方案。
135.特别地，本技术实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本技术的方法中限定的上述功能。
136.需要说明的是，本技术所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器 (cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
137.而在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播
或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
138.可以以一种或多种程序设计语言或其组合来编写用于执行本技术的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
139.附图中的流程图或框图示出了按照本技术各种实施例的设备、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的针对硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
140.作为另一方面，本技术还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机程序指令，所述计算机程序指令可被处理器执行以实现前述本技术的多个实施例的方法和/或技术方案。
141.需要注意的是，本技术可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(asic)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本技术的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本技术的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，ram存储器，磁或光驱动器或软磁盘及类似设备。另外，本技术的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
142.对于本领域技术人员而言，显然本技术不限于上述示范性实施例的细节，而且在不背离本技术的精神或基本特征的情况下，能够以其他的具体形式实现本技术。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本技术的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本技术内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。步骤所对应的序号的数字顺序，并不表示任何特定执行顺序，各个步骤在符合执行逻辑的前提下可以采用任意的顺序组合执行。