应用于混沌工程的演练方法和系统与流程

1.本技术涉及云计算技术，尤其涉及一种应用于混沌工程的演练方法和系统。


背景技术：

2.对于多元化的应用场景、规模化的服务节点或者高复杂度的系统架构中，经常会遇到各式各样的故障，这些故障可能会导致系统混乱和服务中断。尽管有监测告警和故障处理流程，但是这些属于事后的响应和被动的应对，为了解决这一问题，近年来，混沌工程(chaos engineering)开始兴起，混沌工程是指在系统上进行由经验指导的受控实验，通过观察系统行为，借此发现系统弱点，以期找到问题后改善系统架构和运维模式。
3.随着云原生技术的普及，越来越多的互联网厂商投身于云原生技术中进行产品开发，这同时也推动了云技术的发展。而云原生技术支持多元化的异构容器，异构容器是指属于不同容器进行时的容器，云平台中除了支持流行度高的docker之外，还支持各种类型的容器进行时，例如，containerd、cri-o等。
4.由于当前的混沌工程只支持单一docker的场景，而不能适用于云原生中的多容器进行时的情况，因此，业界亟需解决如何异构容器场景下目标应用混沌工程的问题。


技术实现要素：

5.本技术提供一种应用于混沌工程的演练方法和系统，用以提高混沌工程平台的兼容性和管理效率。
6.第一方面，本技术提供一种应用于混沌工程的演练方法，包括：服务端向代理端发送目标应用的演练命令，所述服务端设置于混沌工程平台中，所述代理端设置于目标容器所在的节点或主机上，所述目标容器为所述目标应用所在的容器；所述代理端或操作端确定所述目标容器对应的目标容器运行时，所述操作端设置于所述目标容器所在的节点上；所述代理端或所述操作端根据所述目标容器进行时，执行所述演练命令。
7.第二方面，本技术提供应用于混沌工程的演练方法的系统，包括：服务端和管理模块，所述管理模块包括代理端或操作端，所述服务端，用于向所述代理端发送目标应用的演练命令，所述服务端设置于混沌工程平台中，所述代理端设置于目标容器所在的节点或主机上，所述目标容器为所述目标应用所在的容器；所述代理端或所述操作端，用于确定所述目标容器对应的目标容器进行时，所述操作端设置于目标容器所在的节点上；所述代理端或所述操作端，还用于根据所述目标容器进行时，执行所述演练命令。
8.第三方面，提供了一种装置，包括处理器，该处理器用于从存储器调用计算机程序，当所述计算机程序被执行时，该处理器用于执行上述第一方面中由服务端执行的方法，或者用于执行上述第一方面中由代理端执行的方法，或者用于执行上述第一方面中由操作端执行的方法。
9.第四方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序包括用于执行上述第一方面中由服务端执行的方法的代码，或者用于执行上述第一方面中
由代理端执行的方法的代码，或者用于执行上述第一方面中由操作端执行的方法的代码。
10.第五方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序包括用于执行上述第一方面中由服务端执行的方法的代码，或者用于执行上述第一方面中由代理端执行的方法的代码，或者用于执行上述第一方面中由操作端执行的方法的代码。
11.在本技术实施例中，提出了一种应用于混沌工程的演练方案，在执行演练过程中，获取目标容器对应的容器运行时，然后再根据不同的容器运行时，将演练操作进行分发执行，从而达到了对异构容器的兼容，也对上层执行操作做了最大的透明化，无需关心底层使用的容器运行时，做到了无侵入兼容，并且适用于云原生架构和主机模式，提高了混沌工程平台的兼容性和管理效率。
附图说明
12.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
13.图1是本技术一实施例的应用场景的示意图；
14.图2是本技术一实施例的混沌工程平台应用于k8s架构的场景示意图；
15.图3是本技术一实施例的混沌工程平台应用于idc机房的场景示意图；
16.图4是本技术一实施例的应用于混沌工程的演练方法的示意图；
17.图5是本技术一实施例的应用于混沌工程的演练方法的流程示意图；
18.图6是本技术又一实施例的应用于混沌工程的演练方法的流程示意图；
19.图7是本技术一实施例的应用于混沌工程的演练方法的流程示意图；
20.图8是本技术一实施例的应用于混沌工程的演练方法的流程示意图；
21.图9是本技术一实施例的装置900的结构示意图。
具体实施方式
22.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
23.为了便于理解，首先对本技术所涉及的名词进行解释：
24.混沌工程：是指在系统上进行由经验指导的受控实验，通过观察系统行为，借此发现系统弱点，以期找到问题后改善系统架构和运维模式。上述系统可以包括但不限于分布式系统、微服务系统、云原生系统等。
25.云原生(cloudnative)：是一种构建和运行应用程序的方法。云原生包括云(cloud)+原生(native)两个部分。“云”表示应用程序位于云平台中，而不是传统的数据中心。“原生”表示应用程序为在云平台应用而设计的，以充分利用云平台的弹性和分布式优势。
26.其中，符合云原生定义的应用程序通常包括以下条件：采用开源堆栈(k8s+docker)进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、devops支持迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
27.容器：可以理解为一种特殊的进程，可以将资源、文件、状态和配置划分到一个独立的空间。这个独立空间可以被转移到任何宿主机器上，并且不影响里面的软件的运行。
28.为了实现容器进程对外界的隔离，容器底层主要运用了命名空间(namespaces)、控制组(control groups)和切根(chroot)。每个运行的容器都有自己的命名空间，不同容器可以通过名字空间区分。控制组是linux内核提供的一种可以限制、记录、隔离进程组的物理资源机制。切根是指通过改变一个程序运行时参考的根目录位置，让不同容器在不同的虚拟根目录下工作，从而相互不直接影响。
29.docker：是一种开源的应用容器引擎，开发者可以利用docker将应用程序以及依赖库打包到一个可移植的镜像中，然后发送到宿主机器上，或者也可以实现虚拟化，容器之间不存在任何接口。docker基于linux容器(linux container，lxc)技术，lxc是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。
30.kubernetes:简称为k8s，是一种用于自动部署、扩展和管理容器化应用程序的开源系统。或者说，是一种容器编排系统，用于容器管理和容器之间的负载平衡。
31.devops：devops是develop与operations的缩写，它是一组过程、方法与系统的统称，用于促进开发(例如，应用程序)、技术运营和质量保障这三方面的沟通、协作与整合。其重视“软件开发人员(dev)”和“it运维技术人员(ops)”之间沟通合作，通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
32.容器运行时接口(container runtime interface，cri)：由k8s定义的一组与容器运行时进行交互的接口。
33.混沌工程工具(chaosblade):是一款开源的遵循混沌工程原理实验模型的实验注入工具，能够提供故障场景实现，帮助分布式系统提升容错性和可恢复性，可实现底层故障的注入。
34.舱(pod)：k8s中的最小容器编排单元，一个pod可以包含多个容器。通常情况下，一个集群中可包括多个节点，每个节点中可包括多个pod。
35.边车(sidecar)容器：通常和任务容器部署在同一个宿主机中，为任务容器提供辅助功能。sidecar容器可以和任务容器共享部分命令空间资源，例如，存储、网络等，从而将部分功能在sidecar容器中运行。
36.容器运行时(container runtime)：指容器运行起来需要的一系列程序和环境。例如，可以指执行容器并在节点上管理容器镜像的软件。目前最广泛应用的容器进行时是docker，其它通用的容器进行时还包括但不限于：rkt、containerd和cri-o等。
37.异构容器：是指隶属于不同容器运行时的容器。例如，采用docker运行的容器和使用cri-o运行的容器属于不同的容器运行时。
38.集群：是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群相当于一个独立的服务器。
39.互联网数据中心(internet data center，idc)机房:是指利用已有的互联网通信线路、带宽资源，建立标准化的机房环境，为企业提供服务器托管、租用等服务。
40.图1是本技术一实施例的应用场景的示意图。如图1所示，混沌工程平台可用于对容器进行故障分发和注入。在混沌工程中执行容器相关的故障演练，主要包括两种情况，第一种情况是在k8s架构下，对pod内的容器进行故障演练。其中，k8s架构可支持多个集群，每
个集群中包括多个节点，每个节点中可支持多个pod。第二种情况是在idc机房中的主机上直接运行的容器中进行演练。例如，混沌工程可以支持对多个idc机房中的容器进行故障演练。每个idc机房中可包括多个主机，每个主机中可支持多个容器。
41.本技术实施例的方案可支持对异构容器的故障演练，异构容器可以指属于不同容器运行时的容器。在一些示例中，k8s架构中的不同集群支持的容器运行时可以不同，或者不同idc机房支持的容器运行时也可以不同。又或者，在一些示例中，同一集群中的不同节点支持的容器运行时可以不同，同一pod支持的容器运行时可以不同，同一idc机房中的不同主机支持的容器运行时也可以不同。
42.图2是本技术一实施例的混沌工程平台应用于k8s架构的场景示意图。如图2所示，在k8s架构下，一个集群中可包括多个节点，每个节点中可支持一个或多个pod，每个pod可支持运行一个或多个容器。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行pods所需的服务。
43.混沌工程平台中设置服务端，每个节点中设置有代理端(agent)和操作端(operator)。服务端可与代理端之间进行通信，并向代理端下发故障演练相关的命令。其中，代理端可作为下发命令的通道，对命令进行解析，并发送至相应的模块或单元。操作端用于在k8s环境下，通过用户自定义资源(custom resource definition，crd)管理混沌实验的注入工具。
44.图3是本技术一实施例的混沌工程平台应用于idc机房的场景示意图。如图3所示，混沌工程平台中可设置服务端，一个idc机房中包括多个主机，每个主机可支持一个或多个容器运行，每个主机中设置有代理端。与图2中的功能类似，服务端可与代理端之间进行通信，并向代理端下发故障演练相关的命令。其中，代理端可作为下发命令的通道，对命令进行解析，并发送至相应的模块或单元。
45.应理解，图1至图3中的应用场景的说明仅仅作为示例而非限定，在实践中，可以在上述场景的基础上作适当的变形和增减，仍然适用于本技术实施例的方案。
46.混沌工程平台如果需要进行容器相关演练，均需要调用容器运行环境提供的接口(即cri)，对相应的容器进行操作，例如，创建容器、删除容器、执行命令等。而当前的演练方案是直接嵌入式支持docker，这种情况存在以下问题：1.扩展兼容问题，即只能支持docker，很难进行扩展对其他容器运行时进行支持；2.和目前云原生大的发展方向不一致，当很多云厂商的容器运行时不是docker时，混沌工程平台不能使用，导致应用场景受到限制。
47.在本技术实施例中，为了解决当前的混沌工程只支持单一docker的场景，而不能适用于云原生中的多容器进行时的情况，提出了一种应用于混沌工程的演练方法和系统，能够在执行故障演练的过程中，根据不同的容器运行环境，将操作进行分发执行，以实现对异构容器的兼容，提高了混沌工程的兼容性和管理效率。
48.下面以具体的实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
49.图4是本技术一实施例的应用于混沌工程的演练方法的示意图。所述方法可应用于图1至图3中所示的场景中，如图4所示，该方法包括以下内容。
50.s401、服务端向代理端发送目标应用的演练命令，服务端设置于混沌工程平台中，代理端设置于目标容器所在的节点或主机上，目标容器为目标应用所在的容器。
51.可选地，代理端和操作端设置于目标容器所在的节点上，节点属于kubernetes支持的集群。或者，代理端设置于目标容器所在的主机上，主机属于互联网数据中心idc机房。其中，操作端用于在k8s架构下，通过crd管理混沌实验的注入工具。操作端只应用于k8s架构中，不在idc机房环境中设置。
52.上述目标应用可以是容器中支持的任何应用程序，本技术实施例对此不作限定。演练命令指示的内容可包括故障演练或者其它受控实验类型。例如，网络延时故障演练，cpu满载故障演练等。
53.s402、代理端或操作端确定目标容器对应的目标容器运行时，操作端设置于目标容器所在的节点上。
54.可选地，在kubernetes架构下，图4的方法还包括：代理端根据演练命令，建立用户自定义资源(crd)，crd用于描述故障注入的参数。代理端或操作端确定目标容器对应的目标容器运行时，包括：操作端监测crd，并根据监测到的故障注入的参数，确定目标容器对应的目标容器运行时。
55.可选地，在idc机房架构下，或者说主机模式下，代理端或操作端确定目标容器对应的目标容器运行时，包括：代理端确定目标容器对应的目标容器进行时。
56.s403、代理端或操作端根据目标容器进行时，执行演练命令。
57.其中，上述执行演练命令的方式可包括两种类型，第一种是根据目标容器进行时建立sidecar容器，在sidecar容器中执行演练命令。由于sidecar容器与目标容器之间共享部分命名空间资源，因此在sidecar容器中执行故障演练，其演练效果和在主容器中进行故障演练的一致，并且可以避免影响主容器中的程序的运行，提高了混沌工程的演练过程中的管理效率和可靠性。
58.例如，在kubernetes架构下，图4的方法还包括：操作端向代理端发送通知指令，以用于指示目标容器进行时。代理端或操作端根据目标容器进行时，执行演练命令，包括：在获取通知指令指示的目标容器进行时之后，代理端调用目标容器进行时对应的目标容器进行时接口cri，创建sidecar容器；代理端调用目标cri，在sidecar容器中执行演练命令。
59.又例如，在idc机房架构下，代理端或操作端根据目标容器进行时，执行演练命令，包括：代理端调用目标容器进行时对应的目标容器进行时接口cri，创建sidecar容器；代理端调用目标cri，在sidecar容器中执行演练命令。
60.第二种执行演练命令的方式是直接在目标容器中执行演练命令。
61.例如，在kubernetes架构下，代理端或操作端根据目标容器进行时，执行演练命令，包括：操作端获取与目标容器进行时对应的演练工具；操作端将演练工具发送至目标容器中；操作端根据演练工具，在目标容器中执行演练命令。
62.又例如，在idc机房架构下，代理端或操作端根据目标容器进行时，执行演练命令，包括：代理端调用目标容器进行时对应的目标容器进行时接口cri，将演练工具传输至目标容器；代理端调用目标cri，在目标容器中执行演练命令。
63.在本技术实施例中，提出了一种应用于混沌工程的演练方案，在执行演练过程中，获取目标容器对应的容器运行时，然后再根据不同的容器运行时，将演练操作进行分发执
行，从而达到了对异构容器的兼容，也对上层执行操作做了最大的透明化，无需关心底层使用的容器运行时，做到了无侵入兼容，并且适用于云原生架构和主机模式，提高了混沌工程平台的兼容性和管理效率。
64.图5是本技术一实施例的应用于混沌工程的演练方法的流程示意图。该方法适用于k8s架构，并利用sidecar容器执行演练命令，如图5所示，该方法包括以下内容。
65.s501、服务端向代理端发送目标应用的演练命令。
66.其中，服务端可以先确定代理端，假设目标应用所在的容器为目标容器，该代理端为目标容器所在的节点上的代理端。
67.作为示例，上述演练命令指示的内容可包括故障演练或其它受控实验类型等。例如，网络延时故障演练，cpu满载故障演练等。
68.可选地，可以使用混沌工程工具(chaosblade)作为故障注入的实验工具，或者也可以采用其它程序实现故障注入，本技术实施例对此不作限定。
69.s502、代理端根据演练命令，生成对应的crd。
70.s503、操作端监测crd，并根据监测到的crd进行解析，确定当前目标容器对应的容器运行时。
71.例如，操作端可以对监测到的crd进行解析，并判断当前集群的容器运行时，并附加到通知指令中，并发送到代理端中。
72.其中，crd是用户自定义资源，可用于描述故障注入的参数等信息。例如，crd可记录服务端下发的命令和参数、以及应用执行的状态等。操作端可通过检测crd，获取与容器运行环境有关的参数，例如pod字段，通过调用k8s api可以获取pod的information信息、container信息，从而确定目标容器对应的容器运行时。
73.s504、操作端向代理端发送通知指令，通知指令中包括目标容器的容器运行时。
74.s505、代理端根据容器运行时，调用该容器运行时对应的容器运行时接口(cri)，创建sidecar容器。
75.本技术的方案在执行容器操作时，可兼容不同容器运行时，将命令分发到异构容器的相应接口，适应云原生架构发展，并且在底层自适应异构容器，对用户做到了无侵入兼容和透明化。
76.s506、代理端调用容器运行时对应的容器运行时接口(cri)，在sidecar容器中执行演练命令。
77.可选地，在执行命令之后，可以将sidecar容器删除。
78.其中，由于sidecar容器与目标容器之间共享部分命名空间资源，因此在sidecar容器中执行故障演练，其演练效果和在主容器中进行故障演练的一致，并且可以避免影响主容器中的程序的运行，提高了混沌工程的演练过程中的管理效率和可靠性。
79.图6是本技术又一实施例的应用于混沌工程的演练方法的流程示意图。该方法适用于k8s架构，并在目标容器中执行演练命令，如图6所示，该方法包括以下内容。
80.s601、服务端向代理端发送目标应用的演练命令。
81.其中，服务端可以先确定代理端，假设目标应用所在的容器为目标容器，该代理端为目标容器所在的节点上的代理端。
82.s602、代理端根据演练命令，生成对应的crd。
83.s603、操作端监测crd，并根据监测到的crd进行解析，确定目标容器的容器运行时。
84.s604、操作端根据容器运行时，将故障演练对应的演练工具透传至目标容器中，在目标容器内执行演练命令。
85.在本技术实施例中，提出了一种应用于混沌工程的演练方案，在执行演练过程中，获取集群中容器的容器运行时，然后再根据不同的容器运行时，将操作进行分发执行，从而达到了对异构容器的兼容，也对上层执行操作做了最大的透明化，无需关心集群底层使用的容器运行时，做到了无侵入兼容，从而紧跟云原生架构发展，提高了混沌工程平台的兼容性和管理效率。
86.图7是本技术一实施例的应用于混沌工程的演练方法的流程示意图。该方法适用于主机模式，并利用sidecar容器执行演练命令，如图7所示，该方法包括以下内容。
87.s701、服务端向代理端发送目标应用的演练命令。
88.其中，服务端可以先确定代理端，其中，假设目标应用所在的容器为目标容器，该代理端为目标容器所在的主机上的代理端。
89.s702、代理端在接收演练命令之后，根据目标容器的容器运行时，创建sidecar容器。
90.其中，该sidecar容器与目标容器之间共享部分命名空间资源。
91.s703、调用容器运行时对应的接口，在sidecar容器中执行演练命令。
92.可选地，在执行完命令之后，可以将sidecar容器删除。
93.例如，操作端可以对监测到的crd进行解析，并判断当前集群的容器运行环境，并附加到通知指令中，并发送到代理端中。
94.图8是本技术一实施例的应用于混沌工程的演练方法的流程示意图。该方法适用于主机模式，并且利用目标容器执行演练命令，如图8所示，该方法包括以下内容。
95.s801、服务端向代理端发送目标应用的演练命令。
96.其中，服务端可以先确定代理端，其中，假设目标应用所在的容器为目标容器，该代理端为目标容器所在的主机上的代理端。
97.s802、代理端在接收演练命令之后，根据目标容器的容器运行时，调用对应的容器运行时接口(cri)，将演练工具透传至目标容器中。
98.s803、调用目标容器对应的容器运行时接口，在目标容器中执行演练命令。
99.在本技术实施例中，提出了一种应用于混沌工程的演练方案，在执行演练过程中，对主机中的容器运行时进行获取，然后再根据不同的容器运行时，将操作进行分发执行，从而达到了对异构容器的兼容，也对上层执行操作做了最大的透明化，无需关心底层使用的容器运行时，做到了无侵入兼容，提高了混沌工程平台的兼容性和管理效率。
100.图9是本技术一实施例的装置900的结构示意图。装置900用于执行上文中由服务端、代理端或者操作端执行的方法。
101.该装置900包括处理器910，处理器910用于执行存储器920存储的计算机程序或指令，或读取存储器920存储的数据，以执行上文各方法实施例中的方法。可选地，处理器910为一个或多个。
102.可选地，如图9所示，该装置900还包括存储器920，存储器920用于存储计算机程序
或指令和/或数据。该存储器920可以与处理器910集成在一起，或者也可以分离设置。可选地，存储器920为一个或多个。
103.可选地，如图9所示，该装置900还包括通信接口930，通信接口930用于信号的接收和/或发送。例如，处理器910用于控制通信接口930进行信号的接收和/或发送。
104.可选地，该装置900用于实现上文各个方法实施例中由服务端、代理端或者操作端执行的方法。
105.需要指出的是，图9中的装置900可以是前述实施例中的各功能模块，也可以是功能模块组成部件(如芯片)，在此不做限定。
106.在本技术实施例中，处理器是一种具有信号的处理能力的电路，在一种实现中，处理器可以是具有指令读取与运行能力的电路，例如cpu、微处理器、gpu(可以理解为一种微处理器)、或dsp等；在另一种实现中，处理器可以通过硬件电路的逻辑关系实现一定功能，该硬件电路的逻辑关系是固定的或可以重构的，例如处理器为asic或pld实现的硬件电路，例如fpga。在可重构的硬件电路中，处理器加载配置文档，实现硬件电路配置的过程，可以理解为处理器加载指令，以实现以上部分或全部单元的功能的过程。此外，还可以是针对人工智能设计的硬件电路，其可以理解为一种asic，例如npu、tpu、dpu等。
107.可见，以上装置中的各单元可以是被配置成实施以上方法的一个或多个处理器(或处理电路)，例如：cpu、gpu、npu、tpu、dpu、微处理器、dsp、asic、fpga，或这些处理器形式中至少两种的组合。
108.此外，以上装置中的各单元可以全部或部分可以集成在一起，或者可以独立实现。在一种实现中，这些单元集成在一起，以片上系统(system-on-a-chip，soc)的形式实现。该soc中可以包括至少一个处理器，用于实现以上任一种方法或实现该装置各单元的功能，该至少一个处理器的种类可以不同，例如包括cpu和fpga，cpu和人工智能处理器，cpu和gpu等。
109.相应地，本技术实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序/指令被处理器执行时，致使处理器实现图4至图8中由服务端所执行的方法中的步骤，或者实现图4至图8中由代理端所执行的方法中的步骤，或者实现图4至图6中由操作端所执行的方法中的步骤。
110.相应地，本技术实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器实现图4至图8中由服务端所执行的方法中的步骤，或者实现图4至图8中由代理端所执行的方法中的步骤，或者实现图4至图6中由操作端所执行的方法中的步骤。
111.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
112.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序
指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
113.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
114.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
115.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
116.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
117.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
118.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括上述要素的过程、方法、商品或者设备中还存在另外的相同要素。
119.以上仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。