CN113783822A

CN113783822A - Service timeout management method and device

Info

Publication number: CN113783822A
Application number: CN202010494696.3A
Authority: CN
Inventors: 张晋军
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Wodong Tianjun Information Technology Co Ltd
Priority date: 2020-06-03
Filing date: 2020-06-03
Publication date: 2021-12-10
Anticipated expiration: 2040-06-03
Also published as: CN113783822B

Abstract

The invention discloses a service timeout management method and device, and relates to the technical field of computers. One embodiment of the method comprises: the second micro-service receives the request transmitted by the first micro-service, analyzes the protocol header of the request and obtains a timestamp and the remaining time; calculating a difference value between the current timestamp and the timestamp, and determining first remaining time after the difference value is removed from the remaining time; and estimating the processing time of the request, comparing whether the first remaining time is greater than or equal to the processing time, and further performing corresponding operation according to a comparison result. According to the implementation mode, the content of the 'timeout period' is added in the communication protocol, so that all links on the micro-service calling chain form a consensus mechanism aiming at timeout, once one micro-service is overtime, the calling of the calling chain is directly stopped, and the effect of saving resources is achieved.

Description

Service timeout management method and device

Technical Field

The invention relates to the technical field of computers, in particular to a service timeout management method and device.

Background

In synchronous communication, a sender needs to specify a timeout value when sending a request, and if the response of a receiver is not received when the timeout time is reached, a timeout error or a timeout exception prompt is received, so that the communication is terminated.

Under the micro-service architecture, one application is split into a plurality of micro-services, and business logic is completed through mutual calling among the micro-services to form a calling chain. For example, a call chain is composed of 3 micro-services (S1- > S2- > S3), and there are 2 timeout values (indicated by T12, T23) therebetween, and T12 includes a time T23 when S2 waits for the response of S3, i.e., T12> T23, otherwise the call chain fails in the middle of a certain link due to timeout.

In the process of implementing the invention, the inventor finds that the prior art has at least the following problems:

the existing overtime action is improperly set and only occurs between two adjacent microservices, so that the resource waste of a call chain is easily caused. As in the above example, when the call chain has proceeded to S3, S1 has received a timeout error, and the workloads of S2 and S3 occupy the resources but do not generate the service value, especially when they are still participating in other call chains and the concurrency of these call chains is large, the aforementioned waste of resources may aggravate the service pressure of S2 and S3, cause a service overload phenomenon, and affect the service stability.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for managing service timeout, which can at least solve the problem in the prior art that a timeout effect occurs only between two adjacent micro services, which is likely to cause resource waste of a call chain where the micro services are located.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a service timeout management method including:

the second micro-service receives the request transmitted by the first micro-service, analyzes the protocol header of the request and obtains a timestamp and the remaining time; wherein the first microservice and the second microservice are in the same call chain and adjacent, the timestamp is a starting time for the first microservice to send a request, the remaining time is a time for subscribing the second microservice to receive and process a request, and the timestamp and the remaining time are added to the protocol header by the first microservice;

calculating a difference value between the current timestamp and the timestamp, and determining first remaining time after the difference value is removed from the remaining time;

and estimating the processing time of the request, comparing whether the first remaining time is greater than or equal to the processing time, and further performing corresponding operation according to a comparison result.

Optionally, before the determining the first remaining time after the remaining time is eliminated from the difference, the method further includes: and if the difference is greater than or equal to the remaining time, determining that the second micro service cannot process the request, ending the call chain call, and returning call failure information to the first micro service.

Optionally, the estimating a processing time of the request includes: determining the requests processed by the second micro service in the historical time, acquiring the processing time of each request to obtain the total processing time through accumulation, and taking the ratio of the total processing time to the number of the processed requests as the processing time of the request.

Optionally, the performing corresponding operations according to the comparison result includes:

if the comparison result is greater than or equal to the first remaining time, determining that the second micro service can finish processing the request within the first remaining time; or

And if the comparison result is less than the preset value, determining that the second micro service cannot process the request, ending the call chain call, and returning call failure information to the first micro service.

Optionally, after the determining that the second microservice can process the request within the first remaining time, the method further includes:

when the second micro-service is not the last micro-service in the call chain, determining a first timestamp when a request is sent to an adjacent third micro-service and a second remaining time of a reservation;

adding the first timestamp and the second remaining time to a protocol header of a request before sending the request to the third microservice.

To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided a service timeout management apparatus including:

the protocol processing module is used for receiving the request transmitted by the first micro-service by the second micro-service, analyzing a protocol header of the request and obtaining a timestamp and the remaining time; wherein the first microservice and the second microservice are in the same call chain and adjacent, the timestamp is a starting time for the first microservice to send a request, the remaining time is a time for subscribing the second microservice to receive and process a request, and the timestamp and the remaining time are added to the protocol header by the first microservice;

the overtime processing module is used for calculating the difference value between the current timestamp and the timestamp and determining first remaining time after the difference value is removed from the remaining time; and estimating a processing time for the request, comparing whether the first remaining time is greater than or equal to the processing time;

and the service processing module is used for carrying out corresponding operation according to the comparison result.

Optionally, the timeout processing module is further configured to: and if the difference is greater than or equal to the remaining time, determining that the second micro service cannot process the request, ending the call chain call, and returning call failure information to the first micro service.

Optionally, the timeout processing module is configured to: determining the requests processed by the second micro service in the historical time, acquiring the processing time of each request to obtain the total processing time through accumulation, and taking the ratio of the total processing time to the number of the processed requests as the processing time of the request.

Optionally, the service processing module is configured to:

Optionally, the service processing module is further configured to:

To achieve the above object, according to still another aspect of embodiments of the present invention, there is provided an electronic device for service timeout management.

The electronic device of the embodiment of the invention comprises: one or more processors; a storage device, configured to store one or more programs, which when executed by the one or more processors, cause the one or more processors to implement any of the service timeout management methods described above.

To achieve the above object, according to a further aspect of the embodiments of the present invention, there is provided a computer readable medium having stored thereon a computer program which, when executed by a processor, implements any of the service timeout management methods described above.

According to the scheme provided by the invention, one embodiment of the invention has the following advantages or beneficial effects: by adding the 'timeout period' content in the communication protocol, all links on the micro-service calling chain form a consensus mechanism aiming at timeout, once one micro-service is overtime, the calling of the calling chain is directly stopped, and links after the micro-service are not required to be executed, so that the effect of saving resources is achieved, and in addition, the resources are more reasonably utilized, so that the service stability is improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a schematic main flow chart of a service timeout management method according to an embodiment of the present invention;

FIG. 2 is a flow chart illustrating an alternative service timeout management method according to an embodiment of the present invention;

FIG. 3 is a flow diagram illustrating an alternative service timeout management method according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of the main blocks of a service timeout management apparatus according to an embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 6 is a schematic block diagram of a computer system suitable for use with a mobile device or server implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Referring to fig. 1, a main flowchart of a service timeout management method according to an embodiment of the present invention is shown, including the following steps:

s101: the second micro-service receives the request transmitted by the first micro-service, analyzes the protocol header of the request and obtains a timestamp and the remaining time; wherein the first microservice and the second microservice are in the same call chain and adjacent, the timestamp is a starting time for the first microservice to send a request, the remaining time is a time for subscribing the second microservice to receive and process a request, and the timestamp and the remaining time are added to the protocol header by the first microservice;

s102: calculating a difference value between the current timestamp and the timestamp, and determining first remaining time after the difference value is removed from the remaining time;

s103: and estimating the processing time of the request, comparing whether the first remaining time is greater than or equal to the processing time, and further performing corresponding operation according to a comparison result.

In the above embodiment, for steps S101 to S103, the present invention adds "timeout period" information to the request communication protocol, where the information indicates how much time remains for the service instance corresponding to each link in the call chain to process the request:

1) the time stamp, which represents the starting time when the sender sends the request, can be expressed as an absolute time in computer science, for example, 12: 07/20 seconds at 4/7/2020.

It should be noted that the request initiated by the user invoking the call chain may need some preprocessing operation before actually invoking the call chain, and there is a time interval from the timestamp mentioned in the present invention. The timestamp of the present invention indicates only the time the request was initiated between the invocation of the chain microservice.

2) The remaining time, representing the time left for the receiver to receive the request and process the logic. Usually, the sender and the receiver need to negotiate in advance for the micro service provided by the receiver, and the remaining time value is mainly determined according to the processing time of the service provided by the receiver during negotiation. When actually communicating, no renegotiation is necessary.

In addition, the remaining time cannot be set to be very large, because the sender and the receiver often have an Agreement on SLA (Service-Level Agreement), the sender cannot wait permanently, for example, a WEB user cannot wait for the return of the content of the WEB page permanently, and the user may choose to leave the WEB page if the return does not occur for more than 10 seconds.

The length of the remaining time setting is related to the complexity of the specific service logic, and the more complex the service logic needs longer time, and vice versa. Besides, the negotiation can be made according to the service dependence items and the resource situation.

It should be noted that the remaining time in the present invention only corresponds to two adjacent microservices in the call chain, for example, taking call chain S1- > S2- > S3 as an example, the remaining time T12 between S1 and S2 is independent from the remaining time T23 between S2 and S3. Compared with the conventional T12 mode that the T23 is needed, the method can directly end the calling of the calling chain when the calling of the intermediate micro service fails, thereby reducing the resource consumption.

There is a "protocol header" part in the general protocol design, and these two fields can be added to the protocol header to send the remaining time to the next microservice. For text-based protocols such as HTTP, for example, two extended attributes may be added to the protocol header, such as x-starttime:1576476143, x-remaining-time: 5000 ms; the same applies to the binary protocol.

Taking the call chain S1- > S2- > S3 as an example, S1, S2, and S3 respectively represent service instances corresponding to 3 links (different microservices), and each service instance is provided with a "protocol processing" module, a "timeout processing" module, and a "service processing" module, as shown in fig. 2. Wherein:

1) the protocol processing module is responsible for protocol coding and decoding, and is responsible for coding/decoding work of 'timeout period' information compared with the existing 'timeout period' information;

2) the overtime processing module is responsible for overtime logic and carries out overtime judgment according to the overtime period information decoded by the protocol processing module;

3) the 'business processing' module is responsible for business logic, and normally operates and initiates the call of the microservice of the next link under the condition that the 'overtime processing' module judges that no overtime exists.

The timeout mechanism principle of the present invention is illustrated by taking the call among three microservices of S1, S2 and S3 as an example, and is shown in FIG. 3:

at the initial link of the call chain, the initial caller S1 sets a "timestamp" as the time when the request was sent to the receiver S2, sets a "remaining time" as its timeout value negotiated in advance with S2, and adds the "timestamp" and the "remaining time" to the protocol header of the request through the "protocol processing" module.

The receiver S2, upon receiving the request, also parses the protocol header of the request through the protocol processing module, and obtains the "timeout period" information, the "timestamp" and the "remaining time". Then, the timeout judgment is carried out, the logic is completed in a timeout processing module, and a new remaining time (namely, a first remaining time) is calculated firstly in the following way:

first remaining _ time is original remaining _ time- (cur _ time-old _ time)

Wherein, cur _ time is the current timestamp, and old _ time is the timestamp when the sender sends the request.

As an optimization, it is first determined whether (cur _ time-old _ time) is greater than or equal to the remaining _ time carried in the protocol header, and if so, that is, the first remaining _ time is less than 0, it indicates that the time for receiving the request at S2 is too long and exceeds the remaining _ time, and at this time, the process is not necessary, and the process is ended directly. This approach is simple to implement and does not incur additional overhead.

In actual operation, on one hand, a receiving party continuously receives requests sent by a sending party and then places the requests into a request queue, and on the other hand, the requests are continuously taken from the request queue and processed to form an 'asynchronous processing' working mode, namely, the received requests and the processed requests are divided into different modules to be processed. However, when the speed of sending the request by the sender is higher than the speed of processing the request by the receiver, more requests are accumulated in the request queue, and when the accumulation amount reaches a certain degree, the later-ordered requests wait for too long time in the queue according to the FIFO (First Input First Output) principle and exceed the remaining _ time, and no processing is necessary at this time.

When the first remaining _ time >0, S2 still needs to determine whether it can process the request within the time:

1) first it estimates the time it takes to process the request.

Since the request has not been processed at this time, the processing time needs to be estimated depending on the history data. For example, the requests that have been processed within the history time and the processing time for each request are acquired S2, and then the average value is found as the processing time for the request this time.

Average value (sum of processing time of processed requests)/(number of processed requests)

Further, the processing performance of S2 may be changed, so the selected historical time may be the nearest neighboring to the current timestamp, and the estimated processing time is closer to the actual processing time.

2) Determining whether the first remaining _ time is greater than or equal to the processing time:

to reduce the waste of S2 resources, S2 may return the call failure information to S1 without processing the request. For example, the remaining _ time is set to 10S, 1S when the request is sent in S1, 3S when the request is received in S2, and 8S is calculated as the first remaining _ time. While S2 takes 8.5 seconds to process the request, indicating that S2 cannot complete the request.

② is greater than or equal to. If it takes 7.5S to process the request at S2, it indicates that S2 can finish processing the request and continue to call the next node microservice S3.

Also, here, it is necessary to determine a first timestamp of when the request is sent to S3 by S2 (in this case, the request can be distinguished from the request sent to S2 by S1), and a second remaining time of receiving and processing the request by S3, which are assigned in advance, and then send the two pieces of information to S3 after adding the two pieces of information to the protocol header of the request.

Compared with the prior art, the method provided by the embodiment at least has the following beneficial effects:

1) the existing remaining time setting is often determined by manual quotients of two communication parties, and the quotients result in that: the sender only sets the remaining time in his own program, and the receiver, regardless of this, simply returns the result without regard to whether the sender still needs it. The invention actively transmits the residual time information in the call chain, so that the receiver can autonomously judge whether the receiver needs to process the request, thereby effectively avoiding 'meaningless call';

2) the remaining time is only set between two adjacent micro services in the call chain without considering the processing process of other micro services;

3) by adding the 'timeout period' content in the communication protocol, all links on the micro-service calling chain form a consensus mechanism aiming at timeout, once one micro-service is overtime, the calling of the calling chain is directly stopped, and links after the micro-service are not required to be executed, so that the effect of saving resources is achieved, and in addition, the resources are more reasonably utilized, so that the service stability is improved.

Referring to fig. 4, a schematic diagram of main modules of a service timeout management apparatus 400 according to an embodiment of the present invention is shown, including:

the protocol processing module 401 is configured to receive a request transmitted by the first micro service by the second micro service, and analyze a protocol header of the request to obtain a timestamp and remaining time; wherein the first microservice and the second microservice are in the same call chain and adjacent, the timestamp is a starting time for the first microservice to send a request, the remaining time is a time for subscribing the second microservice to receive and process a request, and the timestamp and the remaining time are added to the protocol header by the first microservice;

an overtime processing module 402, configured to calculate a difference between a current timestamp and the timestamp, and determine a first remaining time after the difference is removed from the remaining time; and estimating a processing time for the request, comparing whether the first remaining time is greater than or equal to the processing time;

and the service processing module 403 is configured to perform corresponding operations according to the comparison result.

In the device for implementing the present invention, the timeout processing module 402 is further configured to: and if the difference is greater than or equal to the remaining time, determining that the second micro service cannot process the request, ending the call chain call, and returning call failure information to the first micro service.

In the device for implementing the present invention, the timeout processing module 402 is configured to: determining the requests processed by the second micro service in the historical time, acquiring the processing time of each request to obtain the total processing time through accumulation, and taking the ratio of the total processing time to the number of the processed requests as the processing time of the request.

In the device for implementing the present invention, the service processing module 402 is configured to:

In the device for implementing the present invention, the service processing module is further configured to:

In addition, the detailed implementation of the device in the embodiment of the present invention has been described in detail in the above method, so that the repeated description is not repeated here.

Fig. 5 illustrates an exemplary system architecture 500 to which embodiments of the invention may be applied.

As shown in fig. 5, the system architecture 500 may include

terminal devices

501, 502, 503, a network 504, and a server 505 (by way of example only). The network 504 serves to provide a medium for communication links between the

terminal devices

501, 502, 503 and the server 505. Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

501, 502, 503 to interact with a server 505 over a network 504 to receive or send messages or the like. Various communication client applications may be installed on the

terminal devices

501, 502, 503.

The

terminal devices

501, 502, 503 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 505 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

501, 502, 503.

It should be noted that the method provided by the embodiment of the present invention is generally executed by the server 505, and accordingly, the apparatus is generally disposed in the server 505.

It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, a block diagram of a computer system 600 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a protocol processing module, a timeout processing module and a service processing module. Where the names of these modules do not in some cases constitute a limitation on the modules themselves, for example, a business process module may also be described as a "process business module".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

According to the technical scheme of the embodiment of the invention, the content of the timeout period is added in the communication protocol, so that all links on the micro-service calling chain form a consensus mechanism aiming at the timeout, once one micro-service has a timeout phenomenon, the calling of the calling chain is directly stopped, and links after the micro-service are not required to be executed, thereby achieving the effect of saving resources.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A service timeout management method, comprising:

2. The method of claim 1, wherein before said determining the first remaining time after said remaining time culling said difference value, further comprising:

and if the difference is greater than or equal to the remaining time, determining that the second micro service cannot process the request, ending the call chain call, and returning call failure information to the first micro service.

3. The method of claim 1, wherein estimating the processing time for the request comprises:

determining the requests processed by the second micro service in the historical time, acquiring the processing time of each request to obtain the total processing time through accumulation, and taking the ratio of the total processing time to the number of the processed requests as the processing time of the request.

4. The method according to claim 1, wherein performing the corresponding operation according to the comparison result comprises:

5. The method of claim 4, further comprising, after said determining that the second microservice can handle the request within the first remaining time:

6. A service timeout management apparatus, comprising:

7. The apparatus of claim 6, wherein the traffic processing module is configured to:

8. The apparatus of claim 7, wherein the traffic processing module is further configured to:

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.

10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.