耗时展示方法、装置、电子设备及存储介质与流程

1.本公开涉及人工智能技术领域，具体涉及云计算、云存储和大数据技术领域，尤其涉及一种耗时展示方法、装置、电子设备及存储介质。


背景技术：

2.耗时是衡量服务能力的一项重要指标，其直接影响到用户对应用或应用客户端的使用体验。对与服务耗时较高的应用或应用客户端进行交互，导致用户体验不佳，甚至会放弃使用该应用。因此，需要对应用的服务耗时进行统计与分析，以便进行问题定位和优化。


技术实现要素：

3.本公开提供了一种用于耗时展示方法、装置、电子设备及存储介质。
4.根据本公开的一方面，提供了一种耗时展示方法，包括：接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，所述执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，所述传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长；根据所述多个请求的标识信息，对所述多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各所述聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；根据多个所述聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，所述耗时图像用于指示对应服务节点响应多个请求的耗时；响应于用户操作，对所述各服务节点的耗时图像进行展示。
5.根据本公开的另一方面，提供了另一种耗时展示方法，包括：确定服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，所述执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，所述传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长；向服务端发送所述服务指示信息。
6.根据本公开的另一方面，提供了一种耗时展示装置，包括：接收模块，用于接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，所述执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，所述传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长；划分模块，用于根据所述多个请求的标识信息，对所述多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各所述聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；绘制模块，用于根据多个所述聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，所述耗时图像用于指示对应服务节点响应多个请求的耗时；展示模块，用于响应于用户操作，对所述各服务节点的耗时图像进行展示。
7.根据本公开的另一方面，提供了一种耗时展示装置，包括：确定模块，用于确定服
务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，所述执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，所述传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长；发送模块，用于向服务端发送所述服务指示信息。
8.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
9.附图用于更好地理解本方案，不构成对本公开的限定。其中：
10.图1是根据本公开第一实施例的示意图；
11.图2是根据本公开实施例的服务节点的示意图；
12.图3是根据本公开第二实施例的示意图；
13.图4是根据本公开第三实施例的示意图；
14.图5是根据本公开第四实施例的示意图；
15.图6是根据本公开第四实施例的示意图；
16.图7是根据本公开第五实施例的示意图；
17.图8是本公开实施例的耗时展示方法的流程示意图；
18.图9是本公开实施例的软件开发工具包、收集器、数据库以及服务端 前端的结构示意图；
19.图10是本公开实施例的软件开发工具包将采集的数据上报至收集器的示意图；
20.图11是本公开实施例的收集器对上报的数据进行处理的流程示意图；
21.图12是本公开实施例的服务节点的耗时示意图；
22.图13是根据本公开第六实施例的示意图；
23.图14是根据本公开第七实施例的示意图；
24.图15是根据本公开第八实施例的示意图；
25.图16是根据本公开第九实施例的示意图；
26.图17示出了可以用来实施本公开的实施例的示例电子设备的示意性框图。
具体实施方式
27.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
28.相关技术中，耗时分析主要是针对全量类别(大量用户)，未做小流量(用户数量小于设定阈值)区分，由于全量类别的耗时数据量较大，不便于耗时分析。此外，耗时分析的主要是远程过程调用(remote procedure call，简称rpc)链路间的耗时，对于服务内部的节点未做统计，耗时分析的准确性较低。
29.因此，针对上述问题，本公开提出一种耗时展示方法、装置、电子设备及存储介质。
30.下面参考附图描述本公开实施例的耗时展示方法、装置、电子设备及存储介质。
31.图1是根据本公开第一实施例的示意图。需要说明的是，本公开实施的耗时展示方法可应用于服务端，本公开以耗时展示方法应用于服务端进行示例性说明。
32.如图1所示，该耗时展示方法可包括如下步骤：
33.步骤101，接收客户端发送的服务指示信息。
34.其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
35.在本公开实施例中，在客户端向服务端发送多个请求后，客户端可向服务端查询多个请求的执行结果，或者，客户端向服务端每发送一个请求，接收到服务端执行该请求的执行结果，并对每个请求的执行结果进行存储，在客户端向服务端发送多个请求后，可查询多个请求对应的执行结果，进而，客户端可根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，可得到多个服务节点响应多个请求的耗时，进而，根据多个请求对应的多个服务节点的耗时，可生成服务指示信息。其中，为了便于耗时的统计分析，客户端可为多个，客户端的数量可小于设定阈值。
36.其中，需要说明的是，每个请求对应的服务节点的类型可包括：rpc链路类型和服务内部自定义类型(如，io(输入-输出)类型、cpu类型)。
37.如图2所示，图2左侧部分的服务节点为rpc链路类型的服务节点，图2中间部分的服务节点为io类型的服务节点，图2右侧的服务节点为cpu类型的服务节点。
38.此外，还需要说明的是，每个服务节点可通过该服务节点的来源名称、下游名称进行标识。比如，如表1所示，每个服务节点的节点信息可如下：
39.表1服务节点的节点信息
[0040][0041]
此外，如表2所示，每个请求对应的请求信息可如下：
[0042]
表2请求对应的请求信息
[0043][0044]
其中，需要了解的是，一次请求可为用户一次完成的访问交互，请求信息中的logid可以唯一标识本次请求，一次请求可能有多长rpc访问(多个微服务交互)，也可能经过多次服务内部自定义节点。因此，一次请求的全部数据信息＝多个服务节点上报信息 单
次请求信息。
[0045]
此外，任一服务节点下的耗时可通过该服务节点的标识信息与该服务节点的耗时信息进行表示，比如，某个小流量(用户数量小于设定阈值)号下特定服务节点的耗时sid_cost，可表示为：
[0046]
sid_cost＝key sid sender receiver latency；
[0047]
其中，key为logid的哈希值，key sid sender receiver为该服务节点的标识信息。
[0048]
步骤102，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0049]
其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0050]
进一步地，在接收到客户端发送的服务指示信息后，可对服务指示信息中包括的多个请求对应的多个服务节点的执行时长和传输时长，按照多个请求的标识信息进行划分，以得到多个聚簇，其中，每个聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0051]
步骤103，根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像。
[0052]
其中，耗时图像用于指示对应服务节点响应多个请求的耗时。
[0053]
为了使各服务节点的耗时直观显示，可根据多个聚簇中多个服务节点的执行时长和传输时长，确定多个请求下的各个服务节点对应的耗时分位值，进而，根据各个服务节点对应的耗时分位值或均值，进行耗时图像绘制，以得到各服务节点的耗时图像。比如，可根据多个请求下的各服务节点的耗时均值进行耗时图像绘制，或者，根据多个服务节点的耗时排列顺序下，设定的耗时排列位置对应的耗时进行耗时图像绘制。
[0054]
步骤104，响应于用户操作，对各服务节点的耗时图像进行展示。
[0055]
在本公开实施例中，用户可在服务端进行操作，比如，查询操作，服务端可对各服务节点的耗时图像进行展示。
[0056]
综上，通过接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，耗时图像用于指示对应服务节点响应多个请求的耗时；响应于用户操作，对各服务节点的耗时图像进行展示，由此，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，可准确得到各请求对应的多个服务节点的执行时长和传输时长，进而，根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅可包括rpc链路服务节点，还可包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0057]
为了清楚地说明上述实施例是如何根据多个请求的标识信息，对多个请求对应的
多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇的，本公开提出另一种耗时展示方法。该耗时展示方法可应用于服务端。
[0058]
图3是根据本公开第二实施例的示意图。
[0059]
如图3所示，该耗时展示方法可包括如下步骤：
[0060]
步骤301，接收客户端发送的服务指示信息。
[0061]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
[0062]
步骤302，针对多个请求中的任一请求，根据任一请求的标识信息，确定各任一请求的标识信息对应的哈希值。
[0063]
为了节省相关资源以及提高数据的安全性，可采用各请求的标识信息对应的哈希值，对多个请求的多个服务节点的执行时长和传输时长进行划分。比如，可根据任一请求的标识信息logid，确定任一请求的标识信息logid的哈希值。
[0064]
步骤303，根据任一请求的标识信息对应的哈希值，从多个请求对应的多个服务节点的执行时长和传输时长中，对与任一请求的哈希值匹配的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0065]
进一步地，根据任一请求的标识信息对应的哈希值，对多个请求对应的多个服务节点的执行时长和传输时长进行验证和划分，从而可得到多个聚簇，其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0066]
步骤304，根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像。
[0067]
其中，耗时图像用于指示对应服务节点响应多个请求的耗时。
[0068]
步骤305，响应于用户操作，对各服务节点的耗时图像进行展示。
[0069]
需要说明的是，步骤301、步骤304至305的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0070]
综上，通过针对多个请求中的任一请求，根据任一请求的标识信息，确定各任一请求的标识信息对应的哈希值；根据任一请求的标识信息对应的哈希值，从多个请求对应的多个服务节点的执行时长和传输时长中，对与任一请求的哈希值匹配的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，由此，根据各请求的标识信息，可准确地实现对多个请求的多个服务节点的执行时长和传输时长进行划分，得到多个聚簇，从而，通过对各聚簇中的多个服务节点的执行时长和传输时长进行耗时分析，可提高多个服务节点的耗时分析的准确性和灵活性。
[0071]
为了清楚地说明上述实施例是如何根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像的，本公开提出另一种耗时展示方法。
[0072]
图4是根据本公开第三实施例的示意图。
[0073]
如图4所示，该耗时展示方法可包括如下步骤：
[0074]
步骤401，接收客户端发送的服务指示信息。
[0075]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时
长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
[0076]
步骤402，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0077]
其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0078]
步骤403，将各聚簇中各服务节点的执行时长和传输时长进行相加，以得到各服务节点响应多个请求的耗时。
[0079]
由于各聚簇可包括同一请求对应的多个服务节点的执行时长和传输时长，因此，在本公开实施例中，将各聚簇中，各请求下的各服务节点的执行时长和传输时长进行相加，可得到各服务节点响应各请求的耗时，其中，每个服务节点响应每个请求可对应一个耗时。比如，服务节点a响应请求1、响应请求2以及响应请求3的耗时分别为5us、6us和5us，服务节点b响应请求1、响应请求2以及响应请求3的耗时分别为7us、6us和5us。
[0080]
需要说明的是，服务内部自定义的cpu服务节点，该cpu服务节点对应的传输时长可为0。
[0081]
步骤404，针对任一服务节点，判断任一服务节点响应多个请求的耗时是否处于设定时间范围内。
[0082]
为了进一步提升各服务节点响应多个请求的耗时准确性，在本公开实施例中，可对各服务节点响应多个请求的耗时是否处于设定时间范围内进行判断，比如，设定时间范围为30秒，对于响应多个请求的耗时超过30秒的耗时，可确定为异常耗时，则将该异常耗时进行丢弃。
[0083]
步骤405，根据处于设定时间范围内的各服务节点响应多个请求的耗时，进行图像绘制，以得到各服务节点的耗时图像。
[0084]
进一步地，可根据处于设定时间范围内的各服务节点响应多个请求的耗时，进行图像绘制，以得到各服务节点的耗时图像，比如，可根据处于设定时间范围内的各服务节点响应多个请求的耗时，确定各服务节点响应多个请求的平均耗时，或者，根据多个请求下的各个服务节点对应的耗时分位值，进而，根据各个服务节点对应的平均耗时或耗时分位值，进行耗时图像绘制。
[0085]
步骤406，响应于用户操作，对各服务节点的耗时图像进行展示。
[0086]
需要说明的是，步骤401至402、步骤406的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0087]
综上，通过将各聚簇中各服务节点的执行时长和传输时长进行相加，以得到各服务节点响应多个请求的耗时；针对任一服务节点，判断任一服务节点响应多个请求的耗时是否处于设定时间范围内；根据处于设定时间范围内的各服务节点响应多个请求的耗时，进行图像绘制，以得到各服务节点的耗时图像，由此，根据各聚簇中的各服务节点的执行时长和传输时长，可得到各服务节点响应多个请求的耗时，并对各服务节点的响应多个请求的耗时进行异常判断，提高了各服务节点响应多个请求的耗时的准确性，从而，根据各服务节点响应多个请求的耗时进行图像绘制，将各服务节点响应多个请求的耗时直观显示，提高了耗时分析的准确性。
[0088]
为了清楚地说明上述实施例是如何根据处于设定时间范围内的各所述服务节点
响应多个请求的耗时，进行图像绘制，以得到各服务节点的耗时图像的，本公开提出另一耗时展示方法。
[0089]
图5是根据本公开第四实施例的示意图。
[0090]
如图5所示，该耗时展示方法可包括如下步骤：
[0091]
步骤501，接收客户端发送的服务指示信息。
[0092]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
[0093]
步骤502，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0094]
其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0095]
步骤503，将各聚簇中各服务节点的执行时长和传输时长进行相加，以得到各服务节点响应多个请求的耗时。
[0096]
步骤504，针对任一服务节点，判断任一服务节点响应多个请求的耗时是否处于设定时间范围内。
[0097]
步骤505，将处于设定时间范围内的各服务节点响应多个请求的耗时进行排序，以得到各服务节点响应多个请求的耗时排列顺序。
[0098]
作为一种示例，可对处于设定时间范围内的各服务节点响应多个请求的耗时进行排序，以得到各服务节点响应多个请求的耗时排列顺序。
[0099]
步骤506，获取各服务节点响应多个请求的耗时排列顺序中至少一个设定排列位置的耗时。
[0100]
进一步地，可根据各服务节点响应多个请求的耗时排列顺序，获取各服务节点响应多个请求的耗时排列顺序中的至少一个设定排列位置的耗时，其中，需要说明的是，为了便于耗时分析，设定排列位置可包括：80、90以及99等。
[0101]
步骤507，针对各服务节点的至少一个设定排列位置中的任一设定排列位置，对各服务节点的任一设定排列位置的耗时进行曲线拟合，以得到各服务节点的任一设定排列位置的耗时图像。
[0102]
进而，根据各服务节点的至少一个设定排列位置中的任一设定排列位置，可对各服务节点的任一设定排列位置的耗时进行曲线拟合，可得到各服务节点的任一设定排列位置的耗时图像。
[0103]
作为另一种示例，可对处于设定时间范围内的各服务节点响应多个请求的耗时进行平均计算，可得到各服务节点响应多个请求的耗时的平均值，进而，根据各服务节点响应多个请求的耗时的平均值进行曲线拟合，可得到各服务节点的平均耗时的耗时图像。
[0104]
步骤508，响应于用户操作，对各服务节点的耗时图像进行展示。
[0105]
需要说明的是，步骤501至504、步骤508的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0106]
综上，通过将处于设定时间范围内的各服务节点响应多个请求的耗时进行排序，以得到各服务节点响应多个请求的耗时排列顺序；获取各服务节点响应多个请求的耗时排列顺序中至少一个设定排列位置的耗时；针对各服务节点的至少一个设定排列位置中的任
一设定排列位置，对各服务节点的任一设定排列位置的耗时进行曲线拟合，以得到各服务节点的任一设定排列位置的耗时图像，由此，通过对各服务节点的任一设定排列位置的耗时进行曲线拟合，可得到各服务节点的任一设定排列位置的耗时图像，实现了各服务节点响应多个请求的耗时的直观展示，提高了各服务节点响应多个请求的耗时分析的便捷性。
[0107]
为了进一步提高各服务节点的耗时的准确性，在本公开实施例中，如图6所示，图6是根据本公开第四实施例的示意图，在接收客户端发送的服务指示信息之前，可对客户端的标识信息以及服务指示信息中的数据量进行验证，图6所示实施例可包括如下步骤：
[0108]
步骤601，查询设定白名单中是否存在客户端的标识信息。
[0109]
为了进一步提高各个服务节点响应多个请求的耗时准确性，可对客户端进行权限控制，在本公开实施例中，可根据客户端的标识信息(如，ip)，查询设定白名单中是否存在该客户端的标识信息。
[0110]
步骤602，在设定白名单中存在客户端的标识信息时，确定服务指示信息对应的数据量。
[0111]
进一步地，在设定白名单中存在客户端的标识信息时，可确定服务指示信息对应的数据量，以进一步判断该服务指示信息对应的数据量是否在服务端的接收能力范围内。
[0112]
另外，在设定白名单中不存在客户端的标识信息时，拒绝接收客户端发送的服务指示信息，以避免方式异常的流量造成脏数据出现的情况发生。
[0113]
步骤603，在数据量大于设定数据量阈值时，对服务端的资源进行扩充。
[0114]
其中，资源包括存储资源和/或计算资源。
[0115]
进一步地，在数据量大于设定数据量阈值时，可表示该服务指示信息对应的数据量超过服务端的接收能力范围，可先打开开关，拒绝接收客户端发送的服务指示信息，同时根据服务指示信息的数据量进行资源扩充，在服务端的资源扩充完毕后，打开开关，接收客户端发送的服务指示信息。此外，为了控制客户端的数量，以使客户端的数量小于或等于设定数量阈值(小流量)，还可对客户端的数量进行监控和统计。
[0116]
步骤604，接收客户端发送的服务指示信息。
[0117]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
[0118]
步骤605，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0119]
其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0120]
步骤606，根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像。
[0121]
其中，耗时图像用于指示对应服务节点响应多个请求的耗时。
[0122]
步骤607，响应于用户操作，对所述各服务节点的耗时图像进行展示。
[0123]
需要说明的是，步骤604至607的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0124]
综上，通过查询设定白名单中是否存在客户端的标识信息；在设定白名单中存在客户端的标识信息时，确定服务指示信息对应的数据量；在数据量大于设定数据量阈值时，
对服务端的资源进行扩充，由此，在接收客户端发送的服务指示信息之前，对客户端以及服务指示信息进行权限控制，可避免方式异常的流量造成脏数据，以及无法接收白名单中的客户端发送的服务指示信息的情况发生，提高了各服务节点的耗时准确性。
[0125]
为了清楚地说明上述实施例中服务端接收的服务指示信息是如何确定的，在本公开实施例中，如图7所示，图7是根据本公开第五实施例的示意图，服务端可接收客户端发送的查询请求，服务端可向客户端发送查询请求响应信息，并根据查询请求响应信息确定服务指示信息，图7所示实施例可包括如下步骤：
[0126]
步骤701，接收客户端发送的查询请求。
[0127]
其中，查询请求用于查询多个请求的执行结果。
[0128]
在本公开实施例中，客户端向服务端发送多个请求后，客户端可查询多个请求的执行结果，作为一种可能的实现方式，客户端可向服务端发送查询请求，以查询多个请求的执行结果。
[0129]
步骤702，向客户端发送查询请求响应信息。
[0130]
其中，查询请求响应信息中包括多个请求的执行结果，执行结果用于确定服务指示信息。
[0131]
在本公开实施例中，服务端可响应于该查询请求，向客户端发送查询请求响应信息，客户端根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，可得到多个请求对应的多个服务节点的执行时长和传输时长；进而，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息。
[0132]
比如，针对每个请求，在请求成功的情况下，可统计该请求对应的多个服务节点的执行时长和传输时长，以得到该请求对应的多个服务节点的执行时长和传输时长。
[0133]
步骤703，接收客户端发送的服务指示信息。
[0134]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长。
[0135]
步骤704，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0136]
其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长。
[0137]
步骤705，根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像。
[0138]
其中，耗时图像用于指示对应服务节点响应多个请求的耗时。
[0139]
步骤706，响应于用户操作，对各服务节点的耗时图像进行展示。
[0140]
需要说明的是，步骤703至706的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0141]
综上，通过接收客户端发送的查询请求；向客户端发送查询请求响应信息，由此，可实现客户端根据服务端发送的查询请求响应信息中的多个请求的执行结果，有效地生成服务指示信息。
[0142]
为了清楚地说明上述实施例，现举例进行说明。
[0143]
举例而言，如图8所示，图8是本公开实施例的耗时展示方法的流程示意图。
[0144]
其中，图8中的软件开发工具包(software development kit，简称sdk)可集成在各个服务内部，一个完整的系统通常会有多个微服务，将sdk采集的数据按照logid的哈希值(hash)的规则传给收集器(collector)，收集器会通过已经配置好的小流量白名单进行分类计算，结果存入数据库中，服务端(server)通过查询数据库，将数据传给前端(ui)进行可视化展示。其中，软件开发工具包、收集器、数据库以及服务端 前端的结构可如图9所示。
[0145]
图8所示的耗时展示方法具体可包括如下步骤：
[0146]
1、数据采集(sdk)：通过sdk对多个请求下的各服务节点的耗时进行采集；
[0147]
2、数据汇聚(collector)：如图10所示，将sdk采集的数据上报给收集器(collector)，其中，sdk一次上报的可为多个服务节点的批量信息；此外，如图11所示，collector可对上报的多个服务节点的耗时进行处理，具体过程如下：
[0148]
在collector的入口会进行权限控制，如果上报的ip没有在白名单里会进行拒绝，以避免方式异常的流量造成脏数据出现的情况发生。还具有拒绝开关功能，在流量过大超过服务接受能力时，会先打开开关，拒绝掉所有流量，同时评估流量大小，进行资源扩容，等资源到位后再关闭开关。此外还会进行流量的监控；
[0149]
其中，需要说明的是，collector核心部分又分位一级collector和二级collector。一级collector主要是将sdk发送过来的多个链路和请求头拼接在一起。在一级collector为了将数据量尽可能的分散，进行了分桶，分桶的规则同样是按照logid的hash值，每个分桶对应一个buffer，这里的buffer主要有两类，暂时记为buf和temp。temp中存放下一次即将处理的数据，记为tmpdata，buf中存放的是当前实时的数据，记为bufdata。buf和temp之间的交接流程如下：数据第一次来的时候会先放在buf中，等一个周期(默认10s，后面类似，不再说明)后，会处理temp中的数据，此时temp中的数据为空，不做处理，直接将buf中的数据转移给temp即可。到了第二个周期时，同样也是先检测temp中的数据，这时发现temp有数据，会对其按照key进行节点 请求头拼接，在拼接的同时也会到buf中寻找是否有同样key的数据，如果存在就拼在一起，同时将buf中对应的数据删除，以防止在时间间隔处漏掉数据。拼接完成后，temp中的数据为1个请求 多个node(服务节点)的集合。进而，一方面将这部分数据存到redis中，方便追溯单个请求，key为uid logid，value为对应数据序列化结果，另一方面将数据按照服务节点名进行拆分发送给二级collector。完成后清空temp中数据，buf中的数据转移给temp；
[0150]
此外，对于二级collector同样是rpc服务，这里和一级collector进行了同质部署(代码和服务同为一套，也可分开部署)，方便进行管理和维护。二级collector收到各个节点的请求后，会按照请求中的时间戳进行汇聚，默认同一个窗口的数据会放在一个buffer中。然后按照指定的时间(默认30s)进行推进。将此窗口的数据传给task模块，进行各个分位值的计算。如果过了指定时间窗口(30s)后再有请求时间戳落在已经推进后的窗口内的数据，这时会直接丢弃；
[0151]
task模块会进行此窗口内各个节点的分位值计算，除此之外，如果设置小流量的话还会按照小流量力度进行拆分和计算。小流量白名单来源于数据库，需要提前注册，如果此次请求中的小流量在指定白名单中，则会进行计算，否则不予处理；
[0152]
3、数据存储(db)：这里主要有两类数据库，一类是远程字典服务(remote dictionary server，简称redis)，另一类是关系型数据库管理系统(简称mysql)，其中，
redis主要是以键值对方式(key-value)存储原始请求数据，key为uid logid，value为对应数据序列化结果，方便进行回溯。mysql主要存储各个节点的各个分位值数据(包含均值、80分位、90分位、99分位等)以及请求数和请求失败数。mysql除了存储计算数据之外，还可存储小流量白名单列表；
[0153]
4、数据展示(server ui)：server(服务端)主要负责查询db，并将数据解析为前端所需要的格式，页面则对其进行渲染，方面直观的展示。展示的数据为不同时间序列下的服务节点的耗时。
[0154]
需要说明的是，为了快速定位耗时上涨的服务节点，如图12所示，可通过两个小流量号的对比，以快速定位耗时上涨的服务节点，为后续优化做准备。其中，为了使两个小流量号对应的各服务节点的耗时存在差异，以便进行耗时分析，两个小流量号对应的请求的顺序可不同。
[0155]
本公开实施例的耗时展示方法，通过接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，耗时图像用于指示对应服务节点响应多个请求的耗时；响应于用户操作，对各服务节点的耗时图像进行展示，由此，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，可准确得到各请求对应的多个服务节点的执行时长和传输时长，进而，根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅可包括rpc链路服务节点，还可包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0156]
为了实现上述实施例，本公开提出另一种耗时展示方法。
[0157]
图13是根据本公开第六实施例的示意图。本公开实施的耗时展示方法可应用于客户端，本公开以耗时展示方法应用于客户端进行示例性说明。
[0158]
如图13所示，该耗时展示方法可包括如下步骤：
[0159]
步骤1301，确定服务指示信息。
[0160]
其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长。
[0161]
在本公开实施例中，客户端可在本地查询多个请求的执行结果，也可向服务端发送查询请求以查询多个请求的执行结果。进而，客户端根据多个请求的执行结果，确定多个请求对应的多个服务节点的执行时长和传输时长，进而，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息。
[0162]
步骤1302，向服务端发送服务指示信息。
[0163]
进而，客户端可将服务指示信息发送至服务端，以便于后续各个服务节点的耗时分析。
[0164]
综上，通过确定服务指示信息；向服务端发送服务指示信息，由此，客户端可根据多个请求的执行结果，确定多个请求对应的多个服务节点的执行时长和传输时长，进而，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息，进而，将服务指示信息发送至服务端，服务端可根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅可包括rpc链路服务节点，还可包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0165]
为了清楚地说明上述实施例是如何确定服务指示信息的，本公开提出另一种耗时展示方法。
[0166]
图14是根据本公开第七实施例的示意图。本公开实施的耗时展示方法可应用于客户端。
[0167]
如图14所示，该耗时展示方法可包括如下步骤：
[0168]
步骤1401，查询多个请求的执行结果。
[0169]
其中，执行结果是向服务端发送对应请求后，服务端执行对应请求所得到的。
[0170]
作为一种示例，客户端向服务端发送一个请求后，接收到服务端发送的执行该请求的执行结果后，进行本地存储，在客户端发送多个请求后，并对服务端发送的本次执行结果进行存储后，可在本地进行查询，以得到多个请求的执行结果。
[0171]
作为另一种示例，客户端向服务端发送一个请求后，服务端可对该请求进行响应，并将响应信息发送至客户端，客户端接收到对应的响应信息后，接着向服务端发送另一个请求，不对该响应信息进行存储，服务端执行该另一个请求，并将执行结果发送至客户端，以此类推，在客户端收发送多个请求后，并接收到服务端发送的对应的响应信息后，可向服务端发送查询请求，以查询多个请求的执行结果。
[0172]
步骤1402，根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，以得到多个请求对应的多个服务节点的执行时长和传输时长。
[0173]
进一步地，客户端根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，以得到多个请求对应的多个服务节点的执行时长和传输时长。比如，针对每个请求，在请求成功的情况下，可统计该请求对应的多个服务节点的执行时长和传输时长，以得到该请求对应的多个服务节点的执行时长和传输时长。
[0174]
步骤1403，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息。
[0175]
进而，客户端可根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息。
[0176]
步骤1404，向服务端发送服务指示信息。
[0177]
需要说明的是，步骤1404的执行过程可以分别采用本公开的各实施例中的任一种方式实现，本公开实施例并不对此作出限定，也不再赘述。
[0178]
综上，通过查询多个请求的执行结果；根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，以得到多个请求对应的多个服务节点的执行时长和传输时长，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息，由此，客户端可根据多个请求对应的多个服务节点的执行时长和传输时长，生
成服务指示信息。
[0179]
本公开实施例的耗时展示方法，通过确定服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；向服务端发送服务指示信息，由此，客户端可根据多个请求的执行结果，确定多个请求对应的多个服务节点的执行时长和传输时长，进而，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息，进而，将服务指示信息发送至服务端，服务端可根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅包括rpc链路服务节点，还包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0180]
与上述图1至图12实施例提供的耗时展示方法相对应，本公开还提供一种耗时展示装置，由于本公开实施例提供的耗时展示装置与上述图1至图12实施例提供的耗时展示方法相对应，因此在耗时展示方法的实施方式也适用于本实施例提供的耗时展示装置，在本实施例中不再详细描述。
[0181]
图15是根据本公开第八实施例的示意图。本公开实施的耗时展示方法可应用于服务端。
[0182]
如图15所示，该耗时展示装置1500包括：接收模块1510、划分模块1520、绘制模块1530和展示模块1540。
[0183]
其中，接收模块1510，用于接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；划分模块1520，用于根据所述多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；绘制模块1530，用于根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，耗时图像用于指示对应服务节点响应多个请求的耗时；展示模块1540，用于响应于用户操作，对各服务节点的耗时图像进行展示。
[0184]
作为本公开实施例的一种可能的实现方式，划分模块1520，用于：针对多个请求中的任一请求，根据任一请求的标识信息，确定各任一请求的标识信息对应的哈希值；根据任一请求的标识信息对应的哈希值，从多个请求对应的多个服务节点的执行时长和传输时长中，对与任一请求的哈希值匹配的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇。
[0185]
作为本公开实施例的一种可能的实现方式，绘制模块1530，用于：将各聚簇中各服务节点的执行时长和传输时长进行相加，以得到各服务节点响应多个请求的耗时；针对任一服务节点，判断任一服务节点响应多个请求的耗时是否处于设定时间范围内；根据处于设定时间范围内的各服务节点响应多个请求的耗时，进行图像绘制，以得到各服务节点的耗时图像。
[0186]
作为本公开实施例的一种可能的实现方式，绘制模块1530，还用于：将处于设定时
间范围内的各服务节点响应多个请求的耗时进行排序，以得到各服务节点响应多个请求的耗时排列顺序；获取各服务节点响应多个请求的耗时排列顺序中至少一个设定排列位置的耗时；针对各服务节点的至少一个设定排列位置中的任一设定排列位置，对各服务节点的任一设定排列位置的耗时进行曲线拟合，以得到各服务节点的任一设定排列位置的耗时图像。
[0187]
作为本公开实施例的一种可能的实现方式，耗时展示装置1500还包括：查询模块、确定模块和扩充模块。
[0188]
其中，查询模块，用于查询设定白名单中是否存在客户端的标识信息；确定模块，用于在设定白名单中存在客户端的标识信息时，确定服务指示信息对应的数据量；扩充模块，用于在数据量大于设定数据量阈值时，对服务端的资源进行扩充，其中，资源包括存储资源和/或计算资源。
[0189]
作为本公开实施例的一种可能的实现方式，耗时展示装置1500还包括：拒绝模块。
[0190]
其中，拒绝模块，用于在设定白名单中不存在客户端的标识信息时，拒绝接收客户端发送的服务指示信息。
[0191]
作为本公开实施例的一种可能的实现方式，耗时展示装置1500还包括：发送模块。
[0192]
其中，接收模块，还用于接收客户端发送的查询请求；其中，查询请求用于查询多个请求的执行结果；发送模块，用于向客户端发送查询请求响应信息，其中，查询请求响应信息中包括多个请求的执行结果，所述执行结果用于确定所述服务指示信息。
[0193]
本公开实施例的耗时展示装置，通过接收客户端发送的服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，以得到多个聚簇，其中，各聚簇中包括同一请求对应的多个服务节点的执行时长和传输时长；根据多个聚簇中的多个服务节点的执行时长和传输时长，进行图像绘制，以得到各服务节点的耗时图像；其中，耗时图像用于指示对应服务节点响应多个请求的耗时；响应于用户操作，对各服务节点的耗时图像进行展示，由此，根据多个请求的标识信息，对多个请求对应的多个服务节点的执行时长和传输时长进行划分，可准确得到各请求对应的多个服务节点的执行时长和传输时长，进而，根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅可包括rpc链路服务节点，还可包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0194]
与上述图13至图14实施例提供的耗时展示方法相对应，本公开还提供一种耗时展示装置，由于本公开实施例提供的耗时展示装置与上述图13至图14实施例提供的耗时展示方法相对应，因此在耗时展示方法的实施方式也适用于本实施例提供的耗时展示装置，在本实施例中不再详细描述。
[0195]
图16是根据本公开第九实施例的示意图。本公开实施的耗时展示方法可应用于服务端。
[0196]
如图16所示，该耗时展示装置1600包括：确定模块1610和发送模块1620。
[0197]
其中，确定模块1610，用于确定服务指示信息，其中，服务指示信息中包括多个请
求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各所述服务之间传输对应请求的执行结果的时长；发送模块1620，用于向服务端发送所述服务指示信息。
[0198]
作为本公开实施例的一种可能的实现方式，确定模块1610，用于：查询多个请求的执行结果，执行结果是向服务端发送对应请求后，服务端执行对应请求所得到的；根据多个请求的执行结果，对多个请求对应的多个服务节点的执行时长和传输时长进行统计，以得到多个请求对应的多个服务节点的执行时长和传输时长；根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息。
[0199]
本公开实施例的耗时展示装置，通过确定服务指示信息，其中，服务指示信息中包括多个请求对应的多个服务节点的执行时长和传输时长，执行时长包括对应服务节点中的至少一个服务执行对应请求的时长，传输时长包括对应服务节点中的各服务之间传输对应请求的执行结果的时长；向服务端发送服务指示信息，由此，客户端可根据多个请求的执行结果，确定多个请求对应的多个服务节点的执行时长和传输时长，进而，根据多个请求对应的多个服务节点的执行时长和传输时长，生成服务指示信息，进而，将服务指示信息发送至服务端，服务端可根据各请求对应的多个服务节点的执行时长和传输时长进行耗时图像绘制，可将各服务节点响应多个请求的耗时直观显示，便于进行耗时分析，同时，每个请求对应的多个服务节点不仅可包括rpc链路服务节点，还可包括服务内部自定义服务节点，提高了耗时分析的准确性。
[0200]
为了实现上述实施例，本公开还提出一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使至少一个处理器能够执行上述图1至图12实施例的耗时展示方法，或者，执行图13至图14实施例所述的耗时展示方法。
[0201]
为了实现上述实施例，本公开还提出一种存储有计算机指令的非瞬时计算机可读存储介质，其中，计算机指令用于使所述计算机执行上述图1至图12实施例所述的耗时展示方法，或者，执行图13至图14实施例所述的耗时展示方法。
[0202]
为了实现上述实施例，本公开还提出一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述图1至图12实施例所述的耗时展示方法，或者，实现上述图13至图14实施例所述的耗时展示方法。
[0203]
需要说明的是，本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均在征得用户同意的前提下进行，并且均符合相关法律法规的规定，且不违背公序良俗。
[0204]
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
[0205]
图17示出了可以用来实施本公开的实施例的示例电子设备1700的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
[0206]
如图17所示，设备1700包括计算单元1701，其可以根据存储在只读存储器(rom)1702中的计算机程序或者从存储单元1708加载到随机访问存储器(ram)1703中的计算机程序，来执行各种适当的动作和处理。在ram 1703中，还可存储设备1700操作所需的各种程序和数据。计算单元1701、rom 1702以及ram 1703通过总线1704彼此相连。输入/输出(i/o)接口1705也连接至总线1704。
[0207]
设备1700中的多个部件连接至i/o接口1705，包括：输入单元1706，例如键盘、鼠标等；输出单元1707，例如各种类型的显示器、扬声器等；存储单元1708，例如磁盘、光盘等；以及通信单元1709，例如网卡、调制解调器、无线通信收发机等。通信单元1709允许设备1700通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
[0208]
计算单元1701可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1701的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1701执行上文所描述的各个方法和处理，例如耗时展示方法。例如，在一些实施例中，耗时展示方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1708。在一些实施例中，计算机程序的部分或者全部可以经由rom 1702和/或通信单元1709而被载入和/或安装到设备1700上。当计算机程序加载到ram 1703并由计算单元1701执行时，可以执行上文描述的耗时展示方法的一个或多个步骤。备选地，在其他实施例中，计算单元1701可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行耗时展示方法。
[0209]
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
[0210]
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0211]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或
上述内容的任何合适组合。
[0212]
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
[0213]
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)、互联网和区块链网络。
[0214]
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。
[0215]
其中，需要说明的是，人工智能是研究使计算机来模拟人的某些思维过程和智能行为(如学习、推理、思考、规划等)的学科，既有硬件层面的技术也有软件层面的技术。人工智能硬件技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大数据处理等技术；人工智能软件技术主要包括计算机视觉技术、语音识别技术、自然语言处理技术以及机器学习/深度学习、大数据处理技术、知识图谱技术等几大方向。
[0216]
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
[0217]
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。