配置文件自动化管理方法和系统、配置管理平台和客户端与流程

本发明涉及互联网技术领域，尤其涉及一种配置文件自动化管理方法和系统、配置管理平台和客户端。

背景技术：

随着互联网技术的不断，业务项目也越来越多，项目也越来越复杂，相应的，项目的配置文件也越来越多。为了满足业务需求的变化，一般会在配置文件中设置变量，通过修改配置文件中的变量来满足需求的变更。然而，针对如果快速准确地生成或者更改配置文件，并同步到线上服务器还没有特别好的解决方案。

这主要是因为在系统变复杂的情况下，配置项会越来越多，一方面配置管理变得繁琐，另一方面配置修改后需要重新上线的工作量也非常大。这种情况下就需要一套集中化配置管理系统，一方面提供统一的配置管理，另一方面提供配置变更的自动下发以使得配置变更可以及时生效，现有的统一配置管理系统，常见的有：zookeeper、etcd等等

现有的配置文件自动化管理方案可以如图1所示，server端只需要调用config-server对应的客户端获取配置，然后监听配置变更即可，实现起来较为简单。

confd，它提供了一种新的集成思路，confd的存在类似于快递员，买了东西不需要自己到店取货，confd这个快递员会将货取过来，然后送到家里，并且通知用户端货已经送到了。confd架构流程可以如图2所示。confd是分布式的，较稳定，也更容易上手使用，可以较为简单地接入到自己的用户程序中，然而，confd整体而言比较笨重，对于配置信息的类，回调函数类，都要求是单例的，不关心配置信息内部具体的变动，只有使用者自己去实现这部分功能，实现配置信息类的方法比较繁杂。

zookeeper的主要优势是成熟、健壮以及丰富的特性，然而，zookeeper需要采用java开发，且实现起来较为复杂。

针对现有的配置文件自动化管理方案所存在的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供一种配置文件自动化管理方法和系统、配置管理平台和客户端，以达到简单高效实现文件配置的目的，且可以保证配置文件的正确性和完整性。

一方面，本发明实施例提供了一种配置文件自动化管理方法，包括：

配置管理平台生成版本配置信息；

所述配置管理平台将所述版本配置信息同步配置到多个目标服务器；

在同步配置成功之后，所述配置管理平台发送验证请求到所述多个目标服务器，用于请求验证所述多个目标服务器中各个目标服务器接收到的文件的完整性；

在确定各个目标服务器都验证通过的情况下，确定发布成功；

在确定存在未验证通过的目标服务器的情况下，控制所述多个目标服务器回滚至之前的版本。

另一方面，本发明实施例提供了一种配置文件自动化管理方法，包括：

客户端向目标服务器发送版本更新请求以获取版本配置信息；

所述客户端根据获取的版本配置信息中的版本号，与本地存储的版本号进行比对；

在获取的版本配置信息中的版本号与本地存储的版本号不同的情况下，将所述版本配置信息配置到本地；

对配置后的版本配置信息进行校验，在校验通过的情况下，将所述版本配置信息推送至预设文件夹。

又一方面，本发明实施例提供了一种配置管理平台，包括：

生成模块，用于生成版本配置信息；

同步模块，用于将所述版本配置信息同步配置到多个目标服务器；

发送模块，用于在同步配置成功之后，发送验证请求到所述多个目标服务器，用于请求验证所述多个目标服务器中各个目标服务器接收到的文件的完整性；

确定模块，用于在确定各个目标服务器都验证通过的情况下，确定发布成功；

控制模块，用于在确定存在未验证通过的目标服务器的情况下，控制所述多个目标服务器回滚至之前的版本。

又一方面，本发明实施例提供了一种客户端，包括：

发送模块，用于向目标服务器发送版本更新请求以获取版本配置信息；

比对模块，用于根据获取的版本配置信息中的版本号，与本地存储的版本号进行比对；

配置模块，用于在获取的版本配置信息中的版本号与本地存储的版本号不同的情况下，将所述版本配置信息配置到本地；

校验模块，用于对配置后的版本配置信息进行校验，在校验通过的情况下，将所述版本配置信息推送至预设文件夹。

又一方面，本发明实施例提供了一种配置文件自动化管理系统，包括：上述的配置管理平台、客户端、和多个目标服务器。

上述技术方案具有如下有益效果：由配置管理平台生成版本配置信息，然后将生成的版本配置信息同步配置到多个目标服务器，在配置成功之后，各个目标服务器验证接收到的文件的完整性，只有在确定各个目标服务器都验证通过的情况下，才确定发布成功，如果存在未验证通过的服务器，那么就进行版本回滚。通过上述方案解决了现有的配置文件自动化管理实现过于复杂的技术问题，达到了高效实现文件配置的目的，且可以保证配置文件的正确性和完整性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有的配置文件自动化管理架构示意图；

图2为现有的confd架构流程示意图；

图3为本发明实施例一种配置文件自动化管理方法的流程图；

图4为本发明实施例另一种配置文件自动化管理方法的流程图；

图5为本发明实施例一种配置文件自动化管理装置的结构框图；

图6为本发明实施例另一种配置文件自动化管理装置的结构框图；

图7为本发明实施例一种配置文件自动化管理系统示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

考虑到对于一个可靠的分布式配置平台而言，需要满足如下特性：高可用性，即，服务器集群应该无单点故障，只要集群中还有存活的节点，就能提供服务；容错性，容错性主要针对客户端，应保证即便在配置平台不可用时，也不影响客户端的正常运行；高性能：针对配置平台，主要操作是获取配置，不能因为获取配置给应用带来不可接受的损失；可靠的存储：这包括数据的备份容灾，一致性等，通过数据库和一些运维手段可以解决；近似实时生效：对于配置的变更，客户端应用能够及时感知；负载均衡：为了尽量提升服务器集群的性能及稳定性，应尽量保证客户端的请求能尽量均衡负载到各服务器节点；扩展性：服务器集群应该保证做到无感扩容，以提升集群服务能力。

基于这种需求，在本例中，提供了一种配置文件自动化管理方法，如图3所示，可以包括如下步骤：

步骤301：配置管理平台生成版本配置信息；

其中，配置管理平台具体的可以配置但不限于以下内容：配置生成目录结构：根目录/版本号/服务器ip/项目名称/配置；配置索引路径：根目录/版本号/服务器ip/configlist.md5；配置索引内文件格式：配置路径\t配置内容md5\n；生成一个版本号文件夹，内包含每个node(即，目标服务器)的所有配置。

步骤302：所述配置管理平台将所述版本配置信息同步配置到多个目标服务器；

例如，可以通过如下指令进行远程同步：rsync-av20181018xxxx/ip:port::graystone，以将版本配置信息同步配置到多个目标服务器。

步骤303：在同步配置成功之后，所述配置管理平台发送验证请求到所述多个目标服务器，用于请求验证所述多个目标服务器中各个目标服务器接收到的文件的完整性；

例如：配置管理后台可以发送curl请求verify到刚同步的目标服务器，用于验证每台服务器接收文件的完整性：例如，可以通过如下指令验证：curlip:nodeport/verify/verifyconfig？version＝发布的版本号。

目标服务器到指定目录获取刚同步过来的文件目录，读取configlist.md5，然后，对每个文件的内容进行md5进行校验(判断是否完整)，如果验证成功，则向配置管理平台返回成功，否则，向配置管理平台报错。

步骤304：在确定各个目标服务器都验证通过的情况下，确定发布成功；

步骤305：在确定存在未验证通过的目标服务器的情况下，控制所述多个目标服务器回滚至之前的版本。

在上例中，由配置管理平台生成版本配置信息，然后将生成的版本配置信息同步配置到多个目标服务器，在配置成功之后，各个目标服务器验证接收到的文件的完整性，只有在确定各个目标服务器都验证通过的情况下，才确定发布成功，如果存在未验证通过的服务器，那么就进行版本回滚。通过上述方案解决了现有的配置文件自动化管理实现过于复杂的技术问题，达到了高效实现文件配置的目的，且可以保证配置文件的正确性和完整性。

具体的，在上述步骤304中，在确定各个目标服务器都验证通过的情况下，确定发布成功，可以包括：在确定所述多个目标服务器中各个目标服务器都验证通过的情况下，向所述多个目标服务器发送切换配置命令，其中，所述切换配置指令用于指示目标服务器将所述版本配置信息配置到指定目录中；所述配置管理平台在确定所各个目标服务器都反馈配置成功消息的情况下，确定发布成功。

例如：配置管理平台挨个目标服务器发布完成且所有目标服务器返回curl请求都为成功的情况下，配置管理平台会再次下发switch(切换配置命令)请求到每个目标服务器，每个目标服务器会更新指定版本配置到指定目录和/dev/shm内(不存在configlist.md5的老文件会被删除)更新成功后，在当前switch请求返回成功，否则返回失败及原因。

为了实现对文件完整性的校验，以保证每个目标服务器接收到的是完整的配置文件，以使得每个目标服务器可以同步。配置管理平台发送验证请求到所述多个目标服务器，可以包括：配置管理平台发布版本号到所述多个目标服务器，以触发所述多个目标服务器中的各个目标服务器从接收到的文件的文件目录中读取md5值，并对md5值进行校验，以验证接收到的文件是否完整。

在配置管理平台生成版本配置信息的过程中，需要保证文件的文件名是唯一的，即，需要保证文件名的唯一性，以使得文件在查找的时候不会出现冲突。因此，在接收到添加配置请求的情况下，可以确定请求添加的文件的文件名是否符合唯一性要求；在确定符合唯一性要求的情况下，确定所述请求添加的文件的文件类型是否为预设类型；在确定为预设类型的情况下，将所述请求添加的文件增加至所述版本配置信息中，其中，所述预设类型可以包括但不限于以下至少之一：php、json、xml、ini。即，不仅需要保证文件名的唯一性，还要保证文件的文件类型是有效类型。

在配置管理平台生成版本配置信息的时候，可以对所述多个目标服务器中的各个服务器进行遍历，对各个服务器配置内的变量和常量进行替换，以生成所述版本配置信息。其中，常量或属性是对于一个服务器而言，不经常更改的常量，例如：ip、端口号等，变量是用于服务器分组内定义的可替换的标志：{％变量名％}，变量和常量同名会覆盖常量值。

对于客户端侧而言，在本例中也提供了一种配置文件自动化管理方法，如图4所示，可以包括如下步骤：

步骤401：客户端向目标服务器发送版本更新请求以获取版本配置信息；

步骤402：客户端根据获取的版本配置信息中的版本号，与本地存储的版本号进行比对；

步骤403：在获取的版本配置信息中的版本号与本地存储的版本号不同的情况下，将所述版本配置信息配置到本地；

步骤404：对配置后的版本配置信息进行校验，在校验通过的情况下，将所述版本配置信息推送至预设文件夹。

具体的，客户端向目标服务器发送版本更新请求以获取版本配置信息之前，还可以包括：周期性执行至少一个如下操作：

1)扫描所述目标服务器，判断所述目标服务器是否存在版本更新；

2)扫描本地文件，在确定本地文件存在修改的情况下，对本地文件进行回滚；

3)扫描本地文件的预设文件夹，判断是否存在文件缺失，在确定存在文件缺失的情况下，进行文件恢复操作。

下面结合一个具体实施例对上述方法进行说明，然而，值得注意的是，该实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

本例提供了一种配置文件自动化管理系统，可以包括：配置管理后台(handler)和配置同步客户端(node)，基于该系统可以按照如下方式执行配置流程：

s1：在配置管理后台创建配置：

具体的，可以创建如下配置内容：

配置生成目录结构：根目录/版本号/服务器ip/项目名称/配置

配置索引路径：根目录/版本号/服务器ip/configlist.md5

配置索引内文件格式：配置路径\t配置内容md5\n

生成一个版本号文件夹，内包含每个node的所有配置

s2：配置管理后台在创建配置完成之后，可以rsync(远程同步)新生成的版本配置到每台服务器：

例如，通过如下指令同步：rsync-av20181018xxxx/ip:port::graystone

s3：在同步成功之后，配置管理后台可以发送curl请求verify到刚同步的服务器node服务，用于验证每台服务器接收文件的完整性：

例如，可以通过如下指令验证：curlip:nodeport/verify/verifyconfig？version＝发布的版本号

s4：被请求的node会到指定目录获取刚rsync过来的文件目录，读取configlist.md5，然后，对每个文件的内容进行md5进行校验(判断是否完整)，如果验证成功，则返回成功，否则报错给调用方。

s5：配置管理后台逐个node发布完成且所有node返回curl请求都为成功的情况下，配置管理后台会再次下发switch(切换配置命令)请求到每个node节点，每个node节点会更新指定版本配置到指定目录和/dev/shm内(不存在configlist.md5的老文件会被删除)更新成功后马上在当前switch请求返回成功，否则返回失败及原因。并且记录切换日志到指定目录，并记录当前合法版本版本号，用于重启时回复配置参考。

s6：如果个别服务器发布失败，服务器马上群发回滚命令到之前成功的服务器上，以回滚至之前版本。

上述配置管理后台的设计主要包括：项目管理、配置管理和服务器管理。

1)项目管理，用于配置管理所有项目列表，每个项目为一个目录。

主要字段：项目路径、项目名称、删除标志。

其中，项目列表用于列出所有的项目信息，可以添加、删除、修改、及查看下属配置。

添加项目时，通过目录名、项目名称唯一(只允许英文数字下滑线)方式添加；

编辑项目时，通过目录名，项目名称唯一(只允许英文数字下滑线)方式编辑；

删除项目时，如果项目已经存在配置文件中，则禁止删除。

2)配置管理，用于管理项目内的配置，配置更改提供版本历史记录功能。

主要字段：所属项目、配置文件名(项目内唯一)、文件类型、配置内容、删除标志。

其中，配置列表可以根据项目列出此项目下所有配置列表，也可以列出全部配置列表。

在添加配置时，需要保证文件名在本项目内唯一，文件类型可以包括以下至少之一：php、json、xml、ini等，在配置并提交时，都需要进行格式验证，如果格式验证未通过则禁止提交；

在修改配置时，可以对以上格式和文件名项目内的唯一性进行验证，每次如果配置内容有变化，则会自动产生一条历史记录。

在删除配置时，不是真正删除的，仅是标志状态的更改。

3)服务器常量配置，起到一个模板的作用，每个服务器都会通过这个模板生成一个常量列表，每个服务器都需要进行服务器常量值的配置(例如：服务器的ip、idc等信息)。在发布的时候，如果需要发布配置信息，那么就会根据不同服务器的常量设置替换配置内格式为{％变量名％}的值，以替换成指定对应变量名的值。

主要字段：服务器常量key，服务器常量备注；常量列表：列出所有常量。

在添加常量时，可以添加key；

在修改常量时，可以修改key及备注，其中，备注用于提醒枚举代表的功能。

4)服务器分组配置，用于对现有服务器环境做一个统一分组，例如：线上永丰机房、线上北显机房、线上测试环境。服务器分组内可以配置“变量”，用户可以根据自己需要任意添加配置内可替换的变量名，用于统一环境使用。(例如：env＝online_bx，env＝online_yf)。通过服务器常量和分组变量可以简单地实现多服务器差异自动化配置，每个服务器只可以属于一个分组。

主要字段：分组名称、分组用途备注、任意个数变量；分组列表：服务器可用分组。

在添加分组时，添加服务器分组及变量；

在删除分组时，删除服务器分组；

在修改分组时，修改服务器分组。

5)服务器管理，用于管理被发布服务器的列表，并且在编辑界面可以修改这个服务器专属的常量以及所在服务器分组(内含变量)。如果服务器故障可以临时禁用故障服务器，使其发布时不参与发布。

字段：服务器ip(去重)、服务器端口(rsync的)、备注、服务器分组id、服务器常量。

6)发布管理，用于服务器配置推送发布回滚及历史管理。

在发布的时候，遍历每个服务器，对配置内的变量、常量进行替换，生成配置文件；

目录结构为：服务器ip/版本号/项目路径/配置文件；

索引文件为：版本号/项目路径/configlist.md5，其中，configlist.md5内保存的是服务器ip为起始的所有配置列表和对应的内容md5。

服务器对每个ip发送rsync命令：rsync–av–delete服务器ip目录下的所有ip::graystone/。

在所有服务器都同步成功的情况下，进行下一步，否则终止。发布服务器发送验证本地文件请求，所有服务器节点都会对接收到的文件进行校验，以保证文件的完整性，如果校验成功，则在此次请求返回成功，否则终止发布。

对所有服务器发送服务切换请求，所有服务器将记录此次版本号和上次版本号。对要切换配置文件进行校验保证文件完整然后将配置文件挪到指定目录完成。如果所有服务器有一个失败，则发布服务器可以发送切换回原来版本命令。定期任务扫描本地目标配置是否被修改，如果被修改，则立刻回滚。

上述客户端设计如下：

s1：请求配置服务器，获取最新部署版本；

s2：核对本地版本号和最新发布版本号是否相同，如果不同，则拉取配置到本地；

s3：对本地版本库配置文件进行文件校验；

s4：若校验成功，则将最新配置推送到shm文件夹，如果失败，则马上发动警报，或者停止相关服务。

客户端周期性执行如下操作：

1)扫描线上服务器版本，若发现更新，则定期更新本地配置；

2)本地文件定期扫描，如果发现被修改，则立刻回滚；

3)如果发现本地shm区域文件缺失，则立刻恢复。

通过上述方式实现配置文件自动化管理，实现起来比较方便，且不存在任何依赖，容错性更高。进一步的，客户端有filemd5验证功能，可以保证配置文件的正确性；具有回滚机制，可靠性更强，且可以保证配置文件的统一性。

基于同一发明构思，本发明实施例中还提供了一种配置文件自动化管理装置，如下面的实施例所述。由于配置文件自动化管理装置解决问题的原理与配置文件自动化管理方法相似，因此配置文件自动化管理装置的实施可以参见配置文件自动化管理方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。图5是本发明实施例的配置文件自动化管理装置的一种结构框图，位于配置管理平台中，如图5所示，可以包括：生成模块501、同步模块502、发送模块503、确定模块504和控制模块505，下面对该结构进行说明。

生成模块501，用于生成版本配置信息；

同步模块502，用于将所述版本配置信息同步配置到多个目标服务器；

发送模块503，用于在同步配置成功之后，发送验证请求到所述多个目标服务器，用于请求验证所述多个目标服务器中各个目标服务器接收到的文件的完整性；

确定模块504，用于在确定各个目标服务器都验证通过的情况下，确定发布成功；

控制模块505，用于在确定存在未验证通过的目标服务器的情况下，控制所述多个目标服务器回滚至之前的版本。

在一个实施方式中，发送模块503具体可以发布版本号到所述多个目标服务器，以触发所述多个目标服务器中的各个目标服务器从接收到的文件的文件目录中读取md5值，并对md5值进行校验，以验证接收到的文件的完整性。

在一个实施方式中，确定模块504具体可以在确定各个目标服务器都验证通过的情况下，向所述多个目标服务器发送切换配置命令，其中，所述切换配置指令用于指示目标服务器将所述版本配置信息配置到指定目录中；在确定各个目标服务器都反馈配置成功消息的情况下，确定发布成功。

在一个实施方式中，生成模块501可以在接收到添加配置请求的情况下，确定请求添加的文件的文件名是否符合唯一性要求；在确定符合唯一性要求的情况下，确定所述请求添加的文件的文件类型是否为预设类型；在确定为预设类型的情况下，将所述请求添加的文件增加至所述版本配置信息中，其中，所述预设类型包括以下至少之一：php、json、xml、ini。

在一个实施方式中，生成模块501可以对所述多个目标服务器中的各个目标服务器进行遍历，将各个目标服务器配置内的变量替换为新配置的变量参数，将各个目标服务器配置内的常量替换为新配置的常量参数，以生成所述版本配置信息。

图6是本发明实施例的配置文件自动化管理装置的一种结构框图，位于客户端中，如图6所示，可以包括：发送模块601、比对模块602、配置模块603和校验模块604，下面对该结构进行说明。

发送模块601，用于发送版本更新请求以获取版本配置信息；

比对模块602，用于根据获取的版本配置信息中的版本号，与本地存储的版本号进行比对；

配置模块603，用于在获取的版本配置信息中的版本号与本地存储的版本号不同的情况下，将所述版本配置信息配置到本地；

校验模块604，用于对配置后的版本配置信息进行校验，在校验通过的情况下，将所述版本配置信息推送至预设文件夹。

在一个实施方式中，客户端还用于周期性执行至少一个如下操作：

扫描所述目标服务器，判断所述目标服务器是否存在版本更新；

扫描本地文件，判断本地文件存在修改的情况下，对本地文件进行回滚；

扫描本地文件的预设文件夹，判断是否存在文件缺失，在确定存在文件缺失的情况下，进行文件恢复操作。

上述技术方案具有如下有益效果：由配置管理平台生成版本配置信息，然后将生成的版本配置信息同步配置到多个目标服务器，在配置成功之后，各个目标服务器验证接收到的文件的完整性，只有在确定各个目标服务器都验证通过的情况下，才确定发布成功，如果存在未验证通过的服务器，那么就进行版本回滚。通过上述方案解决了现有的配置文件自动化管理实现过于复杂的技术问题，达到了高效实现文件配置的目的，且可以保证配置文件的正确性和完整性。

在本例中，还提供了一种配置文件自动化管理系统，如图7所示，可以包括：上述的配置管理平台、客户端、和多个目标服务器。

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrativelogicalblock)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrativecomponents)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(asic)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动磁盘、cd-rom或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于asic中，asic可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。