业务请求处理方法、装置、计算机设备和存储介质与流程

1.本技术涉及云计算技术领域，特别是涉及一种业务请求处理方法、装置、计算机设备和存储介质。


背景技术：

2.随着云计算覆盖行业的不断深入，云计算后台业务复杂度越来越高，处理流程越来越长。为应对服务复杂度的膨胀，使服务职责内聚，微服务架构逐渐成为主流。在微服务架构下，复杂业务请求会涉及多个微服务调用，流程可能会很长，如涉及到多个服务节点。
3.微服务架构可应用在一些实时性要求较高的场景，以自动驾驶为例，自动驾驶汽车采集车身周围的图像数据和三维点云数据，实时发送给云服务，由云服务对图像数据和三维点云数据进行识别处理，做出驾驶决策，并返回给自动驾驶汽车。云服务响应自动驾驶汽车的业务请求，多个服务节点调用，例如，一个服务节点对图像数据进行预处理，一个服务节点对三维点云数据进行处理，一个服务节点对预处理后的图像数据进行识别，一个服务节点综合三维点云处理结果和图像识别结果做出驾驶决策。
4.在实际应用中，由于汽车驾驶环境不断发生变化，若其中一个服务节点响应时间过长，导致业务处理占用较长时间，将无法满足用户对服务响应时实性的要求。


技术实现要素：

5.基于此，有必要针对上述技术问题，提供一种能够提高实时性的业务请求处理方法、装置、计算机设备和存储介质。
6.一种业务请求处理方法，所述方法包括：
7.当获取到业务请求时，获取所述业务请求对应的预设超时时间；
8.生成执行所述业务请求的调用链以及所述调用链的根服务节点；
9.根据所述预设超时时间确定所述业务请求调用链的生存时间；所述调用链的生存时间不超过所述预设超时时间；
10.从所述根服务节点执行所述业务请求；
11.当所述调用链的生存时间到过期时，停止执行所述业务请求，返回超时信息。
12.一种业务请求处理装置，其特征在于，所述装置包括：
13.业务请求获取模块，用于当获取到业务请求时，获取所述业务请求对应的预设超时时间；
14.调用链处理模块，用于生成执行所述业务请求的调用链以及所述调用链的根服务节点；
15.生存时间设置模块，用于根据所述预设超时时间确定所述业务请求调用链的生存时间；所述调用链的生存时间不超过所述预设超时时间；
16.执行模块，用于从所述根服务节点执行所述业务请求；
17.控制模块，用于当所述调用链的生存时间到过期时，停止执行所述业务请求，返回
超时信息。
18.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述各实施例任一项方法的步骤。
19.一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现上述各实施例任一项方法的步骤。
20.上述业务处理方法、装置、计算机设备和存储介质，基于调用链技术实现微服务架构调用链追踪，在此基础上，为执行业务请求的调用链设置生存时间，当调用链的生存时间过期时，停止执行业务请求，返回超时信息。从而，能够及时停止响应时间过长的业务请求，确保业务请求的实效性。
附图说明
21.图1为一个实施例中业务请求处理的应用环境图；
22.图2为一个实施例中业务请求处理的流程示意图；
23.图3为一个实施例中云服务的各服务节点的调用关系示意图
24.图4为一个实施例中当生存时间到期时，停止调用链执行的说明示意图；
25.图5为一个实施例中生成服务节点的生存时间的说明示意图；方法的流程示意图；
26.图6为一个实施例中生存时间过期处理策略的流程示意图；
27.图7为另一个实施例中生存时间过期处理策略的流程示意图；
28.图8为一个实施例中业务请求处理装置的结构框图；
29.图9为一个实施例中计算机设备的内部结构图。
具体实施方式
30.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
31.云技术(cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术的一种应用为云计算。
32.云计算(cloud computing)指it基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是it和软件、互联网相关，也可是其他服务。云计算是网格计算(grid computing)、分布式计算(distributedcomputing)、并行计算(parallel computing)、效用计算(utility computing)、网络存储(network storage technologies)、虚拟化(virtualization)、负载均衡(load balance)等传统计算机和网络技术发展融合的产物。
33.随着互联网、实时数据流、连接设备多样化的发展，以及搜索服务、社会网络、移动商务和开放协作等需求的推动，云计算迅速发展起来。不同于以往的并行分布式计算，云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。
34.本技术提供的业务请求处理方法，可以应用于如图1所示的应用环境中。业务终端
102通过网络与服务器104可以通过有线或无线通信方式进行直接或间接地连接。服务器采用微服务架构，涉及到四个服务节点，通过将功能分散到四个服务中心以实现业务处理。可以理解的是，四个服务节点只是一个示例，根据云计算的应用场景，微服务架构可设置更多或更少的服务节点。
35.其中，服务器当获取到业务请求时，获取业务请求对应的预设超时时间；生成执行业务请求的调用链以及调用链的根服务节点；根据预设超时时间确定业务请求调用链的生存时间；调用链的生存时间不超过预设超时时间；从根服务节点执行业务请求；当调用链的生存时间到过期时，停止执行业务请求，返回超时信息。
36.业务终端102为业务请求的发送终端，其实体类型与云计算的应用场景有关，包括但不限于各种智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，网络摄像头，汽车等等。服务器104可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。
37.在一个实施例中，如图2所示，提供了一种业务请求处理方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：
38.步骤202，当获取到业务请求时，获取业务请求对应的预设超时时间。
39.业务请求是由业务终端向云服务器发送的对其业务数据的处理请求。业务请求与云服务器所提供的计算处理服务相关。本技术适应于实时性较高的应用场景的业务请求的处理，例如，云计算提供远程医疗服务，业务请求为医疗数据处理请求，请求云服务器对远程医疗终端采集的医疗数据进行识别处理。又如，云计算提供自动驾驶决策服务，业务请求为自动驾驶汽车采集的驾驶图像数据，请求云服务器对驾驶图像数据进行识别做出驾驶决策。又如，云计算提供图像图别服务，业务请求为图像采集终端采集的视频帧图像数据，请求云服务器对视频帧图像数据进行识别，识别其中的行人。
40.业务终端基于待处理数据向云服务器发送业务请求，当api接口接收到业务终端的业务请求，将业务请求发往云服务器，云服务器根据所调用的api接口确定业务请求超时时间。在实际的应用场景中，云服务器提供不同api接口对不同业务请求进行处理，根据实际业务时效性需求，开发人员预先设置不同api接口对应业务请求的预设超时时间。其中，实时性越高的应用场景，预设超时时间越短，实时性低的应用场景，可设置较长的预设超时时间。
41.步骤204，生成执行业务请求的调用链以及调用链的根服务节点。
42.随着微服务设计理念在系统中的应用，业务的调用链越来越复杂。一个请求可能会涉及到几十个服务的协同操作，涉及到多个团队的业务系统。当遇到问题需要定位时候，也会产生一系列的麻烦。而通过调用连，把一次请求调用过程完整的串联起来，实现了对请求调用路径的监控，便于故障快速定位。
43.当接收到业务请求后，生成一个全局调用链标识(trace id),通过traceid可以串联起整个调用链，一个traceid代表一次请求。
44.云服务器采用服务化框架，由一系列服务组成，且服务是可以独立运行的进程，不同服务可使用不同开发语言，可能分布部署在几千台服务器上，甚至可能横跨多个不同的
数据中心，服务间使用轻量的通信机制，服务之间存在复杂的调用关系。
45.例如，如图3所示，业务终端的业务请求首先到达a服务节点，a服务节点分别对b服务节点和c服务节点进行调用，其中，b服务节点处理完成给a服务节点做出响应，c服务节点还需要调用d服务节点和e服务节点，接收到d服务节点和e服务节点的响应后，再给a服务节点做出响应，最后由a服务节点来响应用户的业务请求。则，a服务节点、b服务节点、c服务节点、d服务节点和e服务节点分别为业务请求时调用链上的服务节点。如图3所示的各服务节点的调用关系图则为该业务请求的调用链。
46.其中，根服务节点是指业务请求服务的入口，即是响应业务请求的入口服务机器。云服务所提供的响应业务请求的根服务节点是预先设置的，云服务接收到的业务请求，首先达到业务请求对应的根服务节点。
47.存在调用关系的两个服务节点互为父服务节点和子服务节点，其中，被调用的服务节点为子服务节点。以对监控终端的视频帧图像的行为进行识别为例，首先业务请求达到a服务节点(根服务节点)，由根服务节点对监控设备进行验证，并在验证通过后，对视频帧图像进行预处理。预处理后，a服务节点对b服务节点进行调用，利用b服务节点的神经网络模型进行图像识别，识别图像中的行人。a服务节点为业务请求调用链的根服务节点。对于b服务节点来说，a服务节点是b服务节点的父服务节点。对于a服务节点来说，b服务节点是a服务节点的子服务节点。
48.步骤206，根据预设超时时间确定业务请求调用链的生存时间；调用链的生存时间不超过预设超时时间。
49.生存时间(time to live,ttl)是指响应业务请求执行业务处理逻辑的最长响应时间。调用链的生存时间，是指调用链的有效生存时长，当该时间到期时，结束根调用链，避免在该生存时间之外仍执行业务请求的调用链。其中，调用链的生存时间以预设超时时间为参照，不超过预设超时时间，通常等于预设超时时间。例如，一个业务请求的预设超时时间为30毫秒，则基于此将调用链的生存时间设置为30毫秒。
50.步骤280，从根服务节点执行业务请求。
51.其中，业务请求在执行时，根据与该业务请求相关的微服务架构，按序调用各服务节点(span)，调用链则是多个服务节点组成的有向无环图。其中，每个服务节点执行对应的业务处理逻辑并向其父服务节点(发起调用的服务节点)返回处理结果。
52.当服务节点在执行业务处理逻辑需要调用子服务节点时，生成子服务节点的节点标识(span id)，记录子服务节点的父服务节点的节点标识(span id)和调用链标识(trace id)，根据调用链标识(traceid)可以串联起整个调用链，根据记录的各父服务节点的子服务节点，可以按序串联整个调用链。
53.其中，业务处理逻辑是指为达到一定的目的计算机程序代码的处理过程，如为了进行图像识别，计算机程序代码实现图像识别的处理过程就是一个业务处理逻辑。每一个服务节点具有完成业务请求对应的业务处理逻辑。业务处理逻辑与具体业务场景相关。例如，图像识别的云服务场景，其中一个服务节点的业务处理逻辑为图像预处理，另一个服务节点的业务处理逻辑为利用神经网络模型进行图像识别。本技术的技术方案不涉及具体业务场景，对于各服务节点的业务处理逻辑不展开说明。
54.步骤210，当调用链的生存时间到过期时，停止执行业务请求，返回超时信息。
55.如图4所示，当调用链的生存时间到期时，停止执行业务请求，返回超时信息，使在设定时间内停止响应时间过长的业务请求，确保业务请求的实效性。而通过取消超时后调用链的后续操作，节约了系统资源。
56.本实施例中，根据不同业务类型对响应实时性的要求以及业务终端的请求频率，预先设置有不同的预设超时时间，进而根据超时时间设置调用链的生存时间，当调用链的生存时间过期时，停止执行业务请求的业务处理逻辑，返回超时信息。
57.以云服务器应用于图像识别应用场景为例，对于摄像机采集的视频帧图像，对视频帧的行人进行识别。摄像机的采集频率为60帧/秒，摄像机采集的视频帧数据实时发送至云服务进行识别处理。预先根据摄像机的采集频率设置超时时间，如设置超时时间为1/60秒，受视频帧图像采集频率的影响，若云服务对当前视频帧图像的识别响应超过超时时间，而此时云服务已接收到下一视频帧图像的业务请求，而最新一个视频帧图像的实效性优于超时未完成的视频帧图像，在这种应用场景下，可停止对该视频帧图像的识别。
58.以云服务器应用于自动驾驶决策应用场景为例，对于自动驾驶汽车采集的车身各摄像头采集的图像数据以及激光雷达三维点云进行识别，做出自动驾驶决策，如调整行驶方向等。预先根据摄像机的采集步骤和激光雷达采集频率设置超时时间，如设置超时时间为1/60秒，若云服务对当前视频帧图像和三维激光点云的识别响应超过超时时间，而此时云服务已接收到下一业务请求(如汽车行驶了一段，车周环境发生变化)，即使计算出行驶决策，也时过境迁，不具有时效，没有使用价值。在这种应用场景下，可停止对该视频帧图像和三维激光点云的识别。
59.可以理解的是，在实时性较高的业务场景，业务终端的业务请求是不停的发送至云服务器的，停止对一个业务请求的处理，并不会对业务造成影响。比如，由于预设超时时间是根据请求频率和摄像机的采集频率设置的，当超过预设超时时间，停止了对视频帧图像处理，但此时已接收到最新一帧视频帧图像，可立即对最新的业务请求进行处理，且由于该业务请求的数据是最新的，对业务终端来说，具有更高的时效性。
60.上述的业务请求处理方法，基于调用链技术实现微服务架构调用链追踪，在此基础上，为执行业务请求的调用链设置生存时间，当调用链的生存时间过期时，停止执行业务请求，返回超时信息。从而，能够及时停止响应时间过长的业务请求，确保业务请求的实效性。
61.在另一个实施例中，根据预设超时时间确定业务请求调用链的生存时间，包括：根据预设超时时间，为调用链的根服务节点设置生存时间；对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间；子服务节点的生存时间不超过父服务节点的生存时间。
62.调用链的生成时间表示链用链上各服务节点的整体生存时间，调用链反应了各服务节点的调用时序，因此，调用链的生存时间反应的是调用链上各服务节点全局的生存时间，可将调用链的生存时间分配给各服务节点，得到各服务节点的生存时间。可以理解的是，各服务节点整体的全局生存时间不应该大于预设超时时间。
63.为确保服务节点的时效性，对于存在调用关系的父服务节点和子服务节点，通常父服务节点的业务执行需要依靠子服务节点，二者在业务执行上具有依赖性。基于这种依赖性，子服务节点的生存时间被分配为依赖于父服务节点的生存时间。而所有的子服务节
点均可看成为根服务节点调用，因此，所有子服务节点的生存时间依赖于根服务节点的生存时间。
64.具体地，根据预设超时时间为根服务节点设置生存时间，根据父服务节点的生存时间为子服务节点设置生存时间。根服务节点的生存时间不超过预设超时时间，子服务节点的生存时间不超过父服务节点的生存时间。
65.具体地，云服务器接收到业务请求后，生成业务请求的根服务节点，为根服务节点设置生存时间。其中，根服务节点的生存时间为业务请求的预设超时时间。例如，业务请求的预设超时时间为30毫秒，则根服务节点的生存时间为30毫秒。
66.可以理解的是，对于调用链的服务节点而言，其生存时间是在生成对它的调用时候设置的，即当需要调用该服务节点时，根据父服务节点的生存时间设置子服务节点的生存时间。
67.从根服务节点执行业务请求。当正在执行业务处理逻辑的根服务节点需要子服务节点时，生成根服务节点所需要调用的子服务节点。如图3所示，为根服务节点a生成子服务节点b。其中，根服务节点a为子服务节点b的父服务节点。从而，子服务节点的生存时间依赖于父服务节点的生存时间。
68.子服务节点是服务节点在执行业务逻辑时，根据业务逻辑被该服务节点所调用的服务节点。如图3所示，b服务节点和c服务节点是a服务节点的子服务节点，d服务节点和e服务节点是c服务节点的子服务节点。
69.父服务节点是调用子服务节点的服务节点。如图3所示，a服务节点是b服务节点和c服务节点的父服务节点，c服务节点是d服务节点和e服务节点的父服务节点。
70.其中，根据父服务节点的生存时间设置子服务节点的生存时间，子服务节点的生存时间不超过父服务节点的生存时间。
71.更进一步地，为使父服务节点和子服务节点的生存时间在同一时刻消耗完毕，确保父服务节点和子服务节点逻辑一致性，子服务节点继承父服务节点的生存时间，即子服务节点的生存时间为父服务节点的剩余生存时间。
72.具体地，对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间，包括：对于执行业务请求时所调用的子服务节点，令子服务节点继承父服务节点的生存时间。如图5所示，子服务节点b的生存时间为根服务节点a的剩余生存时间。
73.其中，剩余生存时间根据子服务节点的生成时间，即开始时间戳所确定。例如，对于正在执行业务请求的c服务节点，c服务节点的生存时间为10毫秒，c服务节点执行业务逻辑的过程中，在第6毫秒生成子服务节点d，则子服务节点d的生存时间为c服务节点的剩余生存时间4秒。
74.其中，根据父服务节点的生存时间、子服务节点的开始时间戳和父服务节点的开始时间戳，为子服务节点设置生存时间。具体地，子服务节点的生存时间＝父服务节点的生存时间-子服务节点的开始时间戳 父服务节点的开始时间戳。如图5所，b服务节点的生存时间＝a服务节点的生存时间-b服务节点的开始时间戳 a服务节点的开始时间戳。例如，a服务节点的生存时间(父服务节点)的生存时间为20毫秒，a服务节点的开始时间戳为8点20分1秒10毫秒，b服务节点(子服务节点)的开始时间戳为8点20分1秒15毫秒，则b服务节点的
生存时间为20毫秒-8点20分1秒15毫秒 8点20分1秒10毫秒＝15毫秒。
75.进一步地，正在执行业务处理逻辑的子服务节点b需要子服务节点时，生成子服务节点所需要调用的子服务节点c。其中，子服务节点b为子服务节点c的父服务节点。子服务节点c的生存时间为子服务节点b的剩余生存时间。
76.其中，c服务节点的生存时间＝b服务节点的生存时间-c服务节点的开始时间戳 b服务节点的开始时间戳。例如，服务节点b的生存时间为15毫秒，父服务节点b的开始时间戳为8点20分1秒15毫秒，子服务节点c的开始时间戳为8点20分1秒20毫秒，则子服务节点c的生存时间为15毫秒-8点20分1秒20毫秒 8点20分1秒15毫秒＝10毫秒。
77.该方法采用继承的方法，使子服务节点继承父服务节点的生存时间，能够使父服务节点和子服务节点的生存时间在同一时刻消耗完毕。同时，为各服务节节点分别设置生存时间，各服务节点只需要关心自己的到期时间，无需与其它服务节点沟通，节约了服务器资源。
78.由于子服务节点的生存时间继承了父服务节点的生存时间，根服务节点的生存时间为全局生存时间，因此，可以认为，当某一个子服务节点的生存时间到期时，整个调用链的生存时间到期。
79.在另一个实施例中，当调用链的生存时间到过期时，停止执行业务请求，返回超时信息，包括：当正在执行业务处理逻辑的当前服务节点的生存时间过期时，停止执行业务处理逻辑，返回超时信息。
80.具体地，正在执行业务处理逻辑的当前服务节点，可以是调用链上正在执行业务处理逻辑的根服务节点或任一个子服务节点，对于正在执行业务处理逻辑的当前服务点而言，当生存时间到期时，停止执行业务处理逻辑，返回超时信息。
81.其中，正在执行业务处理逻辑的子服务节点的生存时间到期时，停止执行业务处理逻辑，向父服务节点返回超时信息。正在执行业务处理逻辑的根服务节点的生存时间到期时，停止执行业务处理逻辑，向业务终端返回超时信息。此处的业务处理逻辑指的是每一个服务节点为完成业务请求所需要实施的业务处理过程。
82.在实际应用中，云服务通过各服务节点执行业务请求，为完成业务请求，各服务节点所执行的业务逻辑不同，执行业务逻辑所占用的资源也不相同。以云服务实现图像识别为例，服务节点1判断视频帧图像是否为关键帧，服务节点2对关键帧图像利用卷积神经网络进行识别。服务节点1仅处理简单的业务逻辑，对资源消耗不大，服务节点2需要识别出图像中的实体，需要占用较大的cpu和gpu资源。
83.当当前服务节点的生存时间到期时，不能暴力的底层直接干掉进程，针对不同占用资源不同的服务节点，为在实时性、资源和性能损耗中取得平衡。开发人员可预先根据服务节点执行业务处理逻辑时所占用的资源情况，采用不同的过期执行策略。
84.一个实施例中，当正在执行业务处理逻辑的当前服务节点的生存时间过期时，停止执行业务处理逻辑，返回超时信息，包括：针对占用资源大于预设标准的第一类服务节点，建立定时器监控生存时间，在当前服务节点执行业务逻辑时，若定时器到期，则停止执行业务逻辑，返回超时信息。
85.具体地，开发人员根据服务节点执行业务处理逻辑时所占用的资源损耗，对于占用资源较大，逻辑较重的服务节点，将其归类为第一类服务节点。对于第一类服务节点，设
置了“强过期”执行策略，为避免生存时间到期后，执行业务逻辑仍占用较大的系统资源，当前服务节点在服务节点的生存时间到期后即退出，向父服务节点返回超时信息。
86.针对占用资源大于预设标准的第一类服务节点，建立定时器监控生存时间，在当前服务节点执行业务逻辑时，若定时器到期，则停止执行业务逻辑，返回超时信息，包括：针对占用资源大于预设标准的第一类服务节点，创建主线程，主线程根据生存时间生成定时器；建立子线程执行业务处理逻辑；当主线程的定时器到期时，若子线程的业务处理逻辑未完成，则主线程返回超时信息。
87.若开发人员根据当前服务节点执行业务处理逻辑时所占用的资源情况，确定当前服务节点为第一类服务节点时，为该服务节点设置“强过期”执行策略。“强过期”执行策略的目的是针对执行业务处理逻辑占用资源较大的服务节点，一旦生存时间到期，即强制结束，返回超时信息。如图6所示，每一个父服务节点生成子服务节点时，将调用链id(trace id),服务节点id(span id)以及服务节点的生存时间写下span上下文信息。子服务节点建立主线程601访问span上下文信息，解析得到当前服务节点的生存时间，生成调用链的当前服务节点，主线程启用过期时间为生存时间的定时器，并等待定时器到期。同时，子服务节点创建子线程602，子线程执行业务处理逻辑，如图像识别的预处理，又如基于卷积神经网络进行图像识别等。子线程602在业务处理逻辑执行完毕后，向主线程601发送消息，返回执行结果，主线程在定时器到期后，根据是否接收到子线程返回的执行结果判断子线程的业务处理逻辑是否执行完毕，若未完成，则向其父服务节点返回超时信息，强制停止当前服务节点的业务处理逻辑，避免继续执行业务处理逻辑占用大量资源。
88.进一步地，当主线程的定时器到期时，若子线程的业务处理逻辑完成，则返回业务处理结果。
89.本实施例中，针对执行业务处理逻辑占用较大资源的当前服务节点预先设置“强过期”处理策略，通过建立定时器监控，一旦当前服务节点的生存时间到期，立即停止执行业务处理逻辑，返回超时信息，一方面保证了业务处理的实效性，避免业务处理流程无限制的执行下去，另一方面，避免继续执行业务处理逻辑占用大量资源，及时释放资源。
90.在另一个实施例中，当正在执行业务处理逻辑的当前服务节点的生存时间过期时，停止执行业务处理逻辑，返回超时信息，包括：针对占用资源小于预设标准的第二类服务节点，在执行业务逻辑需要调用子服务节点时，若当前服务节点的生存时间过期，则停止执行业务处理逻辑，返回超时信息。
91.开发人员根据当前服务节点执行业务处理逻辑时所占用的资源情况，若占用资源较少，确定当前服务节点为第二类服务节点时，为该服务节点设置“懒过期”执行策略。“懒过期”执行策略的是针对执行业务处理逻辑占用资源较小的服务节点，无需强制生存时间到期即停止业务处理流程，而是到达一定的条件再去判断生时时间是否过期，以避免建立定时器和双线程所占用较大资源。由于该服务节点本身在执行业务处理逻辑时所占用的资源较少，即使生存时间稍加过期，并不会过多占用系统资源，且判断过期后停止执行业务流程，能够确保实效性，实效性、资源找到平衡。
92.具体地，开发人员根据服务节点执行业务处理逻辑时所占用的资源损耗，对于占用资源较小，逻辑较轻的服务节点，将其归类为第二类服务节点。第二类服务节点，服务节点仅处理简单的业务逻辑，对资源消耗不大。对于第二类服务节点，设置了“懒过期”执行策
略，无需实时监控生存期。只有当当前服务节点根据业务处理逻辑需要调用子服务节点时，判断当前服务节点的生存时间是否到期。若当前服务节点的生存时间过期时，则向父服务节点返回超时信息。由于第二类服务节点在执行业务处理逻辑时，所占用的资源少，在需要调用子服务节点时再判断其生存时间是否耗尽，并不会占用过多资源。相比较利用定时器建立双线程的“强过期”处理策略，能够避免建立定时器和子线程所占用内核资源，为实效性、资源找到平衡。
93.在执行业务逻辑需要调用子服务节点时，若当前服务节点的生存时间未过期，则执行对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间的步骤。即生成子服务节点，为子服务节点分配生存时间。
94.同时，在当前服务节点的业务处理逻辑执行完毕后，若当前服务节点的生存时间未过期，则向当前服务节点的父服务节点返回业务处理结果。若当前服务节点的生存时间过期，则向父服务节点返回超时信息。
95.具体地，如图7所示，“懒过期”处理策略包括以下步骤：
96.s702：解析生存时间，生成当前服务节点。
97.每一个父服务节点生成子服务节点时，将调用链id(trace id),服务节点id(span id)以及服务节点的生存时间写下span上下文信息。子服务节点的主线程访问span上下文信息，解析得到当前服务节点的生存时间，父服务节点的节点id，调用链id，生成调用链的当前服务节点。根据子服务节点的节点id，父服务节点的节点id以及调用链id，可用于追踪业务请求的调用链。
98.s704，执行当前服务节点的业务处理逻辑。
99.s706，在执行业务处理流程时，监控是否需要生成子服务节点。若是，则执行步骤s708。若否，则执行步骤s710。
100.s708，判断当前服务节点的生存时间是否过期。若是，则返回超时信息返回超时信息。若否，则生成子服务节点。
101.当前服务节点执行业务处理流程，当根据业务逻辑需要调用子服务节点时，判断当前服务节点的生存时间是否到期，若当前服务节点的生存时间到期，则返回超时信息。
102.若当前服务节点的生存时间未到期，则生成子span，具体的，执行对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间的步骤。即，根据父服务节点的剩余生存时间为子服务节点生成子服务节点的生存时间。
103.具体地，根据当前服务节点的剩余生存时间判断当前服务节点的生存时间是否过期。剩余生存时间的计算方法为：剩余生存时间＝当前服务节点的生存时间-当前时间戳 当前服务节点的开始时间戳。当剩余生存时间大于0时，表示当前服务节点的生存时间未到期。当剩余生存时间小于0时，表示当前服务节点的生存时间已过期。
104.该生存时间是否过期的判断，是在当业务处理逻辑需要调用子服务节点时，根据判断结果，若生存时间过期，则向父服务节点返回超时信息，若生存时间未过期，则生成子服务节点。在需要调用子服务节点时，判断是否有剩余生存时间，对子服务节点负责，以判断是否有足够的剩余生存时间去生成子服务节点。
105.s710，继续执行业务处理流程，直至业务处理逻辑结束。
106.若当前服务节点的剩余生存时间未过期，则继续执行业务处理流程，直至业务处理逻辑结束。
107.在步骤s710之后，执行s712。
108.s712，判断当前服务节点的生存时间是否过期。若是，则返回超时信息。若否，则返回业务处理结果。
109.在业务处理逻辑结束后，进一步判断当前服务节点的生存时间是否到期，该生存时间是否过期的判断是在当前服务节点的业务处理逻辑结束后，根据判断结果，当前服务节点可向父服务节点反馈，对父服务节点负责，在判断该业务处理逻辑是否在生存时间内处理完成。若生存时间过期，则返回超时信息，若生存时间未过期，则返回业务处理结果。
110.本实施例的“懒过期”策略，无需实时监控生存时间，只有当需要调用子服务节点以及完成当前服务节点的业务处理逻辑时，才触发生存时间是否过期的判断，由于在执行业务处理逻辑时，所占用的资源本来就少，在需要调用子服务节点时或执行结束后再判断其生存时间是否耗尽，并不会占用过多资源，为实效性、资源找到平衡。
111.本技术还提供一种应用场景，该应用场景应用上述的业务处理方法。具体地，该业务处理方法在该应用场景的应用如下：
112.该应用场景为自动驾驶，自动驾驶汽车车周装有设置摄像头，定位系统以及激光雷达，云服务器提供自动驾驶决策计算。自动驾驶汽车以60帧/秒的速度采集视频帧图像以及三维激光点云数据并发送至云服务器。
113.云服务器当获取到业务请求时，获取业务请求对应的预设超时时间。其中，预设超时时间设置有23毫秒。这是因为自动驾驶汽车的采集频率为60秒/帧，若对一帧视频图像的响应时间过长，将导致驾驶决策不具有实效性。
114.云服务器生成执行业务请求的调用链以及调用链的根服务节点。
115.云服务器的调用链如图3所示，当业务请求到达a服务节点时，由a服务节点响应业务请求，做出汽车行驶决策。a服务结点调用b服务结果对定位数据进行处理，确定自动即使汽车当前位置，a服务节点调用c服务节点根据三维点云数据和图像数据确定前方障碍物。c服务节点调用d服务节点对三维点云数据进行处理，识别车道线和障碍物，调用e服务节点对图像数据进行处理，基于图像识别行人和汽车等障碍物。d服务节点和e服务节点的处理结果返回给c服务节点，c服务节点根据图像识别和三维点云检测的障碍物，确定可移动方向，c服务节点和b服务节点的处理结果返回给a服务节点，a服务结果根据确定的可移动方向和当前定位，确定最终移动方向。
116.云服务器根据预设超时时间确定业务请求调用链的生存时间。具体地，将预设超时时间设置为根服务节点的生存时间，在执行业务处理逻辑的服务节点调用子服务节点时，根据父服务节点的剩余生存时间为子服务节点设置生存时间，从而能够使父子服务节点的生存时间在同一时刻消耗完毕。例如，根服务节点a的生存时间为23毫秒。在根服务节点执行业务处理逻辑需要调用子服务结点b时，若根服务节点剩余时间为15秒，则设置子服务节点的生存时间为15秒。
117.从根服务节点执行业务请求，当调用链的生存时间到过期时，停止执行业务请求，返回超时信息。具体地，当正在执行业务处理逻辑的当前服务节点的生存时间过期时，停止执行业务处理逻辑，返回超时信息，云服务器对更具时效性的下一业务请求进行处理。而正
在执行业务处理逻辑的当前服务节点的生存时间未过期，则继续执行业务处理逻辑，向父服务节点返回业务处理结果。当a服务节点在生存时间内接收到子服务节点的业务处理结果，a服务节点向自动驾驶汽车返回行驶决策。
118.该方法能够及时停止响应时间过长的业务请求，确保业务请求的实效性。
119.其中，过期执行策略由开发人员根据服务节点执行业务处理逻辑时所占用的资源确定，对于占用资源较大的服务节点，使用“强过期”处理策略，利用定时器和子线程，一旦定时器的生存时间到期，立即停止执行业务处理逻辑。
120.对于占用资源较小的服务节点，使用“懒过期”处理策略，在需要调用子线程以及当前服务节点的业务处理逻辑执行完毕时，才检测生存时间是否到期，在过期后，停止执行业务处理逻辑。
121.可以理解的是，在一个微服务架构中，两个过期处理策略同时应用在不同的服务节点，为实效性、资源找到平衡。
122.应该理解的是，虽然图2，5-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2，5-6中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
123.在一个实施例中，如图8所示，提供了一种业务请求处理装置，该装置可以采用软件模块或硬件模块，或者是二者的结合成为计算机设备的一部分，该装置具体包括：
124.业务请求获取模块801，用于当获取到业务请求时，获取业务请求对应的预设超时时间；
125.调用链处理模块802，用于生成执行业务请求的调用链以及调用链的根服务节点；
126.生存时间设置模块803，用于根据预设超时时间确定业务请求调用链的生存时间；调用链的生存时间不超过预设超时时间；
127.执行模块804，用于从根服务节点执行业务请求；
128.控制模块805，用于当调用链的生存时间到过期时，停止执行业务请求，返回超时信息。
129.上述业务请求处理装置，基于调用链技术实现微服务架构调用链追踪，在此基础上，为执行业务请求的调用链设置生存时间，当调用链的生存时间过期时，停止执行业务请求，返回超时信息。从而，能够及时停止响应时间过长的业务请求，确保业务请求的实效性。
130.在另一个实施例中，生存时间设置模块，包括：
131.根节点设置模块，用于根据预设超时时间，为调用链的根服务节点设置生存时间。
132.子节点设置模块，用于对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间；子服务节点的生存时间不超过父服务节点的生存时间。
133.在另一个实施例中，控制模块，用于当正在执行业务处理逻辑的当前服务节点的生存时间过期时，停止执行业务处理逻辑，返回超时信息。
134.在另一个实施例中，控制模块，用于针对占用资源大于预设标准的第一类服务节点，建立定时器监控生存时间，在当前服务节点执行业务逻辑时，若定时器到期，则停止执行业务逻辑，返回超时信息。
135.在另一个实施例中，控制模块，用于针对占用资源大于预设标准的第一类服务节点，创建主线程，主线程根据生存时间生成定时器；建立子线程执行业务处理逻辑；当主线程的定时器到期时，若子线程的业务处理逻辑未完成，则主线程返回超时信息。
136.在另一个实施例中，控制模块，用于当主线程的定时器到期时，若子线程的业务处理逻辑完成，则返回业务处理结果。
137.在另一个实施例中，控制模块，用于针对占用资源小于预设标准的第二类服务节点，在执行业务逻辑需要调用子服务节点时，若当前服务节点的生存时间过期，则停止执行业务处理逻辑，返回超时信息。
138.在另一个实施例中，控制模块，用于若当前服务节点的生存时间到期，则执行对于执行业务请求时所调用的子服务节点，根据子服务节点的父服务节点的生存时间为子服务节点设置生存时间的步骤。
139.在另一个实施例中，控制模块，用于当前服务节点的业务处理逻辑执行完毕后，若当前服务节点的生存时间未过期，则向当前服务节点的父服务节点返回业务处理结果。
140.在另一个实施例中，控制模块，用于在当前服务节点的业务处理逻辑执行完毕后，若当前服务节点的生存时间过期，则向父服务节点返回超时信息。
141.在另一个实施例中，子节点设置模块，用于对于执行业务请求时所调用的子服务节点，令子服务节点继承父服务节点的生存时间。
142.在另一个实施例中，子节点设置模块，用于对于执行业务请求时所调用的子服务节点，根据父服务节点的生存时间，子服务节点的开始时间戳和父服务节点的开始时间戳确定当前服务节点的剩余生存时间，根据剩余生存时间确定子服务节点的生存时间。
143.关于业务请求处理装置的具体限定可以参见上文中对于业务请求处理方法的限定，在此不再赘述。上述业务请求处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
144.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储业务请求处理数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务请求处理方法。
145.本领域技术人员可以理解，图9中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
146.在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储
有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
147.在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
148.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。
149.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
150.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。