kubernetes集群的测试方法及装置与流程

1.本发明涉及计算机技术领域，尤其是涉及一种kubernetes集群的测试方法及装置。


背景技术：

2.目前，要测试kubernetes容器集群的组件主要有两种方式：
3.方式一，在公有云上开启的kubernetes容器集群，需要人工登录到kubernetes容器集群内部，在其中的一台节点上执行kubectl的命令来检查节点以及服务的正常情况。
4.方式二，传统自动化测试，需要在其中的一台节点上挂载一个eip(elastic ip address，弹性公网ip地址)，供外部访问，然后通过ssh(secure shell，安全外壳协议)登录到集群内部，执行kubectl的命令来检查节点以及服务的正常情况。
5.第一种直接的人工登录，人工检查，耗时耗力；第二种，虽然实现了自动化的测试，节省了些人力，但有如下不足：申请eip并为某个节点绑定eip，再使用ssh方式登录到节点内部，操作复杂；并且该ssh方式需要节点开启22端口，以便获取节点上的密码，需要获取更多的集群信息，依赖的信息多，需要获取到节点的密码，安全性低；一旦集群所在的网络有所变动，自动化的代码需要做相应的改变(例如：虚机的vpc信息，安全组放开22端口等)。


技术实现要素：

6.本发明的目的在于提供一种kubernetes集群的测试方法及装置，以缓解了现有技术中存在的测试效率低的技术问题。
7.第一方面，本发明实施例提供一种kubernetes集群的测试方法，所述kubernetes集群位于云服务器中，所述kubernetes集群包括组件，所述方法包括：
8.获取待测试的kubernetes集群id；
9.向所述云服务器获取所述待测试的kubernetes集群id对应的ca(certification authority，证书颁发机构)证书；
10.基于所述ca证书，向所述云服务器获取所述待测试的kubernetes集群的组件状态；
11.基于所述待测试的kubernetes集群的组件状态，生成测试结果。
12.在可选的实施方式中，在所述获取待测试的kubernetes集群id的步骤之前，所述方法还包括：
13.部署本地kubernetes集群，所述本地kubernetes集群包括配置文件。
14.在可选的实施方式中，基于所述ca证书，向所述云服务器获取所述待测试的kubernetes集群的组件状态的步骤，包括：
15.基于所述ca证书更新所述配置文件；
16.基于更新后的配置文件，通过kubectl命令在所述云服务器中获取所述待测试的kubernetes集群的资源信息；
17.基于所述待测试的kubernetes集群的资源信息，确定所述待测试的kubernetes集群的组件状态。
18.在可选的实施方式中，所述获取待测试的kubernetes集群id的步骤，包括：
19.接收来自用户设备的测试请求，所述测试请求包括所述待测试的kubernetes集群id。
20.在可选的实施方式中，所述组件包括节点和容器，所述组件状态包括节点状态、容器运行状态以及容器对外提供服务是否正常。
21.在可选的实施方式中，所述kubernetes集群还包括接口，在所述向所述云服务器获取所述待测试的kubernetes集群id对应的ca证书的步骤之前，所述方法还包括：
22.对所述待测试的kubernetes集群的接口进行测试。
23.在可选的实施方式中，向所述云服务器获取所述待测试的kubernetes集群id对应的ca证书的步骤，包括：
24.基于所述待测试的kubernetes集群的接口，向所述云服务器获取所述待测试的kubernetes集群id对应的ca证书。
25.第二方面，本发明实施例提供一种kubernetes集群的测试装置，所述kubernetes集群位于云服务器中，所述kubernetes集群包括组件，所述装置包括：
26.第一获取模块，用于获取待测试的kubernetes集群id；
27.第二获取模块，用于向所述云服务器获取所述待测试的kubernetes集群id对应的ca证书；
28.所述第二获取模块还用于，基于所述ca证书，向所述云服务器获取所述待测试的kubernetes集群的组件状态；
29.生成模块，用于基于所述待测试的kubernetes集群的组件状态，生成测试结果。
30.第三方面，本发明实施例提供一种计算机设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述前述实施方式任一项所述的方法的步骤。
31.第四方面，本发明实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行所述前述实施方式任一项所述的方法。
32.本发明提供的一种kubernetes集群的测试方法及装置，通过获取待测试的kubernetes集群id；向云服务器获取待测试的kubernetes集群id对应的ca证书；以及基于ca证书，向云服务器获取待测试的kubernetes集群的组件状态；基于待测试的kubernetes集群的组件状态，生成测试结果。可以通过测试服务器来实现对云服务器中的kubernetes集群的组件的测试，操作简便，测试结果可信度高，提升了测试效率。
附图说明
33.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
34.图1为本技术实施例提供的一种kubernetes集群的测试方法流程示意图；
35.图2为本技术实施例提供的一种kubernetes集群的测试方法的一个示例；
36.图3为本技术实施例提供的一种kubernetes集群的测试装置结构示意图；
37.图4为本技术实施例提供的一种计算机设备结构示意图。
具体实施方式
38.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
39.因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
40.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
41.需要说明的是，在本发明实施例中，kubernet是一个开源的，用于管理云平台中多个主机上的容器化的应用，kubernetes还可以简称为k8s，该kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，该kubernetes提供了应用部署、规划、更新、维护的一种机制。
42.节点可以是kubernetes中最小的计算硬件单元。节点可以是集群中单个机器的表示。例如，节点可以是数据中心中的物理机，或者是托管在云平台上的虚拟机(例如，云服务器)。可以简单地将每个节点看作一组可以使用的cpu和ram资源。这样，任何节点都可以替代kubernetes集群中的任何其他节点。
43.对于kubernetes集群来说，可以将该kubernetes集群看作一个整体。在kubernetes中，节点汇聚资源，形成更强大的kubernetes集群。该kubernetes集群用于部署程序，该kubernetes集群可以将工作分配给kubernetes集群中的各个节点。如果添加或删除了任何节点，kubernetes集群将根据需要在工作中进行转换。其中，在kubernetes上运行的程序被打包成容器。该容器可以包括程序和依赖项。
44.kubernetes不直接运行容器，它将一个或多个容器封装到一个称为pod的高级结构中。相同pod中的任何容器都将共享相同的名称空间和本地网络。容器可以与其他容器在相同的容器中进行通信。
45.pod可以容纳多个容器，也可以将多个程序添加到单个容器中。
46.kubernetes集群通过入口(ingress)或接口可以与外部进行通信。
47.下面结合附图，对本发明的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。
48.图1为本发明实施例提供的一种kubernetes集群的测试方法流程示意图。该kubernetes集群位于云服务器中，该云服务器可以属于公有云，该kubernetes集群可以包括组件，如图1所示，该方法可以应用于测试服务器中，该测试服务器可以为客户端
(client)服务器，该方法具体可以包括如下步骤：
49.步骤s110，获取待测试的kubernetes集群id。
50.在一些实施例中，在步骤s110之前，可以先在本地部署本地kubernetes集群，该本地kubernetes集群包括配置文件。可以应用该本地kubernetes集群，实现对云服务器中的kubernetes集群进行测试。该配置文件可以为kubeconfig文件，该kubeconfig文件用于存储和组织关于集群、用户、命名空间和身份验证机制的信息。通过kubectl命令行工具，可以使用kubeconfig文件来查找选择集群并与集群的api服务器进行通信所需的信息，默认情况下，kubectl使用的配置文件(kubeconfig文件)为“$home/.kube”目录下config文件。
51.在本地kubernetes集群初始部署完成后，该配置文件的内容可以为空。
52.其中，获取待测试的kubernetes集群id的方式可以具有多种：
53.作为一个示例，用户可以通过用户设备登录测试服务器，并通过用户设备输入待测试的kubernetes集群id。测试服务器可以接收来自用户设备的测试请求，该测试请求可以包括输入的待测试的kubernetes集群id。
54.作为另一个示例，该待测试的kubernetes集群id可以预先存储在测试服务器中。例如，可以预先在测试服务器中存储多个待测试的kubernetes集群id，测试服务器可以按照指定的次序获取并进行测试。
55.步骤s120，向云服务器获取待测试的kubernetes集群id对应的ca证书。
56.测试服务器在获取到待测试的kubernetes集群id后，可以向云服务器请求ca证书。该ca证书可以包括：电子签证机关的信息、公钥用户信息、公钥、权威机构的签字(例如，电子签证机关的签字)和有效期等等。该待测试的kubernetes集群id对应的ca证书可以从该待测试的kubernetes集群对应的配置文件中获取。
57.其中，ca是证书的签发机构，该ca是公钥基础设施(public key infrastructure，pki)的核心。ca是负责签发证书、认证证书、管理已颁发证书的机关(也可以称为电子签证机关)。通过验证ca证书中权威机构的签字，以便确定是否可信。该子签证机关的信息可以指该子签证机关的标识或者该子签证机关的公钥等信息；该公钥用户信息可以指拥有该ca证书的用户信息，该公钥用户信息可以包括该公钥用户的用户名或者标识等信息；该权威机构的签字，可以是指，该权威机构使用私钥加密一段明文数据得到，通过该权威机构的公钥可以对该权威机构的签字进行解密以便确认该签字是否可信；该有效期一般依据需求设置。
58.步骤s130，基于ca证书，向云服务器获取待测试的kubernetes集群的组件状态。
59.基于上述在本地部署本地kubernetes集群以及获取到的ca证书可以实现对待测试的kubernetes集群的组件进行测试。基于此，该步骤s130可以通过如下步骤实现：
60.步骤a)，基于ca证书更新本地kubernetes集群的配置文件；将本地kubernetes集群的配置文件更新为待测试的kubernetes集群的ca证书后，该本地kubernetes集群既可以具有与待测试的kubernetes集群中的各个节点通信的能力。
61.步骤b)，基于更新后的配置文件，通过kubectl命令在云服务器中获取待测试的kubernetes集群的资源信息；
62.该资源信息可以包括节点资源信息以及容器资源信息等等。
63.其中，该节点的资源可以指节点的数量，每个节点的cpu、内存、硬盘以及链接等资
源。该节点资源信息可以包括资源利用率、业务负载的比例情况、等等。
64.该容器资源可以指pod资源，该pod资源信息可以包括pod的数量、正常的pod数量，有问题的pod数量、容器资源利用率、应用程序信息等等，该应用程序信息可以包括并发，请求响应，项目用户数量，订单数等。
65.另外，该资源信息可以为该待测试的kubernetes集群的运行日志，在kubernetes集群运行时，集群内产生的事件可以记录在运行日志中，该事件可以包括节点以及容器在创建或运行过程中发生的事件。
66.需要说明的是，在本技术实施例中，通过kubectl命令可以获取全部的资源信息，也可以获取有针对性的资源信息。例如，可以仅获取已部署成功的节点和容器的数量，和/或未部署完成的节点和容器的数量。
67.步骤c)，基于待测试的kubernetes集群的资源信息，确定待测试的kubernetes集群的组件状态。
68.其中，kubectl是一个用于操作kubernetes集群的命令行接口，通过利用kubectl的各种命令可以实现各种功能。例如，该kubectl命令可以包括kubectl get node命令和kubectl get pod命令。
69.kubernetes api服务提供了kubernetes各类资源对象(例如pod，rc，service等)的增、删、改、查及watch等http rest接口，是整个系统的数据总线和数据中心，命令行工具kubectl客户端，通过命令行参数转换为对kubernetes api服务的rest api调用，并将调用结果输出。
70.其中，组件可以包括节点和容器，组件状态包括节点状态、容器(或pod)运行状态以及容器(或pod)对外提供服务是否正常。根据资源信息可以确定该组件状态。例如，可以根据容器的资源利用率来确定容器对外提供服务器是否正常，如果资源利用率小于一定的阈值(例如，0)则可以任务该容器对外提供服务异常。再例如，可以根据运行日志中的服务异常记录确定各个容器对外提供服务是否正常。再例如，对于节点状态和容器状态可以为节点部署情况以及容器部署情况。该节点和容器的部署情况可以根据未部署完成的节点和容器的数量来确定；还可以根据运行日志中，节点和容器部署完成的事件确定已部署成功的容器，其他容器即为未部署完成的容器。
71.容器是k8s系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在k8s上运行容器化应用的资源对象。
72.步骤s140，基于待测试的kubernetes集群的组件状态，生成测试结果。
73.其中该测试结果可以根据实际需要确定。例如，用户可以仅需要知道待测试的kubernetes集群的组件是否已经部署完成且功能正常，此时，该测试结果可以结果可以为是或否。
74.用户在收到该测试结果后，可以在测试服务器中对具体的各个组件的状态进行查询。
75.本发明实施例通过获取待测试的kubernetes集群id；向云服务器获取待测试的kubernetes集群id对应的ca证书；以及基于ca证书，向云服务器获取待测试的kubernetes集群的组件状态；基于待测试的kubernetes集群的组件状态，生成测试结果。可以通过测试服务器来实现对云服务器中的kubernetes集群的组件的测试，操作简便，测试结果可信度
高，提升了测试效率。
76.在一些实施例中，该kubernetes集群还包括接口，在对kubernetes集群的组件进行测试之前，还可以对待测试的kubernetes集群的接口进行测试。在对待测试的kubernetes集群的接口测试后，如果接口正常，则对kubernetes集群的组件进行测试；如果接口不正常，则可以直接输出测试结果，该测试结果可以指示接口异常。基于此，上述步骤s120具体可以包括：基于待测试的kubernetes集群的接口，向云服务器获取待测试的kubernetes集群id对应的ca证书。
77.在一些实施例中，如图2所示，在一台测试服务器(可通外网)上初始化部署本地kubernetes集群相应的kubernetes组件(该kubernetes组件可以执行kubectl的命令即可，对于待测试的kubernetes集群中的各个组件的测试均可以在该测试服务器上执行)。基于此，该方法可以包括如下步骤：
78.步骤1)，用户访问client上的服务，传递参数容器集群id。其中，该容器集群即为kubernetes集群，该client指测试服务器，该client上的服务指测试服务器上的kubernetes集群组件的测试服务。
79.步骤2)，测试服务器通过容器集群id获取该容器集群的ca证书。其中，共有云中(也可以称为云服务器)的容器openapi服务可以提供接口，通过该接口可以获取在公有云上创建的kubernetes集群的ca证书：即是该kubernetes集群的kubeconfig文件。
80.步骤3)，云服务器返回该容器集群的ca证书。
81.步骤4)，将ca证书导入并替换本地的“$home/.kube/config”文件中。
82.其中，通过将测试服务器上的“$home/.kube/config”文件中的内容替换成该kubernetes集群中的ca证书，这样测试服务器非集群内部的节点，也具备连通到kubernetes集群内部的功能；换句话说，在这个测试服务器上执行kubectl命令，获取到的是该待测试的kubernetes集群内部的资源信息。
83.步骤5)，在本地执行kubectl命令检查节点和pod状态以及其他组件的检查命令。
84.步骤6)，通过serviceip检查pod提供的服务是否正常。基于以上可以通过获取到ca证书即可连通到kubernetes集群内部获取资源信息，因此只需在这台client端部署一套通用检查服务即可，该服务中涵盖如下方面的常规检查点，例如：kubernetes的节点所处状态检查，例如：kubectl get node；pod状态的检查，例如：kubectl get pod；pod提供的服务访问检查，例如nginx 80端口的访问：curl http://serviceip:80/，如果想检查其它共通的检查点，只需添加修改到该脚本中即可。
85.步骤7)，将执行的结果获取的信息做分析。
86.最后对这些检查点查询结果做分析，以上检查点可以封装成一个web服务；接收相应的kubernetes集群id参数，获取该集群的ca证书(即kubeconfig文件内容)，替换到本地的“$home/.kube/config”中；执行如上的命令检查点，均是连通到该kubernetes集群中api server中执行的查询；最终将命令查询的结果做分析，返回到相应信息。
87.步骤9)，将检测分析的结果返回给用户。
88.作为一个示例，该方法还可以通过如下步骤实现：
89.步骤1.1)，开启一台client服务器，该client服务器开通外网，初始化部署一套kubernetes组件，之后任何的集群的测试均可以在这台client服务器上进行；
90.步骤1.2)，部署一套检查脚本，开启80端口，对外提供web服务，基于该web服务可以与用户进行交互，以便进行获取待测试的kubernetes集群的相关信息；
91.步骤1.3)，用户访问该client服务器中的80端口，传递待测试的kubernetes集群id；该待测试的kubernetes集群id可以由用户输入。
92.步骤1.4)，该服务获取到该kubernetes集群的id后，通过公有云上的服务接口获取该集群的ca证书(即该集群的kubeconfig文件内容)，导入到本地“$home/.kube/config”中；
93.步骤1.5)，该client服务器通过kubectl命令访问kubernetes集群中的api server服务，获取该待测试kubernetes集群内部的资源信息；
94.步骤1.6)，执行本地的检查代码，检查相应的集群信息；例如，通过本地的检查代码查看待测试kubernetes集群内部的资源信息中是否存在组件创建成功的事件，如果存在则确定组件创建成功。
95.步骤1.7)，将执行kubectl命令检查点以及其他的检查点返回的结果进行解析，返回给用户；
96.例如：对于测试kubernetes集群的节点状态和pod运行情况，以及pod对外提供的外网nginx服务是否正常；假如client的地址为“ip”，开启的web服务端口为“80”，kubernetes集群的id为“aaabbb”，公有云上的容器服务器获取ca证书的接口为“http://k8sopenapi/userid/cluster_id/ca/file”；可以通过如下方法进行自动化测试：
97.步骤2.1)，用户访问传递该kubernetes集群(待测试的集群)的集群id，例如，可以通过如下url实现：“http://ip:80/php？cluster_id＝aaabbb”。
98.步骤2.2)，服务内部通过该集群id访问k8s的openapi读取ca证书，将该ca证书导入测试服务器的“$home/.kube/config”中。其中，对于读取ca证书可以通过如下url实现：“http://k8sopenapi/userid/aaabbb/ca/file”。
99.步骤2.3)，在执行检查脚本，例如，执行“kubectl get node”和“kubectl get pod”等命令。
100.步骤2.4)，将执行命令获取的结果进行分析整理，最后返回给用户。
101.提出一种对搭建的kubernetes集群中的组件加载、集群节点状态、部署的外网pod连通性等自动化测试方案；能够对在用户在公有云上开启的kubernetes集群以及搭建的外网pod服务实现自动化测试，一键点击即可完成集群的可用性检查，降低测试成本，提高测试效率，节约测试时间；只要给我要测的kubernetes集群的id号，即可实现该kubernetes集群的自动化检查，检查点可继续丰富，具有很高的可扩展性和可移植性。
102.图3为本发明实施例提供的一种kubernetes集群的测试装置结构示意图。其中，该kubernetes集群位于云服务器中，该kubernetes集群包括组件。
103.该装置可以包括：
104.第一获取模块301，用于获取待测试的kubernetes集群id；
105.第二获取模块302，用于向云服务器获取待测试的kubernetes集群id对应的ca证书；
106.第二获取模块302还用于，基于ca证书，向云服务器获取待测试的kubernetes集群的组件状态；
107.生成模块303，用于基于待测试的kubernetes集群的组件状态，生成测试结果。
108.在一些实施例中，该装置还可以包括：
109.部署模块，用于部署本地kubernetes集群，本地kubernetes集群包括配置文件。
110.在一些实施例中，第二获取模块302具体用于：
111.基于ca证书更新配置文件；
112.基于更新后的配置文件，通过kubectl命令在云服务器中获取待测试的kubernetes集群的资源信息；
113.基于待测试的kubernetes集群的资源信息，确定待测试的kubernetes集群的组件状态。
114.在一些实施例中，第一获取模块301具体用于：
115.接收来自用户设备的测试请求，测试请求包括待测试的kubernetes集群id。
116.在一些实施例中，组件包括节点和容器，组件状态包括节点状态、容器运行状态以及容器对外提供服务是否正常。
117.在一些实施例中，该装置还可以包括：
118.接口测试模块，用于对待测试的kubernetes集群的接口进行测试。
119.在一些实施例中，第二获取模块302具体用于：基于待测试的kubernetes集群的接口，向云服务器获取待测试的kubernetes集群id对应的ca证书。
120.本技术实施例提供的kubernetes集群的测试装置，与上述实施例提供的kubernetes集群的测试方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。
121.如图4所示，本技术实施例提供的一种计算机设备700，包括：处理器701、存储器702和总线，所述存储器702存储有所述处理器701可执行的机器可读指令，当电子设备运行时，所述处理器701与所述存储器702之间通过总线通信，所述处理器701执行所述机器可读指令，以执行如上述kubernetes集群的测试方法的步骤。
122.具体地，上述存储器702和处理器701能够为通用的存储器和处理器，这里不做具体限定，当处理器701运行存储器702存储的计算机程序时，能够执行上述kubernetes集群的测试方法。
123.对应于上述kubernetes集群的测试方法，本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述kubernetes集群的测试方法的步骤。
124.本技术实施例所提供的kubernetes集群的测试装置可以为设备上的特定硬件或者安装于设备上的软件或固件等。本技术实施例所提供的装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述方法实施例中相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的系统、装置和单元的具体工作过程，均可以参考上述方法实施例中的对应过程，在此不再赘述。
125.在本技术所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻
辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
126.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
127.在本技术所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本技术的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
128.另外，在本技术提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
129.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述移动控制方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，简称rom)、随机存取存储器(random access memory，简称ram)、磁碟或者光盘等各种可以存储程序代码的介质。
130.应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
131.最后应说明的是：以上所述实施例，仅为本技术的具体实施方式，用以说明本技术的技术方案，而非对其限制，本技术的保护范围并不局限于此，尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本技术实施例技术方案的范围。都应涵盖在本技术的保护范围之内。