Distributed micro-service operation request processing method and device and electronic equipment

Abstract

The invention discloses a distributed micro-service operation request processing method, a distributed micro-service operation request processing device and electronic equipment, and relates to the technical field of distributed micro-services, and the processing method comprises the following steps: receiving a distributed micro-service operation request initiated by a user, creating a transaction identifier based on the distributed micro-service operation request, and creating a transaction identifier based on the transaction identifier; executing the distributed micro-service operation request, obtaining an operation log of each business micro-service executing the distributed micro-service operation request, obtaining an audit log of a preset database, and establishing an association index between all the operation logs and the audit log based on the transaction identifier, and under the condition that an exception occurs in the process of executing the distributed micro-service operation request, executing a rollback operation based on the associated index until the distributed micro-service operation request is successfully processed. According to the method and the device, the technical problem of relatively low efficiency of processing the distributed micro-service operation request in related technologies is solved.

Description

Technical Field

[0001] This invention relates to the field of distributed microservice technology, and more specifically, to a method, apparatus, and electronic device for processing distributed microservice operation requests. Background Technology

[0002] Currently, the following problems exist in operation auditing and transaction rollback in distributed microservice architecture: (1) Fragmented audit logs: Business operation logs and database change logs are stored independently, which means that operation chain tracing requires manual splicing across systems, resulting in low location efficiency; (2) Weak rollback capability: Cross-microservice business operations cannot achieve atomic rollback, relying on manual writing of compensation logic, resulting in a high error rate; (3) Uncontrolled storage costs: Database audit logs store full data snapshots, occupying space many times that of business data; (4) Risk of operation chain breakage: When there are multiple layers of microservice call depth (such as more than 5 layers), the complete traceability rate of the operation chain is low, which makes it easy to lose logs of key links.

[0003] Therefore, in the above distributed microservice architecture, when processing distributed microservice operation requests, it is impossible to meet the requirements of high efficiency, accuracy and low cost for operation auditing and transaction rollback in the distributed microservice environment, resulting in low efficiency in processing distributed microservice operation requests.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, apparatus, and electronic device for processing distributed microservice operation requests, to at least solve the technical problem of low efficiency in processing distributed microservice operation requests in related technologies.

[0006] According to one aspect of the present invention, a method for processing distributed microservice operation requests is provided, comprising: receiving a distributed microservice operation request initiated by a user, and creating a transaction identifier based on the distributed microservice operation request; executing the distributed microservice operation request based on the transaction identifier, and obtaining operation logs of each business microservice executing the distributed microservice operation request; obtaining audit logs of a preset database, and establishing an association index between all operation logs and audit logs based on the transaction identifier; and, in the event of an exception during the execution of the distributed microservice operation request, performing a rollback operation based on the association index until the distributed microservice operation request is successfully processed.

[0007] Furthermore, the step of creating a transaction identifier based on a distributed microservice operation request includes: obtaining the timestamp of the user initiating the distributed microservice operation request; obtaining the terminal identifier and physical location of the terminal initiating the distributed microservice operation request; and creating a transaction identifier based on the timestamp, terminal identifier, and physical location of the terminal.

[0008] Furthermore, the steps for obtaining the operation logs of each business microservice executing the distributed microservice operation request include: determining the operation to be executed for each distributed microservice based on the distributed microservice operation request; capturing operation parameters through a preset aspect for each distributed microservice when the distributed microservice is executing the operation to be executed; and generating operation logs based on the operation parameters.

[0009] Furthermore, the steps for obtaining audit logs from a preset database include: deploying an interceptor in the preset database; capturing the change parameters of the preset database using the interceptor when a change operation is detected; and generating audit logs based on the change parameters.

[0010] Furthermore, the steps for generating audit logs based on the change parameters include: identifying the changed fields where the change operation occurred; querying the original values ​​of the changed fields before the change operation was performed, and determining the latest values ​​of the changed fields after the change operation was performed based on the change parameters corresponding to the changed fields; constructing a triple array of the changed fields based on the changed fields, their original values, and the latest values; generating an initial audit log based on all the triple arrays, and compressing the initial audit log to obtain the audit log.

[0011] Furthermore, in the event of an exception during the execution of a distributed microservice operation request, the steps for performing a rollback operation based on the related index include: querying a preset database based on the related index to obtain the audit log; determining whether a database change operation has occurred based on the audit log; if no database change operation has occurred, determining the operation log of each business microservice based on the related index; changing the execution status of the business microservice to an inactive state based on the operation log; and performing a rollback operation on the preset database based on the audit log if a database change operation has occurred.

[0012] Furthermore, the steps for performing a rollback operation on the preset database based on the audit logs include: rolling back the latest values ​​of all changed fields in the preset database to their original values ​​based on the audit logs; and, in cases where the latest values ​​of changed fields have not been rolled back to their original values, calling the compensation interface in reverse to cancel the changes to the changed fields using the compensation interface.

[0013] Furthermore, in the event of an exception during the execution of distributed microservice operation requests, the following measures are also included: if the number of abnormal distributed microservice operation requests exceeds a preset threshold, a data version rollback is performed using a snapshot image of a preset database; if a snapshot image contains missing snapshots, the compensation interface corresponding to the missing snapshot is called in reverse to perform a mixed rollback of the preset database.

[0014] According to another aspect of the present invention, a processing apparatus for distributed microservice operation requests is also provided, comprising: a creation unit, configured to receive a distributed microservice operation request initiated by a user and create a transaction identifier based on the distributed microservice operation request; a first acquisition unit, configured to execute the distributed microservice operation request based on the transaction identifier and acquire operation logs of each business microservice executing the distributed microservice operation request; a second acquisition unit, configured to acquire audit logs of a preset database and establish an association index between all operation logs and audit logs based on the transaction identifier; and an execution unit, configured to perform a rollback operation based on the association index in the event of an exception during the execution of the distributed microservice operation request, until the distributed microservice operation request is successfully processed.

[0015] Furthermore, the creation unit includes: a first acquisition module, used to acquire the timestamp of the user's distributed microservice operation request; a second acquisition module, used to acquire the terminal identifier and physical location of the terminal that initiated the distributed microservice operation request; and a first creation module, used to create a transaction identifier based on the timestamp, terminal identifier, and physical location of the terminal.

[0016] Furthermore, the first acquisition unit includes: a first determination module, used to determine the operation to be executed for each distributed microservice based on the distributed microservice operation request; a first capture module, used to capture operation parameters through a preset aspect for each distributed microservice when the distributed microservice is executing the operation to be executed; and a first generation module, used to generate an operation log based on the operation parameters.

[0017] Furthermore, the second acquisition unit includes: a first deployment module for deploying an interceptor in a preset database; a second capture module for capturing the change parameters of the preset database using the interceptor when a change operation is detected in the preset database; and a second generation module for generating audit logs based on the change parameters.

[0018] Furthermore, the second generation module includes: a first determination submodule, used to determine the changed field where the change operation occurred; a first query submodule, used to query the original value of the changed field before the change operation was performed, and determine the latest value of the changed field after the change operation was performed based on the change parameters corresponding to the changed field; a first construction submodule, used to construct a triple array of the changed field based on the changed field, the original value corresponding to the changed field, and the latest value; and a first generation submodule, used to generate an initial audit log based on all triple arrays, and compress the initial audit log to obtain the audit log.

[0019] Furthermore, the execution unit includes: a first query module, used to query a preset database based on the associated index to obtain audit logs; a first judgment module, used to determine whether a database change operation has occurred based on the audit logs; a second determination module, used to determine the operation logs of each business microservice based on the associated index if no database change operation has occurred; a first change module, used to change the execution status of the business microservice to an inactive state based on the operation logs; and a first rollback module, used to perform a rollback operation on the preset database based on the audit logs if a database change operation has occurred.

[0020] Furthermore, the first rollback module includes: a first rollback submodule, used to roll back the latest value of all changed fields in the preset database to the original value based on the audit log; and a first call submodule, used to reverse call the compensation interface in the case where the latest value of a changed field has not been rolled back to the original value, so as to cancel the change to the changed field using the compensation interface.

[0021] Furthermore, the processing device also includes: a second rollback module, used to perform data version rollback using a snapshot image of a preset database when an exception occurs during the execution of a distributed microservice operation request and the number of abnormal distributed microservice operation requests exceeds a preset threshold; and a first invocation module, used to reverse-invoke the compensation interface corresponding to the missing snapshot in the case where the snapshot image has missing snapshots, and perform a mixed rollback of the preset database.

[0022] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements a method for processing distributed microservice operation requests as described above.

[0023] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described methods for processing distributed microservice operation requests.

[0024] In this invention, a distributed microservice operation request initiated by a user is received, and a transaction identifier is created based on the distributed microservice operation request. Based on the transaction identifier, the distributed microservice operation request is executed, and the operation logs of each business microservice executing the distributed microservice operation request are obtained. The audit logs of a preset database are also obtained, and an association index between all operation logs and audit logs is established based on the transaction identifier. In the event of an exception during the execution of the distributed microservice operation request, a rollback operation is performed based on the association index until the distributed microservice operation request is successfully processed. This solves the technical problem of low efficiency in processing distributed microservice operation requests in related technologies.

[0025] This invention employs a distributed, unique transaction identifier. By generating this identifier immediately upon receiving a user-initiated distributed microservice operation request and maintaining it throughout the entire operation chain, it ensures that every business operation and its database changes are traceable to the same transaction, thereby achieving efficient operation auditing and transaction rollback. Specifically, when executing a distributed microservice operation request, the operation logs of each business microservice are automatically captured and recorded. Simultaneously, audit logs are retrieved from a pre-set database, and a strongly correlated index is established between these logs using the transaction identifier. If any anomaly is detected during the operation, a rollback operation is automatically executed based on the constructed correlated index until the original operation is successfully processed or restored to its initial state. This effectively solves the technical problems of inefficient auditing and inadequate rollback functionality caused by fragmented logs in a distributed environment. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0027] Figure 1 This is a flowchart of an optional method for processing distributed microservice operation requests according to an embodiment of the present invention;

[0028] Figure 2 This is a schematic diagram of an optional distributed microservice operation auditing and transaction rollback system structure based on dual log linkage according to an embodiment of the present invention;

[0029] Figure 3This is a schematic diagram of an optional distributed microservice operation auditing and transaction rollback process based on dual log linkage according to an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of an optional distributed microservice operation request processing device according to an embodiment of the present invention;

[0031] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) for processing distributed microservice operation requests according to an embodiment of the present invention. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0033] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] To facilitate understanding of the present invention by those skilled in the art, some terms or nouns involved in the various embodiments of the present invention are explained below:

[0035] Dual-log collaboration mechanism: By strongly associating operation logs (business layer) and database audit logs (storage layer) using a global transaction ID (identifier), end-to-end tracing of the operation chain is achieved.

[0036] Lightweight database change snapshot technology: Utilizing bytecode-enhanced SQL (Structured Query Language) interceptors, it automatically captures before / after images of data changes, storing only the differences instead of the full data, thus reducing storage costs.

[0037] Transaction rollback engine: Supports three levels of rollback strategies, including: business operation rollback (reverse call to compensation interface), data version rollback (application database snapshot mirroring), and hybrid rollback (business compensation and data snapshot collaboration).

[0038] Log compression storage model: Replace the full log with an operation instruction set, and record the [operation type, affected field, old value, new value] quadruple to improve storage efficiency.

[0039] It should be noted that all related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data comply with the relevant laws, regulations, and standards of the relevant regions, necessary confidentiality measures have been taken, and it does not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface, and the relevant information is obtained only after receiving consent from the aforementioned user or organization.

[0040] This invention belongs to the field of distributed microservice technology and involves operation auditing, transaction rollback and log management technology. It proposes a distributed microservice operation auditing and transaction rollback method based on dual log linkage to solve problems such as fragmented audit logs, weak rollback capabilities, uncontrolled storage costs and the risk of operation chain breakage.

[0041] In this invention, a dual-log collaboration mechanism is used to strongly associate business operation logs and database audit logs through a global transaction ID, ensuring the integrity and traceability of the operation chain and achieving end-to-end tracing of the operation chain. Furthermore, lightweight database change snapshot technology and a log compression storage model are employed to reduce log storage space usage, improve storage efficiency, and lower storage costs. In addition, a three-level rollback strategy of the transaction rollback engine enables business operation rollback, data version rollback, and hybrid rollback, simplifying compensation logic writing, reducing error rates, and providing efficient transaction rollback capabilities.

[0042] The present invention will now be described in detail with reference to various embodiments.

[0043] Example 1

[0044] According to an embodiment of the present invention, an embodiment of a method for processing distributed microservice operation requests is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0045] Figure 1 This is a flowchart of an optional distributed microservice operation request processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0046] Step S101: Receive the distributed microservice operation request initiated by the user, and create a transaction identifier based on the distributed microservice operation request.

[0047] In this embodiment of the invention, a distributed microservice operation request initiated by a user (such as a user initiating an order payment request on an e-commerce platform) can be received first. When the request enters the system, a globally unique transaction identifier (TraceId) can be dynamically generated through a centralized service or component before business processing. This transaction identifier can be generated using the Snowflake algorithm (a distributed ID generation algorithm) combined with regional ID enhancement. It can serve as a "trace" in the distributed transaction, running through the entire microservice call chain, ensuring the traceability and integrity of the transaction.

[0048] In this embodiment of the invention, to ensure that transaction identifiers can be successfully transmitted within a distributed microservice architecture, they can be added to the HTTP (Hypertext Transfer Protocol) request header or the context of an RPC (Remote Procedure Call) call. In this way, regardless of how operations cross different microservice boundaries, transaction identifiers can be correctly identified and recorded, ensuring sufficient information to subsequently track and correlate various microservice activities throughout the entire operation.

[0049] Step S102: Based on the transaction identifier, execute the distributed microservice operation request and obtain the operation log of each business microservice that executes the distributed microservice operation request.

[0050] In this embodiment of the invention, during the processing of operation requests by various business microservices, a transaction identifier is used at each stage to mark and record the operation log of that service. Furthermore, within each microservice, Spring AOP (Aspect-Oriented Programming) technology is used to automatically capture operation parameters to obtain the operation logs of each business microservice executing the distributed microservice operation request.

[0051] Step S103: Obtain the audit logs of the preset database, and establish an association index between all operation logs and audit logs based on the transaction identifier.

[0052] In this embodiment of the invention, during the operation of distributed microservices, each service involving database operations generates corresponding database audit logs. These logs typically need to be stored in a unified, reliable database for later analysis and rollback. The default database can be a centralized audit log database or a transaction-level data warehouse.

[0053] In this embodiment of the invention, to effectively associate operation logs and database audit logs, a transaction identifier can be used as a key to index all logs, creating a relational index. This relational index allows for the rapid retrieval and association of all relevant logs using the transaction identifier. Both operation logs and database audit logs can be managed and viewed uniformly within the same transaction, improving log readability and auditing efficiency.

[0054] In step S104, if an exception occurs during the execution of a distributed microservice operation request, a rollback operation is performed based on the associated index until the distributed microservice operation request is successfully processed.

[0055] In this embodiment of the invention, if an anomaly is detected during the execution of a distributed microservice operation request, a rollback mechanism can be triggered immediately. Based on the associated index, the transaction rollback engine quickly locates all affected operation logs and database audit logs. The transaction rollback engine can determine the specific rollback operation based on a predefined rollback strategy (e.g., business operation rollback, data version rollback, or hybrid rollback). If there are pre-registered compensation interfaces (methods defined at the business level for undoing specific operations), the business state will be restored by reverse-calling these compensation interfaces first. For database-level changes, it can be checked whether there is a complete data snapshot. If so, the snapshot is directly applied to restore the database to its state before the change. If there is no complete snapshot but there is a compensation interface, a hybrid rollback strategy can be adopted, simultaneously executing business compensation and data snapshot rollback to restore the initial state of the entire transaction as much as possible. Through this series of rollback operations based on transaction identifier associated indexes, abnormal situations can be handled automatically and efficiently until the distributed microservice operation request can be successfully processed or the transaction state is completely rolled back to a safe point. In this way, not only is the writing and maintenance of rollback logic simplified, but the frequency of human intervention is also reduced, improving the stability and reliability of the system.

[0056] In summary, a distributed, unique transaction identifier can be created. This identifier is generated immediately upon receiving a user-initiated distributed microservice operation request and persists throughout the entire operation chain. This ensures that every business operation and its database changes are traceable to the same transaction, achieving efficient operation auditing and transaction rollback. Specifically, when a distributed microservice operation request is executed, the operation logs of each business microservice are automatically captured and recorded. Simultaneously, audit logs are retrieved from a pre-set database, and a strongly correlated index is established between these logs using the transaction identifier. If any anomaly is detected during the operation, a rollback operation is automatically executed based on the constructed correlated index until the original operation is successfully processed or restored to its initial state. This effectively solves the technical problems of inefficient auditing and incomplete rollback functionality caused by fragmented logs in a distributed environment.

[0057] To improve the accuracy of transaction identifier creation, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, the timestamp of the user initiating the distributed microservice operation request is obtained; the terminal identifier and physical location of the terminal initiating the distributed microservice operation request are obtained; and a transaction identifier is created based on the timestamp, terminal identifier, and physical location of the terminal.

[0058] In this embodiment of the invention, when the system receives a user's operation request, it can record the precise time the request arrived as a timestamp. This operation is typically accomplished by implementing a timestamp recording aspect in the front-end service node. The timestamp acquisition employs a high-precision clock synchronization mechanism, ensuring consistency and accuracy of time during cross-service calls. Simultaneously, the terminal identifier and physical location of the user initiating the distributed microservice operation request can be obtained. Here, the terminal identifier is a unique identifier for the user device, such as a MAC (Media Access Control) address or device ID, while the terminal's physical location is obtained through IP address positioning, GPS (Global Positioning System) information, or other positioning technologies. This information can be collected during the initial stage of user authentication or request, automatically extracted and recorded using features provided by middleware or frameworks.

[0059] In this embodiment of the invention, the Snowflake algorithm can be used to generate a base ID. Then, the timestamp, terminal identifier, and terminal physical location information are processed through a hash operation and appended to the base ID to form a composite transaction identifier that includes user operation time, device information, and geographical location. This not only ensures the global uniqueness of the transaction ID but also enriches the transaction's contextual information, providing a more comprehensive basis for subsequent auditing and rollback.

[0060] In this embodiment, the information dimensions of transaction identifiers are enriched, enabling operation auditing and transaction rollback processes to be accurate not only at the operation level, but also down to time, device, and geographical location, thereby improving the auditing accuracy of distributed microservice operations and the intelligence of rollback strategies.

[0061] To improve the accuracy of generated operation logs, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, the operation to be executed for each distributed microservice is determined based on the distributed microservice operation request; for each distributed microservice, when the distributed microservice executes the operation to be executed, the operation parameters are captured by a preset aspect; and the operation log is generated based on the operation parameters.

[0062] In this embodiment of the invention, when a user initiates an operation request, the request may involve multiple cooperating microservices. In this case, the system needs to parse the request, identify all the microservices involved in the operation and their respective sub-tasks. For example, the operation request can be parsed through a service gateway or service coordinator, and broken down into multiple sub-requests, which are then directed to the relevant microservices.

[0063] Within each microservice, one or more aspects are pre-defined using Spring AOP. These aspects are triggered at specified join points (usually before and after a method call), automatically intercepting and capturing the operation parameters of the calling method. This can be achieved using Spring's `@Around` annotation, for example, recording input parameters before the method call and recording output results after the method call. In this way, detailed records of the input and output of each service when processing requests can be maintained, providing comprehensive data for subsequent operation auditing and fault diagnosis. Once the operation parameters are captured, the system can generate corresponding operation logs based on these parameters.

[0064] Here, the operation log includes the service name, operation name, operation parameters, operation result, and contextual information about the operation (such as time, client information, etc.). The generation of the operation log can be accomplished by the enhancement corresponding to the aspect, which formats the captured operation parameters and other relevant information into log entries and saves them to the logging system. This ensures the completeness and accuracy of the operation log, facilitating subsequent auditing and rollback operations.

[0065] In this embodiment, the auditing capabilities of distributed microservice operations are enhanced, enabling fine-grained decomposition of operation requests and automated capture of operation parameters, ensuring detailed logging of every operation. This not only helps to quickly locate and resolve problems in distributed systems but also provides a solid data foundation for transaction rollback and operation analysis.

[0066] To improve the accuracy of generated audit logs, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, an interceptor is deployed in a preset database; when a change operation is detected in the preset database, the interceptor captures the change parameters of the preset database; and based on the change parameters, an audit log is generated.

[0067] In this embodiment of the invention, one or more interceptors can be deployed at the database access layer. For example, a plugin configuration can be added to the MyBatis (a persistence layer framework) configuration file to introduce a custom SQL interceptor. This interceptor is used to listen for and intercept all SQL operations on the preset database, especially data modification operations (such as insert, update, delete, etc.). When any application attempts to perform a data modification operation on the database, the pre-deployed SQL interceptor will be triggered. The interceptor will parse detailed information about the modification operation from the SQL statement, including the data table being operated on, the affected fields, and the data values ​​before and after the change. In addition, the interceptor will also capture the global transaction ID (TraceId) of this SQL operation.

[0068] In this embodiment of the invention, after the interceptor captures database change parameters, it converts this information into audit logs. The generation of audit logs follows certain formats and rules; for example, it may include key information such as the database name, data table, change operation type, affected fields, old value, new value, operation time, and global transaction ID. Audit logs can be stored in various ways, but considering efficiency and cost, a lightweight database change snapshot technique can be used, which stores only the differing fields instead of the full data to reduce storage overhead. Furthermore, to improve storage efficiency, a log compression storage model can be used, which converts the audit logs into a triple instruction set for storage.

[0069] In this embodiment, by deploying interceptors in a pre-defined database and capturing changing parameters in real time to generate audit logs, comprehensive monitoring and auditing methods are provided for database operations under a distributed microservice architecture. This not only helps to promptly detect and locate data anomalies but also provides necessary historical data snapshots in the event of failures or when transaction rollback is required. Simultaneously, the use of lightweight snapshot technology and a log compression storage model effectively balances the conflict between data integrity and storage costs, improving the overall performance and reliability of the system.

[0070] To further improve the accuracy of generated audit logs, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, the changed field of the change operation is determined; the original value of the changed field before the change operation is executed is queried, and the latest value of the changed field after the change operation is determined based on the change parameters corresponding to the changed field; a triple array of the changed field is constructed based on the changed field, the original value of the changed field, and the latest value; an initial audit log is generated based on all triple arrays, and the initial audit log is compressed to obtain the audit log.

[0071] In this embodiment of the invention, when the interceptor captures a data change operation, it can analyze the specific content of the change operation and identify all modified fields. This can be achieved by parsing SQL statements or listening to API (Application Programming Interface) calls. After determining the changed fields, the original values ​​of these fields before the change operation was executed can be queried. For example, the changed record can be locked, and its current state can be read so that data differences can be accurately captured in subsequent operations.

[0072] In this embodiment of the invention, the change parameters include the new value information of the fields after the change operation is executed. After the data change operation is submitted and successful, the interceptor can directly obtain the latest value from the change parameters. Then, it constructs a triplet for each pair of changed fields, original values, and latest values ​​and stores it in an array. This triplet array is the smallest audit unit of the database change operation, recording only the differences in fields, not the full data, which helps reduce the storage overhead of the audit log. Afterwards, all the constructed triplet arrays are integrated into a complete audit log. This audit log contains the global transaction ID (TraceId) of the change operation, the operation time, the database name, the table name, the change type, and the triplet information of all changed fields.

[0073] In this embodiment of the invention, efficient compression algorithms, such as Protocol Buffers (a data serialization and deserialization mechanism), can be used to compress the initial audit logs, thereby reducing the log storage space and improving storage and transmission efficiency. The compressed audit logs retain all necessary information but are smaller in size, making them easier to manage and analyze.

[0074] In this embodiment, by accurately capturing the details of database change operations, constructing differentiated audit logs, and storing them using a high-efficiency compression algorithm, the management of audit logs is greatly optimized. This not only reduces storage costs but also improves the readability and analyzability of the logs, providing crucial support for operation auditing and transaction rollback in a distributed microservice architecture, thereby enhancing the overall operational efficiency and data consistency assurance capabilities of the system.

[0075] To accurately execute rollback operations, the distributed microservice operation request processing method provided in Embodiment 1 of this application queries a preset database based on the association index to obtain audit logs; based on the audit logs, it is determined whether a database change operation has occurred; if no database change operation has occurred, the operation logs of each business microservice are determined based on the association index; based on the operation logs, the execution status of the business microservice is changed to an inactive state; if a database change operation has occurred, a rollback operation is performed on the preset database based on the audit logs.

[0076] In this embodiment of the invention, the global transaction ID (TraceId) can be used as a correlation index to query relevant audit logs in a preset database. The audit logs contain all information about the transaction, including whether a database change occurred, the type of change, the time of the change, the changed fields, and the data values ​​before and after the change. By analyzing the audit log records, it can be determined whether the transaction involved database modification operations. If the audit logs indicate that the transaction did not involve database changes, the system will further analyze the individual operation logs of the business microservices and, based on the information in the operation logs, change the status of each business microservice from executed to inexecuted.

[0077] If the audit log shows that the transaction did indeed involve database changes, the system will perform a data version rollback based on the snapshot information saved in the audit log. This data version rollback refers to using the before-image (values ​​before the change) and after-image (values ​​after the change) data in the audit log to restore the database to its state before the transaction began, ensuring data consistency.

[0078] In this embodiment, the linkage of dual logs enables fine-grained control and flexible rollback of transaction operations in a distributed microservice environment. Regardless of whether a transaction involves database changes, appropriate rollback strategies can be adopted through joint analysis of operation logs and audit logs. These strategies include business operation rollback, data version rollback, or hybrid rollback, thereby ensuring the stable operation of the system and the integrity of the data, and improving the robustness and operational efficiency of the system.

[0079] In order to accurately perform rollback operations on the preset database, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, based on the audit log, the latest value of all changed fields in the preset database is rolled back to the original value; in the case where the latest value of a changed field is not rolled back to the original value, the compensation interface is called in reverse to cancel the change to the changed field using the compensation interface.

[0080] In this embodiment of the invention, audit logs can be read, and rollback SQL statements can be constructed based on the changed fields, latest values, and original values ​​recorded therein. Executing these rolledback SQL statements rolls back the latest values ​​of the changed fields in the preset database to their original values, restoring the database to its state before the transaction began and ensuring data consistency. If the latest value in a changed field is not rolled back to its original value, the audit logs can be checked for pre-registered compensation interfaces. If such interfaces exist, they are called to achieve the rollback by reversing the business operations. If no compensation interface exists or the compensation interface fails to execute, a follow-up processing mechanism, such as manual intervention or a retry mechanism, is required. This ensures a complete transaction rollback; even if the database rollback is incomplete or fails, the transaction state can be restored through the reverse execution of business operations.

[0081] Here, the compensation interface is a reverse operation interface defined for a specific business operation, used to undo completed business operations, thereby achieving transaction rollback.

[0082] This embodiment combines a dual mechanism of database version rollback and business operation rollback to ensure the reliability and integrity of transaction rollback. By directly rolling back modified fields at the database level, the data state can be quickly and accurately restored. When database rollback encounters obstacles, reverse calls to the compensation interface provide additional protection, ensuring that the business state can be rolled back synchronously, thereby avoiding data inconsistency. This two-layer rollback mechanism makes transaction management in a distributed microservice environment more robust, effectively handling various abnormal situations and improving system stability and data consistency.

[0083] In order to accurately perform hybrid rollback on the preset database, in the distributed microservice operation request processing method provided in Embodiment 1 of this application, if an exception occurs during the execution of the distributed microservice operation request, and if the number of abnormal distributed microservice operation requests exceeds a preset threshold, a snapshot image of the preset database is used for data version rollback; if there are missing snapshots in the snapshot image, the compensation interface corresponding to the missing snapshot is called in reverse to perform hybrid rollback on the preset database.

[0084] In this embodiment of the invention, abnormal situations in distributed microservice operation requests can be monitored, and the number of abnormalities can be counted. When the number of abnormalities reaches a preset threshold, a rollback can be performed using the previous image (data state before the change) in the snapshot image to restore the database state. Here, abnormal situations refer to unexpected errors or exceptions that occur when executing distributed microservice operations, such as service unavailability, network interruption, data verification failure, etc. If there are missing snapshots in the snapshot image, it is possible to first identify which database change operations lack snapshots. For change operations with missing snapshots, the corresponding compensation interface is found and called to restore the business state by executing the reverse operation of the compensation interface. At the same time, combined with the result of data version rollback, a final hybrid rollback is performed to achieve the best rollback effect.

[0085] In this embodiment, not only can most of the database state be quickly restored through data version rollback, but also, when faced with the problem of missing snapshots, business compensation can be used to make up for the lack of data recovery, ensuring that data consistency is not affected.

[0086] The following describes in detail another optional implementation method.

[0087] In this embodiment of the invention, a distributed microservice operation auditing and transaction rollback system based on dual log linkage is proposed to solve problems such as fragmented audit logs, weak rollback capabilities, uncontrolled storage costs, and the risk of operation chain breakage.

[0088] Figure 2 This is a schematic diagram of an optional distributed microservice operation auditing and transaction rollback system architecture based on dual-log linkage according to an embodiment of the present invention, such as... Figure 2 As shown, the system includes: a log acquisition layer, a log processing layer, a transaction rollback layer, and a storage and transport layer. The functions of each layer are as follows:

[0089] (1) Log collection layer.

[0090] At the business layer, Spring AOP aspects are used to automatically capture operation parameters and generate operation logs.

[0091] At the data layer, a bytecode-enhanced SQL interceptor transparently captures database change operations and generates database audit logs.

[0092] (2) Log processing layer.

[0093] The Snowflake algorithm and region ID enhancement are used to create a distributed unique transaction ID, which is then transmitted across services via HTTPHeader / RPC Context. At the same time, the transaction ID is injected into the database connection, and a strong correlation index is established between the operation log and the database log.

[0094] Before performing a database change operation, query the old value (e.g., using SELECT FOR UPDATE). After submission, obtain the new value, generate a field-level difference triple [field name, old value, new value] using a reflection comparison algorithm, and store it using Protocol Buffers binary compression.

[0095] (3) Transaction rollback layer.

[0096] Check if a pre-registered compensation interface exists. If it does, roll back the business operation, i.e., call the compensation interface in reverse. If the full data snapshot is complete and reversible, roll back the data version and apply the database snapshot image. If some snapshots are missing but a compensation interface exists, perform a hybrid rollback, coordinating business compensation with the data snapshot.

[0097] (4) Storage and transport layer.

[0098] An operation instruction set is used instead of a full log, recording a four-tuple of [operation type, affected field, old value, new value] to improve storage efficiency, and asynchronous log pipelines are used for log transmission to achieve zero-blocking business threads.

[0099] Figure 3 This is a schematic diagram of an optional distributed microservice operation auditing and transaction rollback process based on dual-log linkage according to an embodiment of the present invention, as shown below. Figure 3 As shown, the process includes the following:

[0100] (1) Operation Initiation: A user initiates a distributed microservice operation request.

[0101] (2) Log collection: The business layer captures operation parameters through Spring AOP aspects to generate operation logs, and the data layer captures database change operations through SQL interceptors to generate database audit logs.

[0102] (3) Transaction ID allocation and transmission: Create a distributed unique transaction ID and transmit it across services through HTTP Header / RPCContext, while injecting the transaction ID into the database connection.

[0103] (4) Log association: Establish a strong association index between operation logs and database logs to ensure the integrity and traceability of the operation chain.

[0104] (5) Data change capture and storage: Before performing database change operations, query the old value, and after submission, obtain the new value. Generate field-level difference triples through reflection comparison algorithm and store them using Protocol Buffers binary compression.

[0105] (6) Transaction rollback judgment: Determine whether the transaction needs to be rolled back based on preset conditions. If it needs to be rolled back, proceed with the transaction rollback process.

[0106] (7) Transaction rollback execution: Select business operation rollback, data version rollback or hybrid rollback strategy according to the specific situation to achieve reliable transaction rollback.

[0107] The following section will take the order payment operation scenario in a distributed microservice environment as an example for detailed explanation.

[0108] (1) Operation Initiation: The user initiates an order payment request on the e-commerce platform.

[0109] (2) Log collection: The business layer captures the parameters of the order payment operation through Spring AOP aspect and generates operation logs; the data layer captures database operations such as order status change and payment amount change through SQL interceptor and generates database audit logs.

[0110] (3) Transaction ID allocation and transmission: Create a distributed unique transaction ID and transmit it across services through HTTP Header / RPCContext. At the same time, inject the transaction ID into the database connection to ensure that the operation logs and database logs of various microservices such as order service, payment service, and inventory service can be associated through the transaction ID.

[0111] (4) Data change capture and storage: When updating database operations such as order status and payment amount, the old value is queried before execution and the new value is obtained after submission. Field-level difference triples are generated through reflection comparison algorithm, such as [order status, unpaid, paid], [payment amount, 0, 100], etc., and Protocol Buffers binary compression storage is used to store only the difference fields instead of the full data, thereby reducing storage costs.

[0112] (5) Transaction Rollback Judgment and Execution: Assuming that the payment service call fails during the payment process, the system determines that the transaction needs to be rolled back. Since there are pre-registered compensation interfaces (such as order cancellation and inventory rollback), the business operation is rolled back first, and the compensation interface is called in reverse to cancel the order and roll back the inventory. At the same time, for operations such as order status changes and payment amount changes in the database, since the full data snapshot is complete and reversible, the data version is rolled back, and the database snapshot image is used to restore the data to the state before the change. If some snapshots are missing but compensation interfaces exist, a mixed rollback is performed, coordinating business compensation and data snapshots to ensure the integrity and consistency of the transaction.

[0113] In this embodiment of the invention, an end-to-end tracing of the operation chain is achieved through a dual-log collaboration mechanism, avoiding manual log splicing across systems and improving operation auditing efficiency. Furthermore, lightweight database change snapshot technology and a log compression storage model effectively reduce log storage space usage and lower storage costs. In addition, the three-level rollback strategy of the transaction rollback engine simplifies the writing of compensation logic, reduces the error rate, and ensures reliable transaction rollback in a distributed microservice environment. Simultaneously, the non-intrusive log collection method achieves zero blocking of business threads and has minimal impact on business performance.

[0114] The following is a detailed description with reference to another embodiment.

[0115] Example 2

[0116] The distributed microservice operation request processing device provided in this embodiment includes multiple implementation units, each of which corresponds to a specific implementation step in Embodiment 1 above.

[0117] Figure 4 This is a schematic diagram of an optional distributed microservice operation request processing apparatus according to an embodiment of the present invention, such as... Figure 4As shown, the processing device may include: a creation unit 40, a first acquisition unit 41, a second acquisition unit 42, and an execution unit 43.

[0118] The creation unit 40 is used to receive distributed microservice operation requests initiated by users and create transaction identifiers based on the distributed microservice operation requests.

[0119] The first acquisition unit 41 is used to execute a distributed microservice operation request based on the transaction identifier, and to acquire the operation log of each business microservice that executes the distributed microservice operation request.

[0120] The second acquisition unit 42 is used to acquire the audit logs of the preset database and establish an association index between all operation logs and the audit logs based on the transaction identifier;

[0121] Execution unit 43 is used to perform a rollback operation based on the associated index in the event of an exception during the execution of a distributed microservice operation request, until the distributed microservice operation request is successfully processed.

[0122] The aforementioned processing device employs a method of creating a distributed, unique transaction identifier. By immediately generating this identifier upon receiving a user-initiated distributed microservice operation request and maintaining it throughout the entire operation chain, it ensures that every business operation and its database changes can be traced back to the same transaction, thereby achieving the technical effects of efficient operation auditing and transaction rollback. Specifically, when executing a distributed microservice operation request, it automatically captures and records the operation logs of each business microservice, while simultaneously retrieving audit logs from a pre-set database and establishing a strongly correlated index among these logs using the transaction identifier. If any anomaly is detected during the operation, a rollback operation is automatically executed based on the constructed correlated index until the original operation is successfully processed or restored to its initial state. This effectively solves the technical problems of inefficient auditing and incomplete rollback functionality caused by fragmented logs in a distributed environment.

[0123] Optionally, the creation unit includes: a first acquisition module for acquiring the timestamp of the user's distributed microservice operation request; a second acquisition module for acquiring the terminal identifier and physical location of the terminal that initiated the distributed microservice operation request; and a first creation module for creating a transaction identifier based on the timestamp, terminal identifier, and physical location of the terminal.

[0124] Optionally, the first acquisition unit includes: a first determination module, configured to determine the operation to be executed for each distributed microservice based on the distributed microservice operation request; a first capture module, configured to capture operation parameters for each distributed microservice by means of a preset aspect when the distributed microservice is executing the operation to be executed; and a first generation module, configured to generate an operation log based on the operation parameters.

[0125] Optionally, the second acquisition unit includes: a first deployment module for deploying an interceptor in a preset database; a second capture module for capturing the change parameters of the preset database using the interceptor when a change operation is detected in the preset database; and a second generation module for generating audit logs based on the change parameters.

[0126] Optionally, the second generation module includes: a first determination submodule, used to determine the changed field where the change operation occurred; a first query submodule, used to query the original value of the changed field before the change operation was performed, and determine the latest value of the changed field after the change operation was performed based on the change parameters corresponding to the changed field; a first construction submodule, used to construct a triple array of the changed field based on the changed field, the original value of the changed field, and the latest value; and a first generation submodule, used to generate an initial audit log based on all triple arrays, and compress the initial audit log to obtain the audit log.

[0127] Optionally, the execution unit includes: a first query module, used to query a preset database based on the associated index to obtain audit logs; a first judgment module, used to determine whether a database change operation has occurred based on the audit logs; a second determination module, used to determine the operation logs of each business microservice based on the associated index if no database change operation has occurred; a first change module, used to change the execution status of the business microservice to an inactive state based on the operation logs; and a first rollback module, used to perform a rollback operation on the preset database based on the audit logs if a database change operation has occurred.

[0128] Optionally, the first rollback module includes: a first rollback submodule, used to roll back the latest value of all changed fields in the preset database to the original value based on the audit log; and a first call submodule, used to reverse call the compensation interface in the case where the latest value of a changed field has not been rolled back to the original value, so as to cancel the change to the changed field using the compensation interface.

[0129] Optionally, the processing device further includes: a second rollback module, used to perform data version rollback using a snapshot image of a preset database when an exception occurs during the execution of a distributed microservice operation request and the number of abnormal distributed microservice operation requests exceeds a preset threshold; and a first invocation module, used to reverse-invoke the compensation interface corresponding to the missing snapshot to perform a hybrid rollback of the preset database when the snapshot image contains missing snapshots.

[0130] The aforementioned processing device may further include a processor and a memory. The creation unit 40, the first acquisition unit 41, the second acquisition unit 42, the execution unit 43, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0131] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, a rollback operation can be performed based on associated indexes in the event of an exception during the execution of a distributed microservice operation request, until the distributed microservice operation request is successfully processed.

[0132] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0133] This invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialization program with the following method steps: receiving a distributed microservice operation request initiated by a user, creating a transaction identifier based on the distributed microservice operation request, executing the distributed microservice operation request based on the transaction identifier, obtaining the operation log of each business microservice executing the distributed microservice operation request, obtaining the audit log of a preset database, and establishing an association index between all operation logs and audit logs based on the transaction identifier; in the event of an exception during the execution of the distributed microservice operation request, performing a rollback operation based on the association index until the distributed microservice operation request is successfully processed.

[0134] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements a method for processing distributed microservice operation requests as described above.

[0135] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the above-described method for processing distributed microservice operation requests.

[0136] Figure 5 This is a hardware structure block diagram of an electronic device (or mobile device) for processing distributed microservice operation requests according to an embodiment of the present invention. Figure 5 As shown, an electronic device may include one or more processors (e.g., Figure 5 The processors 502a, 502b, ..., 502n, etc., may include, but are not limited to, processing devices such as microprocessors (MCUs) or programmable logic devices (FPGAs), and a memory 504 for storing data. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports in the I / O interface), a network interface, a keyboard, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 5 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 5 The more or fewer components shown, or having the same Figure 5 The different configurations shown.

[0137] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0138] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0139] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0140] In the several embodiments provided by this invention, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection can be through some interfaces; the indirect coupling or communication connection of units or modules can be electrical or other forms.

[0141] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0143] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0144] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for processing distributed microservice operation requests, characterized in that, include: Receive distributed microservice operation requests initiated by users, and create transaction identifiers based on the distributed microservice operation requests; Based on the transaction identifier, execute the distributed microservice operation request and obtain the operation log of each business microservice that executes the distributed microservice operation request; Obtain the audit logs of the preset database, and based on the transaction identifier, establish an association index between all the operation logs and the audit logs; If an exception occurs during the execution of the distributed microservice operation request, a rollback operation is performed based on the associated index until the distributed microservice operation request is successfully processed.

2. The processing method according to claim 1, characterized in that, The steps for creating a transaction identifier based on the distributed microservice operation request include: Obtain the timestamp of the user's request to initiate the distributed microservice operation; Obtain the terminal identifier and physical location of the terminal that initiated the distributed microservice operation request by the user; The transaction identifier is created based on the timestamp, the terminal identifier, and the physical location of the terminal.

3. The processing method according to claim 1, characterized in that, The steps for obtaining the operation logs of each business microservice executing the distributed microservice operation request include: Based on the distributed microservice operation request, determine the operation to be executed for each of the distributed microservices; For each of the distributed microservices, when the distributed microservices execute the operation to be executed, the operation parameters are captured through a preset aspect. The operation log is generated based on the operation parameters.

4. The processing method according to claim 1, characterized in that, The steps to obtain the audit logs of the preset database include: Deploy an interceptor in the preset database; If a change operation is detected in the preset database, the interceptor is used to capture the change parameters of the preset database; The audit log is generated based on the changed parameters.

5. The processing method according to claim 4, characterized in that, The steps for generating the audit log based on the changed parameters include: Identify the changed fields in which the change operation occurred; Query the original value of the changed field before the change operation is performed, and determine the latest value of the changed field after the change operation is performed based on the change parameter corresponding to the changed field; Based on the changed field, the original value corresponding to the changed field, and the latest value, construct a triple array of the changed field; Based on all the aforementioned triple arrays, an initial audit log is generated, and the initial audit log is compressed to obtain the audit log.

6. The processing method according to claim 1, characterized in that, In the event of an exception during the execution of the distributed microservice operation request, the steps for performing a rollback operation based on the associated index include: Based on the associated index, the preset database is queried to obtain the audit log; Based on the audit logs, determine whether a database change operation has occurred; In the absence of the database change operation, the operation log of each of the business microservices is determined based on the associated index; Based on the operation log, the execution status of the business microservice is changed to an unexecuted status; In the event of the database change operation, a rollback operation is performed on the preset database based on the audit log.

7. The processing method according to claim 6, characterized in that, The steps for performing a rollback operation on the preset database based on the audit logs include: Based on the audit log, the latest values ​​in all changed fields in the preset database are rolled back to their original values; If the latest value in the changed field has not been rolled back to the original value, the compensation interface is called in reverse to cancel the change to the changed field.

8. The processing method according to claim 1, characterized in that, In the event of an exception during the execution of the distributed microservice operation request, the following additional conditions may be met: If the number of abnormal distributed microservice operation requests exceeds a preset threshold, a data version rollback is performed using a snapshot image of the preset database. In the event that a snapshot image is missing, the compensation interface corresponding to the missing snapshot is called in reverse to perform a mixed rollback on the preset database.

9. A processing apparatus for distributed microservice operation requests, characterized in that, include: A creation unit is used to receive distributed microservice operation requests initiated by users and create a transaction identifier based on the distributed microservice operation requests; The first acquisition unit is used to execute the distributed microservice operation request based on the transaction identifier, and to acquire the operation log of each business microservice that executes the distributed microservice operation request; The second acquisition unit is used to acquire the audit logs of the preset database and, based on the transaction identifier, establish an association index between all the operation logs and the audit logs; The execution unit is configured to perform a rollback operation based on the associated index in the event of an exception during the execution of the distributed microservice operation request, until the distributed microservice operation request is successfully processed.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the distributed microservice operation request processing method according to any one of claims 1 to 8.

Images