Information service management method and system for cross-business domains of an e-commerce platform

Abstract

The application discloses an information service management method and system for cross-business domains of an e-commerce platform, and relates to the field of e-commerce. The method comprises the following steps: collecting multiple business domains of the e-commerce platform, performing full-business-process analysis to generate multiple intra-domain business operation sets; analyzing the consistency requirement strength of operation types, performing synchronous and asynchronous division to construct synchronous and asynchronous operation sets; building a twin resource pool, receiving multiple service requests initiated by multiple users, performing cross-business-domain resource pool calling simulation, judging whether to perform asynchronous blocking calling, and if yes, responding to the asynchronous arrangement with the synchronous and asynchronous operation sets. The application solves the technical problem that the existing cross-business-domain information service management cannot guarantee the strong consistency of core business data while taking into account the high concurrency performance and low response delay of the system, and achieves the technical effect that the cross-domain calling is adaptively balanced between consistency guarantee and performance optimization through intelligent identification and dynamic arrangement.

Description

Technical Field

[0001] This application relates to the field of e-commerce, and in particular to methods and systems for managing information services across business domains on e-commerce platforms. Background Technology

[0002] As e-commerce platform operations become increasingly complex, service calls across multiple independent business domains have become crucial for supporting core transaction chains, and their performance and reliability directly impact user experience and platform stability. Currently, the industry primarily employs unified synchronous calls or fully asynchronous decoupling based on message queues to achieve cross-domain service collaboration. However, unified synchronous calls are prone to request blocking and response delays as cross-domain chains grow, while fully asynchronous solutions struggle to guarantee strong data consistency and execution timing for core business operations.

[0003] Currently, the relevant technologies used for cross-business domain information service management on e-commerce platforms face the technical challenge of ensuring strong consistency of core business data while simultaneously achieving high system concurrency performance and low response latency. Summary of the Invention

[0004] This application provides a method and system for managing cross-business domain information services on e-commerce platforms. It collects data from multiple independent business domains within the e-commerce platform and analyzes the entire business process to identify independently executable set of structured business operations within each domain. Based on the consistency requirements of operation types, these operations are categorized as synchronous or asynchronous, forming corresponding operation sets. A twin resource pool simulating the real resource configuration of each business domain is built. Resource calls for user-initiated cross-business domain service requests are simulated to determine whether asynchronous blocking processing is necessary. If so, reactive asynchronous orchestration is performed according to the synchronous and asynchronous operation sets. This solves the technical problem of existing cross-business domain information service management for e-commerce platforms, which struggles to ensure strong consistency of core business data while maintaining high system concurrency performance and low response latency. It achieves an adaptive balance between consistency assurance and performance optimization in cross-domain calls through intelligent identification and dynamic orchestration.

[0005] This application provides a method for managing cross-business domain information services on an e-commerce platform, comprising: collecting multiple business domains of the e-commerce platform; performing full business process analysis on the multiple business domains to generate multiple sets of business operations within each domain; analyzing the consistency requirement intensity of operation types in the multiple sets of business operations within each domain, dividing them into synchronous and asynchronous operations, and constructing a set of synchronous operations and a set of asynchronous operations related to the business domain and operation type; building a twin resource pool for the multiple business domains, receiving multiple service requests initiated by multiple users on the e-commerce platform, and performing cross-business domain resource pool call simulation to determine whether to perform asynchronous blocking calls; if so, performing reactive asynchronous orchestration using the set of synchronous operations and the set of asynchronous operations.

[0006] In one possible implementation, multiple business domains of the e-commerce platform are collected, and the entire business process of the multiple business domains is analyzed to generate multiple sets of business operations within the domains. The following processing is performed: the workflow definition file of each business domain is parsed, the activity nodes and transition conditions in the business process are extracted, and a business process modeling tool is used to construct a business process model within the domain, including sequential flow, parallel flow and decision flow; the operation type and input / output parameters of each business operation within each business domain are identified according to the business process model, and the multiple sets of business operations within the domains are generated.

[0007] In a possible implementation, the consistency requirement intensity of operation types in the multiple domain-based business operation sets is analyzed, and synchronous and asynchronous operations are divided. Synchronous operation sets and asynchronous operation sets for each business domain and operation type are constructed, and the following processing is performed: Predefined consistency intensity quantification indicators are read, including data real-time requirements, transaction correlation, user-perceived latency tolerance, and operation reentrancy and idempotency, as well as predefined consistency evaluation weights for each indicator; for each operation in the multiple domain-based business operation sets, a score is assigned based on the consistency intensity quantification indicators, and a weighted consistency intensity score is calculated for each operation; the consistency intensity score is compared with a preset intensity threshold to divide the synchronous candidate operation set and asynchronous candidate operation set under each business domain; forced synchronization filtering and cross-domain dependency filtering are performed on the synchronous candidate operation set and the asynchronous candidate operation set to generate the synchronous operation set and the asynchronous operation set.

[0008] In one possible implementation, the following process is performed: Forced synchronization filtering is performed by filtering through a list of key business rules predefined by the administrator.

[0009] In a possible implementation, the following processing is performed: the cross-domain dependency filtering steps include: parsing the full business process of the multiple business domains and constructing a directed graph model with business operations as nodes and call dependencies as edges; in the directed graph model, detecting direct dependency paths from operation nodes in the synchronous operation candidate set to operation nodes in the asynchronous operation candidate set; for the direct dependency path, determining whether the asynchronous operation in the path is a key downstream dependency of the upstream synchronous operation, and migrating all asynchronous operations determined to be key downstream dependencies from the asynchronous operation candidate set to the synchronous operation candidate set.

[0010] In a possible implementation, a twin resource pool is built for the multiple business domains to receive multiple service requests initiated by multiple users on the e-commerce platform. Cross-business domain resource pool call simulation is performed to determine whether to perform asynchronous blocking calls. The following processes are then executed: the twin resource pool is driven to run, the path, time consumption, and resource consumption of the multiple service requests as they flow through different virtual resource pools are tracked, and a cross-domain request call chain performance report is generated; the call chain performance report is parsed to identify whether the total request time exceeds a preset time threshold, and to determine whether to perform asynchronous blocking calls.

[0011] In a possible implementation, reactive asynchronous orchestration is performed using the synchronous operation set and the asynchronous operation set, and the following processing is performed: All business domain operations involved in the multiple service requests are decomposed, and multiple cross-domain business operation chains are constructed; based on the multiple cross-domain business operation chains, a synchronous task queue is searched in the synchronous operation set, and an asynchronous task queue is searched in the asynchronous operation set; the synchronous task queue is executed synchronously in real time; a unique transaction ID is assigned to each task in the asynchronous task queue, and a preliminary response containing the transaction ID is returned to the user, the user-end connection is released, and in the background, through an event-driven architecture, the tasks in the asynchronous task queue are executed one by one according to priority and dependency, and the final state is updated.

[0012] In a possible implementation, tasks in the asynchronous task queue are executed one by one according to priority and dependency, and the following processing is also performed: a retry mechanism is set for each asynchronous task in the asynchronous task queue, and when the task fails, it is automatically retried according to the exponential backoff strategy; if the number of retries exceeds the maximum limit and still fails, the task is marked as a dead letter and moved to the dead letter queue for manual processing.

[0013] In a possible implementation, after marking a task as a dead letter, the following processing is also performed: a compensation operation registration interface is configured, and a corresponding compensation operation is registered for each asynchronous task through the compensation operation registration interface; after marking a task as a dead letter, transaction rollback and state correction are performed based on the compensation operation.

[0014] This application also provides an information service management system for cross-business domains of e-commerce platforms, including: a full business process analysis module, used to collect multiple business domains of the e-commerce platform, perform full business process analysis on the multiple business domains, and generate multiple sets of business operations within the domains; an operation synchronous / asynchronous partitioning module, used to analyze the consistency requirement intensity of operation types in the multiple sets of business operations within the domains, perform synchronous and asynchronous partitioning, and construct synchronous operation sets and asynchronous operation sets related to business domains and operation types; and an asynchronous orchestration module, used to build twin resource pools for the multiple business domains, receive multiple service requests initiated by multiple users on the e-commerce platform, and perform cross-business domain resource pool call simulation to determine whether to perform asynchronous blocking calls. If so, perform reactive asynchronous orchestration with the synchronous operation sets and the asynchronous operation sets.

[0015] The proposed method and system for cross-business domain information service management in e-commerce platforms first collects data from multiple business domains of the e-commerce platform. It then performs full business process analysis on these domains, generating multiple sets of business operations within each domain. Next, it analyzes the consistency requirements of operation types within these sets, classifying them as synchronous or asynchronous, and constructs synchronous and asynchronous operation sets for each business domain and operation type. Finally, it builds a twin resource pool for the multiple business domains, receives multiple service requests initiated by users on the e-commerce platform, and simulates cross-business domain resource pool calls. It determines whether to perform asynchronous blocking calls; if so, it performs reactive asynchronous orchestration using the synchronous and asynchronous operation sets. Through this process, the proposed method and system achieve an adaptive balance between consistency assurance and performance optimization in cross-domain calls through intelligent identification and dynamic orchestration. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings of the embodiments of the present invention will be briefly described below. Flowcharts are used in this application to illustrate the operations performed by the system according to the embodiments of the present application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0017] Figure 1 This is a flowchart illustrating a method for managing cross-business domain information services on an e-commerce platform, as provided in an embodiment of this application.

[0018] Figure 2 This is a schematic diagram of the structure of an information service management system for cross-business domains of an e-commerce platform, provided in an embodiment of this application.

[0019] Figure labeling: Full business process analysis module 10, operation synchronous / asynchronous division module 20, asynchronous orchestration module 30. Detailed Implementation

[0020] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0021] This application provides a method for managing cross-business domain information services on e-commerce platforms, such as... Figure 1 As shown, the method includes: Step S100: Collect multiple business domains of the e-commerce platform, perform full business process analysis on the multiple business domains, and generate multiple sets of business operations within the domains.

[0022] Specifically, a business domain refers to a functionally independent, data-closed-loop business module within an e-commerce platform. For example, the order domain is responsible for order creation, modification, and querying; the payment domain for payment verification and account deduction; the inventory domain for inventory locking, deduction, and replenishment; and the logistics domain for logistics order creation and tracking. Each business domain corresponds to an independent service cluster and database. Full business process analysis refers to the end-to-end breakdown of the process within each business domain, including not only the normal execution path but also exception handling processes, such as payment failure retries and insufficient inventory callbacks. The set of business operations within a domain refers to a structured data set categorized and organized by business domain, containing a unique identifier, execution logic, input / output parameters, and other core information for each operation.

[0023] This step transforms scattered operations across various business domains into structured data that can be recognized and managed by the system by parsing the workflow and extracting key nodes and parameters. This solves the problems of inconsistent operation definitions and unclear dependencies in cross-domain service management, and provides data support for synchronous / asynchronous partitioning and cross-domain orchestration.

[0024] In one possible implementation, multiple business domains of an e-commerce platform are collected, and the entire business process of these domains is analyzed to generate multiple sets of business operations within each domain. Step S100 further includes step S110, which involves parsing the workflow definition file of each business domain, extracting activity nodes and transition conditions from the business process, and using a business process modeling tool to construct a business process model within the domain, including sequential flow, parallel flow, and decision flow. Specifically, a workflow parsing engine is used to read workflow definition files in XML or JSON format. A syntax parser extracts activity nodes, such as unique identifiers and execution logic descriptions for order creation, payment verification, and logistics scheduling, as well as judgment rule expressions in transition conditions, such as proceeding to the delivery process upon successful payment and triggering a replenishment process if inventory is insufficient. Business process modeling tools, such as Camunda Modeler and the process modeling module of Draw.io, are used to map the extracted nodes and transition conditions to a process model through visual drag-and-drop and rule configuration. In this model, sequential flow defines the execution order through linear connections between nodes, parallel flow splits multiple parallel execution paths through a branching gateway and aggregates the results through an aggregation gateway, and decision flow dynamically selects the execution path based on the transition condition expression through an exclusive gateway.

[0025] Step S120: Based on the business process model, identify the operation type and input / output parameters of each business operation within each business domain, generating the multiple domain-specific business operation sets. Specifically, based on the business process model constructed in step S110, scan the backend service interface corresponding to each activity node using a reflection mechanism or interface document parsing tool to identify operation types, such as query, add, modify, delete, and notification operations. Query operations are marked as read-only, add / modify / delete operations are marked as write operations, and notification operations are marked as message pushes. By parsing the request parameter list and response parameter list of the interface, extract the field names, data types, and required attributes of the input parameters, as well as the field structure and relationships of the output parameters. The input parameters include order number, user ID, product ID, purchase quantity, etc., the data types include strings, integers, dates, etc., and the output parameters include operation result status codes, returned data objects, error messages, etc. The operation types and input / output parameters of each business domain are stored in the business operation table of a relational database according to the structure of business domain name-operation ID-operation type-input parameter list-output parameter list, forming a domain-specific business operation set.

[0026] Step S200: Analyze the consistency requirement intensity of operation types for the multiple domain-based business operation sets, divide them into synchronous and asynchronous operations, and construct synchronous operation sets and asynchronous operation sets for business domain-operation types.

[0027] Specifically, consistency requirement intensity refers to the degree to which business operations require data consistency, execution sequence, and user-perceived latency. For example, order payment requires real-time synchronization of funds and order status, which is considered high intensity, while logistics information push allows for short delays, which is considered low intensity. Synchronous operation sets refer to business operations that need to be executed in real-time and whose results must be immediately fed back to the user. During execution, the user's connection is occupied until the operation is completed, such as inventory locking and payment confirmation. Asynchronous operation sets refer to business operations that do not require real-time feedback and can be executed asynchronously in the background. During execution, user requests are not blocked; only a request acceptance response is returned, and subsequent execution is completed through background threads or message queues.

[0028] This step uses quantitative indicators and multiple rounds of screening to classify operations with different intensity requirements, avoiding slow system response caused by all operations being executed synchronously, or inconsistencies in core business data caused by all operations being executed asynchronously.

[0029] In one possible implementation, the consistency requirement intensity of operation types is analyzed for the multiple domain-specific business operation sets, and synchronous and asynchronous operations are divided. Synchronous operation sets and asynchronous operation sets for each business domain and operation type are constructed. Step S200 further includes step S210, which reads predefined consistency intensity quantification indicators, including data real-time requirements, transaction correlation, user-perceived latency tolerance, and operation reentrancy and idempotency, as well as predefined consistency evaluation weights for each indicator. Specifically, the predefined consistency intensity quantification indicator configuration is read through the configuration center. The configuration is stored in key-value pair format, where each quantification indicator corresponds to a specific evaluation dimension and value range, and the weight coefficients of each indicator are stored, with a total weight of 1. The data real-time requirement ranges from 0 to 10, with 0 indicating a tolerance for delays exceeding 1 hour and 10 indicating millisecond-level synchronization. The transaction dependency ranges from 0 to 10, with 0 indicating no transaction dependency and 10 indicating strong transaction dependence. The user-perceived latency tolerance ranges from 0 to 10, with 0 indicating a tolerance for delays exceeding 5 seconds and 10 indicating a latency below 100 milliseconds. The operation reentrancy and idempotency ranges from 0 to 10, with 0 indicating non-reentrant and non-idempotent, and 10 indicating fully reentrant and idempotent. Predefined weighting coefficients include: data real-time requirement 0.3, transaction dependency 0.4, user-perceived latency tolerance 0.2, and operation reentrancy and idempotency 0.1. Administrators can dynamically adjust these weights through the configuration center.

[0030] Step S220: For each operation in the multiple domain-specific business operation sets, a score is assigned based on the consistency strength quantification index, and a weighted consistency strength score is calculated for each operation. Specifically, the evaluation logic of each quantification index is transformed into executable rules through a rule engine. Each business operation is scored by matching the rules one by one, and then the final score is calculated using the weighted summation formula: Consistency Strength Score = Data Real-Time Score × Data Real-Time Weight + Transaction Correlation Score × Transaction Correlation Weight + User-Perceived Latency Tolerance Score × User-Perceived Latency Tolerance Weight + Operation Reentrancy and Idempotency Score × Operation Reentrancy and Idempotency Weight. Among them, the data real-time performance score is determined by judging the data synchronization delay threshold required for the operation. For example, the order payment operation requires a delay of less than 100 milliseconds, which corresponds to 10 points; the transaction correlation score is determined by judging whether the operation belongs to a distributed transaction. For example, order creation + inventory deduction belongs to a strong transaction correlation, which corresponds to 10 points; the user-perceived latency tolerance score is judged by the user operation scenario. For example, the delay in displaying the order status after immediate payment should be less than 100 milliseconds, which corresponds to 10 points; the operation reentrancy and idempotency score is determined by checking whether the operation implements idempotent logic. For example, using the order number as a unique identifier to achieve idempotency, which corresponds to 10 points.

[0031] Step S230: Compare the consistency strength score with a preset strength threshold to divide each business domain into a synchronous candidate operation set and an asynchronous candidate operation set. Specifically, the preset strength threshold is configured through a configuration center. All business operations' consistency strength scores are iterated through, and operations with scores greater than or equal to the threshold are stored in the synchronous candidate operation set, while operations with scores less than the threshold are stored in the asynchronous candidate operation set. During storage, metadata such as operation ID, business domain name, and consistency strength score are associated, and the division result is recorded in the operation log table, including information such as operation ID, division time, score, threshold, and set type, to support traceability.

[0032] For example, with a preset strength threshold of 7 points, order payment confirmation (9.8 points) and inventory lock (8.5 points) are stored in the synchronous candidate operation set of the order business domain, while order logistics information push (3.1 points) and order evaluation statistics (4.2 points) are stored in the asynchronous candidate operation set of the order business domain.

[0033] Step S240 involves performing forced synchronization filtering and cross-domain dependency filtering on the synchronous candidate operation set and the asynchronous candidate operation set to generate the synchronous operation set and the asynchronous operation set. Specifically, a serial execution logic of first performing forced synchronization filtering and then cross-domain dependency filtering is adopted. Forced synchronization filtering directly includes operations that meet the rules into the synchronous operation set by reading a list of key business rules predefined by the administrator. Cross-domain dependency filtering analyzes the dependencies between operations by constructing a directed graph model and adjusts the affiliation of candidate sets. Finally, the synchronous operation set and the asynchronous operation set are stored in a relational database.

[0034] In one possible implementation, step S240 further includes step S241, whereby forced synchronization filtering is performed using a list of key business rules predefined by the administrator. Specifically, the administrator maintains the list of key business rules through the backend management system. The list is stored in JSON format, and each rule includes fields such as rule ID, business domain name, operation type, operation keyword, and effective status. The system reads the list of rules with an "enabled" effective status through a Java database connection, iterates through the synchronous candidate operation set and the asynchronous candidate operation set, and directly moves operations that meet the rules from the candidate operation set to the synchronous operation set. This filtering result cannot be overwritten by subsequent cross-domain dependency filtering.

[0035] For example, the list of key business rules is as follows: Rule ID 101, Business Domain Name: Payment Business Domain; Operation Type: Write Operation; Operation Keyword: Funds; Activation Status: Enabled. After reading this rule, the system iterates through all candidate operations and moves account deductions, payment transfers, and other operations in the Payment Business Domain that are write operations with the keyword "funds" directly into the synchronization operation set, regardless of whether their consistency strength score meets the standard.

[0036] Step S242, the cross-domain dependency filtering steps include: parsing the full business process of the multiple business domains, and constructing a directed graph model with business operations as nodes and call dependencies as edges; in the directed graph model, detecting direct dependency paths from operation nodes in the synchronous operation candidate set to operation nodes in the asynchronous operation candidate set; for the direct dependency path, determining whether the asynchronous operation in the path is a key downstream dependency of the upstream synchronous operation, and migrating all asynchronous operations determined to be key downstream dependencies from the asynchronous operation candidate set to the synchronous operation candidate set.

[0037] Specifically, a directed graph model is constructed using a graph database. Node attributes include operation ID, business domain name, and candidate set type. Edge attributes include dependency type and dependency weight. Dependency types include direct calls and indirect calls, while dependency weights range from 0 to 1, representing the degree of dependency tightness. Nodes and directed edges are created in the graph database by parsing the call relationships in the business process model. A depth-first search algorithm is used to traverse the directed graph, detecting direct dependency paths from synchronous candidate nodes to asynchronous candidate nodes—paths where the edge attribute indicates a direct call. The criteria for determining critical downstream dependencies are preset by the configuration center, including whether it is a mandatory subsequent step of the upstream operation, whether it affects the core user experience, and whether the dependency weight is greater than 0.8. Meeting any one of these conditions determines it to be a critical downstream dependency. For example, when constructing a directed graph, if the synchronous candidate node - Order Creation directly calls the asynchronous candidate node - Logistics Order Creation, with the edge attribute being "direct call" and the dependency weight being 0.9, and this direct dependency path is detected by the depth-first search algorithm, determining that Logistics Order Creation is a key downstream dependency of Order Creation, then Logistics Order Creation is moved from the asynchronous candidate operation set to the synchronous candidate operation set. The attribute of this node in the graph database is updated to synchronous candidate, and the operation ID is removed from the asynchronous candidate operation set of the order business domain and added to the synchronous candidate operation set of the order business domain.

[0038] Step S300: Build a twin resource pool for the multiple business domains, receive multiple service requests initiated by multiple users on the e-commerce platform, and simulate cross-business domain resource pool calls to determine whether to perform asynchronous blocking calls. If so, perform reactive asynchronous orchestration using the synchronous operation set and the asynchronous operation set.

[0039] Specifically, a twin resource pool is a virtual resource cluster that simulates the real resource configurations of various business domains on an e-commerce platform. It's used to simulate the call paths and performance of cross-domain requests, avoiding the risks associated with direct testing in a production environment. Asynchronous blocking calls refer to switching some non-core operations to background asynchronous execution when the total time of cross-domain requests exceeds a threshold, releasing client connections and avoiding long waiting times for users. Responsive asynchronous orchestration refers to scheduling asynchronous task execution based on task priority and dependencies using an event-driven architecture, supporting task retries and failure compensation to ensure eventual consistency of asynchronous tasks.

[0040] This step first identifies performance bottlenecks through twin resource pool simulation, then executes synchronous tasks in real time and orchestrates asynchronous tasks in the background. At the same time, it handles abnormal situations through retry, dead letter queues, and transaction compensation mechanisms, thereby solving problems such as excessively long request times, unreliable execution of asynchronous tasks, and non-standard exception handling in cross-domain services, and improving user experience and system stability.

[0041] In one possible implementation, a twin resource pool is built for the multiple business domains. This pool receives multiple service requests initiated by multiple users on the e-commerce platform and simulates cross-business domain resource pool calls. It determines whether to perform asynchronous blocking calls. Step S300 further includes step S310, driving the twin resource pool to run, tracking the paths, time consumption, and resource consumption of the multiple service requests as they flow through different virtual resource pools, and generating a cross-domain request call chain performance report. Specifically, the twin resource pool is built based on container orchestration technology, creating virtual resource pools by simulating the real resource configurations of each business domain. A distributed tracing system is used to track service requests. By injecting tracing identifiers and span identifiers into the request header, the flow path of the request in each virtual resource pool is recorded, such as user request → order virtual resource pool → payment virtual resource pool → inventory virtual resource pool. The time consumption of each span (i.e., the time difference between the request entering and leaving the virtual resource pool) and resource consumption, including CPU utilization, memory usage, and network I / O, are collected through event tracking. The call chain performance report is generated in JSON format and includes information such as tracer identifier, request path, time spent at each node, total time spent, peak resource consumption of each node, and whether there are any timeout nodes. It is stored in the time series database.

[0042] Step S320: Parse the call chain performance report to identify whether the total request time exceeds a preset time threshold and determine whether to perform asynchronous blocking calls. Specifically, the preset time threshold is configured through the configuration center, such as 500 milliseconds for order requests and 1000 milliseconds for querying the order list. The system reads the total time field in the call chain performance report through the query interface of the time-series database and compares it with the preset threshold. If the total time exceeds the threshold, and the time consumption of nodes corresponding to asynchronous candidate operations in the report exceeds 30%, it is determined that asynchronous blocking calls are required. For example, if the total call chain time for an order request is 600 milliseconds, exceeding the preset threshold of 500 milliseconds, and the time consumption of the node corresponding to the asynchronous candidate operation of creating a logistics order is 200 milliseconds, accounting for 33.3% of the total time (>30%), it is determined that asynchronous processing is required.

[0043] In one possible implementation, reactive asynchronous orchestration is performed using the synchronous operation set and the asynchronous operation set. Step S300 further includes step S330, which involves decomposing all business domain operations involved in the multiple service requests and constructing multiple cross-domain business operation chains. Specifically, a request parsing engine is used to parse the HTTP request header, request parameters, and request body of the service request to extract the business scenario corresponding to the request. Based on the mapping relationship between business scenarios and business operations, all business domain operations involved in the request are decomposed. According to the execution order of the business process, a cross-domain business operation chain is constructed using a linked list data structure, where each linked list node contains information such as operation ID, business domain name, operation type, and dependent preceding operation ID.

[0044] Step S340: Based on the multiple cross-domain business operation chains, search for the synchronous task queue in the synchronous operation set and the asynchronous task queue in the asynchronous operation set. Specifically, traverse each node of the cross-domain business operation chain, query the synchronous operation set and the asynchronous operation set by operation ID, and determine the affiliation of each operation. Nodes belonging to the synchronous operation set are stored in the synchronous task queue in the order of the operation chain, and nodes belonging to the asynchronous operation set are stored in the asynchronous task queue in the order of the operation chain. Each element in the queue contains information such as operation ID, business domain name, input parameters, and the storage address of the results of dependent preceding operations. Expiration times are set for both queues to avoid cache accumulation.

[0045] Step S350: Perform real-time synchronous execution on the synchronous task queue. Specifically, a thread pool is used to execute the synchronous task queue. Each thread in the thread pool retrieves a task from the synchronous task queue, calls the corresponding business domain service interface of the task through the RPC framework, and passes in the input parameters. During execution, a countdown latch is used to implement the waiting of previous tasks; for example, the payment confirmation task needs to wait for the inventory locking task to complete and return a success result. If the synchronous task execution fails, an error response is immediately returned to the user, and a failure log is recorded in the logging system.

[0046] Step S360: Assign a unique transaction ID to each task in the asynchronous task queue, return a preliminary response containing the transaction ID to the user, release the user's connection, and execute the tasks in the asynchronous task queue one by one according to priority and dependency relationship in the background through an event-driven architecture, and update the final state. Specifically, a distributed transaction ID generator is used to assign a transaction ID to each asynchronous task. The preliminary response is returned in JSON format, including status code, prompt information, and transaction ID, and is returned to the user via HTTP response, while closing the TCP connection between the user's client and the server. The event-driven architecture is implemented based on a message queue, encapsulating asynchronous tasks into messages. The message body includes transaction ID, operation ID, input parameters, dependencies, etc., and is sent to the corresponding topic. The message queue's priority mechanism sorts tasks according to a preset priority, and message dependency checks ensure dependencies.

[0047] In one possible implementation, tasks in the asynchronous task queue are executed one by one according to priority and dependency. Step S360 further includes step S361, setting a retry mechanism for each asynchronous task in the asynchronous task queue. When a task fails, it is automatically retried according to an exponential backoff strategy. Specifically, retry parameters are configured on the consumer side of the message queue, including the maximum number of retries and the initial retry interval. The implementation logic of the exponential backoff strategy is: the Nth retry interval = the initial retry interval × 2 to the power of (N-1), where N is the number of retries, 1 ≤ N ≤ the maximum number of retries. Retry triggering conditions include: business interface call timeout, interface returning a non-success status code, exception throwing, etc. Each retry records a retry log, including the transaction ID, the number of retries, the retry time, and the reason for failure, to the log system.

[0048] Step S362: If the retry count exceeds the maximum limit and the task still fails, the task is marked as dead letter and moved to the dead letter queue for manual processing. Specifically, when the message queue consumer detects that the retry count has reached the maximum limit, it marks the message corresponding to the task as dead letter and automatically moves it to the dead letter queue through the message queue's dead letter queue mechanism. The message storage duration in the dead letter queue is set through the configuration center, and manual viewing of detailed information about dead letter messages is supported through the message queue management platform. Simultaneously, the task status is updated to dead letter, and an alarm notification is triggered.

[0049] In one possible implementation, after marking the task as a dead letter, step S360 further includes step S363, configuring the compensation operation registration interface, through which a corresponding compensation operation is registered for each asynchronous task. Specifically, the compensation operation registration interface is designed following the representational state transition architecture style, allowing other services to submit requests via the POST method. The request includes: a globally unique transaction number, a task number, the address of the business interface used for compensation, a template of parameters required for compensation, and the conditions for triggering compensation. To ensure security, the interface uses a JSON-formatted Web token for authentication; only services holding a valid token and authorized can successfully register a compensation operation. All successfully registered compensation operation information is saved in a database table, which records key fields including the transaction number, task number, network address of the compensation interface, parameter template with placeholders, trigger conditions, and registration time.

[0050] Step S364: After marking the task as dead letter, transaction rollback and state correction are performed based on the compensation operation. Specifically, when a task is marked as dead letter, the system triggers a compensation execution process. This process first queries the pre-registered compensation operation information, including the network address and parameter template of the compensation interface, from the database table storing compensation operations based on the task's transaction number. Then, the actual business parameters are extracted from the original execution context of the dead letter task, and the placeholders in the parameter template are replaced with these real parameters to generate a complete and executable compensation request. Finally, the compensation interface is invoked via remote procedure call or Hypertext Transfer Protocol request to execute the corresponding reverse business logic to undo or correct the impact of the asynchronous task on the system state, ensuring eventual data consistency.

[0051] This application's embodiments collect data from multiple independent business domains of an e-commerce platform. Through full business process analysis, a set of independently executable structured business operations within each business domain is identified. Based on the consistency requirements of operation types, these operations are classified as synchronous or asynchronous, forming corresponding operation sets. A twin resource pool simulating the real resource configuration of each business domain is built. Resource calls are simulated for cross-business domain service requests initiated by users to determine whether asynchronous blocking processing is required. If so, reactive asynchronous orchestration is performed according to the synchronous and asynchronous operation sets. This solves the technical problem of existing cross-business domain information service management for e-commerce platforms, which struggles to ensure strong consistency of core business data while maintaining high system concurrency performance and low response latency. It achieves an adaptive balance between consistency assurance and performance optimization in cross-domain calls through intelligent identification and dynamic orchestration.

[0052] In the above text, refer to Figure 1 This paper describes in detail a method for managing cross-business domain information services on an e-commerce platform according to embodiments of the present invention. Next, reference will be made to... Figure 2 This invention describes an information service management system for cross-business domains of an e-commerce platform, based on an embodiment of the present invention.

[0053] The cross-business domain information service management system for e-commerce platforms according to embodiments of the present invention addresses the technical problem of existing cross-business domain information service management systems for e-commerce platforms, which struggle to ensure strong consistency of core business data while simultaneously maintaining high system concurrency performance and low response latency. It achieves an adaptive balance between consistency assurance and performance optimization in cross-domain calls through intelligent identification and dynamic orchestration. The cross-business domain information service management system for e-commerce platforms includes: a full business process parsing module 10, an operation synchronous / asynchronous partitioning module 20, and an asynchronous orchestration module 30.

[0054] The full business process analysis module 10 is used to collect data from multiple business domains of the e-commerce platform, perform full business process analysis on the multiple business domains, and generate multiple sets of business operations within each domain. The operation synchronous / asynchronous partitioning module 20 is used to analyze the consistency requirement intensity of operation types in the multiple sets of business operations within each domain, perform synchronous and asynchronous partitioning, and construct synchronous operation sets and asynchronous operation sets related to business domain and operation type. The asynchronous orchestration module 30 is used to build twin resource pools for the multiple business domains, receive multiple service requests initiated by multiple users on the e-commerce platform, and perform cross-business domain resource pool call simulation to determine whether to perform asynchronous blocking calls. If so, it performs reactive asynchronous orchestration based on the synchronous operation sets and the asynchronous operation sets.

[0055] The detailed description of the specific configuration of the full business process parsing module 10 is explained as follows: As mentioned above, multiple business domains of the e-commerce platform are collected, and full business process parsing is performed on the multiple business domains to generate multiple sets of business operations within the domains. The full business process parsing module 10 may further include: a domain business process model building unit used to parse the workflow definition file of each business domain, extract the activity nodes and transition conditions in the business process, and use a business process modeling tool to build a domain business process model, including sequential flow, parallel flow, and decision flow; and a domain business operation set generation unit used to identify the operation type and input / output parameters of each business operation in each business domain according to the business process model, and generate the multiple sets of business operations within the domains.

[0056] The detailed description of the specific configuration of the operation synchronous / asynchronous partitioning module 20 is explained as follows: As mentioned above, the module analyzes the consistency requirement intensity of operation types for the multiple domain-specific business operation sets, performs synchronous and asynchronous partitioning, and constructs synchronous operation sets and asynchronous operation sets for business domain-operation type. The operation synchronous / asynchronous partitioning module 20 may further include: an indicator reading unit for reading predefined consistency intensity quantification indicators, including data real-time requirements, transaction correlation, user-perceived latency tolerance, and operation reentrancy and idempotency, as well as predefined consistency evaluation weights for each indicator; a scoring unit for scoring each operation in the multiple domain-specific business operation sets according to the consistency intensity quantification indicators, and weighted calculation to obtain the consistency intensity score corresponding to each operation; a synchronous / asynchronous partitioning unit for comparing the consistency intensity score with a preset intensity threshold to partition the synchronous candidate operation set and the asynchronous candidate operation set under each business domain; and a filtering unit for performing forced synchronous filtering and cross-domain dependency filtering on the synchronous candidate operation set and the asynchronous candidate operation set to generate the synchronous operation set and the asynchronous operation set.

[0057] The filtering unit may further include: forced synchronization filtering, which filters based on a list of key business rules predefined by the administrator.

[0058] The filtering unit may further include the following steps for cross-domain dependency filtering: parsing the full business process of the multiple business domains and constructing a directed graph model with business operations as nodes and call dependencies as edges; detecting direct dependency paths from operation nodes in the synchronous operation candidate set to operation nodes in the asynchronous operation candidate set in the directed graph model; determining whether the asynchronous operation in the path is a key downstream dependency of the upstream synchronous operation, and migrating all asynchronous operations determined to be key downstream dependencies from the asynchronous operation candidate set to the synchronous operation candidate set.

[0059] The detailed description of the specific configuration of the asynchronous orchestration module 30 is explained as follows: As mentioned above, it builds twin resource pools for multiple business domains, receives multiple service requests initiated by multiple users on the e-commerce platform, and performs cross-business domain resource pool call simulation to determine whether to perform asynchronous blocking calls. The asynchronous orchestration module 30 may further include: a call chain performance report generation unit for driving the twin resource pool to run, tracking the path, time consumption, and resource consumption of the multiple service requests when they flow through different virtual resource pools, and generating a call chain performance report for cross-domain requests; and a judgment unit for parsing the call chain performance report, identifying whether the total request time exceeds a preset time threshold, and determining whether to perform asynchronous blocking calls.

[0060] The asynchronous orchestration module 30, which performs reactive asynchronous orchestration using the synchronous operation set and the asynchronous operation set, may further include: a cross-domain business operation chain construction unit for decomposing all business domain operations involved in the multiple service requests and constructing multiple cross-domain business operation chains; a task queue lookup unit for searching for synchronous task queues in the synchronous operation set and asynchronous task queues in the asynchronous operation set based on the multiple cross-domain business operation chains; a synchronous task execution unit for performing real-time synchronous execution on the synchronous task queues; and an asynchronous task execution unit for assigning a unique transaction ID to each task in the asynchronous task queue, returning an initial response containing the transaction ID to the user, releasing the user-end connection, and executing the tasks in the asynchronous task queue one by one in the background according to priority and dependency using an event-driven architecture, and updating the final state.

[0061] The asynchronous task execution unit may further include: an automatic retry subunit for setting a retry mechanism for each asynchronous task in the asynchronous task queue, and automatically retrying according to an exponential backoff strategy when a task fails; and a manual processing subunit for marking the task as dead letter and moving it into a dead letter queue for manual processing if the number of retries exceeds the maximum limit and still fails.

[0062] After marking a task as a dead letter, the asynchronous task execution unit may further include: a compensation operation registration subunit for configuring a compensation operation registration interface, and registering a corresponding compensation operation for each asynchronous task through the compensation operation registration interface; and a status correction subunit for performing transaction rollback and status correction based on the compensation operation after marking a task as a dead letter.

[0063] The information service management system for cross-business domains of e-commerce platforms provided in the embodiments of the present invention can execute the information service management method for cross-business domains of e-commerce platforms provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0064] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0065] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for information service management across business domains for an e-commerce platform, characterized in that, include: Collect data from multiple business domains of an e-commerce platform, perform full business process analysis on these multiple business domains, and generate multiple sets of business operations within each domain. Analyze the consistency requirement intensity of operation types for the multiple domain-specific business operation sets, divide them into synchronous and asynchronous operations, and construct synchronous operation sets and asynchronous operation sets for business domains and operation types. A twin resource pool for the multiple business domains is built to receive multiple service requests initiated by multiple users on the e-commerce platform, and cross-business domain resource pool call simulation is performed to determine whether to perform asynchronous blocking calls. If so, reactive asynchronous orchestration is performed using the synchronous operation set and the asynchronous operation set.

2. The method for information service management across business domains of an e-commerce platform of claim 1, wherein, Collect data from multiple business domains of an e-commerce platform, perform full business process analysis on these domains, and generate multiple sets of business operations within each domain, including: Parse the workflow definition file of each business domain, extract the activity nodes and transition conditions in the business process, and use business process modeling tools to build business process models within the domain, including sequential flow, parallel flow, and decision flow; Based on the business process model, identify the operation type and input / output parameters of each business operation within each business domain, and generate a set of business operations within the multiple domains.

3. The method for information service management across business domains of an e-commerce platform of claim 1, wherein, Analyze the consistency requirements of operation types for the multiple domain-specific business operation sets, perform synchronous and asynchronous operations, and construct synchronous and asynchronous operation sets for each business domain and operation type, including: Read the predefined consistency strength quantification indicators, including data real-time requirements, transaction correlation, user-perceived latency tolerance, and operation reentrancy and idempotency, as well as the predefined consistency evaluation weights for each indicator; For each operation in the multiple domain-specific business operation sets, a score is assigned based on the consistency strength quantification index, and a weighted consistency strength score is calculated for each operation. Compare the consistency strength score with a preset strength threshold to divide the synchronous candidate operation set and asynchronous candidate operation set under each business domain; Forced synchronization filtering and cross-domain dependency filtering are performed on the synchronous candidate operation set and the asynchronous candidate operation set to generate the synchronous operation set and the asynchronous operation set.

4. The information service management method for cross-business domains of e-commerce platforms as described in claim 3, characterized in that, Forced synchronization filtering uses a list of key business rules predefined by the administrator.

5. The method for information service management across business domains of an e-commerce platform as claimed in claim 3, wherein, The steps for cross-domain dependency filtering include: The entire business process of the multiple business domains is analyzed, and a directed graph model is constructed with business operations as nodes and call dependencies as edges. In the directed graph model, direct dependency paths from operation nodes in the synchronous operation candidate set to operation nodes in the asynchronous operation candidate set are detected. For the direct dependency path, determine whether the asynchronous operation in the path is a key downstream dependency of the upstream synchronous operation, and move all asynchronous operations that are determined to be key downstream dependencies from the asynchronous operation candidate set to the synchronous operation candidate set.

6. The method for information service management across business domains of an e-commerce platform as claimed in claim 1, wherein, Establish a twin resource pool for the multiple business domains, receive multiple service requests initiated by multiple users on the e-commerce platform, and simulate cross-business domain resource pool calls to determine whether to perform asynchronous blocking calls, including: Drive the twin resource pool to run, track the path, time and resource consumption of the multiple service requests as they flow through different virtual resource pools, and generate a cross-domain request call chain performance report; The call chain performance report is parsed to identify whether the total request time exceeds a preset time threshold, and to determine whether to perform an asynchronous blocking call.

7. The information service management method for cross-business domains of e-commerce platforms as described in claim 6, characterized in that, Responsive asynchronous orchestration using the set of synchronous operations and the set of asynchronous operations includes: The multiple service requests are broken down into all the business domain operations involved, and multiple cross-domain business operation chains are constructed. Based on the multiple cross-domain business operation chains, a synchronous task queue is searched in the synchronous operation set, and an asynchronous task queue is searched in the asynchronous operation set. The synchronization task queue is executed synchronously in real time; Assign a unique transaction ID to each task in the asynchronous task queue, return an initial response containing the transaction ID to the user, release the user connection, and execute the tasks in the asynchronous task queue one by one in the background according to priority and dependency using an event-driven architecture, and update the final state.

8. The method for information service management across business domains of an e-commerce platform of claim 7, wherein, Executing tasks in the asynchronous task queue one by one according to priority and dependency also includes: A retry mechanism is set for each asynchronous task in the asynchronous task queue. When a task fails to execute, it will automatically retry according to the exponential backoff strategy. If the number of retries exceeds the maximum limit and still fails, the task will be marked as a dead letter and moved to the dead letter queue for manual processing.

9. The method for information service management across business domains of an e-commerce platform of claim 8, wherein, Marking a task as a dead letter also includes: Configure a compensation operation registration interface, and register a corresponding compensation operation for each asynchronous task through the compensation operation registration interface; After marking the task as a dead letter, transaction rollback and state correction are performed based on the compensation operation.

10. A system for information service management across business domains for an e-commerce platform, characterized in that, The system is used to implement the information service management method for cross-business domains of an e-commerce platform as described in any one of claims 1-9, the system comprising: The full business process parsing module is used to collect data from multiple business domains of the e-commerce platform, perform full business process parsing on the multiple business domains, and generate multiple sets of business operations within the domains. The synchronous / asynchronous operation partitioning module is used to analyze the consistency requirement intensity of operation types for the business operation sets within the multiple domains, perform synchronous and asynchronous partitioning, and construct synchronous operation sets and asynchronous operation sets for business domains and operation types. The asynchronous orchestration module is used to build twin resource pools for the multiple business domains, receive multiple service requests initiated by multiple users on the e-commerce platform, simulate cross-business domain resource pool calls, determine whether to perform asynchronous blocking calls, and if so, perform reactive asynchronous orchestration using the synchronous operation set and the asynchronous operation set.

Images