SCA service execution method and device based on reflection mechanism and retry mechanism
By adopting reflection mechanism and retry mechanism methods in SCA business, the extended services are independently executed, which solves the problem of the new functions that expand services affect the core services, and achieves the decoupling and final consistency of business processes.
Patent Information
- Application Number
- CN202411255818.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-09
- Publication Date
- 2025-02-18
Smart Images
Figure CN119473648A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of SCA service execution, and in particular to a SCA service execution method and device based on a reflection mechanism and a retry mechanism. Background Art
[0002] In the daily business design process of SCA, most of the new functions are not core businesses, but extended businesses. Therefore, in order to avoid affecting the code of core businesses and maintain the open-closed principle of software design, when developing software, the extended design is carried out based on the original code.
[0003] In order to ensure the execution efficiency of SCA code and the quality of software, asynchronous threads are usually started to handle extended business. However, such a design will still add uncertainty to the processing of the original core business and easily affect the overall business logic. Summary of the invention
[0004] The purpose of the present invention is to provide an SCA business execution method and device based on a reflection mechanism and a retry mechanism, which utilizes a reflection mechanism in conjunction with an asynchronous thread pool to independently execute extended services, is non-invasive to the overall SCA business process, and achieves overall business decoupling. The final consistency of the extended business execution is ensured through a retry mechanism to improve the robustness of the SCA business.
[0005] In order to achieve the above object, the present invention discloses an SCA service execution method based on a reflection mechanism and a retry mechanism, which comprises:
[0006] Scan all tasks in the SCA container and obtain tasks marked with custom annotations;
[0007] Determine whether the task is executed asynchronously through the custom annotation of the task. If it is executed asynchronously, obtain the execution method corresponding to the task through reflection and save it to the first database;
[0008] Determine whether the execution method corresponding to the acquired task is saved successfully. If saved successfully, publish the task as an MQ message;
[0009] Consume the MQ message and determine whether the MQ message is consumed successfully. If the consumption is successful, update the status of the corresponding task in the first database to successful execution; if the consumption fails, record the number of consumption failures and the reasons for the consumption failures, and save the corresponding task to the second database;
[0010] The tasks in the second database are executed regularly to determine whether the execution is successful. If the execution is successful, the status of the corresponding task in the first database is updated to successful execution. If the execution fails, the reason for the failure is recorded and the task is retried a set number of times.
[0011] Furthermore, the “determining whether the execution method corresponding to the acquired task is saved successfully, and if saved successfully, publishing the task through an MQ message” also includes:
[0012] If the saving fails, the execution method corresponding to the acquired task will be saved again, and it will be determined whether the execution method corresponding to the acquired task is saved successfully again. If the saving is successful again, the task will be published as an MQ message. If the saving fails again, the corresponding task will be directly executed according to the acquired execution method.
[0013] Furthermore, after the “publishing the task as an MQ message”, the method further includes:
[0014] Determine whether the MQ message is published successfully. If so, consume the MQ message. If not, update the status of the corresponding task in the first database to execution failure, and save the corresponding task to the second database.
[0015] Furthermore, after the “retrying the task a set number of times”, the method further includes:
[0016] Determine whether the task is executed successfully. If the task fails, send a notification message.
[0017] Furthermore, after the “periodically executing the tasks in the second database”, the method further includes:
[0018] The details of tasks to be executed and executed are collected in real time and displayed.
[0019] In order to achieve the above object, the present invention discloses an SCA service execution device based on a reflection mechanism and a retry mechanism, which includes:
[0020] Annotation acquisition module, which is used to scan all tasks in the SCA container and obtain tasks marked with custom annotations;
[0021] An asynchronous judgment module, used to judge whether a task is executed asynchronously through a custom annotation of the task. If it is executed asynchronously, the execution method corresponding to the task is obtained through reflection and saved in the first database;
[0022] The message publishing module is used to determine whether the execution method corresponding to the acquired task is saved successfully. If it is saved successfully, the task is published as an MQ message;
[0023] A message consumption module, used to consume MQ messages and determine whether the MQ messages are consumed successfully. If the consumption is successful, the status of the corresponding task in the first database is updated to successful execution; if the consumption fails, the number of consumption failures and the reasons for the consumption failures are recorded, and the corresponding tasks are saved in the second database;
[0024] The task retry module is used to periodically execute the tasks in the second database and determine whether the execution is successful. If the execution is successful, the status of the corresponding task in the first database is updated to successful execution. If the execution fails, the reason for the failure is recorded and the task is retried a set number of times.
[0025] In order to achieve the above object, the present invention discloses an electronic device, which includes:
[0026] one or more processors;
[0027] One or more memories are used to store one or more programs. When one or more of the programs are executed by the processor, the processor implements the SCA business execution method based on the reflection mechanism and the retry mechanism as described above.
[0028] In order to achieve the above object, the present invention discloses a computer-readable storage medium on which a program is stored. When the program is executed by a processor, the SCA service execution method based on the reflection mechanism and the retry mechanism as described above is implemented.
[0029] In this application, the decoupling and robustness of the execution of SCA extended services are ensured through reflection mechanism and retry mechanism. First, it is necessary to scan all tasks in the SCA container and obtain tasks marked with custom annotations; identify asynchronously executed tasks through custom annotations, and obtain and save their corresponding execution methods to the first database through reflection, and publish MQ messages for successfully saved tasks; then execute tasks through MQ message consumption, update the status of tasks corresponding to successfully consumed MQ messages to successful execution, and save tasks corresponding to failed MQ messages to the second database; re-execute tasks in the second database at regular intervals, update the status of successfully re-executed tasks to successful execution, and retry re-executed tasks for a set number of times. The above-mentioned use of reflection mechanism in conjunction with asynchronous thread pool to independently execute extended services is non-invasive to the overall SCA business process, realizes overall business decoupling, and ensures the final consistency of extended business execution through a retry mechanism to improve the robustness of SCA services. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] Figure 1 It is a flowchart of operations 101-104 of the SCA service execution method based on the reflection mechanism and the retry mechanism according to an embodiment of the present invention.
[0031] Figure 2 This is a flowchart of operation 105 in the SCA service execution method based on the reflection mechanism and the retry mechanism according to an embodiment of the present invention.
[0032] Figure 3 It is a module diagram of an SCA service execution device based on a reflection mechanism and a retry mechanism according to an embodiment of the present invention.
[0033] Figure 4 4 is a system diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION
[0034] In order to explain the technical content, structural features, achieved objectives and effects of the present invention in detail, the following is a detailed description in conjunction with the implementation methods and the accompanying drawings.
[0035] Embodiment 1
[0036] See also Figure 1 and Figure 2 The present invention discloses an SCA service execution method based on a reflection mechanism and a retry mechanism, which includes:
[0037] 101. Scan all tasks in the SCA container and obtain tasks marked with custom annotations;
[0038] It is understandable that during the process of starting the project and running the program, custom annotations are obtained by scanning the annotations of all tasks. The custom annotations of the task indicate whether the task is executed asynchronously, which is convenient for distinguishing which logic in the SCA business code needs to be processed asynchronously, and caching the tasks to be executed marked with custom annotations, that is, saving their entry parameters and method call chains for later calls, but not limited to this.
[0039] 102. Determine whether the task is executed asynchronously through the custom annotation of the task. If it is executed asynchronously, obtain the execution method corresponding to the task through reflection and save it to the first database;
[0040] You only need to introduce the corresponding SDK component dependency to implement the execution of new services through the reflection mechanism, so as to decouple the overall SCA business and ensure the closed nature of the SCA core business process.
[0041] It is understandable that when the business process runs and executes the corresponding task, it will first determine whether the current task is a task that needs to be executed asynchronously through the custom annotation marked on the task in the cache. If it is a task that needs to be executed asynchronously, the task annotation is scanned through the reflection mechanism to obtain the execution method of the task, that is, the entry parameters and method call chain of the corresponding task are obtained from the buffer, and the execution method corresponding to the obtained task is saved in the first database, but not limited to this.
[0042] 103. Determine whether the execution method corresponding to the acquired task is saved successfully. If saved successfully, publish the task as an MQ message;
[0043] By asynchronously processing business processes to ensure the execution of new services, it is helpful to avoid affecting the core business processes of SCA.
[0044] It is understandable that the tasks that need to be executed asynchronously and their execution methods are saved in the first database, and the event mechanism provided by the Spring framework is used to broadcast the saved tasks as events, so as to push the execution of the tasks as MQ messages to the MQ message queue, but not limited to this.
[0045] Furthermore, “determining whether the execution method corresponding to the acquired task is saved successfully, and if saved successfully, publishing the task as an MQ message” also includes:
[0046] 1030. If the saving fails, the execution method corresponding to the acquired task is saved again, and it is determined whether the execution method corresponding to the acquired task is saved successfully again. If the saving is successful again, the task is published as an MQ message. If the saving fails again, the corresponding task is directly executed according to the acquired execution method.
[0047] It is understandable that if the task that needs to be executed asynchronously and its execution method fail to be saved to the first database, it will be saved again, and direct execution will serve as a fallback operation. After the re-saving fails, the task that failed to be saved will be executed according to its execution method to ensure the final consistency of the data and avoid data loss due to the failure of asynchronous execution of the task.
[0048] Furthermore, after "publishing the task as an MQ message", it also includes:
[0049] 1031. Determine whether the MQ message is published successfully. If so, consume the MQ message. If not, update the status of the corresponding task in the first database to execution failure, and save the corresponding task to the second database.
[0050] It should be noted that, in this embodiment, the second database is MySQL; after the Spring event publisher receives the relevant triggered event, it pushes the execution of the task to the MQ message queue for orderly consumption, and at the same time controls the concurrency of messages to avoid too many background tasks and blockage of the SCA core business process. If the task fails to be pushed to the MQ message queue, the task to be executed and its execution method will be saved in the second database MySQL to facilitate the retry of the task execution later, but not limited to this.
[0051] 104. Consume the MQ message and determine whether the MQ message is consumed successfully. If the consumption is successful, update the status of the corresponding task in the first database to successful execution; if the consumption fails, record the number of consumption failures and the reasons for the consumption failures, and save the corresponding task to the second database;
[0052] It is understandable that the current MQ message queue adopts a self-production and self-sales model, automatically generates corresponding queue IDs for MQ messages in the queue according to business scenarios, and cooperates with the first-in-first-out mechanism to enable MQ consumers to consume MQ messages in order after listening to related MQ messages, but it is not limited to this.
[0053] It should be noted that if consumption fails, it means that the task execution has failed. In this case, the failed task and its execution method will be saved in the second database MySQL to facilitate the retry of the task execution later. The number of failures will also be recorded and accumulated, as well as the reason for each failure. When the number of failures accumulates and exceeds the set threshold, the administrator will be notified of the number of failures and the reason via email, but this is not limited to this.
[0054] 105. Execute the tasks in the second database regularly and determine whether the execution is successful. If the execution is successful, update the status of the corresponding task in the first database to successful execution. If the execution fails, record the reason for the failure and retry the task a set number of times.
[0055] When a task fails, the eventual consistency of SCA business data is guaranteed through a failure compensation strategy that includes exception handling measures and fallback solutions, effectively enhancing the robustness of the SCA knowledge base.
[0056] Furthermore, after “retrying the task a set number of times”, it also includes:
[0057] 1051. Determine whether the task is executed successfully. If the task fails, send a notification message.
[0058] It is understandable that the XXL-JOB scheduled task component is integrated to regularly obtain tasks in the second database MySQL and execute them, so as to utilize the retry mechanism to achieve the final consistency of task execution and improve the robustness of the SCA knowledge base.
[0059] It should be noted that, based on actual conditions, the number of retries when a task fails to execute can be set, so that after the task fails to execute, the task can be re-executed according to the set number of times, so that when the number of retries reaches the set threshold and all retries fail, the relevant SCA managers can be promptly notified by email through the integrated email notification device, but this is not limited to this.
[0060] Furthermore, after “periodically executing the tasks in the second database”, the method further includes:
[0061] 106. Collect details of tasks to be executed and executed in real time, and display the collected details.
[0062] It is understandable that operation 106 can be executed synchronously with the above operation, and the details of the currently pending and executed tasks collected can be displayed in real time by using the visual operation page program developed by Vue, so as to facilitate the administrator to view and operate.
[0063] In this application, the decoupling and robustness of the execution of SCA extended services are ensured through reflection mechanism and retry mechanism. First, it is necessary to scan all tasks in the SCA container and obtain tasks marked with custom annotations; identify asynchronously executed tasks through custom annotations, and obtain and save their corresponding execution methods to the first database through reflection, and publish MQ messages for successfully saved tasks; then execute tasks through MQ message consumption, update the status of tasks corresponding to successfully consumed MQ messages to successful execution, and save tasks corresponding to failed MQ messages to the second database; re-execute tasks in the second database at regular intervals, update the status of successfully re-executed tasks to successful execution, and retry re-executed tasks for a set number of times. The above-mentioned use of reflection mechanism in conjunction with asynchronous thread pool to independently execute extended services is non-invasive to the overall SCA business process, realizes overall business decoupling, and ensures the final consistency of extended business execution through a retry mechanism to improve the robustness of SCA services.
[0064] Embodiment 2
[0065] See also Figure 1 and Figure 3 The present invention discloses an SCA service execution device based on a reflection mechanism and a retry mechanism, which includes:
[0066] An annotation acquisition module 201 is used to scan all tasks in the SCA container and acquire tasks marked with custom annotations;
[0067] The asynchronous judgment module 202 is used to judge whether the task is executed asynchronously through the custom annotation of the task. If it is executed asynchronously, the execution method corresponding to the task is obtained through reflection and saved to the first database;
[0068] The message publishing module 203 is used to determine whether the execution method corresponding to the acquired task is saved successfully. If it is saved successfully, the task is published as an MQ message;
[0069] The message consumption module 204 is used to consume the MQ message and determine whether the MQ message is consumed successfully. If the consumption is successful, the status of the corresponding task in the first database is updated to successful execution; if the consumption fails, the number of consumption failures and the reasons for the consumption failures are recorded, and the corresponding task is saved in the second database;
[0070] The task retry module 205 is used to periodically execute the tasks in the second database and determine whether the execution is successful. If the execution is successful, the status of the corresponding task in the first database is updated to successful execution. If the execution fails, the reason for the failure is recorded and the task is retried a set number of times.
[0071] Embodiment 3
[0072] See also Figure 1 and Figure 4 , the present invention discloses an electronic device, comprising:
[0073] One or more processors 301;
[0074] One or more memories 302 are used to store one or more programs. When the one or more programs are executed by the processor, the processor implements the SCA service execution method based on the reflection mechanism and the retry mechanism as described above.
[0075] Embodiment 4
[0076] The embodiment of the present application discloses a computer-readable storage medium on which a program is stored. When the program is executed by a processor, the SCA service execution method based on the reflection mechanism and the retry mechanism as described above is implemented.
[0077] Embodiment 5
[0078] The embodiment of the present application discloses a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of an electronic device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the electronic device executes the above-mentioned SCA service execution method based on the reflection mechanism and the retry mechanism.
[0079] It should be understood that in the embodiments of the present application, the processor referred to may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.
[0080] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by hardware related to computer program instructions, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).
[0081] The above disclosure is only the preferred embodiment of the present invention, which certainly cannot be used to limit the scope of rights of the present invention. Therefore, equivalent changes made according to the scope of the patent application of the present invention are still within the scope covered by the present invention.
Claims
1. A SCA service execution method based on reflection mechanism and retry mechanism, characterized in that: include: Scan all tasks in the SCA container and obtain tasks marked with custom annotations; Determine whether the task is executed asynchronously through the custom annotation of the task. If it is executed asynchronously, obtain the execution method corresponding to the task through reflection and save it to the first database; Determine whether the execution method corresponding to the acquired task is saved successfully. If saved successfully, publish the task as an MQ message; Consume the MQ message and determine whether the MQ message is consumed successfully. If the consumption is successful, update the status of the corresponding task in the first database to successful execution; if the consumption fails, record the number of consumption failures and the reasons for the consumption failures, and save the corresponding task to the second database; The tasks in the second database are executed regularly to determine whether the execution is successful. If the execution is successful, the status of the corresponding task in the first database is updated to successful execution. If the execution fails, the reason for the failure is recorded and the task is retried a set number of times.
2. The SCA service execution method based on reflection mechanism and retry mechanism according to claim 1 is characterized in that: The "determining whether the execution method corresponding to the acquired task is saved successfully, and if saved successfully, publishing the task by MQ message" also includes: If the saving fails, the execution method corresponding to the acquired task will be saved again, and it will be determined whether the execution method corresponding to the acquired task is saved successfully again. If the saving is successful again, the task will be published as an MQ message. If the saving fails again, the corresponding task will be directly executed according to the acquired execution method.
3. The SCA service execution method based on reflection mechanism and retry mechanism according to claim 1 is characterized in that: After "publishing the task as an MQ message", it also includes: Determine whether the MQ message is published successfully. If so, consume the MQ message. If not, update the status of the corresponding task in the first database to execution failure, and save the corresponding task to the second database.
4. The SCA service execution method based on reflection mechanism and retry mechanism according to claim 1 is characterized in that: After the "retrying the task a set number of times", it also includes: Determine whether the task is executed successfully. If the task fails, send a notification message.
5. The SCA service execution method based on reflection mechanism and retry mechanism according to claim 1 is characterized in that: After the "periodic execution of the tasks in the second database", the method further includes: The details of tasks to be executed and executed are collected in real time and displayed.
6. An SCA service execution device based on reflection mechanism and retry mechanism, characterized in that: include: Annotation acquisition module, which is used to scan all tasks in the SCA container and obtain tasks marked with custom annotations; An asynchronous judgment module, used to judge whether a task is executed asynchronously through a custom annotation of the task. If it is executed asynchronously, the execution method corresponding to the task is obtained through reflection and saved in the first database; The message publishing module is used to determine whether the execution method corresponding to the acquired task is saved successfully. If it is saved successfully, the task is published as an MQ message; A message consumption module, used to consume MQ messages and determine whether the MQ messages are consumed successfully. If the consumption is successful, the status of the corresponding task in the first database is updated to successful execution; if the consumption fails, the number of consumption failures and the reasons for the consumption failures are recorded, and the corresponding tasks are saved in the second database; The task retry module is used to periodically execute the tasks in the second database and determine whether the execution is successful. If the execution is successful, the status of the corresponding task in the first database is updated to successful execution. If the execution fails, the reason for the failure is recorded and the task is retried a set number of times.
7. An electronic device, characterized in that: include: one or more processors; One or more memories are used to store one or more programs. When one or more of the programs are executed by the processor, the processor implements the SCA business execution method based on the reflection mechanism and the retry mechanism as described in any one of claims 1 to 5.
8. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the SCA service execution method based on the reflection mechanism and the retry mechanism as claimed in any one of claims 1 to 5 is implemented.