Business request processing method and apparatus, computer device, and storage medium

Abstract

The application relates to a cloud-computing-based business request processing method and device, computer equipment and a storage medium. The method comprises the following steps: when a business request is acquired, a preset timeout time corresponding to the business request is acquired; a calling chain for executing the business request and a root service node of the calling chain are generated; the survival time of the business request calling chain is determined according to the preset timeout time; the survival time of the calling chain does not exceed the preset timeout time; the business request is executed from the root service node; when the survival time of the calling chain expires, the execution of the business request is stopped, and timeout information is returned. The method can timely stop a business request with a long response time, and ensures the effectiveness of the business request.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and in particular to a business request processing method and device, computer equipment and a storage medium. BACKGROUND

[0002] With the deepening of cloud computing covering industries, the complexity of cloud computing background business is higher and higher, and the processing flow is longer and longer. In order to cope with the expansion of service complexity and make the service responsibility cohesive, micro-service architecture gradually becomes mainstream. Under the micro-service architecture, complex business requests may involve multiple micro-service calls, and the flow may be very long, such as involving multiple service nodes.

[0003] The micro-service architecture can be applied to some scenarios with high real-time requirements. For example, an automatic driving car collects image data and three-dimensional point cloud data around the car body, and sends them to a cloud service in real time. The cloud service identifies and processes the image data and three-dimensional point cloud data, makes a driving decision, and returns it to the automatic driving car. The cloud service responds to the business request of the automatic driving car, and multiple service nodes are called, for example, one service node preprocesses the image data, one service node processes the three-dimensional point cloud data, one service node identifies the preprocessed image data, and one service node makes a driving decision based on the three-dimensional point cloud processing result and the image recognition result.

[0004] In actual application, due to the continuous change of the driving environment of the car, if the response time of one of the service nodes is too long, the business processing will occupy a long time, which will not meet the user's requirements for service response real-time. SUMMARY

[0005] Therefore, it is necessary to provide a business request processing method, device, computer equipment and storage medium capable of improving real-time performance to solve the above technical problems.

[0006] A business request processing method, the method comprising:

[0007] When a business request is obtained, a preset timeout time corresponding to the business request is obtained;

[0008] generating a call chain for executing the business request and a root service node of the call chain;

[0009] determining a survival time of the business request call chain according to the preset timeout time; the survival time of the call chain does not exceed the preset timeout time;

[0010] executing the business request from the root service node;

[0011] When the survival time of the call chain expires, stop executing the business request and return timeout information.

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

[0013] A service request obtaining module, configured to obtain a preset timeout time corresponding to a service request when the service request is obtained;

[0014] A call chain processing module, configured to generate a call chain for executing the service request and a root service node of the call chain;

[0015] A time-to-live setting module, configured to determine a time-to-live of the service request call chain according to the preset timeout time; the time-to-live of the call chain does not exceed the preset timeout time;

[0016] An execution module, configured to execute the service request from the root service node;

[0017] A control module, configured to stop executing the service request and return timeout information when the time-to-live of the call chain expires.

[0018] A computer device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the steps of the method of any one of the above embodiments when executing the computer program.

[0019] A computer readable storage medium, storing a computer program, the computer program is executed by a processor to implement the steps of the method of any one of the above embodiments.

[0020] The above service processing method, apparatus, computer device and storage medium, based on the call chain technology, realize the monitoring of the call chain of the micro-service architecture, and on this basis, set a time-to-live for the call chain for executing the service request, stop executing the service request and return timeout information when the time-to-live of the call chain expires. Thus, the service request with a long response time can be stopped in time, and the effectiveness of the service request is ensured. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 An application environment diagram for service request processing in one embodiment;

[0022] Figure 2 A flowchart for service request processing in one embodiment;

[0023] Figure 3 A call relationship diagram of service nodes of a cloud service in one embodiment

[0024] Figure 4 An explanatory diagram for stopping the execution of a call chain when the time-to-live expires in one embodiment;

[0025] Figure 5 a diagram illustrating a method for generating a lifetime of a service node in one embodiment;

[0026] Figure 6 a diagram illustrating a lifetime expiration processing strategy in one embodiment;

[0027] Figure 7 a diagram illustrating a lifetime expiration processing strategy in another embodiment;

[0028] Figure 8 a block diagram illustrating a service request processing apparatus in one embodiment;

[0029] Figure 9 a diagram illustrating an internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0030] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application.

[0031] Cloud technology refers to a kind of hosting technology that unifies a series of resources such as hardware, software and network to realize data calculation, storage, processing and sharing in a wide area network or a local area network. One application of cloud technology is cloud computing.

[0032] Cloud computing refers to a delivery and use mode of IT infrastructure, which means that resources required are obtained in a manner of on-demand and easy expansion through a network. Broad-sense cloud computing refers to a delivery and use mode of service, which means that services required are obtained in a manner of on-demand and easy expansion through a network. The service can be IT and software, Internet related, or other services. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, load balancing, etc.

[0033] With the development of the Internet, real-time data flow, and the diversification of connected devices, and the demand for search services, social networks, mobile commerce, and open collaboration, cloud computing has rapidly developed. Unlike previous parallel distributed computing, the emergence of cloud computing will revolutionize the entire Internet model and enterprise management model.

[0034] The business request processing method provided by the application can be applied to the application environment as shown in Figure 1 The business terminal 102 can be directly or indirectly connected to the server 104 through wired or wireless communication through the network. The server adopts a micro-service architecture, involving four service nodes, which disperses functions to four service centers to achieve business processing. It can be understood that the four service nodes are only an example, and according to the application scenario of cloud computing, the micro-service architecture can set more or fewer service nodes.

[0035] Among them, when the server obtains a business request, the preset timeout time corresponding to the business request is obtained; the call chain for executing the business request and the root service node of the call chain are generated; the survival time of the business request call chain is determined according to the preset timeout time; the survival time of the call chain does not exceed the preset timeout time; the business request is executed from the root service node; when the survival time of the call chain expires, the execution of the business request is stopped, and the timeout information is returned.

[0036] The business terminal 102 is the sending terminal of the business request, and its entity type is related to the application scenario of cloud computing, including but not limited to various smart phones, tablet computers, notebook computers, desktop computers, smart speakers, smart watches, network cameras, cars, etc. The server 104 can be a standalone physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and big data and artificial intelligence platforms. Basic cloud computing services such as platform.

[0037] In one embodiment, as shown in Figure 2 A business request processing method is provided, which is applied to the server in Figure 1 for example, including the following steps:

[0038] Step 202, when obtaining a business request, obtaining the preset timeout time corresponding to the business request.

[0039] The business request is a processing request for business data sent by the business terminal to the cloud server. The business request is related to the computing processing service provided by the cloud server. The application is suitable for processing of business requests in an application scenario with high real-time performance. For example, the cloud computing provides remote medical service, the business request is a medical data processing request, and the cloud server is requested to identify and process the medical data collected by the remote medical terminal. For another example, the cloud computing provides automatic driving decision service, the business request is driving image data collected by an automatic driving vehicle, and the cloud server is requested to identify the driving image data and make driving decisions. For another example, the cloud computing provides image recognition service, and the business request is video frame image data collected by an image collection terminal, and the cloud server is requested to identify the video frame image data and identify pedestrians therein.

[0040] The business terminal sends a business request to the cloud server based on to-be-processed data. When the API interface receives the business request of the business terminal, the business request is sent to the cloud server, and the cloud server determines the business request timeout time according to the called API interface. In actual application scenarios, the cloud server provides different API interfaces to process different business requests, and a developer sets preset timeout times of the business requests corresponding to different API interfaces according to actual business timeliness requirements. In the application scenarios with higher real-time performance, the preset timeout time is shorter, and in the application scenarios with lower real-time performance, a longer preset timeout time can be set.

[0041] Step 204, generating a calling chain for executing the business request and a root service node of the calling chain.

[0042] With the application of the micro-service design concept in the system, the calling chain of the business is becoming more and more complex. One request may involve the cooperative operation of dozens of services and the business systems of multiple teams. When a problem needs to be located, a series of troubles will also be caused. However, through the calling chain, the request calling process is completely connected, the monitoring of the request calling path is realized, and the fault can be quickly located.

[0043] When the business request is received, a global calling chain identifier (TraceID) is generated. The entire calling chain can be connected through the TraceID, and one TraceID represents one request.

[0044] The cloud server adopts a service framework composed of a series of services, and the services are independent processes. Different services can use different development languages, can be distributed and deployed on thousands of servers, and can even span multiple different data centers. A lightweight communication mechanism is used between services, and there is a complex calling relationship between services.

[0045] For example, as shown in FIG. 1, the cloud server is composed of a series of services, and the services are independent processes. Different services can use different development languages, can be distributed and deployed on thousands of servers, and can even span multiple different data centers. A lightweight communication mechanism is used between services, and there is a complex calling relationship between services. Figure 3As shown, the service request of the service terminal first reaches the A service node, the A service node respectively calls the B service node and the C service node, the B service node makes a response to the A service node after processing is completed, the C service node needs to call the D service node and the E service node, after receiving the responses of the D service node and the E service node, the C service node makes a response to the A service node, and finally the A service node responds to the service request of the user. Then, the A service node, the B service node, the C service node, the D service node and the E service node are respectively service nodes on the calling chain of the service request. As shown in the figure, Figure 3 The calling relationship diagram of each service node as shown is the calling chain of the service request.

[0046] The root service node refers to the entry of the service request service, that is, the entry service machine responding to the service request. The root service node responding to the service request provided by the cloud service is pre-set, and the service request received by the cloud service first reaches the root service node corresponding to the service request.

[0047] The two service nodes with a calling relationship are parent service nodes and child service nodes, and the called service node is the child service node. Taking the identification of the behavior of the video frame image of the monitoring terminal as an example, the service request first reaches the A service node (root service node), the root service node verifies the monitoring device, and after verification, the video frame image is preprocessed. After preprocessing, the A service node calls the B service node, and uses the neural network model of the B service node to identify pedestrians in the image. The A service node is the root service node of the service request calling chain. For the B service node, the A service node is the parent service node of the B service node. For the A service node, the B service node is the child service node of the A service node.

[0048] In step 206, the time to live of the service request calling chain is determined according to the preset timeout time; the time to live of the calling chain does not exceed the preset timeout time.

[0049] The time to live (TTL) refers to the longest response time of the service processing logic responding to the service request. The time to live of the calling chain refers to the effective time to live of the calling chain, when the time expires, the root calling chain is ended, so as to avoid still executing the calling chain of the service request outside the time to live. The time to live of the calling chain is referred to the preset timeout time, and does not exceed the preset timeout time, and is usually equal to the preset timeout time. For example, the preset timeout time of a service request is 30 milliseconds, and the time to live of the calling chain is set to 30 milliseconds based on this.

[0050] In step 280, the service request is executed from the root service node.

[0051] The service request is sequentially called each service node (SPAN) according to the micro-service architecture related to the service request when the service request is executed, and the call chain is a directed acyclic graph composed of multiple service nodes. Each service node executes the corresponding business processing logic and returns the processing result to the parent service node (service node initiating the call).

[0052] When the service node needs to call the child service node when executing the business processing logic, the node identifier (SpanID) of the child service node is generated, the node identifier (SpanID) of the parent service node of the child service node and the call chain identifier (TraceID) are recorded, the entire call chain can be concatenated according to the call chain identifier (TraceID), and the entire call chain can be sequentially concatenated according to the recorded child service nodes of each parent service node.

[0053] The business processing logic refers to the processing process of computer program code for achieving a certain purpose, such as the processing process of computer program code for image recognition. Each service node has a corresponding business processing logic for completing the business request. The business processing logic is related to the specific business scenario. For example, in the 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 using a neural network model. The technical solution of the present application does not involve specific business scenarios, and the business processing logic of each service node is not expanded.

[0054] Step 210, when the survival time of the call chain expires, stop executing the business request and return the timeout information.

[0055] As shown in Figure 4 When the survival time of the call chain expires, stop executing the business request and return the timeout information, so that the business request with long response time is stopped within a certain time, and the effectiveness of the business request is ensured. By canceling the subsequent operation of the call chain after timeout, system resources are saved.

[0056] In this embodiment, different preset timeout times are set in advance according to the requirements of different business types for response real-time and the request frequency of the business terminal, and then the survival time of the call chain is set according to the timeout time, and when the survival time of the call chain expires, the business processing logic of the business request is stopped, and the timeout information is returned.

[0057] Taking the cloud server applied to the image recognition application scenario as an example, the video frame images collected by the camera are recognized. The camera collection frequency is 60 frames per second, and the video frame data collected by the camera is sent to the cloud service for recognition processing in real time. The timeout time is set in advance according to the camera collection frequency, such as setting the timeout time to 1 / 60 second. Influenced by the video frame image collection frequency, if the cloud service response to the current video frame image recognition exceeds the timeout time, and at this time the cloud service has received the next video frame image service request, and the effectiveness of the latest video frame image is better than that of the video frame image whose recognition is not completed within the timeout time, in this application scenario, the recognition of the video frame image can be stopped.

[0058] Taking the cloud server applied to the automatic driving decision application scenario as an example, the image data collected by each camera of the automatic driving car and the three-dimensional laser point cloud are recognized to make automatic driving decisions, such as adjusting the driving direction. The timeout time is set in advance according to the camera collection step and the laser radar collection frequency, such as setting the timeout time to 1 / 60 second. If the cloud service response to the current video frame image and three-dimensional laser point cloud recognition exceeds the timeout time, and at this time the cloud service has received the next service request (such as the car has traveled a distance, and the environment around the car has changed), even if the driving decision is calculated, it is also time to change, and it does not have timeliness and use value. In this application scenario, the recognition of the video frame image and the three-dimensional laser point cloud can be stopped.

[0059] It can be understood that in a real-time business scenario, the business terminal sends business requests to the cloud server continuously, and stopping processing of a business request will not affect the business. For example, since the preset timeout time is set according to the request frequency and the camera collection frequency, when the preset timeout time is exceeded and the video frame image processing is stopped, the latest video frame image has been received, and the latest business request can be processed immediately. Since the data of the business request is the latest, the business terminal has higher timeliness.

[0060] The above business request processing method realizes micro-service architecture call chain monitoring based on call chain technology, sets the survival time for the call chain of the executed business request, stops executing the business request when the survival time of the call chain expires, and returns the timeout information. Thus, the business request with a long response time can be stopped in time, and the effectiveness of the business request can be ensured.

[0061] In another embodiment, the life time of the service request call chain is determined according to the preset timeout time, including: setting the life time of the root service node of the call chain according to the preset timeout time; for the sub-service node called when executing the service request, setting the life time of the sub-service node according to the life time of the parent service node of the sub-service node; the life time of the sub-service node does not exceed the life time of the parent service node.

[0062] The generation time of the call chain represents the overall life time of the chain with each service node on the chain, and the call chain reflects the calling sequence of each service node, therefore, the life time of the call chain reflects the global life time of each service node on the call chain, and the life time of the call chain can be allocated to each service node to obtain the life time of each service node. It can be understood that the global life time of each service node as a whole should not be greater than the preset timeout time.

[0063] To ensure the timeliness of the service node, for the parent service node and the sub-service node with calling relationship, the service execution of the parent service node usually needs to rely on the sub-service node, and the two have dependency in service execution. Based on this dependency, the life time of the sub-service node is allocated to depend on the life time of the parent service node. And all sub-service nodes can be regarded as the call of the root service node, therefore, the life time of all sub-service nodes depends on the life time of the root service node.

[0064] Specifically, the life time of the root service node is set according to the preset timeout time, and the life time of the sub-service node is set according to the life time of the parent service node. The life time of the root service node does not exceed the preset timeout time, and the life time of the sub-service node does not exceed the life time of the parent service node.

[0065] Specifically, after the cloud server receives the service request, the root service node of the service request is generated, and the life time of the root service node is set. The life time of the root service node is the preset timeout time of the service request. For example, the preset timeout time of the service request is 30 milliseconds, and the life time of the root service node is 30 milliseconds.

[0066] It can be understood that for the service node of the call chain, its life time is set when the call to it is generated, that is, when the service node needs to be called, the life time of the sub-service node is set according to the life time of the parent service node.

[0067] The service request is executed from the root service node. When the root service node that is executing the business processing logic needs a sub-service node, the sub-service node that needs to be called by the root service node is generated. Figure 3As shown, sub-service node B is generated for root service node A. Wherein, root service node A is the parent service node of sub-service node B. Thus, the survival time of the sub-service node depends on the survival time of the parent service node.

[0068] The sub-service node is the service node called by the service node in executing the business logic. For example, Figure 3 As shown, B service node and C service node are the sub-service nodes of A service node, and D service node and E service node are the sub-service nodes of C service node.

[0069] The parent service node is the service node that calls the sub-service node. For example, Figure 3 As shown, A service node is the parent service node of B service node and C service node, and C service node is the parent service node of D service node and E service node.

[0070] Wherein, the survival time of the sub-service node is set according to the survival time of the parent service node, and the survival time of the sub-service node does not exceed the survival time of the parent service node.

[0071] Further, in order to make the survival time of the parent service node and the sub-service node consumed at the same time, and to ensure the logical consistency of the parent service node and the sub-service node, the sub-service node inherits the survival time of the parent service node, i.e. the survival time of the sub-service node is the remaining survival time of the parent service node.

[0072] Specifically, for the sub-service node called in executing the business request, the survival time of the sub-service node is set according to the survival time of the parent service node of the sub-service node, including: for the sub-service node called in executing the business request, the sub-service node inherits the survival time of the parent service node. For example, Figure 5 As shown, the survival time of sub-service node B is the remaining survival time of root service node A.

[0073] Wherein, the remaining survival time is determined according to the generation time of the sub-service node, i.e. the start time stamp. For example, for the C service node that is executing the business request, the survival time of the C service node is 10 milliseconds, and in the process of executing the business logic of the C service node, sub-service node D is generated at the 6th millisecond, so the survival time of sub-service node D is the remaining survival time of the C service node, which is 4 seconds.

[0074] Wherein, the survival time of the sub-service node is set according to the survival time of the parent service node, the start time stamp of the sub-service node and the start time stamp of the parent service node. Specifically, the survival time of the sub-service node = the survival time of the parent service node - the start time stamp of the sub-service node + the start time stamp of the parent service node. For example, Figure 5The lifetime of the B service node = the lifetime of the A service node - the start time stamp of the B service node + the start time stamp of the A service node. For example, the lifetime of the A service node (parent service node) is 20 milliseconds, the start time stamp of the A service node is 8:20:1:10 milliseconds, and the start time stamp of the B service node (child service node) is 8:20:1:15 milliseconds, then the lifetime of the B service node is 20 milliseconds - 8:20:1:15 milliseconds + 8:20:1:10 milliseconds = 15 milliseconds.

[0075] Further, when the child service node B that is executing the business processing logic needs a child service node, the child service node C that needs to be invoked by the child service node B is generated. The child service node B is the parent service node of the child service node C. The lifetime of the child service node C is the remaining lifetime of the child service node B.

[0076] The lifetime of the C service node = the lifetime of the B service node - the start time stamp of the C service node + the start time stamp of the B service node. For example, the lifetime of the service node B is 15 milliseconds, the start time stamp of the parent service node B is 8:20:1:15 milliseconds, and the start time stamp of the child service node C is 8:20:1:20 milliseconds, then the lifetime of the child service node C is 15 milliseconds - 8:20:1:20 milliseconds + 8:20:1:15 milliseconds = 10 milliseconds.

[0077] The method adopts the inheritance method, and the child service node inherits the lifetime of the parent service node, so that the lifetimes of the parent service node and the child service node are consumed at the same time. Meanwhile, the lifetimes of the service nodes are set respectively, and each service node only needs to concern its expiration time, and does not need to communicate with other service nodes, thereby saving the server resources.

[0078] 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 entire calling chain expires when the lifetime of a certain child service node expires.

[0079] In another embodiment, when the lifetime of the calling chain expires, the business request is stopped from being executed, and a timeout information is returned. When the lifetime of the current service node that is executing the business processing logic expires, the business processing logic is stopped from being executed, and the timeout information is returned.

[0080] Specifically, the current service node that is executing the business processing logic can be the root service node or any child service node on the calling chain that is executing the business processing logic. When the lifetime expires, the business processing logic is stopped from being executed, and the timeout information is returned for the current service node that is executing the business processing logic.

[0081] When the lifetime of the service node executing the business processing logic expires, the business processing logic is stopped, and timeout information is returned to the parent service node. When the lifetime of the root service node executing the business processing logic expires, the business processing logic is stopped, and timeout information is returned to the business terminal. The business processing logic here refers to the business processing procedure that each service node needs to implement to complete a business request.

[0082] In actual applications, cloud services execute business requests through service nodes, and the business logic executed by each service node to complete a business request is different, and the resources occupied by the execution of the business logic are also different. Taking cloud services implementing image recognition as an example, service node 1 judges whether a video frame image is a key frame, and service node 2 identifies the key frame image using a convolutional neural network. Service node 1 only processes simple business logic and consumes little resources, and service node 2 needs to identify entities in the image and needs to occupy large CPU and GPU resources.

[0083] When the lifetime of the current service node expires, the process cannot be directly killed by force at the bottom layer, and different service nodes that occupy different resources are balanced in real-time, resources, and performance loss. Developers can pre-emptively adopt different expiration execution strategies according to the resources occupied by the service node when executing the business processing logic.

[0084] In one embodiment, when the lifetime of the current service node executing the business processing logic expires, the business processing logic is stopped, and timeout information is returned, including: for a first type of service node that occupies resources greater than a preset standard, a timer is established to monitor the lifetime, and when the current service node executes the business logic, if the timer expires, the business logic is stopped, and timeout information is returned.

[0085] Specifically, developers classify service nodes that occupy more resources and have heavier logic as the first type of service node according to the resource loss of the service node when executing the business processing logic. For the first type of service node, a "strong expiration" execution strategy is set, to avoid the execution of the business logic still occupying large system resources after the lifetime expires, the current service node exits after the lifetime of the service node expires, and timeout information is returned to the parent service node.

[0086] For the first type of service nodes that occupy more resources than the preset standard, a timer is established to monitor the survival time. When the current service node executes the business logic, if the timer expires, the business logic is stopped and a timeout message is returned, including: for the first type of service nodes that occupy more resources than the preset standard, a main thread is created, and the main thread generates a timer according to the survival time; a child thread is established to execute the business processing logic; when the timer of the main thread expires, if the business processing logic of the child thread is not completed, the main thread returns a timeout message.

[0087] If the developer determines that the current service node is a first-class service node based on the resources occupied by the current service node when executing business processing logic, the "strong expiration" execution policy is set for the service node. The purpose of the "strong expiration" execution policy is to force the service node to terminate once the survival time expires and return a timeout message. Figure 6 As shown, when each parent service node generates a child service node, it writes the call chain ID (traceid), service node ID (span id), and service node lifetime into the SPAN context information. The child service node establishes a main thread 601 to access the SPAN context information, parse the lifetime of the current service node, and generate the current service node in the call chain. The main thread activates a timer with an expiration time equal to the lifetime and waits for the timer to expire. Simultaneously, the child service node creates a child thread 602, which executes business processing logic, such as image recognition preprocessing or image recognition based on a convolutional neural network. After completing the business processing logic, child thread 602 sends a message to the main thread 601 and returns the execution result. After the timer expires, the main thread determines whether the business processing logic of the child thread has completed execution based on whether it has received the execution result returned by the child thread. If not, the main thread returns a timeout message to its parent service node, forcibly stopping the business processing logic of the current service node to prevent continued execution of the business processing logic from consuming a large amount of resources.

[0088] Furthermore, when the timer of the main thread expires, if the business processing logic of the child thread is completed, the business processing result is returned.

[0089] In this embodiment, a "strong expiration" processing strategy is pre-set for the current service node that occupies a large amount of resources in executing business processing logic. By establishing a timer monitoring, once the lifetime of the current service node expires, the execution of the business processing logic is immediately stopped and a timeout message is returned. On the one hand, the effectiveness of the business processing is guaranteed and the business processing flow is prevented from being executed indefinitely. On the other hand, the continued execution of the business processing logic is prevented from occupying a large amount of resources and resources are released in time.

[0090] In another embodiment, when the life time of the current service node executing the business processing logic expires, the execution of the business processing logic is stopped, and a timeout information is returned, including: for the second type of service node occupying less than a preset standard of resources, when the execution of the business logic needs to call a child service node, if the life time of the current service node expires, the execution of the business processing logic is stopped, and a timeout information is returned.

[0091] When the developer determines that the current service node is the second type of service node according to the resources occupied by the current service node when executing the business processing logic, and the resources are less, the developer sets a "lazy expiration" execution strategy for the service node. The "lazy expiration" execution strategy is for the service node which occupies less resources when executing the business processing logic, and does not need to stop the business processing flow when the life time expires, but judges whether the life time expires after reaching a certain condition, so as to avoid occupying large resources by establishing a timer and double threads. Since the service node itself occupies less resources when executing the business processing logic, even if the life time is slightly expired, it will not occupy too many system resources, and after judging the expiration, the execution of the business flow is stopped, which can ensure the effectiveness and balance between effectiveness and resources.

[0092] Specifically, the developer classifies the service node as the second type of service node according to the resources occupied by the service node when executing the business processing logic, and the resources are less and the logic is lighter. The second type of service node only processes simple business logic and does not consume much resources. For the second type of service node, a "lazy expiration" execution strategy is set, and the life time does not need to be monitored in real time. Only when the current service node needs to call a child service node according to the business processing logic, it is judged whether the life time of the current service node expires. If the life time of the current service node expires, a timeout information is returned to the parent service node. Since the second type of service node occupies less resources when executing the business processing logic, it is not necessary to judge whether the life time of the service node is exhausted when calling the child service node, and it will not occupy too many resources. Compared with the "strong expiration" processing strategy of establishing a timer and double threads, it can avoid occupying kernel resources by establishing a timer and child threads, and balance between effectiveness and resources.

[0093] When the execution of the business logic needs to call a child service node, if the life time of the current service node does not expire, the execution of the child service node called when executing the business request is executed, and the life time of the child service node is set according to the life time of the parent service node of the child service node. That is, the child service node is generated, and the life time of the child service node is allocated.

[0094] 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 parent service node of the current service node. If the survival time of the current service node is expired, the timeout information is returned to the parent service node.

[0095] Specifically, as shown in Figure 7 the "lazy expiration" processing strategy includes the following steps:

[0096] S702: Analyze the survival time to generate the current service node.

[0097] When each parent service node generates a child service node, the trace id, the spanid of the service node and the survival time of the service node are written into the SPAN context information. The main thread of the child service node accesses the SPAN context information to analyze the survival time of the current service node, the node ID of the parent service node and the trace id to generate the current service node of the trace. According to the node ID of the child service node, the node ID of the parent service node and the trace id, the calling chain of the business request can be monitored.

[0098] S704: Execute the service processing logic of the current service node.

[0099] S706: When the service processing flow is executed, whether a child service node needs to be generated is monitored. If yes, step S708 is executed. If no, step S710 is executed.

[0100] S708: Determine whether the survival time of the current service node is expired. If yes, the timeout information is returned. If no, a child service node is generated.

[0101] When the current service node executes the service processing flow, whether the survival time of the current service node is expired is determined. If the survival time of the current service node is expired, the timeout information is returned.

[0102] If the survival time of the current service node is not expired, a child SPAN is generated. Specifically, the steps of setting the survival time of the child service node according to the survival time of the parent service node of the child service node are executed for the child service node called when the business request is executed. That is, the survival time of the child service node is generated according to the remaining survival time of the parent service node.

[0103] Specifically, whether the survival time of the current service node is expired is determined according to the remaining survival time of the current service node. The calculation method of the remaining survival time is: remaining survival time = survival time of the current service node - current timestamp + start timestamp of the current service node. When the remaining survival time is greater than 0, it indicates that the survival time of the current service node is not expired. When the remaining survival time is less than 0, it indicates that the survival time of the current service node is expired.

[0104] The determination of whether the survival time is expired is performed when the business processing logic needs to call the child service node. According to the determination result, if the survival time is expired, the timeout information is returned to the parent service node, and if the survival time is not expired, the child service node is generated. When the child service node needs to be called, whether there is a remaining survival time is determined, and the child service node is responsible for determining whether there is enough remaining survival time to generate the child service node.

[0105] S710, the business processing flow is continued to be executed until the business processing logic ends.

[0106] If the remaining survival time of the current service node is not expired, the business processing flow is continued to be executed until the business processing logic ends.

[0107] After step S710, S712 is executed.

[0108] S712, whether the survival time of the current service node is expired is determined. If yes, the timeout information is returned. If no, the business processing result is returned.

[0109] After the business processing logic ends, whether the survival time of the current service node is expired is further determined. The determination of whether the survival time is expired is performed after the business processing logic of the current service node ends. According to the determination result, the current service node can feed back to the parent service node, and the parent service node is responsible for determining whether the business processing logic is completed within the survival time. If the survival time is expired, the timeout information is returned, and if the survival time is not expired, the business processing result is returned.

[0110] The "lazy expiration" strategy of the embodiment does not need to monitor the survival time in real time. Only when the child service node needs to be called and the business processing logic of the current service node is completed, the determination of whether the survival time is expired is triggered. Since the resources occupied in the execution of the business processing logic are originally small, the determination of whether the survival time is exhausted when the child service node needs to be called or after the execution ends will not occupy too many resources, and the effectiveness and resources are balanced.

[0111] The application also provides an application scenario. The business processing method is applied in the application scenario.

[0112] The application scenario is automatic driving. The automatic driving car is equipped with a camera, a positioning system, and a laser radar. A cloud server provides automatic driving decision calculation. The automatic driving car collects video frame images and three-dimensional laser point cloud data at a speed of 60 frames per second and sends them to the cloud server.

[0113] When the cloud server obtains the service request, the cloud server obtains a preset timeout time corresponding to the service request. The preset timeout time is set to 23 milliseconds. This is because the collection frequency of the automatic driving car is 60 seconds / frame. If the response time for a frame of video image is too long, the driving decision will not be effective.

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

[0115] The call chain of the cloud server is as shown in Figure 3 When the service request reaches the A service node, the A service node responds to the service request and makes a car driving decision. The A service node calls the B service result to process the positioning data and determine the current position of the automatic driving car. The A service node calls the C service node to determine the front obstacle based on the three-dimensional point cloud data and the image data. The C service node calls the D service node to process the three-dimensional point cloud data and identify the lane line and the obstacle. The C service node calls the E service node to process the image data and identify the pedestrian and the car as obstacles. The processing results of the D service node and the E service node are returned to the C service node. The C service node determines the movable direction based on the image recognition and the three-dimensional point cloud detection of the obstacle. The processing results of the C service node and the B service node are returned to the A service node. The A service result determines the final moving direction based on the determined movable direction and the current positioning.

[0116] 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 survival time of the root service node. When a service node that executes the service processing logic calls a child service node, the survival time of the child service node is set according to the remaining survival time of the parent service node, so that the survival times of the parent and child service nodes are consumed at the same time. For example, the survival time of the root service node A is 23 milliseconds. When the root service node needs to call a child service node B to execute the service processing logic, if the remaining time of the root service node is 15 seconds, the survival time of the child service node is set to 15 seconds.

[0117] The service request is executed from the root service node, and when the lifetime of the call chain expires, the execution of the service request is stopped, and timeout information is returned. Specifically, when the lifetime of the current service node that is executing the service processing logic expires, the execution of the service processing logic is stopped, and timeout information is returned, and the cloud server processes the next service request that is more time-sensitive. If the lifetime of the current service node that is executing the service processing logic has not expired, the execution of the service processing logic is continued, and the service processing result is returned to the parent service node. When the A service node receives the service processing result of the child service node within the lifetime, the A service node returns the driving decision to the autonomous vehicle.

[0118] The method can timely stop a service request with a long response time, and ensure the effectiveness of the service request.

[0119] The expired execution strategy is determined by a developer according to resources occupied by the service node when executing the service processing logic. For a service node that occupies a large amount of resources, a "strong expiration" processing strategy is used, and a timer and a child thread are used. Once the lifetime of the timer expires, the execution of the service processing logic is immediately stopped.

[0120] For a service node that occupies a small amount of resources, a "lazy expiration" processing strategy is used. When a child thread needs to be called and the service processing logic of the current service node is executed, it is detected whether the lifetime expires. After expiration, the execution of the service processing logic is stopped.

[0121] It can be understood that in a micro-service architecture, the two expiration processing strategies are applied to different service nodes at the same time, and a balance between effectiveness and resources is found.

[0122] It should be understood that although Figure 2 the steps in the flowcharts of 5-6 are displayed in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this article, the execution of these steps has no strict order restriction, and these steps can be executed in other orders. Moreover, Figure 2 at least part of the steps in 5-6 can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0123] In one embodiment, as Figure 8 shown, a service request processing apparatus is provided, which can be a part of a computer device in the form of a software module or a hardware module, or a combination of the two. The apparatus specifically includes:

[0124] The business request obtaining module 801 is configured to obtain a preset timeout period corresponding to the business request when the business request is obtained.

[0125] The call chain processing module 802 is configured to generate a call chain for executing the business request and a root service node of the call chain.

[0126] The time-to-live setting module 803 is configured to determine a time-to-live of the call chain for executing the business request according to the preset timeout period; the time-to-live of the call chain does not exceed the preset timeout period.

[0127] The execution module 804 is configured to execute the business request from the root service node.

[0128] The control module 805 is configured to stop executing the business request and return timeout information when the time-to-live of the call chain expires.

[0129] The above business request processing apparatus is based on the call chain technology to realize the call chain monitoring of the micro-service architecture, and on this basis, sets the time-to-live of the call chain for executing the business request, stops executing the business request and returns the timeout information when the time-to-live of the call chain expires. Thus, the business request with a long response time can be stopped in time, and the effectiveness of the business request can be ensured.

[0130] In another embodiment, the time-to-live setting module comprises:

[0131] The root node setting module is configured to set the time-to-live of the root service node of the call chain according to the preset timeout period.

[0132] The child node setting module is configured to set the time-to-live of a child service node of the call chain according to the time-to-live of a parent service node of the child service node when the child service node is called to execute the business request; the time-to-live of the child service node does not exceed the time-to-live of the parent service node.

[0133] In another embodiment, the control module is configured to stop executing the business processing logic and return the timeout information when the time-to-live of the current service node that is executing the business processing logic expires.

[0134] In another embodiment, the control module is configured to establish a timer to monitor the time-to-live for a first type of service node that occupies resources greater than a preset standard, and stop executing the business logic and return the timeout information when the timer expires while the current service node is executing the business logic.

[0135] In another embodiment, the control module is configured to create a main thread for a first type of service node that occupies resources greater than a preset standard, the main thread generating a timer according to a lifetime; establish a sub-thread to execute a service processing logic; and when the timer of the main thread expires, if the service processing logic of the sub-thread is not completed, the main thread returns a timeout information.

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

[0137] In another embodiment, the control module is configured to, for a second type of service node that occupies resources less than a preset standard, when a service logic needs to call a sub-service node to execute, if a lifetime of a current service node expires, stop executing the service processing logic and return a timeout information.

[0138] In another embodiment, the control module is configured to, if the lifetime of the current service node expires, execute a step of setting a lifetime of a sub-service node according to a lifetime of a parent service node of the sub-service node for the sub-service node called when executing a service request.

[0139] In another embodiment, the control module is configured to, after the service processing logic of the current service node is executed, if the lifetime of the current service node does not expire, return a service processing result to a parent service node of the current service node.

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

[0141] In another embodiment, the sub-node setting module is configured to, for a sub-service node called when executing a service request, make the sub-service node inherit a lifetime of a parent service node.

[0142] In another embodiment, the sub-node setting module is configured to, for a sub-service node called when executing a service request, determine a remaining lifetime of a current service node according to a lifetime of a parent service node, a start time stamp of the sub-service node and a start time stamp of the parent service node, and determine a lifetime of the sub-service node according to the remaining lifetime of the current service node.

[0143] The specific limitation of the service request processing apparatus can refer to the limitation of the service request processing method, which will not be repeated here. Each module in the service request processing apparatus can be realized by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the computer device in hardware form, or can be stored in the memory in the computer device in software form, so as to call and execute the operation corresponding to each module by the processor.

[0144] In one embodiment, a computer device, which can be a server, is provided, and its internal structure diagram can be as shown in Figure 9 The computer device includes a processor, a memory and a network interface connected by a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile 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 operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store service request processing data. The network interface of the computer device is used to communicate with the external terminal through the network connection. The computer program is executed by the processor to implement a service request processing method.

[0145] Those skilled in the art can understand that Figure 9 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or less components than those shown in the figure, or combine certain components, or have different component arrangements.

[0146] In one embodiment, a computer device is also provided, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in each method embodiment.

[0147] In one embodiment, a computer readable storage medium is provided, which stores a computer program. The computer program is executed by the processor to implement the steps in each method embodiment.

[0148] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium, and when executed, can include the processes of the above-mentioned embodiment methods. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0149] Any combination of the technical features of the above embodiments can be made. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, but as long as the combination of the technical features does not exist, it should be considered as the scope of the present application.

[0150] The above embodiments only express several implementation manners of the present application, and the description is more specific and detailed, but it should not be understood as a limitation on the scope of the patent. It should be pointed out that for those skilled in the art, without departing from the concept of the present application, some modifications and improvements can be made, which are all within the protection scope of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.

Claims

1. A method for processing a service request, the method comprising: When a service request is received, a preset timeout period corresponding to the service request is obtained; Generate a call chain for executing the business request and a root service node of the call chain; Determine the lifetime of the service request call chain according to the preset timeout period; The lifetime of the call chain does not exceed the preset timeout period; Executing the service request from the root service node; For the second type of service nodes that occupy less resources than the preset standard, when executing business processing logic and need to call a sub-service node, if the lifetime of the current service node expires, the business processing logic will be stopped and a timeout message will be returned.

2. The method according to claim 1, wherein determining the lifetime of the service request call chain according to the preset timeout period comprises: According to the preset timeout period, a lifetime is set for the root service node of the call chain; For the child service node called when executing the service request, a survival time is set for the child service node according to the survival time of the parent service node of the child service node; the survival time of the child service node does not exceed the survival time of the parent service node.

3. The method according to claim 2, characterized in that The method further comprises: For the first type of service nodes that occupy resources greater than a preset standard, a timer is established to monitor the survival time. When the current service node executes the service processing logic, if the timer expires, the service processing logic is stopped and a timeout message is returned.

4. The method according to claim 3, characterized in that For a first-category service node whose resource occupancy exceeds a preset standard, a timer is established to monitor the lifetime. When the current service node executes the service processing logic, if the timer expires, the service processing logic is stopped and timeout information is returned, including: For the first type of service nodes that occupy more resources than the preset standard, a main thread is created, and the main thread generates a timer based on the survival time; Establish a child thread to execute business processing logic; When the timer of the main thread expires, if the business processing logic of the child thread is not completed, the main thread returns a timeout message.

5. The method according to claim 4, characterized in that When the timer of the main thread expires, if the business processing logic of the sub-thread is completed, the business processing result is returned.

6. The method according to claim 2, characterized in that When the business processing logic needs to call a child service node, if the lifetime of the current service node has not expired, the step of setting the lifetime of the child service node called when executing the business request according to the lifetime of the parent service node of the child service node is executed.

7. The method according to claim 2, characterized in that After the service processing logic of the current service node is executed, if the lifetime of the current service node has not expired, the service processing result is returned to the parent service node of the current service node.

8. The method according to claim 2, characterized in that After the business processing logic of the current service node is executed, if the lifetime of the current service node expires, timeout information is returned to the parent service node.

9. The method according to claim 2, characterized in that For the sub-service node called when executing the business request, the survival time of the sub-service node is set according to the survival time of the parent service node of the sub-service node, including: for the sub-service node called when executing the business request, the sub-service node is allowed to inherit the survival time of the parent service node.

10. The method according to claim 9, characterized in that For the child service node called when executing the business request, the child service node is made to inherit the life span of the parent service node, including: for the child service node called when executing the business request, the remaining life span of the current service node is determined according to the life span of the parent service node, the start timestamp of the child service node and the start timestamp of the parent service node, and the life span of the child service node is determined according to the remaining life span.

11. A service request processing device, characterized in that: The device comprises: A service request acquisition module is used to obtain a preset timeout period corresponding to a service request when a service request is obtained; A call chain processing module, configured to generate a call chain for executing the service request and a root service node of the call chain; A survival time setting module, configured to determine the survival time of the service request call chain according to the preset timeout time; the survival time of the call chain does not exceed the preset timeout time; An execution module, configured to execute the service request from the root service node; The control module is used to stop executing the business processing logic for the second type of service node whose occupied resources are less than the preset standard and return a timeout message if the lifetime of the current service node expires when the service processing logic needs to call the sub-service node.

12. The service request processing device according to claim 11, characterized in that: The lifetime setting module includes: A root node setting module, configured to set a lifetime for the root service node of the call chain according to the preset timeout period; The child node setting module is used to set the survival time of the child service node called when executing the business request according to the survival time of the parent service node of the child service node; the survival time of the child service node does not exceed the survival time of the parent service node.

13. The service request processing device according to claim 12, characterized in that: The control module is also used to establish a timer to monitor the survival time for the first type of service node whose occupied resources are greater than the preset standard. When the current service node executes the business processing logic, if the timer expires, the business processing logic is stopped and a timeout message is returned.

14. The service request processing device according to claim 13, characterized in that: The control module is also used to create a main thread for the first type of service node that occupies resources greater than a preset standard, and the main thread generates a timer based on the survival time; establish a child thread to execute business processing logic; when the timer of the main thread expires, if the business processing logic of the child thread is not completed, the main thread returns a timeout information.

15. The service request processing device according to claim 14, characterized in that: The control module is further configured to return a business processing result if the business processing logic of the sub-thread is completed when the timer of the main thread expires.

16. The service request processing device according to claim 12, characterized in that: The control module is also used to execute the step of setting the survival time of the sub-service node called when executing the business processing logic and calling the sub-service node according to the survival time of the parent service node of the sub-service node if the survival time of the current service node has not expired.

17. The service request processing device according to claim 12, characterized in that: The control module is further configured to return a service processing result to the parent service node of the current service node after the service processing logic of the current service node is executed and if the lifetime of the current service node has not expired.

18. The service request processing device according to claim 12, characterized in that: The control module is further configured to return timeout information to the parent service node if the lifetime of the current service node expires after the execution of the service processing logic of the current service node is completed.

19. The service request processing device according to claim 12, characterized in that: The child node setting module is further configured to enable the child service node called when executing the service request to inherit the lifespan of the parent service node.

20. The service request processing device according to claim 19, characterized in that: The child node setting module is also used to determine the remaining survival time of the current service node for the child service node called when executing the business request based on the survival time 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 survival time of the child service node based on the remaining survival time.

21. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 10 is implemented.

22. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

23. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images