Multi-version compatible request processing method and device, equipment and readable storage medium

Abstract

The application discloses a multi-version compatible request processing method and device, equipment and a readable storage medium, and the method comprises the steps of receiving and analyzing a target request to obtain a compatible condition corresponding to the target request; checking whether the compatible condition has a version compatibility requirement; if the compatible condition has a version compatibility requirement, determining a target call chain for processing the target request; the target call chain comprises a call sequence and a target node method, and at least two node methods in the target node method correspond to different version processing flows; according to the call sequence, the target node method is executed to obtain a return result. According to the application, only the node method in the call chain is matched with the different version processing flows, so that the version compatibility can be realized, and the system complexity caused by the version compatibility can be reduced; since the node method is matched with the different version processing flows, not only the request entry and processing method of high and low versions can be kept consistent, the code redundancy caused by the version compatibility can be reduced, but also the bidirectional compatibility can be realized.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a multi-version compatible request processing method, apparatus, device, and readable storage medium. Background Technology

[0002] Typically, applications are constantly being updated and iterated. As a result, the number of application versions increases, making compatibility with different versions a problem that cannot be ignored.

[0003] Adding hierarchical levels to URL (Uniform Resource Locator) directories can enable version compatibility for web applications. However, this compatibility solution increases gateway complexity, has a wide-ranging impact on version compatibility, and adds redundant code.

[0004] In conclusion, how to effectively solve problems such as version compatibility is a technical issue that urgently needs to be addressed by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a multi-version compatible request processing method, apparatus, device, and readable storage medium. Version compatibility is achieved through a call chain, without adjusting the gateway and without affecting the gateway complexity. Since the node methods in the target node method that processes the target request can correspond to different version processing flows, the request entry point and processing method of high and low versions can be kept consistent. This not only reduces code redundancy caused by version compatibility, but also achieves bidirectional compatibility and reduces compatibility costs.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] Firstly, this application provides a multi-version compatible request processing method, including:

[0008] Receive and parse the target request to obtain the compatibility conditions corresponding to the target request;

[0009] Verify whether the compatibility conditions have version compatibility requirements;

[0010] If the compatibility conditions require version compatibility, then the target call chain for processing the target request is determined; wherein, the target call chain includes the call sequence and the target node method, and at least two node methods in the target node method correspond to different versions of the processing flow;

[0011] The target node method is executed according to the call sequence, and the return result is obtained.

[0012] In one specific embodiment of this application,

[0013] According to the aforementioned call sequence, the target node method is executed, and the return result is obtained, including:

[0014] Execute the current node method in the target node method;

[0015] If the execution is successful, the current node method is re-determined from the target node method according to the call sequence.

[0016] If execution fails, the execution of the target node method will be interrupted;

[0017] The return result is obtained after the target node method has been executed.

[0018] In one specific embodiment of this application, executing the current node method in the target node method includes:

[0019] Determine whether the current node method has a corresponding node call chain; the node call chain includes: node call sequence and child node methods;

[0020] If so, the child node method is executed according to the node invocation sequence;

[0021] If not, then the current node method will be executed directly.

[0022] In one specific embodiment of this application, executing the current node method in the target node method includes:

[0023] The current node method is executed using the target executor, wherein the target executor corresponds to the version of the current node method.

[0024] In one specific embodiment of this application, before verifying whether the compatibility conditions require version compatibility, the method further includes:

[0025] Perform business logic validation on the target request to obtain the logic validation result;

[0026] If the logical verification result does not correspond to the version compatibility requirement, the processing of the target request will be terminated;

[0027] If the logical verification result corresponds to a version compatibility requirement, then determine whether to perform the step of verifying whether the compatibility condition has a version compatibility requirement.

[0028] In one specific embodiment of this application, verifying whether the compatibility conditions require version compatibility includes:

[0029] Based on the compatibility conditions, the set of verification methods is obtained through reflection.

[0030] Based on the verification annotations, the target verification method is determined from the set of verification methods;

[0031] The target verification method is executed to verify the compatibility conditions;

[0032] If the verification passes, it is determined that the compatibility conditions have version compatibility requirements;

[0033] If the verification fails, it is determined that the compatibility conditions do not require version compatibility.

[0034] In one specific embodiment of this application, after determining that the compatibility conditions have no version compatibility requirements, the method further includes:

[0035] An exception is thrown, and the processing of the target request is terminated.

[0036] In one specific embodiment of this application, determining the target call chain for processing the target request includes:

[0037] The compatibility conditions are used as input parameters, and the corresponding executor is retrieved based on the dependency injection annotation declared by the executor.

[0038] The default processing method of the executor is invoked to obtain the target call chain.

[0039] In one specific embodiment of this application, the default processing method of the executor is invoked to obtain the target call chain, including:

[0040] Based on the compatibility conditions, the target call chain corresponding to the executor is obtained by reflection; the target call chain corresponds to the compatible method, and the compatible method corresponds to a directed graph structure.

[0041] In one specific embodiment of this application, obtaining the target call chain corresponding to the executor by reflection according to the compatibility conditions includes:

[0042] Using the compatibility key value in the compatibility condition, the target call chain that processes the target request is retrieved from the call chain set.

[0043] In one specific embodiment of this application, the target call chain for processing the target request is retrieved from the call chain set using the compatibility key value in the compatibility conditions, including:

[0044] Retrieve the main call chain corresponding to the compatible key value from the call chain set;

[0045] If the main call chain exists and its state is available, then the main call chain is determined as the target call chain;

[0046] If the main call chain does not exist and / or is unavailable, then the backup call chain corresponding to the main call chain is determined as the target call chain.

[0047] In one specific embodiment of this application, querying the main call chain corresponding to the compatible key value from the call chain set includes:

[0048] By utilizing the mapping relationship between key values ​​and call chains in the call chain annotation, the main call chain corresponding to the compatible key value is queried from the call chain set.

[0049] Secondly, this application provides a multi-version compatible request processing apparatus, comprising:

[0050] The request interface is used to receive and parse the target request to obtain the compatibility conditions corresponding to the target request.

[0051] A verifier is used to verify whether the compatibility conditions have version compatibility requirements;

[0052] A router is configured to determine a target call chain for processing the target request if the compatibility conditions require version compatibility; wherein the target call chain includes a call sequence and target node methods, and at least two node methods in the target node methods correspond to different versions of the processing flow;

[0053] An executor is used to execute the target node method according to the invocation sequence and obtain the return result.

[0054] Thirdly, this application provides an electronic device, comprising:

[0055] Memory, used to store computer programs;

[0056] A processor for implementing the above-described multi-version compatible request processing method when executing the computer program.

[0057] Fourthly, this application provides a readable storage medium storing a computer program, which, when executed by an executor, implements the steps of the aforementioned multi-version compatible request processing method.

[0058] The method provided in this application embodiment is used to receive and parse a target request to obtain the compatibility conditions corresponding to the target request; verify whether the compatibility conditions have version compatibility requirements; if the compatibility conditions have version compatibility requirements, determine the target call chain for processing the target request; wherein, the target call chain includes a call sequence and target node methods, and at least two node methods in the target node methods correspond to different versions of the processing flow; according to the call sequence, the target node methods are executed to obtain the return result.

[0059] In this application, when the compatibility condition table of the target request explicitly indicates a version compatibility requirement, the target call chain for processing the target request can be determined. It is important to note that in this application, the target call chain includes the call sequence and target node methods, and at least two of the target node methods correspond to different version processing flows. Then, according to this call sequence, the target node methods can be executed, thereby obtaining the return result. Therefore, in this application, when processing target requests with version compatibility requirements, different version processing flows can be used, thus achieving version compatibility. Compared to version compatibility solutions that rely on URLs, this application only requires modifying the call chain in the business system to make the node methods in the call chain correspond to the processing flow of different versions, thus achieving version compatibility. This avoids affecting systems or devices outside the business system and reduces the system complexity caused by version compatibility. Since the node methods that process the target request can correspond to different version processing flows, it not only maintains the consistency of request entry points and processing methods between high and low versions, reducing code redundancy caused by version compatibility, but also achieves bidirectional compatibility, meaning that low-version requests can use high-version processing flows, and high-version requests can also use low-version processing flows, thus reducing compatibility costs.

[0060] Accordingly, embodiments of this application also provide multi-version compatible request processing apparatus, devices, and readable storage media corresponding to the above-described multi-version compatible request processing method, which have the above-described technical effects, and will not be repeated here. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 This is a flowchart illustrating the implementation of a multi-version compatible request processing method in this application.

[0063] Figure 2 This is a schematic diagram of a call chain definition in an embodiment of this application;

[0064] Figure 3 This is a schematic diagram of a target call chain in an embodiment of this application;

[0065] Figure 4 This is a schematic diagram of another call chain in an embodiment of this application;

[0066] Figure 5This is a schematic diagram of the structure of a multi-version compatible request processing device according to an embodiment of this application;

[0067] Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0068] Figure 7 This is a schematic diagram of the specific structure of an electronic device in an embodiment of this application. Detailed Implementation

[0069] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0070] This application provides a multi-version compatible request processing method that enables compatibility between different versions. The application achieving version compatibility can be a common application, such as a web application, or other common applications. This application does not limit the specific application for achieving version compatibility. This method can be specifically applied to electronic devices (such as servers), service platforms, or devices corresponding to applications requiring version compatibility. When applied to a device, the specific structure of the device can refer to the multi-version compatible request processing device provided in this application; when applied to an electronic device, the specific structure of the electronic device can refer to the electronic device provided in this application.

[0071] Please refer to Figure 1 , Figure 1 This is a flowchart of a multi-version compatible request processing method according to an embodiment of this application. The method includes the following steps:

[0072] S101. Receive and parse the target request to obtain the compatibility conditions corresponding to the target request.

[0073] You can receive target requests sent by clients through the request interface. After receiving the target request, you can then parse it.

[0074] In this embodiment, the compatibility conditions corresponding to the target request can be obtained by parsing the target request. The target request can be labeled with compatibility conditions, meaning it inherently carries the corresponding compatibility conditions. Alternatively, the compatibility conditions corresponding to the receiving method can be obtained by parsing the specific method of receiving the target request. These compatibility conditions can specifically include compatibility condition content, or they can be a string or parameter that determines the compatibility condition content. The compatibility condition content can specifically be the requirement to be compatible with a certain version of a certain processing method, or a compatibility key-value tag indicating which versions and methods are required for processing the target request.

[0075] It should be noted that in this embodiment, all requests to the application may include target requests with compatibility conditions, as well as other requests without compatibility conditions. For other requests without compatibility conditions, the relevant request processing flow can be referred to; that is, this embodiment does not limit the specific processing flow corresponding to other requests without compatibility conditions.

[0076] S102. Verify whether there are version compatibility requirements.

[0077] After obtaining the compatibility conditions corresponding to the target request, it is possible to further verify whether the compatibility conditions do indeed have version compatibility requirements, that is, to determine whether processing the target request requires compatibility with different versions.

[0078] Specifically, in this embodiment, a compatibility verification method can be pre-set. After obtaining the compatibility conditions, the version compatibility requirements of the compatibility conditions can be verified according to the compatibility verification method.

[0079] S103. If there is a version compatibility requirement, then determine the target call chain for processing the target request.

[0080] The target call chain includes the call sequence and the target node method. At least two node methods in the target node method correspond to different versions of the processing flow.

[0081] If there is indeed a version compatibility requirement, the target call chain for handling the target request can be determined.

[0082] In this context, the call chain refers to the sequence (call sequence) and node methods of the methods executed by the server corresponding to a business operation, from receiving and processing the request to receiving the return parameters (i.e., the feedback result corresponding to the request). There are no duplicate node methods in the call chain, and each node method corresponds to one processing flow. Typically, the processing flows corresponding to node methods in a call chain belong to the same application version. However, in this embodiment, there are several node methods in the target call chain, and at least two of these node methods correspond to two different versions of the processing flow. That is, there will be at least two different versions of the processing flow corresponding to each target node method in the target call chain. Specifically, the target node method corresponds to all node methods in the target call chain. In this embodiment, the target node method includes at least two node methods; that is, the target node method can correspond to two node methods, three node methods, or more than three node methods.

[0083] It is important to note that in this embodiment, at least two node methods in the target node method correspond to different processing flows. For example, if the target call chain includes node method 1 and node method 2, then the target node method includes node method 1 and node method 2, where node method 1 corresponds to the processing flow of version 1, and node method 2 corresponds to the processing flow of version 2. Alternatively, if the target call chain specifically includes node method 1, node method 2, and node method 3, then the target node includes node method 1, node method 2, and node method 3, where node method 1 corresponds to the processing flow of version 1, node method 2 corresponds to the processing flow of version 2, and node method 3 corresponds to the processing flow of version 1 or 2.

[0084] In this embodiment, to facilitate the description of the call sequence, node methods, and versions of the node methods in the call chain, the Mi-j-Vk format can be used to represent each node method. Specifically, Mi represents the method name, j represents the execution order, and Vk represents the method version. For example, M1-2-V3 means that the method name is M1, the execution order is 2, and the method version is V3. Accordingly, a call chain is represented by at least two Mi-j-Vk sequences, such as M1-1-V2, M2-2-V1, and M1-3-V1.

[0085] Specifically, the target call chain is the call chain capable of handling the target request. In this embodiment, multiple call chains can be pre-set. Then, upon receiving the target request and determining that the target request has version compatibility requirements, the target call chain capable of handling the target request is selected from these call chains. Specifically, the method for selecting the target call chain can refer to the methods for selecting general call chains in related technologies. Of course, methods other than those for selecting general call chains can also be used to select the target call chain.

[0086] S104. Execute the target node method according to the call sequence and obtain the return result.

[0087] Once the target call chain for processing the target request is clearly defined, the target node method can be executed according to the call sequence of that chain to obtain the return result. Specifically, after the target node method completes its execution, the return result can be populated into the request context, from which the user can then retrieve the result for further processing or continue processing.

[0088] For example: If the target node methods in the target call chain include M1-1-V2, M2-2-V1, and M1-3-V1, it means that three node methods need to be executed. Specifically, the M1 method corresponding to version 2 is executed first, then the M2 method corresponding to version 1 is executed, and finally the M1 method corresponding to version 1 is executed.

[0089] The method provided in this application embodiment is used to receive and parse a target request to obtain the compatibility conditions corresponding to the target request; verify whether the compatibility conditions have version compatibility requirements; if the compatibility conditions have version compatibility requirements, determine the target call chain for processing the target request; wherein, the target call chain includes a call sequence and target node methods, and at least two node methods in the target node methods correspond to different versions of the processing flow; according to the call sequence, the target node methods are executed to obtain the return result.

[0090] In this application, when the compatibility condition table of the target request explicitly indicates a version compatibility requirement, the target call chain for processing the target request can be determined. It is important to note that in this application, the target call chain includes the call sequence and target node methods, and at least two of the target node methods correspond to different version processing flows. Then, according to this call sequence, the target node methods can be executed, thereby obtaining the return result. Therefore, in this application, when processing target requests with version compatibility requirements, different version processing flows can be used, thus achieving version compatibility. Compared to version compatibility solutions that rely on URLs, this application only requires modifying the call chain in the business system to make the node methods in the call chain correspond to the processing flow of different versions, thus achieving version compatibility. This avoids affecting systems or devices outside the business system and reduces the system complexity caused by version compatibility. Since the node methods that process the target request can correspond to different version processing flows, it not only maintains the consistency of request entry points and processing methods between high and low versions, reducing code redundancy caused by version compatibility, but also achieves bidirectional compatibility, meaning that low-version requests can use high-version processing flows, and high-version requests can also use low-version processing flows, thus reducing compatibility costs.

[0091] It should be noted that, based on the above embodiments, the embodiments of this application also provide corresponding improvement schemes. In the preferred / improved embodiments, the same or corresponding steps as in the above embodiments can be referred to each other, and the corresponding beneficial effects can also be referred to each other; however, these will not be elaborated upon in the preferred / improved embodiments herein.

[0092] In one specific embodiment of this application, considering the possibility of node method execution failure, to avoid long waiting times due to node method failure, consuming computing resources, or continuing to execute subsequent node methods resulting in error feedback, the node method execution flow can be interrupted in a timely manner when a node method fails. When a node method executes successfully, the next node method is executed according to the calling sequence. That is, step S104 above can specifically include:

[0093] Step 1: Execute the current node method within the target node's method;

[0094] Step 2: If the execution is successful, then determine the current node method from the target node method according to the call sequence;

[0095] Step 3: If execution fails, interrupt the execution of the target node method;

[0096] Step 4: After the method on the target node has finished executing, the return result is obtained.

[0097] The current node method can be the first node method in the target node method, or it can be a node method that is re-determined from the target node method according to the call sequence after some node methods have been executed. In other words, each node method in the target node method will become the current node method in turn according to the call sequence. Of course, if it is not the first node method, it becomes the current node method only if the previous node method has been successfully executed.

[0098] In other words, if the execution of the current node method fails according to the call sequence, the processing of the target request is interrupted. Only if the current node method executes successfully will the current node method be re-determined from the target node methods and execution continue until the target node method has been completed (i.e., all node methods in the target node method have been executed). For example, for the target call chain corresponding to M1-1-V2, M2-2-V1, M1-3-V1, if the execution of M2-2-V1 fails, the execution process can be directly interrupted, that is, M1-3-V1 will no longer be processed in sequence. If M2-2-V1 executes successfully, then M1-3-V1 can be determined as the current node method and executed.

[0099] Preferably, step one above, executing the current node method in the target node method, can specifically include: using the target executor to execute the current node method; wherein the target executor corresponds to the version of the current node method. It should be noted that for node methods of the same version, the corresponding target executor can be the same. That is, when executing the current node method, the target executor corresponding to that current node method can be directly used. For example, if the target call chain includes 5 node methods, each node method corresponding to a target executor, where node methods 1 and 2 correspond to target executor 1, and node methods 3 to 5 correspond to target executor 2, then target executor 1 is used to execute node methods 1 and 2 sequentially, and target executor 2 executes node methods 3 to 5. In this way, different versions of executors can be used for the corresponding node methods, reducing the code required to ensure compatibility with methods at different stages.

[0100] Considering that in practical applications, a node method in a call chain may also correspond to a call chain, meaning that a node method has a corresponding sub-method, the specific execution process of step one above can also include:

[0101] Step 1: Determine whether the current node method has a corresponding node call chain; the node call chain includes: the node call sequence and child node methods;

[0102] Step 2: If so, execute the child node methods according to the node call sequence;

[0103] Step 3: If not, execute the current node's method directly.

[0104] In other words, when executing the current node method, it's necessary to determine if it has a corresponding node call chain. This node call chain can be identical to a regular call chain, or it can be similar to the target call chain, including different versions of the corresponding node methods. For clarity, we'll refer to the call chain corresponding to the current node method as the node call chain. If the current node method has a node call chain, the child node methods are executed according to the node call sequence. If the current node method doesn't have a node call chain, it can be executed directly. In this way, the node call chain can be considered as the node methods in the target call chain, allowing for more complex business logic to be implemented while minimizing code size and logical complexity, thus meeting a wider range of business needs.

[0105] In one specific embodiment of this application, before performing step S102 to verify whether there is a version compatibility requirement, the request can be filtered to achieve a rapid response. The specific implementation process includes:

[0106] Step 1: Perform business logic validation on the target request and obtain the validation results;

[0107] Step 2: If the logical verification result does not correspond to the version compatibility requirements, then terminate the processing of the target request.

[0108] Step 3: If the logical verification result corresponds to version compatibility requirements, then determine whether there are version compatibility requirements for performing the verification compatibility conditions.

[0109] For ease of description, the three steps above will be used in combination below.

[0110] In this application, a custom validator and corresponding business validation logic can be defined. Specifically, the business validation logic can perform authentication, security verification, and version compatibility verification on the target request. After performing business logic validation on the target request, a validation result is obtained. If the validation result corresponds to a version compatibility requirement, it can be verified whether the compatibility condition has a version compatibility requirement; if the validation result does not correspond to a version compatibility requirement, it can be determined that the target request is abnormal, the processing of the target request can be terminated, and a request error can be reported. In other words, the version compatibility requirement can be verified only if the validation result corresponding to the business logic validation matches the version compatibility requirement. Thus, when the target request is abnormal, processing can be terminated in advance for a rapid response, and it also ensures that the version compatibility requirement verification of the compatibility condition is necessary, reducing the average processing time of the request.

[0111] In one specific embodiment of this application, step S102, verifying whether the compatibility conditions require version compatibility, includes:

[0112] Step 1: Based on compatibility conditions, use reflection to obtain the set of verification methods;

[0113] Step 2: Based on the verification annotations, determine the target verification method from the set of verification methods;

[0114] Step 3: Perform the target verification method to verify the compatibility conditions;

[0115] Step 4: If the verification passes, it is determined that there is a version compatibility requirement.

[0116] Step 5: If the verification fails, it is determined that there is no version compatibility requirement.

[0117] For ease of description, the above five steps will be explained in combination below.

[0118] Specifically, a validator can be used to retrieve a set of validation methods via reflection based on the compatibility conditions in the parsing context. Then, based on the validation annotation (@MTDVersion annotation), the target validation method is retrieved from the validation method set and executed. If the validation passes, it indicates that the compatibility conditions have version compatibility requirements, meaning the target request does not have version compatibility requirements; otherwise, it indicates that the compatibility conditions do not have version compatibility requirements, meaning the target request does not have version compatibility requirements.

[0119] Reflection, in this context, refers to obtaining content through the reflection mechanism. Specifically, Java reflection allows, at runtime, all attributes and methods of any class to be known; and any method and attribute of any object to be invoked. This dynamic acquisition of information and dynamic invocation of object methods is called Java's reflection mechanism. Using Java's reflection mechanism can be done by following these steps:

[0120] Step 1: Obtain the Class object of the class you want to manipulate;

[0121] Step 2: Use the Class object obtained in Step 1 to retrieve the names of the methods or properties of the class being operated on;

[0122] Step 3: Perform the operation on the method or attribute obtained in step 2.

[0123] Furthermore, regarding how to obtain the set of validation methods through reflection, please refer to the implementation process of obtaining content, objects, or object properties through reflection, which will not be elaborated here.

[0124] It's important to note that to improve request processing efficiency and quickly identify the exception, once it's determined that there are no version compatibility requirements, an exception can be thrown, terminating the processing of the target request. Throwing an exception (`throwException`) refers to a programmatic action in Java. If a method doesn't catch a potential exception, other methods that call that method should catch and handle it. To explicitly specify that a method should not catch a certain type of exception, but instead allow other methods that call it to catch it, the `throws` option can be used when defining the method to throw that type of exception.

[0125] In other words, if the version compatibility requirement verification fails, the validator can throw an exception, allowing other methods that call this method to catch and handle the exception, terminate the call, and directly return the result (such as a message indicating that the version compatibility requirement verification failed).

[0126] In one specific embodiment of this application, step S103 determines the target call chain for processing the target request, including:

[0127] Step 1: Use compatibility conditions as input parameters and retrieve the corresponding executor based on the dependency injection annotation declared by the executor;

[0128] Step 2: Call the executor's default processing method to obtain the target call chain.

[0129] For ease of description, the two steps described above will be combined below.

[0130] In this embodiment, the input parameter is the parameter value required by the called function. That is, the compatibility condition is used as the input parameter, and then the corresponding executor is retrieved according to the dependency injection annotation (@Resource annotation) declared by the executor, and the default processing method of the executor is called, finally obtaining the target call chain. Here, dependency injection annotation means that the annotation method is dependency injection.

[0131] Specifically, step two above may include, based on compatibility conditions, retrieving the target call chain corresponding to the executor via reflection; the target call chain corresponds to the compatible method, and the compatible method corresponds to a directed graph structure. Specifically, in this application, as... Figure 2 As shown, parameters for each call chain can be predefined, such as compatibility keywords, specified call chain, call chain ID, compatibility key (compatibility key-value pair), compatibility VAL (compatibility version), compatibility scheme, and specific operation (i.e., details shown in the diagram). The target call chain corresponds to the compatibility method, which has a directed graph structure. For example: Figure 3As shown, a target call chain includes four node methods in sequence, and the directed arrows between the nodes represent the call sequence. M1-V1 corresponds to a method named M1 in version V1; M2-V3 corresponds to a method named M2 in version V3; M3-V1 corresponds to a method named M1 in version V1; and M4-V3 corresponds to a method named M4 in version V3.

[0132] When the compatibility condition specifically includes a compatibility key value, the target call chain corresponding to the executor is obtained through reflection based on the compatibility condition. Specifically, the target call chain for processing the target request is retrieved from the call chain set using the compatibility key value in the compatibility condition. In other words, the target call chain can be retrieved from the call chain set based on the compatibility key.

[0133] Preferably, to prevent business processing exceptions caused by the absence of methods, a primary and backup call chain can be set when defining each call chain. That is, when a new call chain is published, a backup call chain (referred to as the backup call chain or standby chain) must be specified. When a node method (or primary chain node) in the primary call chain (referred to as the primary chain) is removed or the primary chain becomes unavailable, the primary chain is automatically downgraded to a backup chain. When using primary and backup chains, creating or modifying the primary chain is not allowed. Any changes to the backup chain require the corresponding primary chain to be unavailable. The correspondence between primary and backup chains is one-to-one. Methods declared in the primary and backup chains cannot be deleted (a check to see if the method has been deleted can be performed at startup).

[0134] Thus, in the above embodiments, using the compatibility key value in the compatibility condition to query the target call chain for processing the target request from the call chain set includes:

[0135] Step 1: Query the main call chain corresponding to the compatible key value from the call chain set;

[0136] Step 2: If the main call chain exists and its state is available, then the main call chain is determined as the target call chain;

[0137] Step 3: If the main call chain does not exist and / or is unavailable, then the backup call chain corresponding to the main call chain is determined as the target call chain.

[0138] For ease of description, the above three steps will be described together below.

[0139] In this embodiment, after querying the main call chain based on the compatible key-value pair, the first step is to determine whether the main call chain exists and whether its corresponding state is available. If the main call chain can be found, it indicates that the main call chain exists; if it is not found, it indicates that the main call chain does not exist. The availability of the main call chain's state can be determined based on its state label, or by checking if all its corresponding main chain methods are present; if any are missing, the main call chain's state is considered unavailable. The main call chain is identified as the target call chain only if its state is available and it exists. If the main call chain's state is unavailable, or it does not exist, or if both its state and state are unavailable, the backup call chain corresponding to the main call chain can be directly identified as the target call chain.

[0140] Step 1, which involves querying the main call chain corresponding to the compatible key value from the call chain set, includes: using the mapping relationship between key values ​​and call chains in the call chain annotation (@BusinessLine annotation), querying the main call chain corresponding to the compatible key value from the call chain set.

[0141] For example: Figure 4 As shown, the user uses `@BusinessLine(value = {"BL1", "BL2", "BL3", "BL4"})` at the Controller (the entry function for receiving requests). The four lines in the diagram indicate that the compatible method (call chain) has four compatible versions. During class loading, the device will parse methods declared with this annotation. Figure 4 The example shown will extract the call chain mapping relationship of BL1-4, extract the compatibility key and compatibility rules (>=, <=, contain, etc.) of each call chain, and assemble them into a Map. When a request arrives, the call sequence and version of each node corresponding to the call chain will be retrieved from the Map based on the compatibility key value. Figure 4 The solid lines in the code correspond to M1-1-V1, M2-2-V1, M3-3-V4, and M4-4-V1, indicating that the current target request needs to be handled using this call chain. The executor then retrieves the corresponding compatible methods for each node based on the @MTDVersion annotation, executes them in sequence, and returns the results.

[0142] After the executor finishes execution, it will fill the request context with the returned result (the executor class will declare IN and OUT generics). The user can retrieve the result from the context for further processing or continue processing.

[0143] Corresponding to the above method embodiments, this application also provides a multi-version compatible request processing apparatus. The multi-version compatible request processing apparatus described below and the multi-version compatible request processing method described above can be referred to in correspondence.

[0144] See Figure 5 As shown, the device includes the following modules:

[0145] Request interface 101 is used to receive and parse the target request to obtain the compatibility conditions corresponding to the target request.

[0146] Verifier 102 is used to verify whether the compatibility conditions have version compatibility requirements;

[0147] Router 103 is used to determine the target call chain for processing the target request if there is a version compatibility requirement; wherein the target call chain includes the call sequence and the target node method, and at least two node methods in the target node method correspond to different versions of the processing flow;

[0148] Executor 104 is used to execute the target node method according to the call sequence and obtain the return result.

[0149] Using the apparatus provided in the embodiments of this application, a target request is received and parsed to obtain the compatibility conditions corresponding to the target request; it is verified whether the compatibility conditions have version compatibility requirements; if the compatibility conditions have version compatibility requirements, the target call chain for processing the target request is determined; wherein, the target call chain includes the call sequence and the target node method, and at least two node methods in the target node method correspond to different versions of the processing flow; the target node method is executed according to the call sequence to obtain the return result.

[0150] In this application, when the compatibility condition table of the target request explicitly indicates a version compatibility requirement, the target call chain for processing the target request can be determined. It is important to note that in this application, the target call chain includes the call sequence and target node methods, and at least two of the target node methods correspond to different version processing flows. Then, according to this call sequence, the target node methods can be executed, thereby obtaining the return result. Therefore, in this application, when processing target requests with version compatibility requirements, different version processing flows can be used, thus achieving version compatibility. Compared to version compatibility solutions that rely on URLs, this application only requires modifying the call chain in the business system to make the node methods in the call chain correspond to the processing flow of different versions, thus achieving version compatibility. This avoids affecting systems or devices outside the business system and reduces the system complexity caused by version compatibility. Since the node methods that process the target request can correspond to different version processing flows, it not only maintains the consistency of request entry points and processing methods between high and low versions, reducing code redundancy caused by version compatibility, but also achieves bidirectional compatibility, meaning that low-version requests can use high-version processing flows, and high-version requests can also use low-version processing flows, thus reducing compatibility costs.

[0151] In one specific embodiment of this application, the executor is further used to execute the current node method in the target node method; if the execution is successful, the current node method is re-determined from the target node method according to the calling sequence; if the execution fails, the execution of the target node method is interrupted; after the target node method is completed, the return result is obtained.

[0152] In one specific embodiment of this application, the executor is specifically used to determine whether the current node method has a corresponding node call chain; the node call chain includes: node call sequence and child node methods; if yes, then the child node methods are executed according to the node call sequence; if no, then the current node method is executed directly.

[0153] In one specific embodiment of this application, the executor corresponds to the target executor, which is specifically used to execute the current node method; wherein, the target executor corresponds to the version of the current node method.

[0154] In one specific embodiment of this application, the verifier is further configured to perform business logic verification on the target request before verifying whether the compatibility conditions have version compatibility requirements, and obtain a logic verification result; if the logic verification result does not correspond to version compatibility requirements, the processing of the target request is terminated; if the logic verification result corresponds to version compatibility requirements, the step of verifying whether the compatibility conditions have version compatibility requirements is determined to be executed.

[0155] In one specific embodiment of this application, the verifier is specifically used to: obtain a set of verification methods by reflection based on compatibility conditions; determine a target verification method from the set of verification methods based on verification annotations; execute the target verification method to verify the compatibility conditions; if the verification passes, it is determined that the compatibility conditions have version compatibility requirements; if the verification fails, it is determined that the compatibility conditions do not have version compatibility requirements.

[0156] In one specific embodiment of this application, after determining that there is no version compatibility requirement, the executor is also used to throw an exception and terminate the processing of the target request.

[0157] In one specific embodiment of this application, the router is specifically used to retrieve the corresponding executor based on the dependency injection annotation declared by the executor, with compatibility conditions as input parameters; and to call the default processing method of the executor to obtain the target call chain.

[0158] In one specific embodiment of this application, the router is specifically used to obtain the target call chain corresponding to the executor by reflection based on compatibility conditions; the target call chain corresponds to the compatible method, and the compatible method corresponds to a directed graph structure.

[0159] In one specific embodiment of this application, the router is specifically used to query the target call chain for processing the target request from the call chain set using the compatibility key value in the compatibility conditions.

[0160] In one specific embodiment of this application, the router is specifically used to query the main call chain corresponding to the compatible key value from the call chain set; if the main call chain exists and is available, the main call chain is determined as the target call chain; if the main call chain does not exist and / or is unavailable, the backup call chain corresponding to the main call chain is determined as the target call chain.

[0161] In one specific embodiment of this application, the router is specifically used to query the main call chain corresponding to the compatible key value from the call chain set by utilizing the mapping relationship between key values ​​and call chains in the call chain annotation.

[0162] To facilitate understanding of the multi-version compatible request processing method and multi-version compatible request processing apparatus provided in the embodiments of this application, the following detailed description of implementing the multi-version compatible request processing method on the multi-version compatible request processing apparatus is provided in conjunction with relevant compatibility solutions.

[0163] First, let's explain how version compatibility is achieved by adding hierarchical levels to URL directories. In this compatibility scheme, the server needs to add new business processing logic; the server-side Controller layer adds the applicable version number to the interface address when accepting POST / GET requests; the gateway layer modifies the URI (a string identifying a resource) and redirects it after the external request is intercepted based on the APP version number. If there is no gateway, the corresponding APP SDK (Application Software Development Kit) needs to modify the original request URL and publish the latest installation package; after receiving the request, the web server assigns it to different servlets for processing based on the URI; the old and new logic coexist by isolating URLs and providing services to the outside world while ensuring compatibility between different versions.

[0164] It is evident that this solution has the following drawbacks: 1. It increases the complexity of the gateway, which in turn increases latency to some extent; 2. Version compatibility has a wide impact, requiring adjustments to the app, gateway, and business systems simultaneously; 3. It increases compatibility complexity and redundant code.

[0165] After applying the multi-version compatible request processing method provided in this application to a multi-version compatible request processing apparatus:

[0166] 1. Initialize the executor set.

[0167] 2. Initialization device.

[0168] Specifically, a multi-version compatible request processing device consists of at least three parts: a validator, a router, and an executor. Each part corresponds to an interface class, which contains an execution method with an anonymous function as input parameters and a default implementation.

[0169] Before initializing the device, it is necessary to retrieve the collection of all versions of the current request executor instances, the call chain mapping, the instantiation validator, and the request context from the bean (a model of Java software components) container. Then, these retrieved contents are passed to the device via the `from` function (a pass function), thus completing the device's initialization and loading. The request context contains compatibility conditions, request information, result generics, parameter information, and additional information, which can be used to store and pass intermediate results after each step of the device's execution.

[0170] 3. Receive the request and retrieve the verifier from the device according to the current request context to perform necessary logical verification.

[0171] Specifically, a custom validator can be passed to the device's `validate` function. The device will execute the validator instance's validation method, which is a user-defined method and includes parameter and necessary business logic validation. If the validation logic has version compatibility requirements, the validator will retrieve the set of validation methods through reflection based on the compatibility conditions in the parsing context and execute the validation methods according to the `@MTDVersion` annotation. If the validation fails, the validator throws an exception, the device terminates the call, and returns the result.

[0172] 4. After the verification is passed, the device routes the corresponding actuator according to the compatibility requirements.

[0173] 5. The compatible executor obtains the compatible method through reflection according to the compatibility requirements.

[0174] 6. Run the compatible method and return the result.

[0175] 7. The executor determines whether to interrupt execution based on the result. If it does not interrupt, it checks whether the compatible method has a sub-method.

[0176] 8. If there are sub-methods, repeat steps 5-7 recursively to execute all sub-methods and then return the result.

[0177] Detailed explanation of steps 4 to 7: After successful verification, the device calls the routing function, with the user-specified compatibility conditions as input. The router in the device parses the routing conditions and retrieves the corresponding executor based on the `@Resource` annotation declared by the executor, then calls the executor's default processing method. This method retrieves the corresponding compatibility method of the executor through reflection based on the compatibility conditions and calls it. When a node method in the compatibility method finishes execution, the executor checks the current return result to determine if the method contains sub-methods. If so, it repeats the execution until all node methods in the compatibility method have finished executing. The executor's compatibility processing method is a directed graph structure, where each node can participate in different version processing flows, and there are no duplicate nodes.

[0178] Therefore, the compatibility solution provided in this application, in scenarios where the compatibility key input parameter is not missing, the addition or deletion of parameters is irrelevant to the device; it only relates to the compatibility method corresponding to the key in the declared call chain. The device will forward the request to the corresponding version's processing method according to the declared call chain. If the key value does not exist at this time, or the call chain state is unavailable, the device will route the request to the backup chain for processing. This ensures that the request entry point and processing method are consistent between high and low versions, and supports customization of the number of call chain methods for different request versions. For example, it is allowed that version 1 processes request 1 corresponding to BL1 using the execution methods M1-1-V1 and M2-2-V2, and version 2 processes request 2 corresponding to BL2 using the execution methods M1-1-V1, M2-2-V2, and M3-3-V1.

[0179] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below and the multi-version compatible request processing method described above can be referred to in correspondence.

[0180] See Figure 6 As shown, the electronic device includes:

[0181] Memory 332 is used to store computer programs;

[0182] Processor 322 is configured to implement the steps of the multi-version compatible request processing method of the above method embodiments when executing a computer program.

[0183] For details, please refer to Figure 7 , Figure 7 This is a schematic diagram of a specific structure of an electronic device provided in this embodiment. The electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) 322 (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer application programs 342 or data 344. The memory 332 can be temporary or persistent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the central processing unit 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the electronic device 301.

[0184] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0185] The steps in the multi-version compatible request processing method described above can be implemented by the structure of the electronic device.

[0186] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below can be referred to in conjunction with the multi-version compatible request processing method described above.

[0187] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the multi-version compatible request processing method of the above-described method embodiments.

[0188] Specifically, the readable storage medium can be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0189] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

Claims

1. A multi-version compatible request processing method, characterized in that, include: Receive and parse the target request to obtain the compatibility conditions corresponding to the target request; The target request carries compatibility conditions, which are either compatibility condition content or strings or parameters used to determine the compatibility condition content; the compatibility condition content indicates which versions and methods are required to process the target request. Verify whether the compatibility conditions have version compatibility requirements; If the compatibility conditions require version compatibility, then the target call chain for processing the target request is determined; wherein, the target call chain includes the call sequence and the target node method, and at least two node methods in the target node method correspond to different versions of the processing flow; one node method corresponds to one processing flow; The target node method is executed according to the aforementioned call sequence, and the return result is obtained. Determining the target call chain for processing the target request includes: The compatibility conditions are used as input parameters, and the corresponding executor is retrieved based on the dependency injection annotation declared by the executor. The default processing method of the executor is invoked to obtain the target call chain; Before verifying whether the compatibility conditions require version compatibility, the process also includes: Perform business logic validation on the target request to obtain the logic validation result; If the logical verification result does not correspond to the version compatibility requirement, the processing of the target request will be terminated; If the logical verification result corresponds to a version compatibility requirement, then determine whether to perform the step of verifying whether the compatibility condition has a version compatibility requirement.

2. The multi-version compatible request processing method according to claim 1, characterized in that, According to the aforementioned call sequence, the target node method is executed, and the return result is obtained, including: Execute the current node method in the target node method; If the execution is successful, the current node method is re-determined from the target node method according to the call sequence. If execution fails, the execution of the target node method will be interrupted; The return result is obtained after the target node method has been executed.

3. The multi-version compatible request processing method according to claim 2, characterized in that, Executing the current node method in the target node method includes: Determine whether the current node method has a corresponding node call chain; the node call chain includes: node call sequence and child node methods; If so, the child node method is executed according to the node invocation sequence; If not, then the current node method will be executed directly.

4. The multi-version compatible request processing method according to claim 2, characterized in that, Executing the current node method in the target node method includes: The current node method is executed using the target executor, wherein the target executor corresponds to the version of the current node method.

5. The multi-version compatible request processing method according to claim 1, characterized in that, Verify whether the compatibility conditions have version compatibility requirements, including: Based on the compatibility conditions, the set of verification methods is obtained through reflection. Based on the verification annotations, the target verification method is determined from the set of verification methods; The target verification method is executed to verify the compatibility conditions; If the verification passes, it is determined that the compatibility conditions have version compatibility requirements; If the verification fails, it is determined that the compatibility conditions do not require version compatibility.

6. The multi-version compatible request processing method according to claim 5, characterized in that, After determining that there are no version compatibility requirements for the aforementioned compatibility conditions, the following is also included: An exception is thrown, and the processing of the target request is terminated.

7. The multi-version compatible request processing method according to claim 1, characterized in that, The target call chain is obtained by invoking the default processing method of the executor, including: Based on the compatibility conditions, the target call chain corresponding to the executor is obtained by reflection; the target call chain corresponds to the compatible method, and the compatible method corresponds to a directed graph structure.

8. The multi-version compatible request processing method according to claim 7, characterized in that, Based on the compatibility conditions, the target call chain corresponding to the executor is obtained via reflection, including: Using the compatibility key value in the compatibility condition, the target call chain that processes the target request is retrieved from the call chain set.

9. The multi-version compatible request processing method according to claim 8, characterized in that, Using the compatibility key value in the compatibility conditions, the target call chain that processes the target request is retrieved from the call chain set, including: Retrieve the main call chain corresponding to the compatible key value from the call chain set; If the main call chain exists and its state is available, then the main call chain is determined as the target call chain; If the main call chain does not exist and / or is unavailable, then the backup call chain corresponding to the main call chain is determined as the target call chain.

10. The multi-version compatible request processing method according to claim 9, characterized in that, Retrieving the main call chain corresponding to the compatible key value from the call chain set includes: By utilizing the mapping relationship between key values ​​and call chains in the call chain annotation, the main call chain corresponding to the compatible key value is queried from the call chain set.

11. A multi-version compatible request processing apparatus, characterized in that, include: The request interface is used to receive and parse the target request to obtain the compatibility conditions corresponding to the target request. The target request carries compatibility conditions, which are either compatibility condition content or strings or parameters used to determine the compatibility condition content; the compatibility condition content indicates which versions and methods are required to process the target request. A verifier is used to verify whether the compatibility conditions have version compatibility requirements; A router is configured to determine a target call chain for processing the target request if the compatibility conditions require version compatibility; wherein the target call chain includes a call sequence and target node methods, and at least two node methods in the target node methods correspond to different versions of the processing flow; one node method corresponds to one processing flow; An executor is used to execute the target node method according to the invocation sequence and obtain the return result; Specifically, the router is used to take the compatibility conditions as input parameters and retrieve the corresponding executor according to the dependency injection annotation declared by the executor; and call the default processing method of the executor to obtain the target call chain; Before verifying whether the compatibility condition has a version compatibility requirement, the verifier is also used to perform business logic verification on the target request to obtain a logic verification result; if the logic verification result does not correspond to a version compatibility requirement, the processing of the target request is terminated; if the logic verification result corresponds to a version compatibility requirement, the step of verifying whether the compatibility condition has a version compatibility requirement is determined to be executed.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the multi-version compatible request processing method as described in any one of claims 1 to 9 when executing the computer program.

13. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by an executor, implements the steps of the multi-version compatible request processing method as described in any one of claims 1 to 9.

Images