API网关配置更新方法及设备与流程

api网关配置更新方法及设备
技术领域
1.本技术实施例涉及计算机网络技术领域，尤其涉及一种应用程序编程接口(application programming interface，简称api)网关配置更新方法及设备。


背景技术：

2.网络服务通常包括客户端和服务端，api网关是客户端和服务端之间的一个桥梁。api网关作为客户端访问后端服务的统一入口，需要其具备良好的可靠性和高可用能力，同时具有一定的编排和扩展能力。
3.现有的api网关普遍采用以配置文件的方式记录路由信息，当api网关启动后，api网关会自动加载其配置文件至内存，并根据内存中的配置文件实现相关的功能。在需要更新api网关的功能时，只能通过改动api网关的配置文件并重启api网关的方式来实现，无法实现在运行状态下的动态更新，背离了对api网关高可靠和高可用原则的要求。


技术实现要素：

4.本技术实施例提供一种api网关配置更新方法及设备，可以在api网关处于运行状态下实现动态更新，有效提升api网关的可靠性与可用能力。
5.第一方面，本技术实施例提供一种api网关配置更新方法，该方法包括：
6.更新装置在监测到配置平台对api网关进行了更新时，从所述配置平台中获取所述api网关的更新信息，所述api网关采用责任链模式且处于运行状态；
7.当所述更新信息用于变更所述api网关已有的功能配置时，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息；
8.当所述更新信息用于为所述api网关新增功能配置时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包，将所述组件包发送至所述api网关，并根据所述更新信息更新所述api网关对应的内存中的配置信息。
9.在一种可行的实施方式中，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息，包括：
10.所述更新装置使用类加载器将所述更新信息加载至所述api网关对应的内存中。
11.在一种可行的实施方式中，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息，包括：
12.所述更新装置确定所述更新信息对应的更新内容，所述更新内容包括更新所述api网关已有的功能的启停状态与编排顺序；
13.所述更新装置根据所述更新内容，更新所述api网关对应的内存中的配置信息。
14.在一种可行的实施方式中，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息之前，还包括：
15.所述更新装置对所述api网关变更的功能配置进行校验；
16.当所述api网关变更的功能配置符合预设变更规则时，所述更新装置根据所述更
新信息更新所述api网关对应的内存中的配置信息。
17.在一种可行的实施方式中，还包括：
18.当所述api网关变更的功能配置不符合所述变更规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
19.在一种可行的实施方式中，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包之前，还包括：
20.所述更新装置对所述api网关新增的目标功能配置进行校验；
21.当所述api网关新增的目标功能配置符合预设新增规则时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包。
22.在一种可行的实施方式中，还包括：
23.当所述api网关新增的目标功能配置不符合所述新增规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
24.第二方面，本技术实施例提供一种api网关配置更新装置，包括：
25.监测模块，用于在监测到配置平台对api网关进行了更新时，从所述配置平台中获取所述api网关的更新信息，所述api网关采用责任链模式，且处于运行状态；
26.更新模块，用于当所述更新信息用于变更所述api网关已有的功能配置时，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息；当所述更新信息用于为所述api网关新增功能配置时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包，将所述组件包发送至所述api网关，并根据所述更新信息更新所述api网关对应的内存中的配置信息。
27.第三方面，本技术实施例提供一种电子终端，包括：至少一个处理器和存储器；
28.所述存储器存储计算机执行指令；
29.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如第一方面提供的api网关配置更新方法。
30.第四方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如第一方面提供的api网关配置更新方法。
31.本技术实施例所提供的api网关配置更新方法及设备，更新装置在监测到配置平台对api网关进行了更新时，从配置平台中获取api网关的更新信息，其中，该api网关采用责任链模式且处于运行状态；当上述更新信息用于变更api网关已有的功能配置时，更新装置根据更新信息更新api网关对应的内存中的配置信息；当上述更新信息用于为api网关新增功能配置时，更新装置根据上述更新信息从预设组件库中获取新增的目标功能配置对应的组件包，将该组件包发送至api网关，并根据上述更新信息更新api网关对应的内存中的配置信息。本技术实施例可以在无重启情况下，在api网关运行过程中实现对api网关的动态更新，有效提升api网关的可靠性与可用能力。
附图说明
32.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对本技术实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图
是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
33.图1为本技术实施例中提供的一种api网关配置更新系统的架构示意图；
34.图2为本技术实施例中提供的一种api网关配置更新方法的流程示意图；
35.图3为本技术实施例中提供的一种热编排机制流程示意图；
36.图4为本技术实施例中提供的一种动态扩展机制流程示意图；
37.图5为本技术实施例中提供的一种api网关配置更新装置的程序模块示意图；
38.图6为本技术实施例中提供的一种电子设备的硬件结构示意图。
具体实施方式
39.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。此外，虽然本技术中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。
40.需要说明的是，本技术中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本技术的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
41.本技术中说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换，例如能够根据本技术实施例图示或描述中给出那些以外的顺序实施。
42.此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
43.本技术中使用的术语“模块”，是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。
44.随着企业服务上云及微服务化的大力推进，api网关逐渐成为应用落地及转发落地的关键组件，作为企业网络架构中关键的一环，除了需要保证网关服务的高可靠和高可用外，还需在无重启的情况下，提供支持对相关功能进行热编排的能力，同时面对各项目对网关能力的多样化需求，还需要提供集成用户自定义网关功能组件的能力。
45.其中，api是一些预先定义的接口(如函数、http接口)，或指软件系统不同组成部分衔接的约定。api网关是访问一组服务所有api的中央接口，使得客户端的请求可以以统一的方式和规则分发至后端服务；除路由分发外，api网关可以集成重要的安全和管理任务，如身份认证、限流、请求及响应转换等。
46.api网关作为用户或客户端访问后端服务的统一入口，要求其具备良好的高可靠和高可用能力，同时具有一定的编排和扩展能力，现有的api网关扩展装置或方法通常具备以下不足：
47.一、自定义扩展成本高：现有的api网关或网络代理都需要基于c 、lua或go等语言进行扩展，且在进行自定义开发和功能增强时没有统一的标准和接口，需要开发者对其产品有较深入的理解，增加了自定义扩展开发的成本。
48.二、自定义扩展后需要重新编译并重启服务：现有api网关产品，在对其进行自定义扩展或功能增强后，需要对整个项目及新增模块代码进行重新打包或编译，无法实现运行时的动态扩展及编排，背离了对网关高可靠和高可用原则的要求。即一般的基于软件实现的api网关在进行配置更新及功能插拔的时候，均需要重启服务，同时无法在不重启服务及不重新打包编译的情况下，提供网关功能的动态扩展，背离了网关本身对可靠、可用以及时效性的要求。
49.面对上述技术问题，本技术提供了一种api网关编排与动态扩展方法，在基于spring-cloud-gateway框架实现的api网关基础上，借助责任链模式及分布式配置平台，实现了对网关功能进行热编排以及热加载第三方功能组件的动态扩展，以支撑企业对api网关的多样化需求，并提升网关的高可靠及高可用能力。下面采用详细的实施例进行详细说明。
50.以下对本技术实施例中涉及到的相关术语进行解释：
51.spring-cloud-gateway：基于spring-cloud推出的第二代网关框架，可以帮助开发者方便的实现路由转发、协议转换、限流等功能。
52.分布式配置平台：分布式配置平台能够集中化管理应用和服务的不同环境、不同集群的配置，配置后能够实现实时推送到服务端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
53.热编排：指网关可以在不重启服务的情况下，实现相关功能的开启和停止。
54.热加载：指在不需要重新编译网关工程及重启网关服务的前提下，实时加载集成第三方自定义开发的网关功能组件。
55.责任链模式：属于程序开发中设计模式的一种，该模式将请求的发送者和处理者进行解耦，请求者只需将请求发送至处理者，链上的每个处理者都包含下一个处理者的引用，若当前处理者不能请求，则会传递给下一个处理者，使得发送者无需关注处理和请求传递的细节。
56.本技术基于spring-cloud-gateway提出了一种支持api网关进行功能热编排和自定义开发增强的api网关配置更新方法。
57.参照图1，图1为本技术实施例中提供的一种api网关配置更新系统的架构示意图。
58.本技术实施例中提供的api网关配置更新系统，基于spring-cloud-gateway实现，包括由使用责任链模式开发的api网关、分布式配置平台以及更新装置。
59.在一些实施例中，api网关部分如附图1所示，其本身在spring-cloud-gateway框架的基础上实现，通过预设的过滤器接入spring-cloud-gateway的过滤链当中，同时使用责任链的设计模式实现api网关的路由转发、身份认证以及限流等功能，同时该设计模式为各功能的热编排以及后续的动态扩展提供了基础；分布式配置平台模块提供了为不同环境不同集群的服务推送配置的功能；更新装置可以与分布式配置平台交互，既可以监听配置平台相关配置的变化，又可以主动从配置平台获取配置。
60.参照图2，图2为本技术实施例中提供的一种api网关配置更新方法的流程示意图，
在一些实施例中，该方法包括：
61.s201、更新装置在监测到配置平台对api网关的功能进行了更新时，从配置平台中获取api网关的更新信息，该api网关采用责任链模式且处于运行状态。
62.在一些实施例中，用户可以通过分布式配置平台，按照变更需求对指定环境中指定集群的网关配置进行更新，更新内容包括指定功能的启停状态、编排顺序以及相关功能的配置等，更新后由分布式配置平台进行配置发布。
63.s202、当上述更新信息用于变更api网关已有的功能配置时，更新装置根据上述更新信息更新api网关对应的内存中的配置信息。
64.本技术实施例中，由用户在配置平台按照规则修改相应的配置，修改后更新装置会监听到配置的改变，主动拉取新配置进行校验后，更新api网关服务内存中的相关配置。
65.可选地，上述变更api网关已有的功能配置包括更新api网关已有的功能的启停状态与编排顺序、删除api网关已有的功能等。
66.s203、当上述更新信息用于为api网关新增功能配置时，更新装置根据上述更新信息从预设组件库中获取新增的目标功能配置对应的组件包，将该组件包发送至api网关，并根据上述更新信息更新api网关对应的内存中的配置信息。
67.本技术实施例中，第三方按照接口标准开发api网关自定义功能后，主动在分布式配置平台新增相关配置，更新装置收到配置信息后使用类加载器动态将新功能加载至运行中的api网关服务，从而使新功能生效。
68.本技术实施例中提供的api网关配置更新方法，具有以下优点：
69.一、提升了spring cloud gateway的可用性和可维护性，能够在运行时对其进行功能的热编排。例如在互联网秒杀场景下，需要紧急增加限流、ip黑名单等功能，开源原生spring cloud gateway需要重启，无法做到热生效，效率低且对业务造成连续性影响。采用本技术提供的更新装置，配合分布式配置平台，可以高效实现网关功能的热编排，有效应对各种突发场景，保护企业的后端系统。
70.二、提升了spring cloud gateway的扩展能力，开源原生spring cloud gateway在增加扩展功能时，必须通过编译方式将原有代码功能加入到jar包中，不具备动态加载扩展代码能力，降低spring cloud gateway网关的扩展能力，同时扩展功能代码的升级及变动，需要重新编译spring cloud gateway及扩展代码，效率低且可靠性低。本技术提供的更新装置，可以动态加载扩展的jar及相应的功能，无需编译spring cloud gateway网关的代码，扩展功能代码的升级及变动，只需要单独编译扩展功能jar，完成相应扩展jar替换即可，增强系统的可维护性和扩展效率。
71.在一些实施例中，上述更新装置使用类加载器将所述更新信息加载至所述api网关对应的内存中。
72.在一些实施例中，更新装置用于确定所述更新信息对应的更新内容，所述更新内容包括更新所述api网关已有的功能的启停状态与编排顺序；根据所述更新内容，更新所述api网关对应的内存中的配置信息。
73.在一些实施例中，更新装置还包括校验模块，用于对所述api网关变更的功能配置进行校验；当所述api网关变更的功能配置符合预设变更规则时，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息；当所述api网关变更的功能配置不符合
所述变更规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
74.在一些实施例中，上述校验模块还用于：
75.对所述api网关新增的目标功能配置进行校验；当所述api网关新增的目标功能配置符合预设新增规则时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包；当所述api网关新增的目标功能配置不符合所述新增规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
76.参照图3，图3为本技术实施例中提供的一种热编排机制流程示意图，在本技术一种可行的实施方式中，实现热编排的流程为：
77.1、配置更新及发布：用户通过分布式配置平台，按照变更需求对指定环境中指定集群的网关配置进行更新，更新内容包括指定功能的启停状态，编排顺序以及相关功能的配置等，更新后由分布式配置平台进行配置发布。
78.2、配置获取及校验：配置发布后，更新装置的监听器会监听到相关消息并主动拉取更新后配置，拉取后按照约定的标准和规则进行校验，若校验通过则会修改运行时网关服务内存中当前的配置，修改成功后新请求通过网关时默认使用最新编排和配置，无需重新打包发布并重启网关服务；若校验失败则会提醒用户，并继续使用当前配置不做更新。
79.3、编排生效：api网关以责任链的设计模式实现，并且采用配置与服务分离的方式部署，在服务首次启动时会将配置文件加载至内存，在用户更新的配置通过更新装置的校验后，会主动更新网关服务内存中的相关配置参数，使得最新配置可以即时生效，实现网关功能和配置的热编排。
80.在一些实施例中，本技术为api网关支持第三方自定义开发功能的加载设计了一套动态扩展机制，第三方用户可以通过依赖公共接口的形式，进行自定义功能的开发，同时api网关可以以集成的方式对新增功能组件进行动态加载。
81.参照图4，图4为本技术实施例中提供的一种动态扩展机制流程示意图，在本技术一种可行的实施方式中，实现动态扩展的流程为：
82.1、第三方自定义开发：第三方用户通过依赖开放的公共接口并实现接口中的方法，可以为自定义组件注入请求上下文信息，并实现自定义增强功能。
83.2、自定义组件打包：自定义组件开发完成后，第三方以jar包的形式对组件进行打包并放置到指定位置的第三方功能组件库中；
84.3、发布新增功能配置：第三方用户通过热编排机制流程描述中的方式，在分布式配置平台新增相关配置并发布，由更新装置实时进行相关配置的验证机功能组件的热加载。
85.4、功能动态加载：更新装置加载组件包后，更新内存中配置及功能编排顺序，新请求进入网关后新增的责任链节点会执行相关新的功能，即实现无重启情况下的动态扩展。
86.本技术实施例中提供的api网关配置更新方法，巧妙地通过责任链的模式，为功能的插拔提供了基础，同时使用应用与配置分离的模式，将相关功能与其参数都通过配置注入，为api网关的动态扩展及热编排提供了前提。
87.进一步的，本技术实施例降低了对api网关进行管理和功能增强的难度和复杂度，用户可以通过统一的接口及规范，充分利用java语言特性，对网关功能在一定程度上进行开放性的扩展和增强；同时，通过本技术可以实时获取到当前网关的功能启停状态和配置
参数，并进行实时修改和编排，解决了网关作为中间件配置复杂、入门门槛高等问题。
88.本技术实施例借助责任链和配置式的编排模式，充分利用分布式配置平台，实现了对运行时api网关功能的热编排、热插拔以及动态加载自定义开发的新的功能组件等需求，避免了功能增强后进行重新编译打包、发布及重启服务等背离网关高可靠和高可用原则的操作。
89.基于上述实施例中所描述的内容，本技术实施例中还提供一种api网关配置更新装置。参照图5，图5为本技术实施例中提供的一种api网关配置更新装置的程序模块示意图，该api网关配置更新装置包括：
90.监测模块501，用于在监测到配置平台对api网关进行了更新时，从所述配置平台中获取所述api网关的更新信息，所述api网关采用责任链模式，且处于运行状态。
91.更新模块502，用于当所述更新信息用于变更所述api网关已有的功能配置时，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息；当所述更新信息用于为所述api网关新增功能配置时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包，将所述组件包发送至所述api网关，并根据所述更新信息更新所述api网关对应的内存中的配置信息。
92.在一些实施例中，所述更新装置使用类加载器将所述更新信息加载至所述api网关对应的内存中。
93.在一些实施例中，更新模块502用于确定所述更新信息对应的更新内容，所述更新内容包括更新所述api网关已有的功能的启停状态与编排顺序；根据所述更新内容，更新所述api网关对应的内存中的配置信息。
94.在一些实施例中，还包括校验模块，用于对所述api网关变更的功能配置进行校验；当所述api网关变更的功能配置符合预设变更规则时，所述更新装置根据所述更新信息更新所述api网关对应的内存中的配置信息；当所述api网关变更的功能配置不符合所述变更规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
95.在一些实施例中，上述校验模块还用于：
96.对所述api网关新增的目标功能配置进行校验；当所述api网关新增的目标功能配置符合预设新增规则时，所述更新装置根据所述更新信息从预设组件库中获取新增的目标功能配置对应的组件包；当所述api网关新增的目标功能配置不符合所述新增规则时，生成提醒消息，所述提醒消息用于提醒用户所述api网关更新失败。
97.本技术提供的api网关配置更新装置，以责任链模式为基础，以配置和服务分离为前提，可以借助分布式配置平台，实现全场景下运行时api网关的功能编排和配置热更新；同时支持第三方自定义功能组件的动态加载，增强原生网关系统的可维护性和扩展效率，适用于企业各应用及系统对api网关需求的动态扩展装置，用户只需实现统一规范的接口，即可利用本装置实现运行时api网关功能的编排和扩展。
98.进一步的，基于上述实施例中所描述的内容，本技术实施例中还提供了一种电子设备，该电子设备包括至少一个处理器和存储器；其中，存储器存储计算机执行指令；上述至少一个处理器执行存储器存储的计算机执行指令，以实现如上述实施例中描述的征信数据管理方法中的各个步骤，本实施例此处不再赘述。
99.为了更好的理解本技术实施例，参照图6，图6为本技术实施例提供的一种电子设
备的硬件结构示意图。
100.如图6所示，本实施例的电子设备包括：处理器601以及存储器602；其中：
101.存储器602，用于存储计算机执行指令；
102.处理器601，用于执行存储器存储的计算机执行指令，以实现上述实施例中描述的征信数据管理方法中的各个步骤，本实施例此处不再赘述。
103.可选地，存储器602既可以是独立的，也可以跟处理器601集成在一起。
104.当存储器602独立设置时，该设备还包括总线603，用于连接所述存储器602和处理器601。
105.进一步的，基于上述实施例中所描述的内容，本技术实施例中还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，以实现如上述实施例中描述的api网关配置更新方法中的各个步骤，本实施例此处不再赘述。
106.在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
107.所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例的目的。
108.另外，在本技术各个实施例中的各功能模块可以集成在一个处理单元中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个单元中。上述模块集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
109.上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本技术各个实施例所述方法的部分步骤。
110.应理解，上述处理器可以是中央处理单元(英文：central processing unit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digital signal processor，简称：dsp)、专用集成电路(英文：application specific integrated circuit，简称：asic)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
111.存储器可能包含高速ram存储器，也可能还包括非易失性存储nvm，例如至少一个磁盘存储器，还可以为u盘、移动硬盘、只读存储器、磁盘或光盘等。
112.总线可以是工业标准体系结构(industry standard architecture，isa)总线、外部设备互连(peripheral component，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制
总线等。为便于表示，本技术附图中的总线并不限定仅有一根总线或一种类型的总线。
113.上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
114.一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(application specific integrated circuits，简称：asic)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。
115.本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
116.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。