Micro-service order processing and transaction consistency guaranteeing method and system based on event driving
By adopting an event-driven microservice-based order processing approach, the data consistency problem in the order management system was solved, cross-service transaction consistency was guaranteed, and the system's reliability and observability were improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 深圳市链宇技术有限公司
- Filing Date
- 2026-01-19
- Publication Date
- 2026-05-05
AI Technical Summary
Existing order management systems lack a global and reliable transaction coordination mechanism when faced with diverse and complex order sources, making it difficult to resolve data inconsistency issues and affecting business reliability and customer experience.
An event-driven microservice-based order processing approach is adopted, which transmits order events through a distributed message middleware, generates order lifecycle events and their state change sequences, and periodically scans the microservice data stream for anomaly detection and automatic repair, thereby achieving consistency assurance across microservice transactions.
It ensures the eventual consistency of business data across services, improves the reliability, observability, and maintainability of the order system, realizes the transformation from passive processing to proactive protection, and enhances security and stability.
Smart Images
Figure CN121981801A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of distributed systems and transaction processing technology, and in particular to an event-driven microservice-based method and system for order processing and transaction consistency assurance. Background Technology
[0002] Currently, order management systems serve as the core hub of enterprise supply chain and sales operations, handling the entire business process from order receipt and fulfillment to delivery. With the rapid development of e-commerce, omnichannel retail, and complex supply chains, modern enterprises face increasingly diversified order sources (such as e-commerce platforms, ERP systems, EDI interfaces, mobile terminals, etc.), and order processing logic has become extremely complex due to differences in product types, delivery models, and customer groups.
[0003] To address this complexity, traditional order management systems often employ monolithic architectures or coarse-grained service-oriented architectures. However, these architectures reveal significant shortcomings when dealing with high concurrency and ever-changing business demands: Existing solutions rely heavily on simple asynchronous messages or scheduled tasks for state synchronization, lacking a global and reliable transaction coordination mechanism. When a service fails, it is difficult to automatically and accurately roll back other successfully executed service operations, easily leading to data inconsistencies (e.g., orders created but inventory not deducted, or inventory locked but orders ultimately canceled), severely impacting business reliability and customer experience. The lack of proactive monitoring and automatic repair capabilities for business logic and data consistency results in business losses. Summary of the Invention
[0004] To address the problems mentioned above, this invention provides an event-driven microservice-based order processing and transaction consistency guarantee method and system to solve the problems of weak cross-service transaction consistency guarantee mechanism and difficulty in locating and resolving data anomaly issues mentioned in the background art.
[0005] An event-driven microservice-based method for order processing and transaction consistency assurance includes the following steps: It receives and parses order requests from multiple channels, generates standardized initial order creation events based on a configurable rule engine, and asynchronously transmits order events using a distributed message middleware. Based on the triggered business logic, multiple related microservices are generated for order events and state snapshots of the transaction domain objects of each microservice are stored. Based on the state snapshots, order lifecycle events and their state change sequences for each order are generated. The execution results of cross-microservice transactions for each order are determined based on the order lifecycle events and their state change sequences, and compensation operations are triggered based on the source tracing records when the execution results fail. Regularly scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and display the full-link processing status of each order in real time.
[0006] Preferably, the step of receiving and parsing order requests from multiple channels, generating standardized initial order creation events based on a configurable rule engine, and asynchronously transmitting order events using a distributed message middleware includes: The multi-channel order access gateway receives original order requests, identifies the source channel and protocol format of each original order request, selects the data acquisition method based on the protocol format, and obtains the original order data of each original order request from the source channel. The original order data is processed sequentially according to a predefined set of rules, including validation, cleaning, mapping, enrichment, and routing decision processing. The processed raw order data is converted into standardized order objects with a unified structure definition, and the standardized order objects are encapsulated as initial order creation events. Asynchronously publish the initial order creation event to a specified topic or queue in the distributed message middleware cluster.
[0007] Preferably, the step of receiving original order requests through a multi-channel order access gateway, identifying the source channel and protocol format of each original order request, selecting a data acquisition method based on the protocol format, and obtaining the original order data for each original order request from the source channel includes: By deploying multiple protocol listeners on the gateway, connection requests from different channels are continuously monitored; When any protocol listener receives an original order request, it extracts the metadata of the original order request and identifies the specific source channel and protocol format of the original order request based on the channel identifier, protocol characteristics and request characteristics in the metadata. Based on the identified protocol format, the corresponding data acquisition adapter is dynamically selected and loaded from the pre-configured adapter registry; The data acquisition adapter is invoked, and the communication specifications of the identified protocol format are followed to interact with the source channel and obtain complete original order data.
[0008] Preferably, the step of performing multiple related microservices on order events based on triggered business logic and storing state snapshots of the domain objects of each microservice transaction, and generating order lifecycle events and their state change sequences for each order based on the state snapshots, includes: Based on the business logic of each order management microservice, the domain state machine of the order management microservice is driven to update the initial entity state snapshot corresponding to the order event and store the initial entity state snapshot in the global state-event storage center. Each order event is processed in parallel by the inventory microservice and the fulfillment microservice, which respectively drive their respective domain state machines to update the inventory reservation state and generate the fulfillment plan state, store their respective subsequent entity state snapshots, and publish relevant domain events; For subsequent microservices that repeatedly trigger, process, store, and publish, until all relevant microservices involved in the order process complete their business logic and update their status; The order lifecycle sequence generator generates a complete lifecycle event and its state change sequence for each order based on the state snapshots of all related entities stored in the global state-event storage center, according to the timeline and business logic.
[0009] Preferably, the step of generating a complete lifecycle event and its state change sequence for each order by means of an order lifecycle sequence generator based on state snapshots of all related entities for each order stored in the global state-event storage center, according to timeline and business logic, includes: Based on the order identifier of each order, query the global state-event storage center to obtain a set of state snapshots of all domain entities logically associated with that order; Extract the state effective timestamp field from each state snapshot in the state snapshot set, perform global time-series sorting on all snapshots, and generate a state snapshot timeline; Scan the state snapshot timeline, aggregate multiple consecutive related state snapshots according to predefined business logic rules, and interpret them as order lifecycle events with high-level business semantics; Arrange all generated order lifecycle events in chronological order of their corresponding state snapshots, and output a complete lifecycle event sequence for each order.
[0010] Preferably, the step of determining the cross-microservice transaction execution result of each order based on the order lifecycle events and their state change sequence, and triggering compensation operations based on the source tracing record when the execution result fails, includes: Based on the order lifecycle event sequence, a pre-defined transaction success / failure determination rule base is used to determine the final execution result of the cross-microservice distributed transaction corresponding to each order; When a transaction fails, the sequence of lifecycle events that caused the failure is analyzed, and the detailed event tracing records in the global state-event storage center are combined to locate the specific microservice operation that was successfully executed but needs to be rolled back or corrected. Determine the set of rollback or correction operations for a specific microservice operation, and determine the execution objects and order of compensation operations based on the set of rollback or correction operations; Based on the execution object and order of the compensation operation, a sequence of compensation instructions for a specific microservice is generated, and the compensation interface of the specific microservice is called in reverse order of business dependencies to perform the compensation operation.
[0011] Preferably, determining the set of rollback or correction operations for a specific microservice operation, and determining the execution objects and order of compensation operations based on the set of rollback or correction operations, includes: Obtain the business activity execution list corresponding to a specific microservice operation, and determine the necessary rollback operation subset in the business activity execution list based on the pre-built business activity dependency graph; For other operations not included in the required rollback operation subset in the business activity execution list, assess whether they can exist independently in a business isolation state. If not, add them to the recommended modified operation subset. Merge the necessary rollback operation subset and the suggested correction operation subset to form the final rollback and correction operation set; Based on the dependencies between operations, the degree of data coupling, and business rules, determine the execution objects and execution order of each compensation operation in the rollback and correction operation set, and generate a compensation instruction execution plan.
[0012] Preferably, the step of periodically scanning the microservice data stream of each order and performing anomaly detection and automatic data repair, and displaying the full-link processing status of each order in real time, includes: According to the scheduling strategy, the microservice data stream for each order range is obtained from the global state-event storage center. The microservice data stream is then matched with rules based on the pre-set anomaly detection rule base to detect abnormal data. Determine the data type of the abnormal data, match the repair strategy according to the data type, generate and execute repair operations for automatic repair items allowed by the repair strategy, and generate repair work orders for manual repair items that require manual handling. Dynamically aggregate the latest end-to-end status information of each order after consistency verification, and render each node, status and anomaly point in the end-to-end status information in real time in the form of a graphical timeline or topology diagram; Highlight, warn, or block abnormal states detected.
[0013] Preferably, the step of obtaining the microservice data stream for each order range from the global state-event storage center according to the scheduling strategy, and performing rule matching on the microservice data stream according to a pre-set anomaly detection rule base to detect abnormal data includes: The current completion stage of each order is determined from the global state-event storage center, and it is determined whether the current completion stage meets the specific stage requirements. If so, the scheduling strategy is triggered by the order status to obtain the full microservice data stream for each order from the global state-event storage center; The entire microservice data stream is converted into fact objects that the rule engine can process, and the rule engine performs rule matching based on the fact objects of the pre-built anomaly detection rule base. The system detects abnormal data in the full microservice data stream by matching rules. The abnormal data includes data inconsistencies, logical conflicts, and process violations.
[0014] An event-driven, microservice-based order processing and transaction consistency guarantee system, comprising: The first generation module is used to receive and parse order requests from multiple channels, generate standardized initial order creation events based on a configurable rule engine, and asynchronously transmit order events using a distributed message middleware. The second generation module is used to perform multiple related microservices on order events based on the triggered business logic and store state snapshots of the domain objects of each microservice transaction. Based on the state snapshots, it generates the order lifecycle events and their state change sequences for each order. The determination module is used to determine the cross-microservice transaction execution result of each order based on the order lifecycle events and their state change sequence, and to trigger compensation operations based on the traceability record when the execution result fails. The data anomaly detection and repair module is used to periodically scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and display the full-link processing status of each order in real time.
[0015] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.
[0016] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.
[0018] Figure 1 The flowchart illustrates the event-driven microservice-based order processing and transaction consistency guarantee method provided by this invention. Figure 2 This is another flowchart of an event-driven microservice-based order processing and transaction consistency guarantee method provided by the present invention; Figure 3 This is another flowchart of an event-driven microservice-based order processing and transaction consistency guarantee method provided by the present invention. Figure 4This is a schematic diagram of the structure of an event-driven microservice-based order processing and transaction consistency guarantee system provided by the present invention. Detailed Implementation
[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0020] An event-driven, microservice-based method for order processing and transaction consistency assurance, such as... Figure 1 As shown, it includes the following steps: Step S101: Receive and parse order requests from multiple channels, generate standardized initial order creation events based on a configurable rule engine, and asynchronously transmit order events using a distributed message middleware; Step S102: Based on the triggered business logic, perform multiple related microservices on the order event and store the state snapshots of the transaction domain objects of each microservice. Generate the order lifecycle event and its state change sequence for each order based on the state snapshots. Step S103: Determine the cross-microservice transaction execution result of each order based on the order lifecycle events and their state change sequence, and trigger compensation operation based on the source tracing record when the execution result fails; Step S104: Regularly scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and display the full-link processing status of each order in real time.
[0021] In this embodiment, related microservices refer to a set of independently deployed microservices that need to work together to complete the same order processing flow according to business rules or event routing mechanisms, and their relevance is determined by a predefined business process model or event subscription relationship.
[0022] In this embodiment, a state snapshot refers to the persistent recording of the business state and key attributes of a specific domain object in a microservice at a specific point in time.
[0023] In this embodiment, the order lifecycle event refers to a high-level business event list that is generated by aggregating and interpreting state snapshots of multiple related microservices, sorted by time, and reflecting the entire process of an order from creation to termination.
[0024] In this embodiment, the cross-microservice transaction execution result refers to the determination of the final state of the order processing flow across multiple microservices. The results include: "success" (all necessary steps were completed as expected), "final failure" (terminated due to an unrecoverable error), and "compensated" (compensation operations have been performed after the failure).
[0025] In this embodiment, the compensation operation refers to the invocation of a dedicated interface provided by the microservice or the execution of specific business logic to undo or correct the impact of a successfully executed microservice operation.
[0026] In this embodiment, abnormal data refers to data, states, or event combinations in the microservice data flow that violate predefined constraints in the anomaly detection rule base.
[0027] In this embodiment, the end-to-end processing status refers to a unified view of order progress for global visualization, formed by aggregating the latest "status snapshots" of orders across all "related microservices" and performing consistency checks. It visually displays the order status at key nodes such as "receive - confirmation - fulfillment - shipment - receipt".
[0028] The working principle of the above technical solution is as follows: It receives and parses order requests from multiple channels, generates standardized initial order creation events based on a configurable rule engine, and asynchronously transmits order events using a distributed message middleware; it triggers business logic to perform multiple related microservices on order events and stores state snapshots of the domain objects of each microservice transaction; it generates order lifecycle events and their state change sequences for each order based on the state snapshots; it determines the cross-microservice transaction execution results for each order based on the order lifecycle events and their state change sequences, and triggers compensation operations based on the source tracing records when the execution results fail; it periodically scans the microservice data streams of each order and performs anomaly detection and automatic data repair, displaying the full-link processing status of each order in real time.
[0029] The beneficial effects of the above technical solution are as follows: by organically combining the four major processes of multi-channel access and event generation, state snapshot and lifecycle management, transaction result judgment and intelligent compensation, and continuous monitoring and visualization, it not only ensures the final consistency of cross-service business data, but also significantly improves the reliability, observability and maintainability of the order system through full-link state tracking and automated anomaly handling. It realizes the transformation from passive processing to proactive protection, improves security, stability and reliability, and solves the problems of weak cross-service transaction consistency guarantee mechanism and difficulty in locating and solving data anomaly problems mentioned in the existing technology.
[0030] In one embodiment, such as Figure 2As shown, the process of receiving and parsing order requests from multiple channels, generating standardized initial order creation events based on a configurable rule engine, and asynchronously transmitting order events using a distributed message middleware includes: Step S201: Receive original order requests through the multi-channel order access gateway, identify the source channel and protocol format of each original order request, select the data acquisition method based on the protocol format, and obtain the original order data of each original order request from the source channel; Step S202: Perform validation, cleaning, mapping, enrichment, and routing decision processing on the original order data in sequence according to the predefined rule set; Step S203: Convert the processed raw order data into a standardized order object with a unified structure definition, and encapsulate the standardized order object into an initial order creation event; Step S204: Asynchronously publish the initial order creation event to a specified topic or queue of the distributed message middleware cluster.
[0031] In this embodiment, the original order data is processed sequentially according to a predefined set of rules, including: verification, cleaning, mapping, enrichment, and routing decision processing. Format validation and cleaning rules: Validate and automatically correct the field formats, required fields, and value ranges of the original order data; Business logic validation rules: Validate order validity based on customer credit rating, product inventory status, and regional sales strategy; Data mapping and conversion rules: Map heterogeneous field names, encoding systems, and numerical units from different channels to unified fields, encodings, and units within the system; Data enrichment rules: Based on the original order data, automatically complete or calculate derived fields. The derived fields include at least: customer level, product category, expected gross profit margin, and recommended fulfillment factory. Routing and distribution rules: Based on the order characteristics, determine the subsequent processing flow that the order is expected to trigger or the specific topic that should be published to the message middleware.
[0032] The beneficial effects of the above technical solution are as follows: by introducing a multi-channel order access gateway and a configurable rule engine, the original, unstructured order data is transformed into unified standardized events within the system, laying a clean and consistent data foundation for subsequent processing. Furthermore, by using a distributed message middleware for asynchronous transmission, the order access layer and the core processing layer are decoupled, improving the system's throughput, response speed, and overall scalability.
[0033] In one embodiment, the step of receiving original order requests through a multi-channel order access gateway, identifying the source channel and protocol format of each original order request, selecting a data acquisition method based on the protocol format, and obtaining the original order data for each original order request from the source channel includes: By deploying multiple protocol listeners on the gateway, connection requests from different channels are continuously monitored; When any protocol listener receives an original order request, it extracts the metadata of the original order request and identifies the specific source channel and protocol format of the original order request based on the channel identifier, protocol characteristics and request characteristics in the metadata. Based on the identified protocol format, the corresponding data acquisition adapter is dynamically selected and loaded from the pre-configured adapter registry; The data acquisition adapter is invoked, and the communication specifications of the identified protocol format are followed to interact with the source channel and obtain complete original order data.
[0034] In this embodiment, the different channels include: HTTP / HTTPS server, message queue consumer, FTP / SFTP client, database connection pool and file system monitor, which are divided into active push channel, pull channel, batch file channel and database channel, etc.
[0035] In this embodiment, the data acquisition adapter is a pluggable component, and each adapter encapsulates all the details of interacting with a specific protocol format, including: HTTP / HTTPS adapter: Used to handle RESTful API or SOAP Web Service calls, supports GET and POST methods, and handles authentication, parameter parsing and response body extraction; Message queue adapter: Used to consume messages from message middleware such as Kafka, RabbitMQ, and RocketMQ, supporting consumer group management, offset commit, and message deserialization; File transfer adapter: Used to connect to FTP and SFTP servers to perform file list retrieval, file download, and content parsing; Database adapter: Used to connect to relational or non-relational databases and execute predefined query statements to retrieve order data; Streaming interface adapter: Used to handle WebSocket long connections or Server-Sent Events, receiving data streams in real time and segmenting them into individual order requests.
[0036] In this embodiment, the specific process of obtaining the original order data includes: For proactive push channels: extract the data payload directly from the received request message; For pull-based channels: the adapter actively initiates a request or subscription to the source channel and waits for a response; For batch file-based channels: The adapter downloads the files and, according to preset file format parsing rules, splits the file content into multiple independent original order data records; For database-type channels: the adapter executes the query and converts the result set into a collection of order data records.
[0037] The beneficial effects of the above technical solution are as follows: by automatically identifying channels and protocols through a protocol listener and dynamically acquiring data using a pluggable adapter, seamless and adaptive access to various channels is achieved. This greatly enhances flexibility and scalability, eliminating the need to modify core code when accessing new channels, reducing maintenance costs, and ensuring the reliability and security of data acquisition.
[0038] In one embodiment, the step of performing multiple related microservices on order events based on triggered business logic and storing state snapshots of the transaction domain objects of each microservice, and generating order lifecycle events and their state change sequences for each order based on the state snapshots, includes: Based on the business logic of each order management microservice, the domain state machine of the order management microservice is driven to update the initial entity state snapshot corresponding to the order event and store the initial entity state snapshot in the global state-event storage center. Each order event is processed in parallel by the inventory microservice and the fulfillment microservice, which respectively drive their respective domain state machines to update the inventory reservation state and generate the fulfillment plan state, store their respective subsequent entity state snapshots, and publish relevant domain events; For subsequent microservices that repeatedly trigger, process, store, and publish, until all relevant microservices involved in the order process complete their business logic and update their status; The order lifecycle sequence generator generates a complete lifecycle event and its state change sequence for each order based on the state snapshots of all related entities stored in the global state-event storage center, according to the timeline and business logic.
[0039] The beneficial effects of the above technical solution are as follows: By introducing a domain state machine into each microservice and persistently updating the stored state snapshots, a reliable state record core is established for distributed order processing. The effects of business operations are solidified into an immutable sequence of state snapshots, which are then corroborated by the event stream. This forms the cornerstone for achieving transaction consistency analysis, fault diagnosis, and business auditing.
[0040] In one embodiment, such as Figure 3As shown, the step of generating a complete lifecycle event and its state change sequence for each order by using the order lifecycle sequence generator based on the state snapshots of all related entities for each order stored in the global state-event storage center, according to the timeline and business logic, includes: Step S301: Based on the order identifier of each order, query and obtain the set of state snapshots of all domain entities logically associated with the order from the global state-event storage center; Step S302: Extract the state effective timestamp field from each state snapshot in the state snapshot set, perform global time-series sorting on all snapshots, and generate a state snapshot timeline; Step S303: Scan the state snapshot timeline, aggregate multiple consecutive related state snapshots according to predefined business logic rules, and interpret them as order lifecycle events with high-level business semantics; Step S304: Arrange all generated order lifecycle events in chronological order of their corresponding state snapshots, and output a complete lifecycle event sequence for each order.
[0041] The beneficial effects of the above technical solution are as follows: by aggregating and interpreting discrete state snapshots, it intelligently constructs an easily understandable sequence of business events that reflects the complete lifecycle of an order. This greatly improves the observability of the system, enabling complex distributed processing flows to be presented with a clear business storyline, providing intuitive and powerful data support for operational monitoring, customer service, and business analysis.
[0042] In one embodiment, determining the cross-microservice transaction execution result of each order based on order lifecycle events and their state change sequences, and triggering compensation operations based on the source tracing record when the execution result fails, includes: Based on the order lifecycle event sequence, a pre-defined transaction success / failure determination rule base is used to determine the final execution result of the cross-microservice distributed transaction corresponding to each order; When a transaction fails, the sequence of lifecycle events that caused the failure is analyzed, and the detailed event tracing records in the global state-event storage center are combined to locate the specific microservice operation that was successfully executed but needs to be rolled back or corrected. Determine the set of rollback or correction operations for a specific microservice operation, and determine the execution objects and order of compensation operations based on the set of rollback or correction operations; Based on the execution object and order of the compensation operation, a sequence of compensation instructions for a specific microservice is generated, and the compensation interface of the specific microservice is called in reverse order of business dependencies to perform the compensation operation.
[0043] In this embodiment, the pre-defined transaction success / failure determination rule base includes: Success determination rule: When the order lifecycle event sequence contains the "order transaction closed loop completed" event, and no "abnormal" or "cancelled" status events appear in the sequence, the transaction is determined to be successful; Failure determination rules: When a preset failure flag event occurs in the order lifecycle event sequence, including "abnormal order termination", "permanent inventory shortage", "final payment failure" or "customer cancellation" event, the transaction is determined to have failed; Timeout determination rule: If an order fails to reach the "shipped" status within the preset maximum fulfillment time and there are no active event updates, the transaction is deemed to have timed out.
[0044] In this embodiment, when a transaction is determined to have failed, the sequence of order lifecycle events that caused the failure is analyzed, and combined with detailed event tracing records in the global state-event storage center, the specific microservice operation that was successfully executed but needs to be rolled back or corrected is located, including: Failure root cause localization: Identify the first abnormal event or state in the order lifecycle event sequence that causes the process to be unable to continue; Impact Scope Analysis: Based on the business process diagram, identify all business activities that occurred before the root cause event and whose effects need to be reversed; Operation reverse mapping: For each business activity that needs compensation, the corresponding original operation request event and response event are searched in the global state-event storage center to determine the specific business object and parameters to which the compensation operation should be applied.
[0045] The beneficial effects of the above technical solution are as follows: by analyzing the order lifecycle sequence through a pre-built rule base, it can automatically and accurately determine whether a transaction is successful or failed. In the event of a failure, the root cause of the problem can be located immediately based on the traceability record, and a compensation process can be triggered. This automates the complex rollback operation that originally required manual intervention, greatly improving the efficiency and accuracy of system exception handling and ensuring the eventual consistency of business operations.
[0046] In one embodiment, determining the set of rollback or correction operations for a specific microservice operation, and determining the execution objects and order of compensation operations based on the set of rollback or correction operations, includes: Obtain the business activity execution list corresponding to a specific microservice operation, and determine the necessary rollback operation subset in the business activity execution list based on the pre-built business activity dependency graph; For other operations not included in the required rollback operation subset in the business activity execution list, assess whether they can exist independently in a business isolation state. If not, add them to the recommended modified operation subset. Merge the necessary rollback operation subset and the suggested correction operation subset to form the final rollback and correction operation set; Based on the dependencies between operations, the degree of data coupling, and business rules, determine the execution objects and execution order of each compensation operation in the rollback and correction operation set, and generate a compensation instruction execution plan.
[0047] In this embodiment, the business activity execution list records the operations that have been successfully invoked in a specific microservice operation process, the business objects corresponding to the operations, the operation execution time, and the operation output results.
[0048] In this embodiment, the business activity dependency graph refers to a metadata model that describes the dependencies between microservice operations. Nodes in the graph represent microservice operations, and directed edges represent data or logical dependencies between operations.
[0049] In this embodiment, the required rollback subset refers to the operations in the business activity execution list that have been successfully executed and must be rolled back because their outputs are directly or indirectly dependent on the failure point.
[0050] In this embodiment, assessing whether it can exist independently in a business isolation state includes: Has this operation generated any irreversible side effects that are visible to external systems? Whether the data object created or modified by this operation is allowed to exist in a "partially completed" state for a long time in a business context; Does the result of this operation depend on other successful business processes in the future?
[0051] In this embodiment, the rules for the execution order of compensation operations include: Dependency Reversal Rule: For operations with dependencies, compensate the dependent party first, then compensate the dependent party. Resource release priority rule: For operations involving the locking of physical resources (such as inventory and transportation capacity), the compensation operation (releasing resources) should be executed first; External system priority rule: For operations involving calls to external third-party systems, the compensation operation should be executed first to remove external constraints as soon as possible; Last rule in the transaction log: Operations used to record the compensation process itself should be executed last.
[0052] The beneficial effects of the above technical solution are as follows: by performing dependency analysis and business impact assessment, it can intelligently distinguish between operations that require rollback and those that are recommended for correction, and generate an accurate and minimal compensation set, avoiding unnecessary resource release and business interruption. While ensuring data consistency, it can minimize the impact of compensation operations on system performance and normal business processes.
[0053] In one embodiment, the step of periodically scanning the microservice data stream of each order, performing anomaly detection and automatic data repair, and displaying the full-link processing status of each order in real time includes: According to the scheduling strategy, the microservice data stream for each order range is obtained from the global state-event storage center. The microservice data stream is then matched with rules based on the pre-set anomaly detection rule base to detect abnormal data. Determine the data type of the abnormal data, match the repair strategy according to the data type, generate and execute repair operations for automatic repair items allowed by the repair strategy, and generate repair work orders for manual repair items that require manual handling. Dynamically aggregate the latest end-to-end status information of each order after consistency verification, and render each node, status and anomaly point in the end-to-end status information in real time in the form of a graphical timeline or topology diagram; Highlight, warn, or block abnormal states detected.
[0054] In this embodiment, the scheduling strategy includes: timed polling scan: starting a full or incremental scan according to a configured fixed time interval; Event-driven scanning: A targeted scan is triggered when a specific event is published to the event bus; Hybrid trigger scanning: Combining timed polling and event-driven methods, and performing more frequent special scans on high-frequency abnormal orders.
[0055] In this embodiment, the preset anomaly detection rule base includes the following rule types: State consistency rule: Check whether the state replicas of the same order in different microservices are logically consistent; Event flow integrity rules: Check whether there are missing, out-of-order, or duplicate events in the event flow, and whether critical business events are missing; Business process timeliness rules: Check whether the dwell time of an order at any processing node exceeds the preset SLA threshold; Data validity rules: Check whether the value range, format, or relationship of key business data violates predefined business constraints.
[0056] The beneficial effects of the above technical solution are as follows: through periodic scanning and rule matching, potential anomalies such as data inconsistencies and process timeouts can be continuously and proactively detected. Combined with a tiered repair strategy (automatic / manual), immediate automated repair of some issues is achieved. Coupled with real-time visualization of the entire process, a global, transparent, and controllable monitoring view is provided to operations and maintenance personnel, significantly improving stability and operational efficiency.
[0057] In one embodiment, the step of retrieving microservice data streams for each order range from the global state-event storage center according to a scheduling strategy, and performing rule matching on the microservice data streams according to a pre-set anomaly detection rule base to detect abnormal data includes: The current completion stage of each order is determined from the global state-event storage center, and it is determined whether the current completion stage meets the specific stage requirements. If so, the scheduling strategy is triggered by the order status to obtain the full microservice data stream for each order from the global state-event storage center; The entire microservice data stream is converted into fact objects that the rule engine can process, and the rule engine performs rule matching based on the fact objects of the pre-built anomaly detection rule base. The system detects abnormal data in the full microservice data stream by matching rules. The abnormal data includes data inconsistencies, logical conflicts, and process violations.
[0058] The beneficial effects of the above technical solution are as follows: By adopting an order status trigger strategy for targeted scanning, the resource consumption of full scanning is avoided, and the detection efficiency is improved. Furthermore, by performing structured matching of data streams through a rule engine, complex logical conflicts and process violations can be identified efficiently and accurately, ensuring the depth and breadth of anomaly detection and providing a reliable basis for subsequent accurate repair.
[0059] In one embodiment, this embodiment also discloses an event-driven microservice-based method for order processing and transaction consistency assurance, such as... Figure 4 As shown, the system includes: The first generation module 401 is used to receive and parse order requests from multiple channels, generate standardized initial order creation events based on a configurable rule engine, and asynchronously transmit order events using a distributed message middleware. The second generation module 402 is used to perform multiple related microservices on order events based on the triggered business logic and store the state snapshots of the transaction domain objects of each microservice, and generate the order lifecycle events and their state change sequences for each order based on the state snapshots. The determination module 403 is used to determine the cross-microservice transaction execution result of each order based on the order lifecycle events and their state change sequence, and to trigger compensation operations based on the source tracing record when the execution result fails. The data anomaly detection and repair module 404 is used to periodically scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and to display the full-link processing status of each order in real time.
[0060] The working principle and beneficial effects of the above technical solution have been explained in the method embodiments, and will not be repeated here.
[0061] Those skilled in the art should understand that the "first" and "second" in this invention simply refer to different application stages.
[0062] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0063] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A microservice-based order processing and transaction consistency guarantee method based on event-driven principles, characterized in that... Includes the following steps: It receives and parses order requests from multiple channels, generates standardized initial order creation events based on a configurable rule engine, and asynchronously transmits order events using a distributed message middleware. Based on the triggered business logic, multiple related microservices are generated for order events and state snapshots of the transaction domain objects of each microservice are stored. Based on the state snapshots, order lifecycle events and their state change sequences for each order are generated. The execution results of cross-microservice transactions for each order are determined based on the order lifecycle events and their state change sequences, and compensation operations are triggered based on the source tracing records when the execution results fail. Regularly scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and display the full-link processing status of each order in real time.
2. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 1, characterized in that, The process of receiving and parsing order requests from multiple channels, generating standardized initial order creation events based on a configurable rule engine, and asynchronously transmitting order events using a distributed message middleware includes: The multi-channel order access gateway receives original order requests, identifies the source channel and protocol format of each original order request, selects the data acquisition method based on the protocol format, and obtains the original order data of each original order request from the source channel. The original order data is processed sequentially according to a predefined set of rules, including validation, cleaning, mapping, enrichment, and routing decision processing. The processed raw order data is converted into standardized order objects with a unified structure definition, and the standardized order objects are encapsulated as initial order creation events. Asynchronously publish the initial order creation event to a specified topic or queue in the distributed message middleware cluster.
3. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 2, characterized in that, The process of receiving original order requests through a multi-channel order access gateway, identifying the source channel and protocol format of each original order request, selecting a data acquisition method based on the protocol format, and obtaining the original order data for each original order request from the source channel includes: By deploying multiple protocol listeners on the gateway, connection requests from different channels are continuously monitored; When any protocol listener receives an original order request, it extracts the metadata of the original order request and identifies the specific source channel and protocol format of the original order request based on the channel identifier, protocol characteristics and request characteristics in the metadata. Based on the identified protocol format, the corresponding data acquisition adapter is dynamically selected and loaded from the pre-configured adapter registry; The data acquisition adapter is invoked, and the communication specifications of the identified protocol format are followed to interact with the source channel and obtain complete original order data.
4. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 1, characterized in that, The process involves triggering multiple related microservices for order events based on business logic and storing state snapshots of the transaction domain objects of each microservice. Based on these state snapshots, the system generates order lifecycle events and their state change sequences for each order, including: Based on the business logic of each order management microservice, the domain state machine of the order management microservice is driven to update the initial entity state snapshot corresponding to the order event and store the initial entity state snapshot in the global state-event storage center. Each order event is processed in parallel by the inventory microservice and the fulfillment microservice, which respectively drive their respective domain state machines to update the inventory reservation state and generate the fulfillment plan state, store their respective subsequent entity state snapshots, and publish relevant domain events; For subsequent microservices that repeatedly trigger, process, store, and publish, until all relevant microservices involved in the order process complete their business logic and update their status; The order lifecycle sequence generator generates a complete lifecycle event and its state change sequence for each order based on the state snapshots of all related entities stored in the global state-event storage center, according to the timeline and business logic.
5. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 4, characterized in that, The process involves using an order lifecycle sequence generator to generate a complete lifecycle event and its state change sequence for each order based on state snapshots of all relevant entities stored in the global state-event storage center, arranged chronologically and according to business logic. This includes: Based on the order identifier of each order, query the global state-event storage center to obtain a set of state snapshots of all domain entities logically associated with that order; Extract the state effective timestamp field from each state snapshot in the state snapshot set, perform global time-series sorting on all snapshots, and generate a state snapshot timeline; Scan the state snapshot timeline, aggregate multiple consecutive related state snapshots according to predefined business logic rules, and interpret them as order lifecycle events with high-level business semantics; Arrange all generated order lifecycle events in chronological order of their corresponding state snapshots, and output a complete lifecycle event sequence for each order.
6. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 1, characterized in that, The process of determining the cross-microservice transaction execution results for each order based on order lifecycle events and their state change sequences, and triggering compensation operations based on the source tracing record when the execution result fails, includes: Based on the order lifecycle event sequence, a pre-defined transaction success / failure determination rule base is used to determine the final execution result of the cross-microservice distributed transaction corresponding to each order; When a transaction fails, the sequence of lifecycle events that caused the failure is analyzed, and the detailed event tracing records in the global state-event storage center are combined to locate the specific microservice operation that was successfully executed but needs to be rolled back or corrected. Determine the set of rollback or correction operations for a specific microservice operation, and determine the execution objects and order of compensation operations based on the set of rollback or correction operations; Based on the execution object and order of the compensation operation, a sequence of compensation instructions for a specific microservice is generated, and the compensation interface of the specific microservice is called in reverse order according to the business dependency to perform the compensation operation.
7. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 6, characterized in that, The process of determining the set of rollback or correction operations for a specific microservice operation, and determining the execution objects and order of compensation operations based on the set of rollback or correction operations, includes: Obtain the business activity execution list corresponding to a specific microservice operation, and determine the necessary rollback operation subset in the business activity execution list based on the pre-built business activity dependency graph; For other operations not included in the required rollback operation subset in the business activity execution list, assess whether they can exist independently in a business isolation state. If not, add them to the recommended modification operation subset. The necessary rollback operation subset and the suggested correction operation subset are merged to form the final rollback and correction operation set; Based on the dependencies between operations, the degree of data coupling, and business rules, determine the execution objects and execution order of each compensation operation in the rollback and correction operation set, and generate a compensation instruction execution plan.
8. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 1, characterized in that, The process involves periodically scanning the microservice data stream of each order, performing anomaly detection and automatic data repair, and displaying the full-chain processing status of each order in real time, including: According to the scheduling strategy, the microservice data stream for each order range is obtained from the global state-event storage center. The microservice data stream is then matched with rules based on the pre-set anomaly detection rule base to detect abnormal data. Determine the data type of the abnormal data, match the repair strategy according to the data type, generate and execute repair operations for automatic repair items allowed by the repair strategy, and generate repair work orders for manual repair items that require manual handling. Dynamically aggregate the latest end-to-end status information of each order after consistency verification, and render each node, status and anomaly point in the end-to-end status information in real time in the form of a graphical timeline or topology diagram; Highlight, warn, or block abnormal states detected.
9. The event-driven microservice-based order processing and transaction consistency guarantee method according to claim 8, characterized in that, The process involves retrieving microservice data streams for each order from the global state-event storage center according to a scheduling strategy, performing rule matching on the microservice data streams based on a pre-set anomaly detection rule base, and detecting abnormal data, including: The current completion stage of each order is determined from the global state-event storage center, and it is determined whether the current completion stage meets the specific stage requirements. If so, the scheduling strategy is triggered by the order status to obtain the full microservice data stream for each order from the global state-event storage center; The entire microservice data stream is converted into fact objects that the rule engine can process, and the rule engine performs rule matching based on the fact objects of the pre-built anomaly detection rule base. The system detects abnormal data in the full microservice data stream by matching rules. The abnormal data includes data inconsistencies, logical conflicts, and process violations.
10. An event-driven, microservice-based order processing and transaction consistency guarantee system, characterized in that, The system includes: The first generation module is used to receive and parse order requests from multiple channels, generate standardized initial order creation events based on a configurable rule engine, and asynchronously transmit order events using a distributed message middleware. The second generation module is used to perform multiple related microservices on order events based on the triggered business logic and store state snapshots of the domain objects of each microservice transaction. Based on the state snapshots, it generates the order lifecycle events and their state change sequences for each order. The determination module is used to determine the cross-microservice transaction execution result of each order based on the order lifecycle events and their state change sequence, and to trigger compensation operations based on the traceability record when the execution result fails. The data anomaly detection and repair module is used to periodically scan the microservice data flow of each order and perform anomaly detection and automatic data repair, and display the full-link processing status of each order in real time.