Serverless workflow function exception retry method and apparatus
By using a combination of interfaces and retry processors to determine and execute delayed queue retry tasks when a Serverless workflow function encounters an exception, the problem of Serverless workflow function exceptions being unable to be retried is solved, thus improving the reliability and stability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING QIYI CENTURY SCI & TECH CO LTD
- Filing Date
- 2022-09-27
- Publication Date
- 2026-07-10
Smart Images
Figure CN115686933B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of serverless workflow, and in particular to a method and apparatus for retrying exceptions in serverless workflow functions. Background Technology
[0002] In recent years, enterprise applications have evolved from microservice architectures to serverless architectures. Serverless applications consist of a series of functions, which are executed by events. The Serverless Workflow Specification is a workflow language specification for microservice or function orchestration. Based on a DSL, workflows can be declaratively defined using YAML or JSON. Functions in a workflow inevitably encounter errors during execution, such as throwing exceptions or function instances being terminated. Some exceptions may be temporary, and the function may recover normally through retries.
[0003] Based on publicly available documentation, the products currently supporting the Serverless Workflow specification include FunctionGraph and the open-source project Synapse. FunctionGraph claims compatibility with the CNCF Serverless Workflow specification, but due to its commercial closed-source nature, its internal implementation is unknown, making direct comparison impossible. Synapse currently does not implement function exception retry functionality.
[0004] There is currently no good solution for how to retry a Serverless workflow function when an exception occurs. Summary of the Invention
[0005] To solve the above-mentioned technical problems, or at least partially solve them, this application provides a method and apparatus for retrying abnormal processes in a serverless workflow function.
[0006] Firstly, this application provides a method for retrying serverless workflow functions in case of exceptions, the method comprising:
[0007] When an exception occurs in a function of a serverless workflow, the event carrying the exception information is obtained through the component's interface;
[0008] Through the interface, if the event is determined to meet the retry policy based on the exception information, a delayed message is sent to the delayed queue. The delayed message contains the event and an interface address carrying operation parameters, which are used to indicate the operation name corresponding to the function exception.
[0009] The retry processor in the component performs a retry task on the delayed message based on the event extension attributes and the exception information, wherein the retry processor has subscribed to the delay queue.
[0010] Optionally, the exception information includes a response code and a function exception name. Determining that the event meets the retry policy based on the exception information includes:
[0011] Determine whether a retry is needed based on the response code;
[0012] If it is determined that a retry is needed, the function exception name and retry threshold of the current operation are parsed from the serverless workflow definition based on the operation parameter values.
[0013] Determine whether a retry is needed based on the function exception name;
[0014] If it is determined that a retry is needed, determine whether the number of retries has exceeded the retry count threshold, wherein the number of retries is obtained based on the retry count extension attribute of the event;
[0015] If the number of retries has not exceeded the threshold, then the event is determined to meet the retry policy.
[0016] Optionally, after the number of retries has not exceeded the threshold, the method further includes:
[0017] Determine when to next execute the retry task;
[0018] Add 1 to the existing retry count extension attribute, whereby the retry count extension attribute is used to record the number of retries.
[0019] Optionally, the exception information also includes the request failure address, and performing a retry task on the delayed message based on the event extension attributes and the exception information includes:
[0020] Retry based on the event's extended attributes and the URL where the request failed;
[0021] If a retry fails, update the response code, function exception name, and request failure address; based on the event after updating the exception information, re-call the interface to determine whether the event satisfies the retry strategy;
[0022] If the retry is successful, the event is processed according to the serverless workflow.
[0023] Optionally, retrying based on the extended attributes of the event and the failed request address includes:
[0024] The retry processor obtains the current operation address, target operation address, and request failure address of the event, wherein the current operation address is used to record the function address of the current operation, the target operation address is used to record the address of the next channel or the final service of the event for the current operation, and the request failure address is used to record the address where the request failed.
[0025] If the request failure address is the same as the current operation address, then the event is sent to the current operation address; the event returned by the current operation address is sent to the target operation address.
[0026] If the request failure address is the same as the target operation address, then the event is sent to the target operation address.
[0027] Optionally, when a retry fails, updating the response code, function exception name, and failed request URL includes:
[0028] If the event fails to be sent to the current operation address or the target operation address, update the response code, function exception name, and request failure address.
[0029] Optionally, upon successful retry, processing the event according to the serverless workflow includes:
[0030] If the target operation address is empty, the request failure address is different from the target operation address, or the event is successfully sent to the target operation address, the event is processed according to the serverless workflow.
[0031] Secondly, a serverless workflow function exception retry system is provided, the system comprising:
[0032] An interface is used to retrieve an event carrying exception information when an exception occurs in a function of a serverless workflow; if the event meets the retry policy based on the exception information, a delayed message is sent to a delayed queue, wherein the delayed message contains the event and an interface address carrying operation parameters, the operation parameters being used to indicate the operation name corresponding to the function exception;
[0033] A retry processor is configured to perform a retry task on the delayed message based on the event extension attributes and the exception information, wherein the retry processor has subscribed to the delay queue.
[0034] Optionally, the system is independent of the serverless workflow.
[0035] Thirdly, a serverless workflow function exception retry device is provided, the device comprising:
[0036] The acquisition module is used to obtain events carrying exception information through the component's interface when an exception occurs in a function of a serverless workflow.
[0037] The sending module is used to send a delayed message to a delayed queue through the interface if the event meets the retry policy based on the exception information. The delayed message contains the event and an interface address carrying operation parameters, wherein the operation parameters are used to indicate the operation name corresponding to the function exception.
[0038] An execution module is configured to perform a retry task on the delayed message based on the event extension attributes and the exception information through a retry processor in the component, wherein the retry processor has subscribed to the delay queue.
[0039] Fourthly, an electronic device is provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0040] Memory, used to store computer programs;
[0041] When a processor executes a program stored in memory, it implements any of the steps of the serverless workflow function exception retry method described above.
[0042] Fifthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements any of the steps of the serverless workflow function exception retry method described above.
[0043] The technical solutions provided in this application have the following advantages compared with the prior art:
[0044] The method provided in this application involves the server sending an event with exception information to an interface. The interface determines that the event meets the retry policy and then sends a delay message to a delay queue. The retry processor executes the retry task based on the delay message. This application solves the problem in the prior art where Serverless workflow functions cannot be retried when exceptions occur. Attached Figure Description
[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.
[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0047] Figure 1 This is a block diagram of an exception retry system provided in an embodiment of this application;
[0048] Figure 2 A flowchart of a serverless workflow function exception retry method provided in this application embodiment;
[0049] Figure 3 This is a schematic diagram illustrating the Sequence definition provided in an embodiment of this application;
[0050] Figure 4 This is a schematic diagram of the internal structure of a Sequence provided in an embodiment of this application;
[0051] Figure 5 A flowchart illustrating the processing of the interface provided in the embodiments of this application;
[0052] Figure 6 A flowchart illustrating the retry worker process provided in this application embodiment;
[0053] Figure 7 This is a flowchart of the exception handling bypass provided in the embodiments of this application;
[0054] Figure 8 A schematic diagram of a serverless workflow function exception retry device provided in this application embodiment;
[0055] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0056] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0057] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustration and has no specific meaning in itself. Therefore, "module" and "part" may be used interchangeably.
[0058] To address the problems mentioned in the background art, according to one aspect of an embodiment of this application, the system includes a Proxy component, which includes an interface and a retry worker. The interface obtains an event carrying exception information from a Knative Channel. If it is determined that the event meets the retry policy, a delayed message is sent to a delayed queue, wherein the delayed message contains the address of the event and the interface. The retry worker has subscribed to the delayed queue and performs a retry task on the delayed message.
[0059] Figure 1 The diagram illustrates the exception retry system. The Knative Channel sends events with exception information to the ` / retry` interface of the Proxy component via a dead-letter sink. The ` / retry` interface determines if the event meets the retry policy. If so, it sends a delayed message to the message system's delayed queue. This message system needs to support delayed queues; Pulsar or the latest version of RocketMQ can be chosen. The retry worker subscribes to the delayed queue and executes a retry task upon receiving a delayed message. If the retry still fails, it calls the ` / retry` interface to initiate further retries.
[0060] A serverless workflow function exception retry method in this application embodiment can be executed by a component to retry the function when an exception occurs in the serverless workflow function.
[0061] The following will describe in detail, with reference to specific implementation methods, a serverless workflow function exception retry method provided in this application embodiment, such as... Figure 2 As shown, the specific steps are as follows:
[0062] Step 201: When an exception occurs in a function of the serverless workflow, obtain the event carrying the exception information through the component's interface.
[0063] In a serverless workflow, the functions corresponding to each action are orchestrated using sequential execution components (Sequences). When a function in a sequential execution component encounters an exception, a way to detect the exception is needed. Knative's Channel provides such a mechanism. Figure 3 This is a diagram illustrating the definition of a Sequence. A Sequence consists of three parts:
[0064] channelTemplate: Channel template, specifying the specific Channel implementation. Figure 1 (Not shown in the image).
[0065] steps: Define services that are executed sequentially, such as function services.
[0066] reply: Defines the target service to which the result of the last service step is forwarded; reply is optional and can be left undefined.
[0067] Figure 4 Is with Figure 3 A diagram showing the internal structure of the corresponding Sequence. From... Figure 4 As can be seen, for each step, there is a corresponding channel and a subscription. Events are stored in the channel, and the subscription acts as a bridge, retrieving events from the channel and forwarding them to the subscribers, which is the function service defined in the step. Below is... Figure 4 The execution flow of a Sequence:
[0068] When an event is sent to a Sequence, it is actually sent to channel 0.
[0069] Subscriber 0 retrieves the event from channel 0 and forwards the event to function 1;
[0070] Subscription 0 forwards the event returned by function 1 to channel 1;
[0071] Subscription 1 retrieves the event from channel 1 and forwards the event to function 2;
[0072] Subscription 1 forwards the event returned by function 2 to function 3;
[0073] If the Sequence does not define a reply, the event in step 5 is discarded.
[0074] As seen in the execution flow above, events need to be forwarded to functions, and then the events returned by the functions are forwarded to the next channel or reply. This event forwarding is actually an HTTP network request, and the network is unreliable; functions may also encounter errors. Sequence supports defining optional event delivery specifications for each step: retries and dead letter sinks. If event delivery still fails after retries, the event is sent to the dead letter sink.
[0075] This application provides a dead-letter sink, specifically the ` / retry` interface of the Proxy component. When a function encounters an exception, the Sequence sends the event to the ` / retry` interface corresponding to that function. The specific implementation of Knative Channel includes the subscription functionality; that is, the forwarding of events to the function service and the next channel or reply is handled by the Channel's specific implementation. If forwarding fails and a dead-letter sink is configured, the event will be forwarded to the dead-letter sink.
[0076] The exception information includes the knativeerrorcode response code, the knativeerrordata function exception name, and the knativeerrordest record of the address where the request failed.
[0077] This application cannot use the retry feature of the Knative event delivery specification for the following reasons:
[0078] 1. The Serverless Workflow specification defines a more robust and complex retry protocol than Knative's. While Knative's event delivery retry protocol can be expressed using Serverless Workflow's retry protocol, the reverse is not always possible. 2. The Serverless Workflow specification does not limit retry intervals, allowing for very long intervals. Knative Channel forwards events synchronously; excessively long retry intervals can block event forwarding for extended periods, impacting workflow performance. 3. The Serverless Workflow specification supports retries only for specified exceptions, while excluding other exceptions. If an action still fails after retries, it is handled according to the `onErrors` status definition. These are application-level retry logics; implementing them in Knative Channel contradicts the principles of layered software architecture.
[0079] Step 202: Through the interface, if the event meets the retry policy based on the exception information, send a delayed message to the delayed queue.
[0080] The delayed message contains the event and the interface address carrying operation parameters, which are used to indicate the operation name corresponding to the function exception.
[0081] The component uses an interface to determine whether an event meets the retry policy based on the exception information. If it does, a delayed message is sent to the delayed queue. The delayed message contains the event, the interface address, and the task ID. Specifically, the interface address is the / retry interface address carrying the actionname parameter (operation parameter). The actionname parameter is used to represent the name of the action (operation) to record which action the error originated from. The name of the action is unique within the workflow.
[0082] If the condition is not met, then the exception handling function is defined according to the onErrors property of the state.
[0083] Step 203: Perform a retry task on the delayed message based on the event extension attributes and exception information through the retry handler in the component.
[0084] The retry processor has subscribed to the delay queue.
[0085] In addition to the ` / retry` interface, the Proxy component also has a retry worker (retry handler) that subscribes to a delay queue. When the retry worker receives a delay message, it indicates that the retry task can be executed. If the retry worker succeeds, the workflow can continue. If the retry fails, it updates the exception information based on the event extension attributes and exception information, and then calls the interface again based on the updated exception information to determine whether the event meets the retry policy.
[0086] In this application, the server sends an event containing exception information to the interface. The interface determines that the event meets the retry policy and then sends a delayed message to the delayed queue. The retry processor executes the retry task based on the delayed message. This application solves the problem in existing technologies where Serverless workflow functions cannot be retried when exceptions occur.
[0087] As an optional implementation, the exception information includes a response code and a function exception name. Determining whether an event meets the retry policy based on the exception information includes: determining whether a retry is needed based on the response code; if a retry is needed, parsing the function exception name and retry count threshold of the current operation from the serverless workflow definition based on the operation parameter values; determining whether a retry is needed based on the function exception name; if a retry is needed, determining whether the number of retries has exceeded the retry count threshold, wherein the number of retries is obtained based on the event's retry count extension attribute; if the number of retries has not exceeded the threshold, then the event meets the retry policy.
[0088] The Knative Channel records exception information in the event's extended attributes. The server extracts the knativeerrorcode response code and knativeerrordata function exception name from the event's extended attributes, and determines the number of retries based on the event's wfretrycount extended attribute (retry count extended attribute).
[0089] The interface determines whether a retry is needed based on the response code. If no retry is needed, the exception is handled according to the onErrors definition of the status. If a retry is needed, the function exception name and retry threshold of the current operation are parsed from the serverless workflow definition based on the actionname parameter value.
[0090] The interface determines whether a retry is needed based on the function exception name. If no retry is needed, the exception is handled according to the onErrors definition of the status. If a retry is needed, it checks whether the number of retries has exceeded the retry threshold.
[0091] If the number of retries has not exceeded the retry threshold, then the event is deemed to meet the retry policy; if the number of retries has exceeded the threshold, then the exception is handled according to the onErrors definition of the status.
[0092] After the number of retries has not exceeded the threshold, the method further includes: determining the time when the retry task will be executed next; and incrementing the existing wfretrycount extended attribute by 1, where the retry count attribute is used to record the number of retries.
[0093] If the number of retries has not exceeded the retry threshold, the interface determines the time to execute the retry task next, and then executes the retry task at that time. The wfretrycount extended property in the event is used to record the number of retries. Each time the retry worker retryes, the existing retry count is incremented by 1.
[0094] Figure 5 This is a flowchart of the interface processing.
[0095] As an optional implementation, the exception information also includes the request failure address. Performing a retry task on the delayed message based on the event extension attributes and exception information includes: retrying based on the event extension attributes and the request failure address; updating the response code, function exception name, and request failure address when the retry fails; re-calling the interface to determine whether the event meets the retry policy based on the event after updating the exception information; and processing the event according to the serverless workflow when the retry succeeds.
[0096] This application adds two new extended properties to the event before forwarding it to the function service.
[0097] knativesubscriptiondest:destUrl, the current operation address, records the address of the function currently being operated on;
[0098] knativesubscriptionreply: replyUrl, the address where the request failed, records the address of the next channel or reply for the current operation; if there is no reply, the knativesubscriptionreply value of the last step is an empty string.
[0099] In the error message, `knativeerrordest`, or `targetUrl`, is the target operation address used to record the address where the request failed. If an error occurs when requesting the next channel or reply, `knativeerrordest` records the URL of the next channel or reply. If an error occurs when requesting a function service defined in the request step, `knativeerrordest` records the URL of the function service.
[0100] Without adding the two extended attributes mentioned above and only having `knativeerrordest`, it's necessary to parse `knativeerrordest` to determine whether the error is in a function, the next channel, or the reply. This parsing and judgment process requires prior knowledge of the structure of various addresses to make a correct judgment, which is not very convenient. Furthermore, if `knativeerrordest` indicates a function error, the address of the next channel or reply also needs to be known. This address can be constructed based on the specific implementation of the workflow state, which is also inconvenient. Adding the two extended attributes eliminates these two inconveniences.
[0101] The retry worker compares the failed request address with the extended attributes of the event to determine the address where the exception occurred, and then retryes for that address. In other words, by comparing targetUrl with destUrl and replyUrl, it can be determined which request failed. This application directly determines whether the error is due to a function error, a function return event forwarding to the next channel, or a reply error, without needing to parse knativeerrordest.
[0102] Figure 6The flowchart for retrying the worker is as follows: If targetUrl and destUrl are the same, the event is sent to destUrl. If the sending fails, it means destUrl has an error, so the event's knativeerrorcode, knativeerrordata, and knativeerrordest are updated. If the sending succeeds, it means destUrl is normal. Check if replyUrl is empty. If replyUrl is not empty, the event returned by destUrl is sent to replyUrl. If sending to replyUrl fails, the event's knativeerrorcode, knativeerrordata, and knativeerrordest are updated.
[0103] If targetUrl and destUrl are different, check if replyUrl is empty. If replyUrl is not empty and targetUrl and replyUrl are the same, send the event to replyUrl. If the event is not sent successfully, it means replyUrl has an error, so update the event's knativeerrorcode, knativeerrordata, and knativeerrordest.
[0104] When a problem occurs in `destUrl`, `knativeerrordata` is updated to the name of the function exception that caused the error; when a problem occurs in `replyUrl`, `knativeerrordata` is updated to empty to indicate that the function did not encounter an error.
[0105] knativeerrordest is updated to the address of the current exception.
[0106] With the updates of knativeerrorcode, knativeerrordata, and knativeerrordest, Figure 5 The response code, function exception name, and failed request address in the event extension attributes will also be updated accordingly, so that the interface can re-determine whether the event meets the retry strategy based on the updated exception information.
[0107] exist Figure 6 If replyUrl is empty, targetUrl is different from replyUrl, or the event was successfully sent to replyUrl, the event is processed according to the serverless workflow.
[0108] This application enhances the functionality of Knative Channel by adding two new extended properties, knativesubscriptiondest and knativesubscriptionreply, to the event before forwarding it to the function service. This makes it easier to determine where the exception occurred during retries and quickly locate the exception address.
[0109] Alternatively, the system is independent of the serverless workflow, and exception handling is a bypass process that is separate from the normal workflow process. This design has no impact on the normal execution performance of the workflow. Figure 7 This is a flowchart for exception handling bypass.
[0110] When defining a Sequence, specify the event delivery rules for each step of the Sequence (i.e., the function service corresponding to the action) as follows:
[0111] 1. Number of retries is 0
[0112] 2. The dead letter sink address is the / retry interface address of the Proxy component. This interface takes an actionname parameter, which represents the name of the action to record which action the error came from. The name of the action is unique within the workflow scope.
[0113] Based on the same technical concept, embodiments of this application also provide a serverless workflow function exception retry device, such as... Figure 8 As shown, the device includes:
[0114] The acquisition module 801 is used to obtain events carrying exception information through the component's interface when an exception occurs in a function of a serverless workflow.
[0115] The sending module 802 is used to send a delayed message to the delayed queue through the interface when the event meets the retry policy based on the exception information. The delayed message contains the event and the interface address carrying operation parameters. The operation parameters are used to indicate the operation name corresponding to the function exception.
[0116] Execution module 803 is used to perform retry tasks on delayed messages based on event extension attributes and exception information through a retry processor in the component, wherein the retry processor has subscribed to a delayed queue.
[0117] Optionally, the exception information includes a response code and a function exception name, and the sending module 802 is used for:
[0118] Determine whether a retry is needed based on the response code;
[0119] If it is determined that a retry is needed, the function exception name and retry threshold of the current operation are parsed from the serverless workflow definition based on the operation parameter values.
[0120] Determine whether a retry is needed based on the function exception name;
[0121] If it is determined that a retry is needed, determine whether the number of retries has exceeded the retry threshold, where the number of retries is obtained based on the event's retry count extension attribute;
[0122] If the number of retries has not exceeded the threshold, then the event is determined to meet the retry policy.
[0123] Optionally, the device is also used for:
[0124] Determine when to next execute the retry task;
[0125] Add 1 to the existing retry count extension property, which is used to record the number of retries.
[0126] Optionally, the execution module 803 is used for:
[0127] Retry based on the event's extended attributes and the URL where the request failed;
[0128] When a retry fails, update the response code, function exception name, and request failure address; based on the event after updating the exception information, re-call the interface to determine whether the event meets the retry policy;
[0129] When a retry is successful, the event is processed according to the serverless workflow.
[0130] Optionally, the execution module 803 is used for:
[0131] The retry processor obtains the current operation address, target operation address, and request failure address of the event. The current operation address is used to record the function address of the current operation, the target operation address is used to record the address of the next channel or the final service of the event for the current operation, and the request failure address is used to record the address where the request failed.
[0132] If the failed request address is the same as the current operation address, the event will be sent to the current operation address; if the event returned by the current operation address is sent to the target operation address.
[0133] If the request failure address is the same as the target operation address, the event will be sent to the target operation address.
[0134] Optionally, the execution module 803 is used for:
[0135] If the event fails to be sent to the current operation address or the target operation address, update the response code, function exception name, and the address where the request failed.
[0136] Optionally, the execution module 803 is used for:
[0137] If the target operation address is empty, the request failure address is different from the target operation address, or the event is successfully sent to the target operation address, the event is processed according to the serverless workflow.
[0138] Based on the same technical concept, embodiments of the present invention also provide an electronic device, such as... Figure 9 As shown, it includes a processor 901, a communication interface 902, a memory 903, and a communication bus 904, wherein the processor 901, the communication interface 902, and the memory 903 communicate with each other through the communication bus 904.
[0139] Memory 903 is used to store computer programs;
[0140] The processor 901 performs the above steps when executing the program stored in the memory 903.
[0141] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.
[0142] The communication interface is used for communication between the aforementioned electronic devices and other devices.
[0143] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0144] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0145] In another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the steps of any of the above methods.
[0146] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform any of the methods described above.
[0147] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).
[0148] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0149] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.
Claims
1. A method for retrying exceptions in a serverless workflow function, characterized in that, The method includes: When an exception occurs in a function of a serverless workflow, the event carrying the exception information is obtained through the component's interface; Through the interface, if the event is determined to meet the retry policy based on the exception information, a delayed message is sent to the delayed queue. The delayed message contains the event and an interface address carrying operation parameters, which are used to indicate the operation name corresponding to the function exception. The retry processor in the component performs a retry task on the delayed message based on the event extension attribute and the exception information, wherein the retry processor has subscribed to the delay queue; The exception information also includes the request failure address. Performing a retry task on the delayed message based on the event extension attributes and the exception information includes: Retry based on the event's extended attributes and the URL where the request failed; If a retry fails, update the response code, function exception name, and request failure address; based on the event after updating the exception information, re-call the interface to determine whether the event satisfies the retry strategy; Upon successful retry, the event is processed according to the serverless workflow. The retrying based on the extended attributes of the event and the failed request address includes: The retry processor obtains the current operation address, target operation address, and request failure address of the event. The current operation address is used to record the function address of the current operation, the target operation address is used to record the address of the next channel or the final service of the event for the current operation, and the request failure address is used to record the address where the request failed. If the request failure address is the same as the current operation address, then the event is sent to the current operation address; the event returned by the current operation address is sent to the target operation address. If the request failure address is the same as the target operation address, then the event is sent to the target operation address.
2. The method according to claim 1, characterized in that, The exception information includes a response code and a function exception name. Determining that the event meets the retry policy based on the exception information includes: Determine whether a retry is needed based on the response code; If it is determined that a retry is needed, the function exception name and retry threshold of the current operation are parsed from the serverless workflow definition based on the operation parameter values. Determine whether a retry is needed based on the function exception name; If it is determined that a retry is needed, determine whether the number of retries has exceeded the retry count threshold, wherein the number of retries is obtained based on the retry count extension attribute of the event; If the number of retries has not exceeded the threshold, then the event is determined to meet the retry policy.
3. The method according to claim 2, characterized in that, After the number of retries has not exceeded the threshold, the method further includes: Determine when to next execute the retry task; Add 1 to the existing retry count extension attribute, whereby the retry count extension attribute is used to record the number of retries.
4. The method according to claim 1, characterized in that, When a retry fails, update the response code, function exception name, and failed request URL, including: If the event fails to be sent to the current operation address or the target operation address, update the response code, function exception name, and request failure address.
5. The method according to claim 1, characterized in that, Upon successful retry, the event is processed according to the serverless workflow, including: If the target operation address is empty, the request failure address is different from the target operation address, or the event is successfully sent to the target operation address, the event is processed according to the serverless workflow.
6. A serverless workflow function exception retry system, characterized in that, The system includes: An interface is used to retrieve an event carrying exception information when an exception occurs in a function of a serverless workflow; if the event meets the retry policy based on the exception information, a delayed message is sent to a delayed queue, wherein the delayed message contains the event and an interface address carrying operation parameters, the operation parameters being used to indicate the operation name corresponding to the function exception; A retry processor is configured to perform a retry task on the delayed message based on the event extension attributes and the exception information, wherein the retry processor has subscribed to the delay queue; The exception information also includes the address where the request failed, and the retry processor is further used for: Retry based on the event's extended attributes and the URL where the request failed; If a retry fails, update the response code, function exception name, and request failure address; based on the event after updating the exception information, re-call the interface to determine whether the event satisfies the retry strategy; Upon successful retry, the event is processed according to the serverless workflow. Specifically, the retry processor is used for: The retry processor obtains the current operation address, target operation address, and request failure address of the event. The current operation address is used to record the function address of the current operation, the target operation address is used to record the address of the next channel or the final service of the event for the current operation, and the request failure address is used to record the address where the request failed. If the request failure address is the same as the current operation address, then the event is sent to the current operation address; the event returned by the current operation address is sent to the target operation address. If the request failure address is the same as the target operation address, then the event is sent to the target operation address.
7. The system according to claim 6, characterized in that, The system is independent of serverless workflows.
8. A serverless workflow function exception retry device, characterized in that, The device includes: The acquisition module is used to obtain events carrying exception information through the component's interface when an exception occurs in a function of a serverless workflow. The sending module is used to send a delayed message to a delayed queue through the interface if the event meets the retry policy based on the exception information. The delayed message contains the event and an interface address carrying operation parameters, wherein the operation parameters are used to indicate the operation name corresponding to the function exception. An execution module is configured to perform a retry task on the delayed message based on the event extension attributes and the exception information through a retry processor in the component, wherein the retry processor has subscribed to the delay queue; The exception information also includes the request failure address, and the execution module is used to: Retry based on the event's extended attributes and the URL where the request failed; If a retry fails, update the response code, function exception name, and request failure address; based on the event after updating the exception information, re-call the interface to determine whether the event satisfies the retry strategy; Upon successful retry, the event is processed according to the serverless workflow. Specifically, the execution module is used for: The retry processor obtains the current operation address, target operation address, and request failure address of the event. The current operation address is used to record the function address of the current operation, the target operation address is used to record the address of the next channel or the final service of the event for the current operation, and the request failure address is used to record the address where the request failed. If the request failure address is the same as the current operation address, then the event is sent to the current operation address; the event returned by the current operation address is sent to the target operation address. If the request failure address is the same as the target operation address, then the event is sent to the target operation address.
9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-5.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-5.