地图服务器的容量测试方法、装置、设备、介质及产品与流程

1.本公开涉及计算机技术领域中的云计算领域，尤其涉及一种地图服务器的容量测试方法、装置、设备、介质及产品。


背景技术：

2.在地图服务中，线上流量的分布和时间段具有关联性，例如早高峰与晚高峰的地图服务需求较多，普通时段的地图服务需求较少。流量可以指地图服务器单位时间内对导航、信息查询等服务请求的处理数量。单位时间可以根据使用需求设置。服务器能够在单位时间内能够处理的服务请求的请求数量可以称为服务器的容量。
3.在实际应用中，服务器的容量越高，成本越高，因此，为了节约成本，通常需要对服务器的容量实时进行调整，准确获知服务器的容量对容量调整起到关键作用。目前，对服务器进行容量测试多是通过历史时段对流量的处理情况进行预估，获得的容量不够准确。


技术实现要素：

4.本公开提供了一种用于电子地图服务器的容量管理场景中的地图服务器的容量测试方法、装置、设备、介质及产品。
5.根据本公开的第一方面，提供了一种地图服务器的容量测试方法，包括：
6.接收针对地图服务器发起的测试请求，生成地图服务器的测试任务；
7.确定至少一个测试场景分别对应的测试词表；
8.从至少一个测试场景中确定与测试任务相匹配的目标测试场景；
9.基于目标测试场景对应目标测试词表，对地图服务器进行容量测试处理，获得地图服务器的目标容量。
10.根据本公开的第二方面，提供了一种地图服务器的容量测试方法，包括：
11.接收压力引擎发送的测试任务的节点测试请求，节点测试请求是基于目标测试场景对应的目标测试词表生成的；
12.响应于节点测试请求，生成压力子任务表；压力子任务表用于记录发压节点的发压状态；
13.确定节点测试请求中的目标测试词表；
14.按照目标测试词表对地图服务器执行发压操作，并更新压力子任务表。
15.根据本公开的第三方面，提供了一种地图服务器的容量测试装置，包括：
16.任务接收单元，用于接收针对地图服务器发起的测试请求，生成地图服务器的测试任务；
17.第一确定单元，用于确定至少一个测试场景分别对应的测试词表；
18.场景确定单元，用于从至少一个测试场景中确定与测试任务相匹配的目标测试场景；
19.容量测试单元，用于基于目标测试场景对应目标测试词表，对地图服务器进行容
量测试处理，获得地图服务器的目标容量。
20.根据本公开的第四方面，提供一种地图服务器的容量测试装置，包括：
21.请求接收单元，用于接收压力引擎发送的测试任务的节点测试请求；
22.子任务生成单元，用于响应于节点测试请求，生成压力子任务表；
23.第二确定单元，用于确定节点测试请求中的目标测试词表；
24.发压测试单元，用于按照目标测试词表对地图服务器执行发压操作，并更新压力子任务表。
25.根据本公开的第五方面，提供一种电子设备，包括：
26.至少一个处理器；以及
27.与至少一个处理器通信连接的存储器；其中，
28.存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行第一方面的方法。
29.根据本公开的第六方面，提供一种发压节点，包括：
30.至少一个处理器；以及
31.与至少一个处理器通信连接的存储器；其中，
32.存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行第二方面的方法。
33.根据本公开的第七方面，提供一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使计算机执行第一方面的方法。
34.根据本公开的第八方面，提供一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使计算机执行第二方面的方法。
35.根据本公开的第九方面，提供一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行第一方面的方法。
36.根据本公开的第十方面，提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得发压节点执行第二方面的方法。
37.根据本公开的技术解决了地图服务器容量测试不准确的问题，通过确定不同场景下的测试词表，以按照测试词表与测试场景的对应关系，对地图服务器按照场景进行针对性测试，提高场景的测试效率以及测试准确度。
38.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
39.附图用于更好地理解本方案，不构成对本公开的限定。其中：
40.图1是根据本公开实施例提供的应用于地图服务器的容量测试方法的一个系统架构图；
41.图2是根据本公开实施例提供的一种地图服务器的容量测试方法的一个实施例的
流程图；
42.图3是本公开实施例提供的地图服务器容量测试方法的一个应用架构图；
43.图4是本公开实施例提供的一种地图服务器的容量测试方法的又一个实施例的流程图；
44.图5是本公开实施例提供的一种地图服务器的容量测试方法的又一个实施例的流程图；
45.图6是本公开实施例提供的一种地图服务器的容量测试装置的一个实施例的结构示意图；
46.图7是本公开实施例提供的一种地图服务器的容量测试装置的一个实施例的结构示意图；
47.图8是用来实现本公开实施例的地图服务器的容量测试方法的电子设备的框图；
48.图9是用来实现本公开实施例的地图服务器的容量测试方法的发压节点的框图。
具体实施方式
49.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
50.本公开实施例的技术方案可以应用于地图服务器的容量自动管理场景中，通过对地图服务器的容量进行测试，以利用测试结果对地图服务器的容量进行自动调整。通过自动测试地图服务器的容量可以提高容量获取效率以及准确度。
51.相关技术中，线上容量的准确预估对地图服务器的容量管理具有重要意义。地图服务器具有最大处理容量，当现上流量达到最大处理容量时，需要对地图服务器进行容量测试。通常，对地图服务器进行容量测试时，可以采用历史数据进行预估的方式，例如，可以采集不同时间段的流量大小以及地图服务器的历史负载情况，推测地图服务器的容量，以对地图服务器在未来时间段内的服务容量进行确定。但是这种方式获得的容量不够准确，对服务容量的更新也具有一定的负面影响，导致地图服务器的控制效率较低。
52.为了解决上述地图服务器的容量测试准确度不高的问题，本公开实施例中考虑为不同测试场景生成测试词表，然后利用不同测试场景的测试词表进行处理，获得地图服务器的目标容量，实现对地图服务器的准确测试。
53.本公开提供一种地图服务器的容量测试方法、装置、设备、介质及产品，应用于计算机技术领域中的云计算领域，以达到提高地图服务器的测试效率以及测试场景的目的。
54.本公开实施例中，可以接针对地图服务器发起的测试请求，生成地图服务器的测试任务，以确定至少一个测试场景分别对应的测试词表，以从至少一个测试场景中确定与测试任务相匹配的目标测试场景，实现对目标测试场景的匹配。获得目标测试场景之后，可以基于目标测试场景对应的目标测试词表，对地图服务器进行容量测试处理，获得地图服务器的目标容量。通过利用测试场景对地图服务器按照场景进行针对性测试，提高场景的测试效率以及测试准确度。
55.下面将结合附图对本公开技术方案进行详细介绍。
56.如图1所示，为本公开实施例提供的应用于一种地图服务器的容量测试方法的系统架构图。在该系统中，地图服务器1可以由至少一个服务器节点11构成，一个服务器节点中可以配置一个或多个地图服务实例，每个地图服务实例可以对外接收服务流量。此外，网络架构中还可以包括与地图服务器1存在有线或无线通信连接的发压节点2。发压节点2可以包括一个或多个。发压节点2可以与电子设备3建立有线或无线通信连接。在实际应用中，电子设备3可以配置有本公开第一方面提供的地图服务器的容量测试方法，对发压节点2进行发压控制。电子设备3可以通过监测地图服务器3获得地服服务器1的目标容量。
57.如图2所示，为本公开实施例提供的一种地图服务器的容量测试方法的一个实施例的流程图，该地图服务器的容量测试方法可以配置于容量测试装置中，容量测试装置可以应用于电子设备中。该地图服务器的容量测试方法的一个实施例的流程图，该方法可以包括以下几个步骤：
58.201：接收针对地图服务器发起的测试请求，生成地图服务器的测试任务。
59.为了便于理解，如图3所示的，用于实现本公开实施例提供的地图服务器容量测试方法的一个应用架构图，电子设备300中可以配置压力引擎301，由压力引擎301可以与发压节点302建立通信连接，执行对发压节点302的发压控制步骤，也即执行词表选择以及容量测试处理等步骤。发压节点302实际可以包括多个，发压节点可以包括多个发压实例，发压实例用于按照测试词表对地图服务器303进行发压。
60.电子设备300除配置压力引擎301之外，还可以配置容量评估平台304，容量评估平台304可以与用户进行交互，以实现发压任务启动、任务状态查询、任务停止以及容量评估结果的查询等功能。当然，在实际应用中，容量评估平台304也可以为独立于电子设备的终端，通过与电子设备的通信连接，以实现与用户完成上述交互。
61.电子设备300中还可以配置有处理器305的任务调度、指标采集、容量分析、词表管理等均可以通过处理器305实现。
62.接收针对地图服务器发起的测试请求，可以指检测用户针对地图服务器发起的测试请求。检测用户可以通过容量评估平台304向电子设备发起测试请求，测试请求中可以包括地图服务器的服务器信息。服务器信息例如可以包括：地图服务器的调度接口、地图服务器的使用场景、服务器所在地等信息。
63.在电子地图提供地图导航、位置查询等服务时，为了提高服务查询效率，通常可以采用分布式方式对地图服务请求进行调度。在一种可能的设计中，地图服务器可以以地域为划分基础。地图服务器通常以地图服务器集群方式向用户提供地图服务，不同集群的所在地不同。例如，地图服务器可以包括：北京集群、南京集群、广州集群、深圳集群等。本公开实施例中的发压节点可以指不同地域的发压集群。
64.202：确定至少一个测试场景分别对应的测试词表。
65.在实际进行压力测试时，可以针对不同的测试场景进行测试。测试场景可以包括地域场景或者时间场景的测试，或者将地域与时间结合的场景。例如，可以将一个或多个地域的服务器集群作为测试场景进行测试，可以将地图服务器的所有集群作为测试场景进行测试，此外，还可以包括针对不同时间的服务器进行测试，例如针对节假日(例如，五一假期、十一假期、春节等节假日)、早高峰、晚高峰等不同时间测试场景的服务器测试，可以将不同低于的服务器集群与测试时间结合作为测试场景的服务器测试。
66.203：从至少一个测试场景中确定与测试任务相匹配的目标测试场景。
67.可选地，建立测试任务时，可以为测试任务生成测试标识。电子设备可以同时处理多个测试请求，通过多个线程启动多个测试任务。每个测试任务可以包括：测试目标、测试对象、待测场景信息、测试需求信息等。
68.可选地，从至少一个测试场景中确定与测试任务相匹配的目标测试场景，可以包括：从至少一个测试场景中确定测试任务中的待测场景信息、测试需求信息或者测试目标相匹配的目标测试场景。例如，待测场景信息可以记载被测试目的相关的测试场景数据。可以计算至少一个测试场景分别与待测测试场景的相似度，获得至少一个测试场景别对应的场景相似度，确定场景相似最高的测试场景为目标测试场景。
69.204：基于目标测试场景对应目标测试词表，对地图服务器进行容量测试处理，获得地图服务器的目标容量。
70.可选地，目标容量可以为地图服务器在目标测试场景对应的容量。在未来时间内，若检测到地图服务器进入到目标测试场景，可以根据目标容量对地图服务器进行扩容或者缩容。获得地图服务器的目标容量之后，还可以包括：基于目标容量生成容量评估结果，响应于用户的用户端发送的结果查询请求，将容量评估结果发送至用户端，由用户端为用户展示容量评估结果。
71.本公开实施例中，可以接针对地图服务器发起的测试请求，生成地图服务器的测试任务，以确定至少一个测试场景分别对应的测试词表，以从至少一个测试场景中确定与测试任务相匹配的目标测试场景，实现对目标测试场景的匹配。获得目标测试场景之后，可以基于目标测试场景对应的目标测试词表，对地图服务器进行容量测试处理，获得地图服务器的目标容量。通过利用测试场景对地图服务器按照场景进行针对性测试，提高场景的测试效率以及测试准确度。
72.作为一个实施例，生成地图服务器的测试任务之后，还包括：
73.基于测试任务，将地图服务器中的地图服务流量调度到目标服务器，控制地图服务器进入待测状态。
74.基于测试任务，将地图服务器中的地图服务流量调度到目标服务器，控制地图服务器进入待测状态可以包括：在确定测试任务正常时，将地图服务器中的地图服务流量调度到目标服务器。目标服务器可以为地图服务器的备用服务器，同样可以对外提供电子地图服务。地图服务流量可以为服务器当前接收到的至少一个服务请求。将地图服务器中的地图服务流量调度到目标服务器可以指将地图服务器接收到的至少一个服务请求进行拦截，并将拦截的至少一个服务请求发送至目标服务器，由目标服务器依次响应至少一个服务请求，向每个服务请求对应的用户终端输出地图服务结果。其中，地图服务流量的调度具体可以地图服务的上下游连接通常通过通机敏(smart)—域名系统(全称：domain name system，简称：bns)。可以通过配置修改的方式将地地图服务器的bns从整个请求组中拆出，使得上游服务的请求无法流入本机房的线上服务，进而达到单模块切流的目的。在切换上游服务的同时，地图服务器的下游服务流量也要同步切流，以确保地图服务器与线上流量的分离。
75.本公开实施例中，在对地图服务器进行测试之前，可以对测试任务将地图服务器中的服务流量调度到目标服务器，将地图服务器进行服务清除，以确保地图服务流量不受
影响，对目标服务器进行准确测试，获得的目标容量更准确。
76.在实际应用中，为了对地图服务器进行准确测试，获得准确的目标容量。可以采用阶段发压的方式，以发压量从大到小的顺序，对地图服务器进行准确测试。
77.如图4所示，为本公开实施例提供的一种地图服务器的容量测试方法的又一个实施例的流程图，该地图服务器的容量测试方法可以配置于容量测试装置中，容量测试装置可以应用于电子设备中。该地图服务器的容量测试方法的一个实施例的流程图，该方法可以包括以下几个步骤：
78.401：接收针对地图服务器发起的测试请求，生成地图服务器的测试任务。
79.本公开实施例中部分步骤与前述实施例中部分步骤相同，为了描述的简洁性考虑，在此不再赘述。
80.402：确定测试任务的测试阶段以及测试阶段对应的发压目标。
81.在压力测试过程中，可以主要可以包括任务初始化和任务准备两个流程。任务初始化可以包括：建立测试任务、生成任务列表。任务列表包括任务总列表以及任务子列表。任务总列表可以用于对整个发压任务进行信息记录。任务子列表可以用于对发压节点的发压过程进行记录。
82.任务初始化还可以包括：确定总体发压目标；在阶梯发压时，确定每个测试阶段的发压目标。例如可以确定被压测的地图服务器，地图服务器以地域为划分依据，划分为不同地域的地图服务器。
83.任务初始化还可以包括：根据发压目标，确定发压节点的节点数量；根据词表标签选择测试词表。
84.可选地，在对地图服务器进行发压测试过程中，可以按照发压量从小到大的顺序，进行阶梯发压。也即，可以采用多级发压，具体可以设置至少一个发压阶段，至少一个发压阶段按照发压顺序的先后，发压量依次增大。也即，前一个发压阶段的发压量小于后一个发压阶段的发压量。
85.发压目标可以包括：发压数量、发压节点的节点数量等信息。
86.403：根据发压目标，确定发压节点的节点数量。
87.根据发压目标，确定发压节点的节点数量可以包括：根据发压目标中发压量与每个发压节点的单个发压量，获得发压节点的节点数量。发压量可以通过每秒查询量(全称：query per second，简称：qps)确定。不同发压节点压测不同服务所能达到的最大并发度不同，故此节点数量需要实时计算。
88.404：确定至少一个测试场景分别对应的测试词表。
89.任务初始化还可以包括：根据发压目标，确定发压节点的节点数量；根据词表标签选择测试词表。
90.可选地，每个测试词表可以对应有词表标签。词表标签可以为对词表的采集场景的场景概述。每个测试场景可以以对应测试词表的词表标签作为场景名称。
91.405：从至少一个测试场景中确定与测试任务相匹配的目标测试场景。
92.除采用信息匹配的方式进行目标场景的确定，还可以采用标签匹配方式。从至少一个测试场景中确定与测试任务相匹配的目标测试场景可以包括：从至少一个测试场景对应的词表标签中，确定与测试任务的测试目标相匹配的目标测试场景。测试目标可以为需
要测试的场景目标。以词表标签进行场景匹配，匹配过程更直接，匹配精度更高。
93.406：基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理。
94.可选地，基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理，包括：按照节点数量从至少一个发压节点中确定目标发压节点，将目标测试词表发送至目标发压词表，由目标发压节点按照目标发压词表模拟用户使用电子地图的服务请求，将模拟产生的多个服务请求发送至地图服务器，对地图服务器进行容量测试处理。
95.对地图服务器进行容量测试处理过程中，还可以包括：计算每个发压节点需要承担的任务量，将对应数量的服务请求调度到对应的发压节点。任务量可以以qps表示。
96.本公开实施例中，在生成地图服务器的测试任务时，可以确定测试任务的测试节点以及测试节点对应的发压目标，利用发压目标，确定发压节点对应的发压数量，以利用该发压数量进行发压。通过发压节点以及发压目标进行阶段发压，使得发压过程更精细化，提高地图服务器的测试效率及准确度。
97.在一种可能的设计中，在基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理之前，该方法还可以包括：
98.为测试任务建立总压力任务表；总压力任务表用于记录测试任务的测试状态；测试状态包括：正常测试状态或者测试完成状态；
99.对地图服务器进行容量测试处理之后，还包括：
100.若测试任务的测试状态为完成状态，更新测试任务的测试阶段以及测试阶段对应的发压目标，并返回至根据发压目标，确定发压节点的节点数量的步骤继续执行。
101.可选地，压力引擎支持的任务类型主要有两类：常规任务和系统级任务。常规任务即单模块单接口发压任务，系统级任务则能支持多模块多接口同时发压。
102.在对地图服务器发起阶段性的压力测试之后，可以将压力开始时间、结束时间、下一阶梯触发时间(阶梯任务专属)记录在总压力任务表中，以便于后续的队列轮询。
103.可选地，压力引擎轮询总压力任务表时，若检测到到达停止时间，则可以发送压力停止指令至正在发压的发压节点，控制正在发压的节点停止发压。在所有正在发压的发压节点停止发压之后，可以更新总压力任务表中的发压状态为发压结束状态。
104.本公开实施例中，对地图服务器进行容量测试时，可以为测试任务建立总压力任务表，以通过总压力任务表记录测试任务的测试状态。通过测试状态对测试的整体进行状态检测。利用检测的测试状态，在测试状态为完成状态时，更新测试任务的测试节点以及测试节点对应的发压目标，并返回根据发压目标，确定发压节点的节点数量的步骤继续执行。利用总压力任务表可以对发压的整体过程进行准确检测，实现对不同发压阶段的准确控制，对于发压效率以及发压准确度有效提升。
105.在一种可能的设计中，基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理之后，该方法还可以包括：
106.采集地图服务器进行容量测试处理过程，在至少一个监测指标分别对应的指标数据；
107.根据至少一个监测指标分别对应的指标数据，确定地图服务器的阶段测试结果；
108.获取地图服务器在至少一个测试阶段分别对应的阶段测试结果；
109.根据至少一个阶段测试结果，确定地图服务器的目标容量。
110.可选地，阶段测试结果可以由至少一个监测指标分别对应的指标数据构成。至少一个监测指标可以包括：资源类指标评估和业务类指标评估。
111.资源类指标：压测过程中线上实例本身的资源使用情况，如中央处理器(简称：cpu，全称：central processing unit)、内存、平响、长尾、网络句柄等。此类信息可以最直观反应当前线上服务的稳定性情况。
112.业务类指标：和业务强相关的一些指标，如报警(warning)日志、错误(fatal)日志、服务错误码等。部分业务类的错误无法通过资源类指标反应出来。
113.可选地，目标容量可以根据至少一个测试阶段分别对应的阶段测试结果确定。具体可以从至少一个测试阶段分别对应的阶段测试结果，将相邻两个测试阶段的阶段测试结果进行比较，获取所有比较结果；将所有比较结果达到结果差异条件的目标比较结果。根据目标比较结果的两个测试阶段分别对应的发压目标确定地图服务器的目标容量。例如，可以将两个测试阶段中，前一个发压目标作为地图服务器的目标容量。阶段测试结果的比较可以指对两个测试阶段在至少一个监测指标的指标数据进行比较。若存在一个或多个监测指标的数据差异大于指标对应的差异阈值，确定比较结果达到结果差异条件。
114.除根据至少一个阶段测试结果，确定地图服务器的目标容量之外，还可以生成地图服务器在目标测试场景的压测报告。压测包括例如可以包括至少一个测试阶段在至少一个检测指标分别对应的指标数据，任一个检测指标的指标数据是否达到指标阈值的判断结果等信息。将资源类指标和业务类指标相结合，可以生成压测报告，压测报告可以指导运维人员进行线上扩容。
115.本公开实施例中，在容量测试过程中，可以采集至少一个监测指标分别对应的指标数据，以根据至少一个监测指标分别对应的指标数据，确定地图服务器的阶段测试结果。实现对不同测试阶段的测试结果的获取，通过不同测试阶段的结果的获取，可以实现对地图服务器在不同测试阶段的检测容量。以在获取地图服务器在至少一个测试阶段分别对应的阶段测试结果时，根据至少一个阶段测试结果，确定地图服务器的目标容量，实现利用不同测试阶段的阶段测试结果，实现对地图服务器的目标容量进行准确确定，提高地图服务器的测试容量测试准确性。
116.在实际应用中，在获得地图服务器在目标测试场景对应的目标容量时，可以在地图服务器的实际服务场景切换至目标测试场景时，根据地图服务器当前接收到的服务流量，结合目标容量，对地图服务器进行扩容或者缩容调整，提高地图服务器的容量控制效率。
117.作为一个实施例，根据至少一个阶段测试结果，确定地图服务器的目标容量之后，该方法还可以包括：
118.根据地图服务器在至少一个测试阶段分别对应的阶段测试结果，确定地图服务器满足容量调整条件时，获取地图服务器的容量调整量；
119.利用容量调整量对目标容量进行调整处理，获得地图服务器在目标测试场景对应的目标场景容量。
120.本公开实施例中，地图服务器在至少一个阶段测试分别对应的阶段测试结果可以
用于对地图服务器的容量进行调整条件的判断，并在确定地图服务器满足容量调整条件时，获取地图服务器的容量调整量。以利用容量调整量对目标容量进行调整处理，获得地图服务器在目标测试场景的目标场景容量，实现按照场景对地图服务器进行容量测试，提高地图服务器的容量测试效率。
121.在又一种可能的设计中，基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理，包括：
122.基于目标测试场景对应的目标测试词表，生成节点测试请求；
123.发送节点测试请求分别至至少一个发压节点；节点测试请求指示发压节点生成压力子任务表，并按照目标测试词表，执行发压操作，更新压力子任务表。
124.节点测试请求中可以包括目标测试词表，以及需要执行的发压量。发压量可以通过qps表示。
125.本公开实施例中，对地图服务器进行容量测试处理时，可以基于目标测试场景对应的目标测试词表，生成节点测试请求，以发送节点测试请求分别至至少一个发压节点，节点测试请求指示发压节点生成压力子任务表，并按照目标测试词表，执行发压操作，更新压力子任务表。通过压力子任务表，可以对各个发压节点的具体发压情况进行准确获取，实现对地图服务器的容量测试处理，提高测试处理准确度。
126.在某些实施例中，压力子任务表包括：发压状态；发送节点测试请求至至少一个发压节点之后，还包括：
127.从发压节点读取压力子任务表，获得至少一个发压节点分别对应的压力子任务表；
128.根据至少一个发压节点分别对应的压力子任务表，更新总压力任务表；总压力任务表包括测试状态；测试状态包括：正常测试状态或者测试完成状态。
129.每个发压节点执行发压任务时，可以分别建立压力子任务表，以对其发压过程产生的信息进行记载，表中记录了发压对象、压力词表、当前任务状态、当前任务qps等压力相关信息。新任务发起时，压力子单元在压力子任务表中注册压力任务信息，便于后续压力状态的流转。
130.本公开实施例中，可以从发压节点读取压力子任务表，获得至少一个发压节点分别对应的压力子任务表，以根据至少一个发压节点分别对应的压力子任务表，更新总压力任务表，通过对总压力任务表的准确获取，提高压力子任务表的测试状态的获取，实现对发压过程的准确确定，提高发压效率以及发压准确度。
131.作为又一个实施例，该方法还可以包括：
132.检测达到发压结束条件时，生成发压停止指令；
133.发送发压停止指令至至少一个发压节点；发压指令指示发压节点停止发压。
134.可选地，发压结束条件可以包括当前时间到达预定发压结束时间。其中，发压结束时间可以在总发压任务表中记录或存储。发压结束条件还可以包括：确认地图服务器的处理容量进入饱和状态。其中，处理容量进入饱和状态可以指即便再增加服务请求的数量，地图服务器的处理量不再增加。
135.本公开实施例中，检测达到发压结束条件时，可以生成发压停止指令，以发送发压停止指令至至少一个发压节点，发压指令指示发压节点停止发压。利用发压结束条件对发
压状态进行准确检测，可以提高发压节点的发压控制效率。
136.在某些实施例中，发送发压停止指令至至少一个发压节点之后，还包括：
137.若确定发压节点的压力子任务表为测试停止状态，则生成发压节点的清除指令，获得至少一个发压节点分别对应的清除指令；
138.发送至少一个发压节点分别对应的清除指令；清除指令指示对应的发压节点清除发压任务以及发压子任务表；
139.接收至少一个发压节点分别反馈的清除结果。
140.此外，清除指令还可以指示发压节点清除发压日志等信息，以释放内存，减少磁盘压力。
141.本公开实施例中，若确定发压节点的压力子任务表为测试停止状态，则可以生成发压节点的清除指令，获得至少一个发压节点的清除指令，发送至少一个发压节点分别对应的清除指令至对应的发压节点，清除指令可以指示对应的发压节点清除发压任务以及发压子任务，实现对至少一个发压节点分别反馈的清除结果。通过清除指令，可以确保发压节点在发压完毕时，可以对发压节点进行内存释放，以便于对发压节点进行高效利用。
142.为了获得准确的测试词表，作为一个实施例，任一个测试场景对应的测试词表可以通过以下步骤确定：
143.采集地图服务器在测试场景对应的至少一个服务请求。
144.根据测试场景对应的至少一个服务请求，生成测试场景对应的测试词表。
145.可选地，采集地图服务器在至少一个测试场景对应的至少一个服务请求可以包括：录制线上真实请求，获得至少一个服务请求。具体可以打开服务远程过程调用(简称：rpc，全称：remote procedure call)框架自带的请求录制开关，即可将线上流量录制(dump)到本地磁盘。由于资源的限制，我们无法打开线上全部实例的录制开关，所以本服务会根据线上实例表现自动选取性能最佳的部分实例开启录制功能。
146.将流量数据录制至线上实例本地后，我们需要一种方式将数据回传至本地。我们借用已有的日志回传平台，按周期将录制的数据切分成指定格式，再通过传输平台(已有平台，非本装置建设)传输至分布式文件系统(全称：andrew file system，简称：afs)集群。afs集群中的数据按录制时间段进行排列，当用户需要不同时段的压测流量时，离线任务按需拉取即可。
147.本公开实施例中，可以采集地图服务器在每个测试场景对应的至少一个服务请求，进而利用测试场景下的至少一个服务请求，生成测试场景对应的测试词表。实现利用测试场景进行测试词表的生成，对测试场景的测试词表进行准确获取。
148.在某些实施例中，根据测试场景对应的至少一个服务请求，生成测试场景对应的测试词表，包括：
149.确定测试场景对应的至少一个服务请求；
150.提取服务请求的关键词，获得至少一个服务请求分别对应服务信息；
151.利用至少一个服务请求对应的服务信息，生成测试场景对应的测试词表。
152.可选地，提取服务请求中的关键词可以包括：提取服务请求中的起始地、目的地等。提取服务请求中的关键字还可以包括：提取服务请求中的查询目标，查询目标例如可以包括商店名称、地名、车辆车牌号等信息。
153.本公开实施例中，确定测试场景对应的至少一个服务请求时，可以提取服务请求的关键词，以获得至少一个服务请求分别对应的服务详细，同时利用至少一个服务请求对应的服务信息，生成测试场景对应的测试词表。通过对服务请求进行关键词提取可以准确获得每个服务请求对应的服务信息，实现对测试场景下的测试词表的准确提取，提供测试词表的获取准确度。
154.作为一种可选实施方式，提取服务请求的关键词，获得至少一个服务请求分别对应服务信息，包括：
155.提取服务请求的关键词；
156.若关键词满足测试场景的场景使用条件，则确定关键词为服务信息；
157.若关键词不满足测试场景的场景使用条件，则按照测试场景的服务策略，更新测试场景的关键词，获得目标关键词，确定目标关键词为服务信息。
158.还可以包括：若关键词不满足测试场景的场景使用条件，将关键词删除，继续提取下一个服务请求的关键词。
159.有些情况下我们除了平时录制的真实的服务流量，还需要模拟节假日场景(如十一、五一、春节等)的流量，这就需要我们对录制的流量进行成分更新或者调配。更新或者调配的主要原则是将流量各个服务请求中例如，出行比例、导航比例进行调配，并加长出行距离等，模拟节假日出行高峰的真实场景。
160.本公开实施例中，提取服务请求的关键词之后，若关键词满足测试场景的场景使用条件，则可以确定关键词为服务详细，若关键词不满足测试场景的场景使用条件，则可以按照测试场景的服务策略，更新测试场景的关键词，获得目标关键词，以确定目标关键词为服务信息。通过场景使用条件，对服务请求提取的关键词进行调整，实现关键词对场景使用条件的适应性调整，获得的服务信息与场景使用条件更匹配，提高测试词表的准确效率。
161.如图5所示，为本公开实施例提供的一种地图服务器的容量测试方法的又一个实施例的流程图，该地图服务器的容量测试方法可以配置于容量测试装置中，容量测试装置可以应用于发压节点中。该地图服务器的容量测试方法的一个实施例的流程图，该方法可以包括以下几个步骤：
162.501：接收压力引擎发送的测试任务的节点测试请求。节点测试请求是基于目标测试场景对应的目标测试词表生成的。
163.本技术实施例中可以参考上述实施例中发压节点的具体描述，在此不再赘述。
164.502：响应于节点测试请求，生成压力子任务表。
165.其中，压力子任务表用于更新压力总任务表。
166.压力子任务表包括发压节点的节点测试状态。
167.503：确定节点测试请求中的目标测试词表。
168.可选地，节点测试请求中的目标测试词表可以为词表地址。确定节点测试请求中的目标测试词表可以包括：从节点测试请求中的词表地址读取目标测试词表。
169.504：按照目标测试词表对地图服务器执行发压操作，并更新压力子任务表。
170.本公开实施例中，接收压力测试引擎发送的测试任务的节点测试请求。而节点测试请求是基于目标测试场景对应的目标测试词表生成的。响应于节点测试请求时，可以生成压力子任务表。压力子任务表可以对压力节点的任务执行状态进行记录。确定节点测试
请求中的目标测试词表之后，可以按照目标测试词表对地图服务器执行发压操作，并更新压力子任务表。通过压力子任务表可以对发压节点的测试过程进行准确控制，提高地图服务器的发压效率。
171.作为一个实施例，按照目标测试词表执行发压操作，并更新压力子任务表，包括：
172.从测试词表中读取至少一个服务信息；
173.分别按照至少一个服务信息生成对应的服务请求；
174.发送至少一个服务请求至地图服务器，并更新压力子任务表。
175.可选地，压力子任务表可以记录了发压对象、压力词表、当前任务状态、当前任务qps等压力相关信息。新任务发起时，压力子单元在压力子任务表中注册压力任务信息，便于后续压力状态的流转。
176.本公开实施例中，在发压过程中，可以从测试词表中读取至少一个服务信息，以分别按照至少一个服务信息生成对应的服务请求，发送至少一个服务请求至地图服务器，实现对地图服务器进行准确发压，之后可以更新压力子任务表。通过读取服务信息可以对地图服务器进行高效而准确的发压，提高发压效率以及准确度。
177.在某些实施例中，发送至少一个服务请求至地图服务器，并更新压力子任务表，包括：
178.接收地图服务器依次反馈的至少一个服务请求分别对应的反馈信息；
179.基于任务更新频率，根据已接收反馈信息的服务请求的请求数量，更新压力子任务表。
180.可选地，任务更新频率可以根据实际的更新需求设置。
181.本公开实施例中，发送服务请求至地图服务器之后，可以接收地图服务器依次反馈的至少一个服务请求分别对应的反馈信息，并基于任务更新频率，根据已接收反馈信息的服务请求的请求数量更新压力子任务表，通过任务更新频率可以对压力子任务表进行准确更新，实现对发压任务的准确控制。
182.在某些实施例中，在更新压力子任务表时，该方法还可以包括：
183.接收压力引擎发送的压力子任务表读取请求；
184.响应于读取请求，发送压力子任务表至压力引擎。
185.可选地，发压节点为了实现阶梯发压的功能，引入了父任务与子任务的概念：子任务负责执行各个阶段的具体发压操作，仅记录本进程的压力大小；父任务负责记录本任务下当前全部进程的总压力大小。父任务与子任务通过测试任务的任务标识相关联，压力大小阶梯上升时在父任务下新增一个压力子任务即可。
186.父任务可以的任务相关信息可以记录于压力总任务表中。子任务的任务相关信息可以记录于压力子任务表中。
187.为了便于理解，参考下列表1所示的父任务与子任务的对应关系。
[0188][0189]
表1
[0190]
表1中可以包括task_id对应的父任务。不同测试阶段可以对应阶段任务task_id_container1至task_id_containern，n个阶段任务。同一测试阶段可以对应task_id_containern_qps1至task_id_containern_qpsm，m个实际的发压任务。
[0191]
本公开实施例中，可以接收压力引擎发送的压力子任务表读取请求，以响应于读取请求，发送压力子任务表至压力引擎。通过获取读取请求以与压力引擎进行压力子任务表的读取，实现对压力子任务表的高效利用。
[0192]
在一种可能的设计中，还包括：
[0193]
接收压力引擎发送的发压停止指令；
[0194]
响应于发压停止指令，关闭发压操作对应的发压进程，停止发压。
[0195]
本公开实施例中，发压节点可以接收发压引擎发送的发压停止指令，响应于该发压停止指令，可以关闭发压操作对应的发压进行，停止发压，实现对发压停止的准确而快速地控制。
[0196]
作为一种可选方式，还包括：
[0197]
接收发压引擎发送的清除指令；
[0198]
响应于清除指令，对测试任务以及压力子任务表进行清除。
[0199]
本公开实施例中，发压节点可以接收发压引擎发送的清除指令，以响应于清除指令，对测试任务以及压力子任务表进行清除，通过清除发压引擎中的测试任务以及压力子任务表可以释放发压节点中的节点内存，以便于再次利用发压节点，提升发压节点的利用率。
[0200]
如图6所示，为本公开实施例提供的一种地图服务器的容量测试装置的一个实施例的结构示意图，该容量测试装置600可以应用于电子设备中，该装置可以包括以下几个单
元：
[0201]
任务接收单元601：用于接收针对地图服务器发起的测试请求，生成地图服务器的测试任务。
[0202]
第一确定单元602：用于确定至少一个测试场景分别对应的测试词表。
[0203]
场景确定单元603：用于从至少一个测试场景中确定与测试任务相匹配的目标测试场景。
[0204]
容量测试单元604：用于基于目标测试场景对应目标测试词表，对地图服务器进行容量测试处理，获得地图服务器的目标容量。
[0205]
作为一个实施例，还包括：
[0206]
测试调度单元，用于基于测试任务，将地图服务器中的地图服务流量调度到目标服务器，控制地图服务器进入待测状态。
[0207]
作为又一个实施例，还包括：
[0208]
目标确定单元，用于确定测试任务的测试阶段以及测试阶段对应的发压目标；
[0209]
节点确定单元，用于根据发压目标，确定发压节点的节点数量；
[0210]
容量测试单元，包括：
[0211]
容量测试模块，用于基于目标测试场景对应的目标测试词表，按照节点数量调度至少一个发压节点，对地图服务器进行容量测试处理。
[0212]
在某些实施例中，还包括：
[0213]
任务建立单元，用于为测试任务建立总压力任务表；总压力任务表用于记录测试任务的测试状态；测试状态包括：正常测试状态或者测试完成状态；
[0214]
对地图服务器进行容量测试处理之后，还包括：
[0215]
若测试任务的测试状态为完成状态，更新测试任务的测试阶段以及测试阶段对应的发压目标，并返回至根据发压目标，确定发压节点的节点数量的步骤继续执行。
[0216]
在一种可能的设计中，还包括：
[0217]
指标采集单元，用于采集地图服务器进行容量测试处理过程，在至少一个监测指标分别对应的指标数据；
[0218]
结果获取单元，用于根据至少一个监测指标分别对应的指标数据，确定地图服务器在测试阶段对应的阶段测试结果；
[0219]
阶段分析单元，用于获取地图服务器在至少一个测试阶段分别对应的阶段测试结果；
[0220]
容量确定单元，用于根据至少一个阶段测试结果，确定地图服务器的目标容量。
[0221]
在某些实施例中，容量测试模块，包括：
[0222]
请求生成子模块，用于基于目标测试场景对应的目标测试词表，生成节点测试请求；
[0223]
请求发送子模块，用于发送节点测试请求分别至至少一个发压节点；节点测试请求指示发压节点生成压力子任务表，并按照目标测试词表，执行发压操作，更新压力子任务表。
[0224]
在某些实施例中，压力子任务表包括：发压状态；还包括：
[0225]
任务读取单元，用于从发压节点读取压力子任务表，获得至少一个发压节点分别
对应的压力子任务表；
[0226]
任务更新单元，用于根据至少一个发压节点分别对应的压力子任务表，更新总压力任务表；总压力任务表包括测试状态；测试状态包括：正常测试状态或者测试完成状态。
[0227]
在一种可能的设计中，还包括：
[0228]
停止生成单元，用于检测达到发压结束条件时，生成发压停止指令；
[0229]
停止发送单元，用于发送发压停止指令至至少一个发压节点；发压指令指示发压节点停止发压。
[0230]
在某些实施例中，还包括：
[0231]
清除生成单元，用于若确定发压节点的压力子任务表为测试停止状态，则生成发压节点的清除指令，获得至少一个发压节点分别对应的清除指令；
[0232]
清除发送单元，用于发送至少一个发压节点分别对应的清除指令；清除指令指示对应的发压节点清除发压任务以及发压子任务表；
[0233]
结果接收单元，用于接收至少一个发压节点分别反馈的清除结果。
[0234]
作为又一个实施例，还包括：
[0235]
请求采集单元，用于采集地图服务器在测试场景对应的至少一个服务请求；
[0236]
词表生成单元，用于根据测试场景对应的至少一个服务请求，生成测试场景对应的测试词表。
[0237]
在某些实施例中，词表生成单元，包括：
[0238]
请求确定模块，用于确定测试场景对应的至少一个服务请求；
[0239]
服务确定模块，用于提取服务请求的关键词，获得至少一个服务请求分别对应服务信息；
[0240]
词表生成模块，用于利用至少一个服务请求对应的服务信息，生成测试场景对应的测试词表。
[0241]
作为一种可选方式，服务确定模块，包括：
[0242]
关键提取子模块，用于提取服务请求的关键词；
[0243]
第一处理子模块，用于若关键词满足测试场景的场景使用条件，则确定关键词为服务信息；
[0244]
第二处理子模块，用于若关键词不满足测试场景的场景使用条件，则按照测试场景的服务策略，更新测试场景的关键词，获得目标关键词，确定目标关键词为服务信息。
[0245]
本公开实施例的具体执行方式可以参考上述实施例中方法的描述，在此不再赘述。
[0246]
如图7所示，为本公开实施例提供的一种地图服务器的容量测试装置的又一个实施例的结构示意图，该容量测试装置700可以应用于发压节点中，该装置可以包括以下几个单元：
[0247]
请求接收单元701：用于接收压力引擎发送的测试任务的节点测试请求；
[0248]
子任务生成单元702：用于响应于节点测试请求，生成压力子任务表；
[0249]
第二确定单元703：用于确定节点测试请求中的目标测试词表；
[0250]
发压测试单元704：用于按照目标测试词表对地图服务器执行发压操作，并更新压力子任务表。
[0251]
作为一个实施例，发压测试单元，包括：
[0252]
信息读取模块，用于从测试词表中读取至少一个服务信息；
[0253]
请求生成模块，用于分别按照至少一个服务信息生成对应的服务请求；
[0254]
请求发送模块，用于发送至少一个服务请求至地图服务器，并更新压力子任务表。
[0255]
在某些实施例中，请求发送模块，包括：
[0256]
反馈获取子模块，用于接收地图服务器依次反馈的至少一个服务请求分别对应的反馈信息；
[0257]
任务更新子模块，用于基于任务更新频率，根据已接收反馈信息的服务请求的请求数量，更新压力子任务表。
[0258]
在一种可能的设计中，还包括：
[0259]
读取接收单元，用于接收压力引擎发送的压力子任务表读取请求；
[0260]
任务发送单元，用于响应于读取请求，发送压力子任务表至压力引擎。
[0261]
在又一种可能的设计中，还包括：
[0262]
停止接收单元，用于接收压力引擎发送的发压停止指令；
[0263]
停止响应单元，用于响应于发压停止指令，关闭发压操作对应的发压进程，停止发压。
[0264]
作为一种可选方式，还包括：
[0265]
清除接收单元，用于接收发压引擎发送的清除指令；
[0266]
节点清除单元，用于响应于清除指令，对测试任务以及压力子任务表进行清除。
[0267]
本公开实施例的具体实施方式可以参考上述实施例中方法的描述，在此不再赘述。
[0268]
需要说明的是，本实施例中的人头模型并不是针对某一特定用户的人头模型，并不能反映出某一特定用户的个人信息。需要说明的是，本实施例中的二维人脸图像来自于公开数据集。
[0269]
本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
[0270]
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
[0271]
根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。
[0272]
图8示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
[0273]
如图8所示，设备800包括计算单元801，其可以根据存储在只读存储器(rom)802中
的计算机程序或者从存储单元808加载到随机访问存储器(ram)803中的计算机程序，来执行各种适当的动作和处理。在ram 803中，还可存储设备800操作所需的各种程序和数据。计算单元801、rom 802以及ram 803通过总线804彼此相连。输入/输出(i/o)接口805也连接至总线804。
[0274]
设备800中的多个部件连接至i/o接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。设备800中计算单元801可以配置发压引擎以及输出单元806可以为容量评估平台。
[0275]
计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如地图服务器的容量测试方法。例如，在一些实施例中，地图服务器的容量测试方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由rom 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到ram 803并由计算单元801执行时，可以执行上文描述的地图服务器的容量测试方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行地图服务器的容量测试方法。
[0276]
此外，如图9所示，本公开实施例还提供了可以用来实施本公开的实施例的示例发压节点900的示意性框图。该发压节点900可以包括计算单元901、只读存储器(rom)902、存储器(ram)903、总线904、输入/输出(i/o)接口905、输入单元906、输出单元907、存储单元908以及通信单元909。发压节点900的硬件结构以及各个单元、总线以及接口之间的结构、连接关系与电子设备800相似，为了描述的简洁性考虑在此不再赘述。
[0277]
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
[0278]
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0279]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供
指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0280]
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
[0281]
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
[0282]
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与vps服务("virtual private server"，或简称"vps")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
[0283]
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
[0284]
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。