阅读说明：本技术 业务请求处理方法、装置、计算机设备和存储介质 (Service request processing method and device, computer equipment and storage medium ) 是由 刘旭 朱杰 于 2020-04-30 设计创作，主要内容包括：本申请涉及一种基于云计算的业务请求处理方法、装置、计算机设备和存储介质。该方法包括：当获取到业务请求时,获取业务请求对应的预设超时时间；生成执行业务请求的调用链以及调用链的根服务节点；根据预设超时时间确定业务请求调用链的生存时间；调用链的生存时间不超过预设超时时间；从根服务节点执行业务请求；当调用链的生存时间到过期时,停止执行业务请求,返回超时信息。该方法能够及时停止响应时间过长的业务请求,确保业务请求的实效性。(The application relates to a service request processing method and device based on cloud computing, computer equipment and a storage medium. The method comprises the following steps: when a service request is acquired, acquiring preset timeout time corresponding to the service request; generating a calling chain for executing the service request and a root service node of the calling chain; determining the survival time of a service request calling chain according to the preset overtime; the survival time of the calling chain does not exceed the preset timeout time; executing the service request from the root service node; and when the survival time of the call chain is expired, stopping executing the service request and returning overtime information. The method can stop the service request with overlong response time in time, and ensure the effectiveness of the service request.)

1. A method for service request processing, the method comprising:

when a service request is acquired, acquiring preset timeout time corresponding to the service request;

generating a calling chain for executing the service request and a root service node of the calling chain;

determining the survival time of the service request call chain according to the preset timeout; the survival time of the calling chain does not exceed the preset timeout time;

executing the service request from the root service node;

and when the survival time of the call chain is expired, stopping executing the service request and returning overtime information.

2. The method of claim 1, wherein determining the lifetime of the service request call chain according to the preset timeout time comprises:

setting survival time for the root service node of the call chain according to the preset overtime;

setting survival time for a child service node called when the service request is executed according to the survival time of a parent service node of the child service node; and the survival time of the child service node does not exceed the survival time of the parent service node.

3. The method of claim 2, wherein stopping the service request when the lifetime of the call chain expires and returning timeout information comprises:

and when the life time of the current service node executing the business processing logic is expired, stopping executing the business processing logic and returning overtime information.

4. The method of claim 3, wherein stopping execution of the business processing logic when a lifetime of a current serving node executing the business processing logic expires, and returning timeout information comprises: and aiming at the first type of service nodes with occupied resources larger than a preset standard, establishing a timer to monitor the survival time, and when the current service node executes the service logic, if the timer expires, stopping executing the service logic and returning overtime information.

5. The method of claim 4, wherein for a first class of service nodes whose occupied resources are greater than a preset criterion, establishing a timer to monitor the lifetime, and when a current service node executes the service logic, if the timer expires, stopping executing the service logic, and returning timeout information, including:

aiming at a first class of service nodes with occupied resources larger than a preset standard, a main thread is created, and the main thread generates a timer according to the survival time;

establishing a sub-thread execution service processing logic;

and when the timer of the main thread expires, if the service processing logic of the sub-thread is not finished, the main thread returns timeout information.

6. The method of claim 5, wherein when the timer of the main thread expires, if the business processing logic of the sub-thread completes, then returning a business processing result.

7. The method of claim 3, wherein stopping execution of the business processing logic when a lifetime of a current serving node executing the business processing logic expires, and returning timeout information comprises: and for the second type of service nodes with occupied resources smaller than the preset standard, when the sub service nodes need to be called when the service logic is executed, if the survival time of the current service node is expired, the service processing logic is stopped to be executed, and overtime information is returned.

8. The method according to claim 7, wherein when the service logic needs to invoke a child service node, if the lifetime of the current service node is not expired, the step of setting the lifetime for the child service node invoked when executing the service request according to the lifetime of the parent service node of the child service node is executed.

9. The method of claim 7, wherein after the service processing logic of the current service node is executed, if the lifetime of the current service node is not expired, then returning a service processing result to the parent service node of the current service node.

10. The method of claim 7, wherein after the business processing logic of the current service node is executed, if the lifetime of the current service node expires, then returning timeout information to the parent service node.

11. The method of claim 2, wherein for a child service node invoked when executing the service request, setting a lifetime for the child service node according to a lifetime of a parent service node of the child service node, comprises: and for the child service node called when the service request is executed, enabling the child service node to inherit the survival time of the father service node.

12. The method of claim 11, wherein for a child service node invoked when executing the service request, having the child service node inherit the lifetime of the parent service node comprises: and for the child service node called when the service request is executed, determining the residual survival time of the current service node according to the survival time of the father service node, the starting time stamp of the child service node and the starting time stamp of the father service node, and determining the survival time of the child service node according to the residual survival time.

13. A service request processing apparatus, characterized in that the apparatus comprises:

the service request acquisition module is used for acquiring preset timeout time corresponding to a service request when the service request is acquired;

the calling chain processing module is used for generating a calling chain for executing the service request and a root service node of the calling chain;

a survival time setting module, configured to determine the survival time of the service request call chain according to the preset timeout; the survival time of the calling chain does not exceed the preset timeout time;

an execution module to execute the service request from the root service node;

and the control module is used for stopping executing the service request and returning overtime information when the survival time of the calling chain is expired.

14. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method according to any of claims 1 to 12.

15. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the steps of the method according to any one of claims 1 to 12.

Technical Field

The present application relates to the field of cloud computing technologies, and in particular, to a service request processing method and apparatus, a computer device, and a storage medium.

Background

With the continuous deepening of the cloud computing coverage industry, the complexity of cloud computing background services is higher and higher, and the processing flow is longer and longer. To cope with the expansion of service complexity, and to make service responsibility cohesive, micro-service architecture is becoming mainstream. In the micro-service architecture, a complex service request may involve multiple micro-service calls, and the flow may be long, for example, involving multiple service nodes.

The micro-service architecture can be applied to scenes with high real-time requirements, for example, automatic driving is taken as an example, an automatic driving automobile acquires image data and three-dimensional point cloud data around an automobile body, the image data and the three-dimensional point cloud data are sent to a cloud service in real time, the cloud service identifies and processes the image data and the three-dimensional point cloud data, a driving decision is made, and the driving decision is returned to the automatic driving automobile. The cloud service responds to a service request of an automatic driving automobile, and a plurality of service nodes are called, for example, one service node preprocesses image data, one service node processes three-dimensional point cloud data, one service node identifies the preprocessed image data, and one service node synthesizes a three-dimensional point cloud processing result and an image identification result to make a driving decision.

In practical application, because the driving environment of the automobile changes continuously, if the response time of one service node is too long, the service processing takes a long time, and the requirement of the user on the real-time service response cannot be met.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a service request processing method, device, computer device, and storage medium capable of improving real-time performance.

A method for service request processing, the method comprising:

when a service request is acquired, acquiring preset timeout time corresponding to the service request;

generating a calling chain for executing the service request and a root service node of the calling chain;

determining the survival time of the service request call chain according to the preset timeout; the survival time of the calling chain does not exceed the preset timeout time;

executing the service request from the root service node;

and when the survival time of the call chain is expired, stopping executing the service request and returning overtime information.

A service request processing apparatus, characterized in that the apparatus comprises:

the service request acquisition module is used for acquiring preset timeout time corresponding to a service request when the service request is acquired;

the calling chain processing module is used for generating a calling chain for executing the service request and a root service node of the calling chain;

a survival time setting module, configured to determine the survival time of the service request call chain according to the preset timeout; the survival time of the calling chain does not exceed the preset timeout time;

an execution module to execute the service request from the root service node;

and the control module is used for stopping executing the service request and returning overtime information when the survival time of the calling chain is expired.

A computer device comprising a memory storing a computer program and a processor implementing the steps of the method of any of the above embodiments when the computer program is executed.

A computer-readable storage medium, storing a computer program which, when executed by a processor, performs the steps of the method of any of the above embodiments.

The service processing method, the device, the computer equipment and the storage medium realize the tracing of the calling chain of the micro-service architecture based on the calling chain technology, on the basis, the survival time is set for the calling chain for executing the service request, when the survival time of the calling chain is expired, the service request is stopped to be executed, and the overtime information is returned. Therefore, the service request with overlong response time can be stopped in time, and the effectiveness of the service request is ensured.

Drawings

FIG. 1 is a diagram of an application environment for service request processing in one embodiment;

FIG. 2 is a flow diagram illustrating the processing of a service request in one embodiment;

FIG. 3 is a schematic diagram illustrating a call relationship between service nodes of a cloud service in one embodiment

FIG. 4 is a schematic diagram illustrating the stopping of call chain execution when a time-to-live expires in one embodiment;

FIG. 5 is an illustration of generating a time-to-live for a service node in one embodiment; a flow diagram of the method;

FIG. 6 is a flow diagram that illustrates a time-to-live expiration processing strategy in one embodiment;

FIG. 7 is a flow diagram illustrating a time-to-live expiration processing strategy in accordance with another embodiment;

FIG. 8 is a block diagram of a service request processing apparatus in one embodiment;

FIG. 9 is a diagram illustrating an internal structure of a computer device according to an embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

Cloud technology refers to a hosting technology for unifying serial resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data. One application of cloud technology is cloud computing.

Cloud computing (cloud computing) refers to a delivery and use mode of an IT infrastructure, and refers to obtaining required resources in an on-demand and easily-extensible manner through a network; the generalized cloud computing refers to a delivery and use mode of a service, and refers to obtaining a required service in an on-demand and easily-extensible manner through a network. Such services may be IT and software, internet related, or other services. Cloud Computing is a product of development and fusion of traditional computers and Network Technologies, such as Grid Computing (Grid Computing), distributed Computing (distributed Computing), Parallel Computing (Parallel Computing), Utility Computing (Utility Computing), Network Storage (Network Storage Technologies), Virtualization (Virtualization), Load balancing (Load Balance), and the like.

With the development of diversification of internet, real-time data stream and connecting equipment and the promotion of demands of search service, social network, mobile commerce, open collaboration and the like, cloud computing is rapidly developed. Different from the prior parallel distributed computing, the generation of cloud computing can promote the revolutionary change of the whole internet mode and the enterprise management mode in concept.

The service request processing method provided by the application can be applied to the application environment shown in fig. 1. The service terminal 102 and the server 104 may be connected directly or indirectly through wired or wireless communication via a network. The server adopts a micro-service architecture, relates to four service nodes, and realizes service processing by dispersing functions to four service centers. It is understood that four service nodes are just one example, and the micro-service architecture may be provided with more or fewer service nodes according to the application scenario of cloud computing.

When the server acquires a service request, acquiring preset timeout time corresponding to the service request; generating a calling chain for executing the service request and a root service node of the calling chain; determining the survival time of a service request calling chain according to the preset overtime; the survival time of the calling chain does not exceed the preset timeout time; executing the service request from the root service node; and when the survival time of the call chain is expired, stopping executing the service request and returning overtime information.

The service terminal 102 is a sending terminal of a service request, and the entity type of the service terminal is related to an application scenario of cloud computing, including but not limited to various smart phones, tablet computers, notebook computers, desktop computers, smart speakers, smart watches, and the like, network cameras, automobiles, and the like. The server 104 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, middleware service, a domain name service, a security service, a CDN, a big data and artificial intelligence platform, and the like.

In an embodiment, as shown in fig. 2, a service request processing method is provided, which is described by taking the application of the method to the server in fig. 1 as an example, and includes the following steps:

step 202, when the service request is acquired, acquiring a preset timeout time corresponding to the service request.

The service request is a processing request of service data of the service terminal, which is sent to the cloud server by the service terminal. The business request is related to a computing processing service provided by the cloud server. The method and the system are suitable for processing the service request of the application scene with high real-time performance, for example, the cloud computing provides remote medical service, the service request is a medical data processing request, and the cloud server is requested to identify and process the medical data acquired by the remote medical terminal. For another example, cloud computing provides an automatic driving decision service, a service request is driving image data acquired by an automatic driving automobile, and a cloud server is requested to identify the driving image data to make a driving decision. For another example, the cloud computing provides an image classification service, the service request is video frame image data acquired by the image acquisition terminal, and the cloud server is requested to identify the video frame image data and identify pedestrians therein.

The service terminal sends a service request to the cloud server based on the data to be processed, when the API receives the service request of the service terminal, the service request is sent to the cloud server, and the cloud server determines the service request timeout time according to the called API. In an actual application scene, the cloud server provides different API interfaces to process different service requests, and developers preset timeout time of the service requests corresponding to the different API interfaces according to the actual service timeliness requirement. The application scene with higher real-time performance is shorter in preset timeout time, and the application scene with low real-time performance can be set with longer preset timeout time.

Step 204, generating a call chain for executing the service request and a root service node of the call chain.

With the application of the micro-service design concept in the system, the call chain of the service is more and more complex. A request may involve the coordinated operation of tens of services, involving the business systems of multiple teams. When problems are encountered and positioning is required, a series of troubles are also caused. And the calling connection is used for completely and serially connecting the primary request calling process, so that the request calling path is monitored, and the fault is conveniently and quickly positioned.

When a service request is received, a global calling chain identifier (Trace ID) is generated, the whole calling chain can be connected in series through the Trace ID, and one Trace ID represents one request.

The cloud server adopts a service framework, the service framework is composed of a series of services, the services are processes which can run independently, different services can use different development languages, the services can be distributed and deployed on thousands of servers and even can span multiple different data centers, a light-weight communication mechanism is used among the services, and complex calling relations exist among the services.

For example, as shown in fig. 3, a service request of a service terminal first reaches a service node a, the service node a calls a service node B and a service node C, respectively, where the service node B completes processing and responds to the service node a, the service node C also needs to call a service node D and a service node E, receives responses of the service node D and the service node E, then responds to the service node a, and finally, the service node a responds to the service request of a user. Then, the service node a, the service node B, the service node C, the service node D and the service node E respectively invoke the service node in the chain when requesting for the service. The call relation diagram of each service node as shown in fig. 3 is the call chain of the service request.

The root service node refers to an entry of a service request service, that is, an entry service machine responding to the service request. The root service node provided by the cloud service and responding to the service request is preset, and the service request received by the cloud service firstly reaches the root service node corresponding to the service request.

The two service nodes with the calling relationship are a parent service node and a child service node, wherein the called service node is the child service node. Taking the behavior of the video frame image of the monitoring terminal as an example for identification, firstly, the service request reaches a service node A (root service node), the root service node verifies the monitoring equipment, and after the verification is passed, the video frame image is preprocessed. After preprocessing, the A service node calls the B service node, image recognition is carried out by utilizing a neural network model of the B service node, and pedestrians in the image are recognized. The A service node is a root service node of the service request call chain. For a B serving node, the a serving node is the parent serving node of the B serving node. For an A serving node, a B serving node is a child of the A serving node.

Step 206, determining the lifetime of the service request call chain according to the preset timeout; the lifetime of the call chain does not exceed a preset timeout.

Time To Live (TTL) refers to the longest response Time to execute the service processing logic in response to a service request. The lifetime of the call chain refers to the effective lifetime of the call chain, and when the lifetime expires, the root call chain is ended, so as to avoid executing the call chain of the service request beyond the lifetime. The lifetime of the call chain is referred to the preset timeout time, does not exceed the preset timeout time, and is generally equal to the preset timeout time. For example, if the preset timeout time for a service request is 30 ms, the lifetime of the call chain is set to 30 ms based on this.

Step 280, the service request is executed from the root service node.

When the service request is executed, the service nodes (SPAN) are called in sequence according to the micro-service architecture related to the service request, and the calling chain is a directed acyclic graph formed by a plurality of service nodes. Each service node executes the corresponding service processing logic and returns a processing result to its parent service node (the service node initiating the call).

When a service node needs to call a child service node during executing a service processing logic, a node identifier (Span ID) of the child service node is generated, a node identifier (Span ID) and a call chain identifier (Trace ID) of a parent service node of the child service node are recorded, the whole call chain can be connected in series according to the call chain identifier (TraceID), and the whole call chain can be connected in series in sequence according to the recorded child service nodes of the parent service nodes.

The business processing logic refers to a processing procedure of computer program codes for achieving a certain purpose, for example, in order to perform image recognition, the processing procedure of the computer program codes for realizing the image recognition is a business processing logic. Each service node has service processing logic corresponding to the completed service request. The business processing logic is associated with a specific business scenario. For example, in a cloud service scenario of image recognition, the business processing logic of one service node is image preprocessing, and the business processing logic of another service node is image recognition by using a neural network model. The technical scheme of the application does not relate to specific service scenes, and the service processing logic of each service node is not explained.

And step 210, when the survival time of the call chain is expired, stopping executing the service request and returning timeout information.

As shown in fig. 4, when the lifetime of the call chain expires, the service request is stopped from being executed, and the timeout information is returned, so that the service request with too long response time is stopped within the set time, and the effectiveness of the service request is ensured. And by canceling the subsequent operation of the calling chain after timeout, the system resource is saved.

In this embodiment, different preset timeout times are preset according to the requirements of different service types on response instantaneity and the request frequency of the service terminal, and then the lifetime of the call chain is set according to the timeout times, and when the lifetime of the call chain is expired, the service processing logic for executing the service request is stopped, and the timeout information is returned.

Taking the cloud server applied to an image recognition application scene as an example, for a video frame image acquired by a camera, a pedestrian of the video frame is recognized. The acquisition frequency of the camera is 60 frames/second, and the video frame data acquired by the camera is sent to the cloud service in real time for identification processing. If the identification response of the cloud service to the current video frame image exceeds the timeout time, and the cloud service has received the service request of the next video frame image at the moment, the effectiveness of the latest video frame image is superior to that of the video frame image which is not finished due to the timeout, the identification of the video frame image can be stopped in the application scene.

Taking the application of the cloud server to an automatic driving decision application scene as an example, the image data acquired by each camera of the vehicle body and the laser radar three-dimensional point cloud acquired by the automatic driving vehicle are identified, and an automatic driving decision is made, such as the adjustment of the driving direction and the like. If the overtime time is set to be 1/60 seconds, if the recognition response of the cloud service to the current video frame image and the three-dimensional laser point cloud exceeds the overtime time, and the cloud service has received the next service request (if the automobile runs for a period and the environment around the automobile changes), the cloud service is too frequent, and has no time effect and no use value even if the running decision is calculated. In such an application scenario, the identification of the video frame image and the three-dimensional laser point cloud may be stopped.

It can be understood that, in a service scenario with high real-time performance, a service request of a service terminal is sent to a cloud server continuously, processing of one service request is stopped, and no influence is caused on a service. For example, since the preset timeout time is set according to the request frequency and the acquisition frequency of the camera, when the preset timeout time is exceeded, the processing of the video frame image is stopped, but the latest frame of video frame image is received at this time, the latest service request can be immediately processed, and since the data of the service request is latest, the service terminal has higher timeliness.

The service request processing method realizes the tracing of the call chain of the micro-service architecture based on the call chain technology, sets the survival time for the call chain executing the service request on the basis, stops executing the service request when the survival time of the call chain is expired, and returns the overtime information. Therefore, the service request with overlong response time can be stopped in time, and the effectiveness of the service request is ensured.

In another embodiment, determining the lifetime of the service request call chain according to the preset timeout comprises: setting survival time for a root service node of a call chain according to preset timeout; setting survival time for a child service node called when the service request is executed according to the survival time of a parent service node of the child service node; the lifetime of the child service node does not exceed the lifetime of the parent service node.

The generation time of the call chain represents the whole survival time of each service node on the chain, and the call chain reflects the call time sequence of each service node, so that the survival time of the call chain reflects the global survival time of each service node on the call chain, and the survival time of the call chain can be distributed to each service node to obtain the survival time of each service node. It is understood that the overall global lifetime of each service node should not be greater than the preset timeout.

In order to ensure timeliness of service nodes, for a parent service node and a child service node with a calling relationship, generally, service execution of the parent service node needs to depend on the child service node, and the parent service node and the child service node have dependency on service execution. Based on this dependency, the lifetime of the child service node is assigned to be dependent on the lifetime of the parent service node. And all the sub service nodes can be regarded as the root service node to be called, so that the survival time of all the sub service nodes depends on the survival time of the root service node.

Specifically, the survival time is set for the root service node according to the preset timeout time, and the survival time is set for the child service node according to the survival time of the parent service node. The survival time of the root service node does not exceed the preset overtime time, and the survival time of the child service node does not exceed the survival time of the father service node.

Specifically, after receiving the service request, the cloud server generates a root service node of the service request, and sets a lifetime for the root service node. Wherein, the survival time of the root service node is the preset overtime time of the service request. For example, if the preset timeout time of the service request is 30 ms, the lifetime of the root service node is 30 ms.

It will be appreciated that for a service node of a call chain, its lifetime is set when a call to it is generated, i.e. when the service node needs to be called, the lifetime of a child service node is set according to the lifetime of the parent service node.

The service request is executed from the root service node. When a root service node executing business processing logic needs a child service node, generating the child service node which the root service node needs to call. As shown in fig. 3, a child serving node B is generated for the root serving node a. Wherein, the root service node A is a father service node of the child service node B. Thus, the lifetime of a child service node is dependent on the lifetime of a parent service node.

The child service node is a service node called by the service node according to the service logic when the service node executes the service logic. As shown in fig. 3, the B service node and the C service node are child service nodes of the a service node, and the D service node and the E service node are child service nodes of the C service node.

The parent service node is the service node that invokes the child service node. As shown in fig. 3, the a service node is a parent of the B service node and the C service node, and the C service node is a parent of the D service node and the E service node.

And setting the survival time of the child service node according to the survival time of the parent service node, wherein the survival time of the child service node does not exceed the survival time of the parent service node.

Furthermore, in order to ensure that the life time of the parent service node and the life time of the child service node are consumed at the same time and ensure the logical consistency of the parent service node and the child service node, the child service node inherits the life time of the parent service node, namely the life time of the child service node is the remaining life time of the parent service node.

Specifically, for a child service node called when executing a service request, setting a lifetime for the child service node according to the lifetime of a parent service node of the child service node, including: and for the child service node called when the service request is executed, enabling the child service node to inherit the survival time of the parent service node. As shown in fig. 5, the lifetime of the child serving node B is the remaining lifetime of the root serving node a.

Wherein the remaining lifetime is determined according to a generation time, i.e. a start timestamp, of the child service node. For example, for a C service node that is executing a service request, the lifetime of the C service node is 10 milliseconds, and in the process of executing the service logic by the C service node, a sub service node D is generated in the 6 th millisecond, so the lifetime of the sub service node D is 4 seconds of the remaining lifetime of the C service node.

And setting the survival time for the child service node according to the survival time of the parent service node, the starting time stamp of the child service node and the starting time stamp of the parent service node. Specifically, the lifetime of the child service node is the lifetime of the parent service node-the start timestamp of the child service node + the start timestamp of the parent service node. As shown in fig. 5, the lifetime of the B service node is the lifetime of the a service node-the start timestamp of the B service node + the start timestamp of the a service node. For example, the lifetime of the a service node (parent service node) is 20 ms, the start timestamp of the a service node is 8 o 'clock 20 min 1 s 10 ms, the start timestamp of the B service node (child service node) is 8 o' clock 20 min 1 s 15 ms, and the lifetime of the B service node is 20 ms-8 o 'clock 20 min 1 s 15 ms +8 o' clock 20 min 1 s 10 ms-15 ms.

Further, when the sub service node B executing the business processing logic needs the sub service node, the sub service node C which the sub service node needs to call is generated. The child service node B is a parent service node of the child service node C. The lifetime of the child serving node C is the remaining lifetime of the child serving node B.

And the survival time of the C service node is the survival time of the B service node, the starting timestamp of the C service node and the starting timestamp of the B service node. For example, if the lifetime of the serving node B is 15 ms, the start timestamp of the parent serving node B is 8 o 'clock 20 min 1 sec 15 ms, and the start timestamp of the child serving node C is 8 o' clock 20 min 1 sec 20 ms, then the lifetime of the child serving node C is 15 ms-8 o 'clock 20 min 1 sec 20 ms +8 o' clock 20 min 1 sec 15 ms, which is 10 ms.

The method adopts an inheritance method, so that the child service node inherits the survival time of the parent service node, and the survival times of the parent service node and the child service node can be consumed at the same time. Meanwhile, the survival time is set for each service node, each service node only needs to care about the expiration time of the service node, communication with other service nodes is not needed, and server resources are saved.

Since the lifetime of the child service node inherits the lifetime of the parent service node, and the lifetime of the root service node is the global lifetime, it can be considered that the lifetime of the whole call chain expires when the lifetime of a certain child service node expires.

In another embodiment, when the lifetime of the call chain expires, the service request is stopped from being executed, and the timeout information is returned, including: and when the life time of the current service node executing the business processing logic is expired, stopping executing the business processing logic and returning overtime information.

Specifically, the current service node executing the business processing logic may be a root service node or any sub-service node calling the chain on which the business processing logic is being executed, and for the current service node executing the business processing logic, when the lifetime expires, the execution of the business processing logic is stopped, and the timeout information is returned.

When the life time of the child service node executing the service processing logic expires, the execution of the service processing logic is stopped, and the overtime information is returned to the parent service node. And when the survival time of the root service node executing the service processing logic expires, stopping executing the service processing logic and returning timeout information to the service terminal. The service processing logic refers to the service processing procedures that each service node needs to implement to complete the service request.

In practical application, the cloud service executes the service request through each service node, and in order to complete the service request, the service logics executed by each service node are different, and the resources occupied by executing the service logics are also different. Taking cloud service to realize image identification as an example, the service node 1 judges whether a video frame image is a key frame, and the service node 2 identifies the key frame image by using a convolutional neural network. The service node 1 only processes simple business logic, the resource consumption is not large, and the service node 2 needs to identify entities in the image and needs to occupy larger CPU and GPU resources.

When the life time of the current service node expires, the process is directly dried off by the bottom layer which cannot be violently done, and the real-time performance, the resource consumption and the performance loss are balanced aiming at different service nodes which occupy different resources. The developer can adopt different overdue execution strategies according to the resource situation occupied by the service node when executing the service processing logic.

In one embodiment, when the lifetime of the current service node executing the business processing logic expires, stopping executing the business processing logic and returning timeout information, the method includes: and aiming at the first class service nodes with the occupied resources larger than the preset standard, establishing a timer to monitor the survival time, and when the current service node executes the service logic, if the timer expires, stopping executing the service logic and returning overtime information.

Specifically, a developer classifies service nodes with large occupied resources and heavy logic as a first class of service nodes according to the resource loss occupied when the service nodes execute service processing logic. For the first class service node, a 'strong overdue' execution strategy is set, in order to avoid that the execution service logic still occupies larger system resources after the lifetime expires, the current service node exits after the lifetime of the service node expires, and the overtime information is returned to the father service node.

Aiming at a first class service node occupying resources larger than a preset standard, a timer is established to monitor survival time, when the current service node executes service logic, if the timer expires, the execution of the service logic is stopped, and overtime information is returned, wherein the method comprises the following steps: aiming at a first class of service nodes with occupied resources larger than a preset standard, a main thread is created, and the main thread generates a timer according to the survival time; establishing a sub-thread execution service processing logic; when the timer of the main thread expires, if the business processing logic of the sub-thread is not completed, the main thread returns timeout information.

If the developer determines that the current service node is the first class service node according to the resource situation occupied when the current service node executes the service processing logic, a 'strong overdue' execution strategy is set for the service node. The purpose of the 'strong expiration' execution strategy is to forcibly end once the survival time expires for a service node which occupies a large resource by executing the business processing logic, and return timeout information. As shown in fig. 6, when each parent service node generates a child service node, SPAN context information is written with a call chain id (trace id), a service node id (SPAN id), and a lifetime of the service node. The sub service node establishes a main thread 601 to access SPAN context information, analyzes the information to obtain the survival time of the current service node, generates the current service node of the call chain, starts a timer with expiration time as the survival time, and waits for the expiration of the timer. Meanwhile, the sub-service node creates a sub-thread 602, and the sub-thread executes service processing logic, such as preprocessing of image recognition, and image recognition based on a convolutional neural network. After the service processing logic is executed, the sub-thread 602 sends a message to the main thread 601 and returns an execution result, after the timer expires, the main thread judges whether the execution of the service processing logic of the sub-thread is completed according to whether the execution result returned by the sub-thread is received, if the execution result is not completed, timeout information is returned to the parent service node of the main thread, the service processing logic of the current service node is stopped forcibly, and a large amount of resources are prevented from being occupied by the continuous execution of the service processing logic.

Further, when the timer of the main thread expires, if the service processing logic of the sub-thread is completed, the service processing result is returned.

In this embodiment, a "strong expiration" processing policy is preset for a current service node that occupies a large resource by executing the service processing logic, and once the lifetime of the current service node expires, execution of the service processing logic is stopped immediately by establishing timer monitoring, and timeout information is returned, so that on one hand, the effectiveness of service processing is ensured, unlimited execution of the service processing flow is avoided, on the other hand, occupation of a large amount of resources by continuously executing the service processing logic is avoided, and resources are released in time.

In another embodiment, when the lifetime of the current service node executing the business processing logic expires, stopping executing the business processing logic and returning timeout information comprises: and for the second type of service nodes with occupied resources smaller than the preset standard, when the execution of the service logic needs to call the sub-service nodes, if the survival time of the current service node is expired, the execution of the service processing logic is stopped, and the overtime information is returned.

And (3) according to the resource situation occupied when the current service node executes the service processing logic, if the occupied resource is less, when the current service node is determined to be the second type service node, the developer sets a lazy overdue execution strategy for the service node. The 'lazy expiration' execution strategy aims at a service node with less resource occupation of the execution service processing logic, the service processing flow is stopped without forcing the expiration of the survival time, and whether the time of the survival time is expired or not is judged after a certain condition is reached so as to avoid establishing a timer and the larger resource occupation of double threads. Because the service node occupies less resources when executing the service processing logic, even if the survival time is slightly overdue, the service node does not occupy too much system resources, and stops executing the service flow after judging the overdue, thereby ensuring the effectiveness, the effectiveness and the balance of resources.

Specifically, the developer classifies service nodes with smaller occupied resources and lighter logic as the second class of service nodes according to the resource loss occupied when the service nodes execute the service processing logic. In the second type of service node, the service node only processes simple service logic and consumes little resources. And for the second class of service nodes, a lazy expiration execution strategy is set, and the life time does not need to be monitored in real time. And only when the current service node calls the sub-service node according to the service processing logic, judging whether the survival time of the current service node is expired. And if the survival time of the current service node is expired, returning overtime information to the father service node. Because the second type of service node occupies less resources when executing the service processing logic, the second type of service node judges whether the survival time is exhausted when needing to call the sub-service node, and does not occupy excessive resources. Compared with the method that a timer is used for establishing a strong overdue processing strategy of double threads, the method can avoid establishing the kernel resources occupied by the timer and the sub-threads, and balance is found for effectiveness and resources.

When the execution business logic needs to call the child service node, if the survival time of the current service node is not expired, executing the step of setting the survival time for the child service node according to the survival time of the parent service node of the child service node for the child service node called when the business request is executed. Namely, generating the sub-service nodes and allocating the survival time for the sub-service nodes.

Meanwhile, after the service processing logic of the current service node is executed, if the survival time of the current service node is not expired, the service processing result is returned to the father service node of the current service node. And if the survival time of the current service node is expired, returning overtime information to the father service node.

Specifically, as shown in fig. 7, the "lazy expiration" processing policy includes the following steps:

s702: and analyzing the survival time to generate the current service node.

When each father service node generates a child service node, SPAN context information is written by a calling chain ID (trace id), a service node ID (SPAN id) and the survival time of the service node. And the main thread of the child service node accesses the SPAN context information, analyzes the life time of the current service node, the node ID of the father service node and the calling chain ID to generate the current service node of the calling chain. The call chain for the service request may be tracked based on the node ID of the child service node, the node ID of the parent service node, and the call chain ID.

S704, executing the service processing logic of the current service node.

S706, when the business processing flow is executed, whether the sub service node needs to be generated or not is monitored. If yes, go to step S708. If not, go to step S710.

S708, judging whether the survival time of the current service node is expired. If yes, returning overtime information and returning overtime information. And if not, generating the sub service node.

And the current service node executes a service processing flow, judges whether the survival time of the current service node is due when the sub-service node is called according to the service logic requirement, and returns overtime information if the survival time of the current service node is due.

And if the survival time of the current service node is not expired, generating a child SPAN, and specifically, executing a step of setting the survival time for a child service node according to the survival time of a parent service node of the child service node for the child service node called when the service request is executed. That is, the lifetime of the child service node is generated for the child service node according to the remaining lifetime of the parent service node.

Specifically, whether the survival time of the current service node is expired is judged according to the remaining survival time of the current service node. The method for calculating the residual survival time comprises the following steps: the remaining lifetime is the lifetime of the current serving node-the current timestamp + the start timestamp of the current serving node. And when the residual life time is more than 0, indicating that the life time of the current service node is not expired. And when the residual survival time is less than 0, indicating that the survival time of the current service node is expired.

And judging whether the survival time is expired or not, namely, when the business processing logic needs to call the child service node, if the survival time is expired, returning overtime information to the father service node according to a judgment result, and if the survival time is not expired, generating the child service node. And when the sub-service node needs to be called, judging whether the remaining survival time exists or not, and taking charge of the sub-service node to judge whether the remaining survival time is enough to generate the sub-service node or not.

S710, the business processing flow is continuously executed until the business processing logic is finished.

And if the residual survival time of the current service node is not expired, continuing to execute the service processing flow until the service processing logic is finished.

After step S710, S712 is performed.

S712, determine whether the lifetime of the current service node is expired. If yes, returning overtime information. If not, returning the service processing result.

After the service processing logic is finished, whether the survival time of the current service node is expired is further judged, whether the survival time is expired is judged, after the service processing logic of the current service node is finished, according to a judgment result, the current service node can feed back to a father service node and is responsible for the father service node, and whether the service processing logic is processed in the survival time is judged. If the survival time is overdue, returning overtime information, and if the survival time is not overdue, returning a service processing result.

The 'lazy expiration' policy of this embodiment does not need to monitor the lifetime in real time, and only when the sub-service node needs to be called and the service processing logic of the current service node is completed, the judgment on whether the lifetime is expired is triggered.

The application also provides an application scene, and the application scene applies the service processing method. Specifically, the service processing method is applied to the application scenario as follows:

the application scene is automatic driving, cameras, a positioning system and a laser radar are arranged on the periphery of an automatic driving automobile, and a cloud server provides automatic driving decision calculation. The automatic driving automobile acquires video frame images and three-dimensional laser point cloud data at the speed of 60 frames/second and sends the video frame images and the three-dimensional laser point cloud data to the cloud server.

When the cloud server acquires the service request, acquiring preset timeout time corresponding to the service request. Wherein the preset timeout time is set to 23 msec. This is because the acquisition frequency of the autonomous driving vehicle is 60 seconds/frame, and if the response time to one frame of video image is too long, the driving decision is not effective.

The cloud server generates a call chain for executing the business request and a root service node of the call chain.

As shown in fig. 3, when the service request reaches the service node a, the service node a responds to the service request to make a vehicle driving decision. And the service node A calls the service result B to process the positioning data, and the service node A calls the service node C to determine a front obstacle according to the three-dimensional point cloud data and the image data. And C, calling the D service node by the service node C to process the three-dimensional point cloud data, identifying lane lines and obstacles, calling the E service node to process the image data, and identifying the obstacles such as pedestrians and automobiles on the basis of the image. And processing results of the service node D and the service node E are returned to the service node C, the service node C determines the movable direction according to the image identification and the three-dimensional point cloud detection barrier, the processing results of the service node C and the service node B are returned to the service node A, and the service node A determines the final moving direction according to the determined movable direction and the current location.

And the cloud server determines the survival time of the service request call chain according to the preset timeout time. Specifically, the preset timeout time is set as the lifetime of the root service node, and when the service node executing the service processing logic calls the child service node, the lifetime is set for the child service node according to the remaining lifetime of the parent service node, so that the lifetime of the parent service node and the child service node can be consumed at the same time. For example, the lifetime of root service node a is 23 milliseconds. When the root service node executes the service processing logic and needs to call the sub service node B, if the remaining time of the root service node is 15 seconds, the survival time of the sub service node is set to be 15 seconds.

And executing the service request from the root service node, stopping executing the service request when the survival time of the calling chain is expired, and returning overtime information. Specifically, when the lifetime of the current service node executing the service processing logic is expired, the service processing logic is stopped from being executed, timeout information is returned, and the cloud server processes the next service request with higher timeliness. And if the survival time of the current service node executing the service processing logic is not expired, the service processing logic is continuously executed, and a service processing result is returned to the father service node. And when the service node A receives the service processing result of the sub-service node in the survival time, the service node A returns a driving decision to the automatic driving automobile.

The method can stop the service request with overlong response time in time, and ensure the effectiveness of the service request.

The overdue execution strategy is determined by a developer according to resources occupied when the service node executes the service processing logic, for the service node with larger occupied resources, a strong overdue processing strategy is used, a timer and a sub-thread are utilized, and once the survival time of the timer expires, the service processing logic is immediately stopped to be executed.

And for the service node occupying less resources, using a 'lazy expiration' processing strategy, detecting whether the survival time is expired or not when the sub-thread needs to be called and the service processing logic of the current service node is executed, and stopping executing the service processing logic after expiration.

It can be understood that, in a micro-service architecture, two expiration processing strategies are applied to different service nodes at the same time, so as to balance effectiveness and resources.

It should be understood that although the various steps in the flowcharts of fig. 2, 5-6 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2, 5-6 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least some of the other steps or stages.

In one embodiment, as shown in fig. 8, there is provided a service request processing apparatus, which may be a part of a computer device using a software module or a hardware module, or a combination of the two modules, and the apparatus specifically includes:

a service request obtaining module 801, configured to obtain a preset timeout time corresponding to a service request when the service request is obtained;

a call chain processing module 802, configured to generate a call chain for executing the service request and a root service node of the call chain;

a lifetime setting module 803, configured to determine the lifetime of the service request call chain according to the preset timeout; the survival time of the calling chain does not exceed the preset timeout time;

an execution module 804, configured to execute the service request from the root service node;

and the control module 805 is configured to stop executing the service request and return timeout information when the lifetime of the call chain expires.

The service request processing device realizes the tracing of the call chain of the micro-service architecture based on the call chain technology, sets the survival time for the call chain executing the service request on the basis, stops executing the service request when the survival time of the call chain is expired, and returns the overtime information. Therefore, the service request with overlong response time can be stopped in time, and the effectiveness of the service request is ensured.

In another embodiment, the time-to-live setting module includes:

and the root node setting module is used for setting survival time for the root service node of the call chain according to the preset timeout.

The child node setting module is used for setting survival time for the child service node called when the service request is executed according to the survival time of the parent service node of the child service node; the lifetime of the child service node does not exceed the lifetime of the parent service node.

In another embodiment, the control module is configured to stop executing the business processing logic and return timeout information when a lifetime of a current service node that is executing the business processing logic expires.

In another embodiment, the control module is configured to establish a timer for monitoring a lifetime for a first class of service node whose occupied resource is greater than a preset standard, and when a current service node executes a service logic, if the timer expires, the execution of the service logic is stopped, and timeout information is returned.

In another embodiment, the control module is configured to create a main thread for a first class of service nodes whose occupied resources are greater than a preset standard, where the main thread generates a timer according to a lifetime; establishing a sub-thread execution service processing logic; when the timer of the main thread expires, if the business processing logic of the sub-thread is not completed, the main thread returns timeout information.

In another embodiment, the control module is configured to, when the timer of the main thread expires, return a service processing result if the service processing logic of the sub-thread is completed.

In another embodiment, the control module is configured to, for a second class of service nodes whose occupied resources are smaller than a preset standard, stop executing the service processing logic and return timeout information if the lifetime of the current service node expires when the execution of the service logic needs to invoke a child service node.

In another embodiment, the control module is configured to execute a step of setting, for a child service node invoked when the service request is executed, a lifetime for the child service node according to the lifetime of a parent service node of the child service node if the lifetime of the current service node expires.

In another embodiment, the control module is configured to, after the execution of the service processing logic of the current service node is completed, return a service processing result to a parent service node of the current service node if the lifetime of the current service node is not expired.

In another embodiment, the control module is configured to, after the service processing logic of the current service node is executed, return timeout information to the parent service node if the lifetime of the current service node expires.

In another embodiment, the child node setting module is configured to, for a child service node invoked when the service request is executed, enable the child service node to inherit the lifetime of the parent service node.

In another embodiment, the child node setting module is configured to determine, for a child service node invoked when the service request is executed, a remaining lifetime of a current service node according to the lifetime of the parent service node, the start timestamp of the child service node, and the start timestamp of the parent service node, and determine the lifetime of the child service node according to the remaining lifetime.

For specific limitations of the service request processing device, reference may be made to the above limitations on the service request processing method, which is not described herein again. The modules in the service request processing device may be implemented wholly or partially by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as shown in fig. 9. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The database of the computer device is used for storing service request processing data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a service request processing method.

Those skilled in the art will appreciate that the architecture shown in fig. 9 is merely a block diagram of some of the structures associated with the disclosed aspects and is not intended to limit the computing devices to which the disclosed aspects apply, as particular computing devices may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is further provided, which includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above method embodiments when executing the computer program.

In an embodiment, a computer-readable storage medium is provided, in which a computer program is stored which, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.