Cross-domain interface collaborative invocation methods, devices, equipment and media

Abstract

This invention relates to the field of microservice architecture technology and discloses a method, apparatus, device, and medium for cross-domain interface collaborative invocation, comprising: receiving a request and generating a request identifier and an initialized processing status; initiating a synchronous interface call and starting asynchronous message listening based on the identifier; if a synchronous result is received within a preset threshold, acquiring a distributed lock, parsing the result and returning it to the upstream, and updating the processing status to complete; if synchronization times out, returning a waiting prompt and recording the status as timeout waiting; when an asynchronous result is detected, acquiring a distributed lock and, if the query status is timeout or unprocessed, performing persistent recording based on the asynchronous result and updating the status to complete. This invention can be applied to business scenarios such as fintech and healthcare, using request identifiers and distributed locks to uniformly control synchronous and asynchronous processing flows, ensuring timely response while avoiding duplicate result processing and status conflicts, and improving the consistency and reliability of cross-domain calls.

Description

Technical Field

[0001] This invention relates to the field of microservice architecture technology, and in particular to a method, apparatus, device and medium for cross-domain interface collaborative invocation. Background Technology

[0002] In enterprise-level microservice architectures, cross-domain API calls are common in multi-level call chains of "upstream service—middleware service—downstream system." Middleware services need to provide timely and stable API responses to upstream services while also handling the actual processing results from downstream systems. However, current technologies often employ separate technical paths for synchronous calls and asynchronous processing, lacking a unified request-level state management and result integration mechanism. This makes it difficult to form a closed loop between real-time responses and subsequent processing. When downstream system processing time is uncontrollable, network jitter occurs, or periodic anomalies arise, issues such as disconnected responses and results, inconsistent processing states, and duplicate records can easily occur, impacting the overall reliability and traceability of the system.

[0003] In the fintech business sector, these issues are particularly prominent. Payment confirmation, transaction fulfillment, fund clearing, and account verification typically require intermediate services to return interface responses to upstream systems within a short timeframe, while simultaneously preserving the complete final processing results of downstream systems to support reconciliation, auditing, risk control, and subsequent business decisions. In existing technologies, purely synchronous call patterns are prone to interface timeouts and link blockages when downstream processing is slow or abnormal, while purely asynchronous processing patterns generally lack centralized management of request states, resulting in a loose connection between asynchronous results and original requests. In high-concurrency, multi-instance operating environments, duplicate consumption of asynchronous messages can also lead to duplicate data writes and state conflicts, increasing the operational risks of financial services.

[0004] In the healthcare sector, cross-domain API calls are also widely used in scenarios such as identity verification, medical data synchronization, dual recording verification, and medical insurance settlement. These services have high requirements for data integrity, processing traceability, and state consistency. However, downstream systems often involve collaborative processing across multiple institutions, resulting in long processing cycles and uncertainties. Existing technologies suffer from issues such as the separation of synchronous and asynchronous processes, rudimentary timeout handling mechanisms, and insufficient control over duplicate asynchronous result processing. These problems can easily lead to incomplete result retrieval or state confusion, hindering further improvements in the stability and data governance of healthcare information systems. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for cross-domain interface collaborative invocation, aiming to solve the technical problem that the existing technology lacks a unified request-level state and mutual exclusion control mechanism for synchronous response and asynchronous result processing in cross-domain interface invocation, which makes it difficult to balance timely response, result integrity, and anti-duplication processing in timeout or asynchronous return scenarios.

[0006] To achieve the above objectives, the present invention provides a cross-domain interface collaborative invocation method, comprising: Receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state; Based on the request identifier, a synchronization interface call is initiated to the second service node as the first receiving channel, and the synchronization response result returned by the second service node is monitored within a preset response time threshold. Based on the request identifier, a message listening mechanism is enabled as a second receiving channel to receive the asynchronous processing results sent by the second service node; When the synchronization response result is received through the first receiving channel within the preset response time threshold, a distributed lock corresponding to the request identifier is acquired; Upon successfully acquiring the distributed lock corresponding to the request identifier, the synchronization response result is parsed, and the final processing result is returned to the first service node based on the parsed synchronization response result. The processing status corresponding to the request identifier is also updated to the completed status. If the synchronization response result is not received within the preset response time threshold, a waiting prompt message is returned to the first service node, and the processing status corresponding to the request identifier is recorded as a timeout waiting status. Upon receiving the asynchronous processing result through the second receiving channel, acquire the distributed lock corresponding to the request identifier; Upon successfully acquiring the distributed lock corresponding to the request identifier and finding that the processing status corresponding to the request identifier is either a timeout waiting state or an initial unprocessed state, data persistence is performed based on the asynchronous processing result, and the processing status corresponding to the request identifier is updated to the completed state.

[0007] Furthermore, to achieve the above objectives, the present invention provides a cross-domain interface collaborative invocation device, comprising: The request identifier initialization module is used to receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state. The synchronous call channel module is used to initiate a synchronous interface call to the second service node based on the request identifier as the first receiving channel, and to listen for the synchronous response result returned by the second service node within a preset response time threshold. An asynchronous listening channel module is used to enable a message listening mechanism as a second receiving channel based on the request identifier, so as to receive the asynchronous processing results sent by the second service node; The synchronization lock acquisition module is used to acquire the distributed lock corresponding to the request identifier when the synchronization response result is received through the first receiving channel within the preset response time threshold. The synchronization result processing module is used to parse the synchronization response result when the distributed lock corresponding to the request identifier is successfully acquired, return the final processing result to the first service node based on the parsed synchronization response result, and update the processing status corresponding to the request identifier to the completed status. The timeout status processing module is used to return a waiting prompt message to the first service node when the synchronization response result is not received within the preset response time threshold, and to record the processing status corresponding to the request identifier as a timeout waiting status. An asynchronous lock acquisition module is used to acquire a distributed lock corresponding to the request identifier when the asynchronous processing result is received through the second receiving channel; The asynchronous result persistence module is used to perform data persistence recording based on the asynchronous processing result and update the processing status of the request identifier to the completed status when the distributed lock corresponding to the request identifier is successfully acquired and the processing status corresponding to the request identifier is found to be either timeout waiting state or initial unprocessed state.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a cross-domain interface cooperative calling program stored in the memory and executable on the processor, wherein when the cross-domain interface cooperative calling program is executed by the processor, it implements the steps of the cross-domain interface cooperative calling method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a cross-domain interface cooperative invocation program, wherein the cross-domain interface cooperative invocation program, when executed by a processor, implements the steps of the cross-domain interface cooperative invocation method as described above.

[0010] Beneficial Effects: This invention relates to the field of microservice architecture technology and discloses a method, apparatus, device, and medium for cross-domain interface collaborative invocation, including: receiving a request and generating a request identifier and an initialized processing state; initiating a synchronous interface call and starting asynchronous message listening based on the identifier; if a synchronous result is received within a preset threshold, acquiring a distributed lock, parsing the result and returning it to the upstream, and updating the processing state to complete; if synchronization times out, returning a waiting prompt and recording the state as timed out; when an asynchronous result is detected, acquiring a distributed lock and, if the query state is timed out or unprocessed, performing persistent recording based on the asynchronous result and updating the state to complete. This invention can be applied to business scenarios such as fintech and healthcare. By introducing a state management and distributed lock control mechanism centered on the request identifier during cross-domain interface calls, it unifies the synchronous response path and asynchronous result processing path into the same processing flow. When the processing time of the downstream system is uncertain, it achieves timely response to the upstream service, while ensuring that the final processing result can be completely received and persistently recorded, effectively avoiding duplicate processing of asynchronous results or state conflicts, thereby improving the stability, consistency, and traceability in cross-domain call scenarios. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a cross-domain interface collaborative invocation method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the cross-domain interface collaborative invocation method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the cross-domain interface collaborative invocation device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The cross-domain interface collaborative invocation method provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can receive requests from the client and generate a request identifier and an initial processing status; based on this identifier, it initiates a synchronous interface call and starts asynchronous message listening; if a synchronous result is received within a preset threshold, it acquires a distributed lock, parses the result and returns it upstream, and updates the processing status to complete; if synchronization times out, it returns a waiting prompt and records the status as timed out; when an asynchronous result is received, it acquires a distributed lock and, if the query status is timed out or unprocessed, performs persistent recording based on the asynchronous result and updates the status to complete. This invention can be applied to business scenarios such as fintech and healthcare. By introducing a state management and distributed lock control mechanism centered on request identifiers during cross-domain interface calls, it unifies the synchronous response path and asynchronous result processing path into the same processing flow. When the processing time of the downstream system is uncertain, it achieves timely response to the upstream service, while ensuring that the final processing result can be completely received and persistently recorded, effectively avoiding duplicate processing of asynchronous results or state conflicts, thereby improving the stability, consistency, and traceability in cross-domain call scenarios. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will now be described in detail through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the cross-domain interface collaborative invocation method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the cross-domain interface collaborative invocation method proposed in this invention includes the following steps: S10, Receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state; In this embodiment, when an upstream business system, such as a mobile payment application or an insurance intelligent underwriting engine, needs to trigger a business process involving external systems, it will initiate a call to this service. This call request is a cross-domain call request, which is essentially a data structure containing business intent and necessary parameters, transmitted and received through agreed network protocols (such as HTTP, gRPC). The receiving action means that the server-side network listening component (such as a web server container, network framework) has successfully parsed the incoming data stream and converted it into a business object that can be processed internally. This process is the starting point for all subsequent collaboration and anti-duplicate mechanisms. Based on this incoming request, a unique request identifier must be generated immediately for it, which is unique throughout the entire system. The generation of this identifier does not depend on any specific algorithm; its core requirement is to be able to clearly distinguish this request from the massive number of other requests that may occur during the system's lifecycle. One implementation is to extract the inherent unique elements in the request (such as user session ID plus timestamp) and combine them for encoding; another is to use a distributed unique ID generator (such as the Snowflake algorithm, UUID) completely independently to generate a new identifier bound to this request. This request identifier becomes a crucial index throughout the entire processing lifecycle, used to associate all relevant events, data, and states. Simultaneously with generating the request identifier, a dedicated, traceable state record—the processing state—needs to be created for this request. This state is not an abstract concept but a persistent data item with a defined value range (e.g., "Not Processed," "Processing," "Completed," "Timeout Waiting"). The key technical step is establishing an unbreakable correspondence between the request identifier and this processing state data item. This is typically achieved by creating a record in a storage system (such as a relational database, key-value store, or distributed cache) containing a state field, using the request identifier as the primary key or key-value pair. This record constitutes the "archive" of this request in the system. After establishing the correspondence, this processing state must be immediately initialized, explicitly set to a specific state value representing "initially not processed." This initialization operation is an atomic write operation, such as inserting a row into a database or setting a cache key-value pair to its initial value. Setting the "Initially Unprocessed" state has clear business semantics. It signifies that the request has been formally accepted by the system and entered the processing queue, but has not yet been substantially consumed or completed by any processing logic (such as synchronous calls or asynchronous messages). This provides a clear benchmark for subsequent dual-channel competitive processing. In financial transaction scenarios, such as when a cross-border remittance is initiated, the unique serial number generated by the system after receiving the request and the initial "Pending Processing" state are the cornerstone for subsequent tracking of remittance execution and preventing duplicate deductions or duplicate payments.

[0016] In implementation, the endpoint receiving the call request can be a highly available API gateway cluster, whose load balancer distributes the request to any service instance. This requires the request identifier generation algorithm to maintain global uniqueness in a distributed environment to avoid conflicts. Request identifier generation can be combined with business context. For example, in financial transactions, the payment channel, merchant ID, merchant order date and time, and a random number can be concatenated and then a fixed-length string can be generated as the identifier using a cryptographic hash function (such as SHA-256). Different data storage strategies can be adopted for establishing the association between processing status and request identifier. In scenarios requiring extremely high concurrency performance, the association can first be written to a distributed cache (such as Redis) with a reasonable expiration time to ensure fast read and write operations. Simultaneously, for persistence and disaster recovery, the same data can be asynchronously persisted to the database. In another implementation with higher requirements for strong data consistency, the association can be directly written to a distributed database with transaction capabilities (such as TiDB), ensuring that record creation and status initialization are completed within an atomic transaction. When initializing the status value, its specific string or numeric code can be designed according to the needs of monitoring and querying, such as using "INIT" or the number "0". Other monitoring fields, such as request receipt timestamp, upstream source system identifier, etc., can be initialized in the record at the same time to enrich the information dimensions of the "file".

[0017] This embodiment generates a globally unique identifier for each incoming request and creates a corresponding status record, providing precise traceability clues and a unified control anchor for the entire processing flow. This allows previously disparate synchronous and asynchronous processing branches to be associated with the same business context through this identifier, laying the data foundation for realizing the "respond first, then supplement" collaborative logic. The explicitness and initialization of status transforms request lifecycle management from implicit to explicit, enabling the system to clearly know the stage of a request at any time. This makes it possible to implement status-based anti-duplicate judgment and process routing, avoiding the risk of data chaos caused by unclear status from the source.

[0018] S20, based on the request identifier, initiate a synchronization interface call to the second service node as the first receiving channel, and listen for the synchronization response result returned by the second service node within a preset response time threshold; In this embodiment, the request identifier serves as the core index for this business call and needs to be transmitted to the downstream system to ensure that the response can be correctly associated. Therefore, a specific call instruction that can be transmitted over the network needs to be constructed based on this request identifier. This involves assembling and encoding the request identifier as a key parameter, along with other data required by the business, according to the interface protocol format specified by the downstream system, to form a complete synchronous call request. The format of this request can be a JSON over HTTP message conforming to the RESTful specification, a gRPC request based on Protocol Buffers serialization, or any other agreed-upon binary or text protocol format. The assembly process ensures that the request identifier is embedded in a location that the downstream system can recognize and may return in subsequent processes. After construction, the call execution component (such as an HTTP client or RPC stub) initiates this call over the network to the network endpoint of the second service node obtained through a pre-configured or service discovery mechanism. The second service node represents an external system that provides specific business capabilities, such as a bank's core system, a credit reporting agency interface, or a drug inventory database. Initiating the call means establishing or reusing a network connection and transmitting the assembled request data, thereby triggering the business processing logic of the downstream system. This synchronous interface call and the complete network interaction path it represents, from sending the request to receiving the expected response, are logically defined as a receiving channel, namely the first receiving channel. It is not a physical connection, but a logical context that spans the "request-response" cycle, encapsulating the target address, protocol, serialization method, and subsequent response monitoring logic of this call. To constrain the waiting time of this synchronous call and avoid indefinite blocking, a clear response time threshold must be set. This threshold is a time length value, and its specific value is not fixed but can be dynamically configured according to the real-time requirements of the business scenario. For example, it can be set to 300 milliseconds for payment password verification and 3 seconds for credit report queries. This threshold is used to control the timeout behavior of this call. Listening for the synchronous response returned by the second service node means that after sending the request, the call execution component initiates a waiting process constrained by the above time threshold. Within this time window, the component continuously monitors input from the network connection. Once a data packet conforming to the protocol format is received from the corresponding connection, it is immediately parsed to extract the response status code and business data. If a valid response is successfully parsed before the threshold is exhausted, the listening process is considered a successful capture. If no complete and valid response is received or parsed before the threshold is exhausted, the listening process terminates due to timeout. This listening mechanism is typically implemented internally by the synchronous API of a network client library or framework. Essentially, it polls in the background or waits for Socket readable events through an event-driven mechanism, and calls the corresponding parsing callback upon receiving data.

[0019] In implementation, when constructing synchronous call requests, in addition to embedding the request identifier, security elements such as request timestamps and caller signatures can be added. For example, in a financial scenario, a deduction request initiated to a payment gateway needs to include the request identifier as part of the merchant order number and generate a signature message according to the gateway's specifications. The network client initiating the call can be selected as needed; it can be a general HTTP client such as Apache HttpClient or OkHttp, or a stub generated for a specific RPC framework (such as Dubbo or gRPC). The configuration of the response time threshold can be very flexible. It can be a global default value, or different values ​​can be set in the configuration center according to different downstream interface types, or it can even be dynamically calculated by a rule engine based on specific attributes of the request (such as user level or business type). The implementation of listening for responses depends on the client; clients using blocking I / O will wait directly on the calling thread until timeout or a response is received; while clients based on asynchronous non-blocking I / O or reactive programming models (such as Project Reactor) will return a Future or Mono / Flux object, allowing the caller to subscribe to the result or set a timeout callback in a non-blocking manner. In implementations that prioritize ultimate reliability, a background timer task can be started simultaneously when the call is initiated, acting as a watchdog. When a preset threshold expires, the network connection is proactively interrupted and a timeout is marked, providing double protection against the client library's built-in timeout mechanism.

[0020] This embodiment establishes the first path for obtaining real-time results by constructing and initiating a synchronous call based on the request identifier. This enables the system to proactively and promptly request business conclusions from downstream systems, meeting the upstream's rigid requirement for low-latency feedback. Defining this interaction as the logical first receiving channel provides clear boundaries and operation handles for managing the lifecycle of this call (such as timeout control and result routing). The introduction of a preset response time threshold gives the system a controllable balance between real-time performance and resource consumption, preventing indefinite suspension of threads or connection resources due to downstream failures and ensuring the overall resilience and availability of the system. The listening mechanism within this threshold ensures that the system can focus on and efficiently capture immediate feedback from downstream systems under normal conditions, providing deterministic input for subsequent possible status judgments and result returns.

[0021] S30, based on the request identifier, a message listening mechanism is started as a second receiving channel to receive the asynchronous processing result sent by the second service node; In this embodiment, when building the result receiving capability in parallel with synchronous calls, it is necessary to establish an event-driven information capture path independent of direct network request responses. This path begins with the request identifier. This identifier is not only crucial for synchronous calls but also needs to be transformed into an addressing basis that the asynchronous messaging system can recognize. A typical transformation method is to combine the request identifier with a pre-agreed logical name (i.e., message topic) representing a certain type of business event or downstream system. This combination is not a simple concatenation but follows the Topic naming conventions or routing key rules of message middleware (such as Apache Kafka and RabbitMQ) to form a subscription point identifier with specific semantics within the message domain. For example, the request identifier can be attached as a message tag to a fixed topic or directly used as part of a dynamic queue name. Determining this subscription point identifier is equivalent to determining a specific, listenable asynchronous message inflow port. Subsequently, the system needs to instantiate a message consumption functional unit to interface with this port. This functional unit is typically referred to as a consumer or listener instance in the message processing model. In fact, the instantiation process can involve creating a new consumer specifically for this request, or registering the context of this request (especially the request identifier) ​​with an existing shared consumer instance responsible for consuming a large category of messages, enabling it to identify messages specific to this request. This consumer instance, along with its complete capabilities and logic for pulling or receiving messages from the subscription point and performing subsequent processing, is defined as the second receiving channel for this request. It is a logical entity that encapsulates the connection to the message middleware, deserialization logic, and message distribution or callback mechanisms. To ensure that this channel only processes messages strictly related to this request and avoids interference from broadcasts of other unrelated requests, filtering rules need to be configured for this consumer instance. These filtering rules are based on the request identifier. If the message middleware supports this, the topic or tag derived from the request identifier can be used directly during subscription for filtering; in systems that do not support subscription-level filtering, the payload or header of each message needs to be parsed within the message processing callback function of the consumer instance, the identifier field extracted, and compared with the current request identifier, processing only matching messages. After completing the creation or association of the consumer instance and the configuration of the filtering rules, an explicit start or activation command must be executed. This might manifest as calling the consumer client's `start()` method, or confirming that the subscription relationship is active on the message broker server, causing the consumer instance to begin continuously pulling messages from the message broker, or preparing to receive messages actively pushed by the message broker. Once the consumer instance is in a working state, it continuously runs its message listening loop or waits for push events.When a message matching the filter criteria is published from the second service node (or its associated message producer) to the corresponding topic or queue and routed to this consumer instance by the message middleware, the message is successfully captured. The consumer instance then decodes the message body, extracting structured business data and status information. This portion constitutes the asynchronous processing result that needs to be processed by subsequent processes. The entire listening process is independent of the network connection used for synchronous calls, relying on the persistence, decoupling, and reliable delivery capabilities provided by the message middleware.

[0022] The implementation of message listening mechanisms can be flexibly chosen based on the characteristics of the selected message middleware and system architecture. When using a publish-subscribe model (such as Kafka), a temporary topic in the format "business type.request identifier" can be created. Downstream systems publish results to this topic, while consumers subscribe to the exact topic. In queue-based scenarios (such as RabbitMQ), an exclusive, automatically deleted queue can be dynamically declared for each request, and this queue can be bound to the result exchange used by the downstream system using a binding key generated from the request identifier. Consumer instance creation can be lightweight; for example, in the Spring framework, listeners can be dynamically declared using the @RabbitListener annotation, injecting the request identifier as the queue name parameter. The implementation of filtering mechanisms can also be diverse: leveraging RocketMQ's SQL expression filtering capabilities, conditions such as TAGS='requestId_123' can be passed during subscription; or in Kafka, the request identifier can be used as the message key, and the consumer can be configured to consume only partitions within a specific key range. In high-concurrency scenarios, creating a separate physical consumer connection for each request can be costly. In such cases, a shared connection pool can be used, but a virtual "subscription context" is maintained in the application layer logic for each request. A global dispatcher routes received messages to the corresponding processing callback function based on the request identifier within the context. Starting the listener can be done synchronously in the request processing thread or asynchronously in a background thread pool to ensure that the main process is not blocked.

[0023] This embodiment establishes an asynchronous message listening channel based on request identifiers, creating an independent and reliable backup result receiving path. This path does not rely on the immediate response capability of downstream systems. Even if synchronous calls are interrupted due to timeouts or failures, this channel can still continuously wait for and capture the final conclusion output of the downstream system after processing, thus fundamentally ensuring the final consistency of business processing. Defining the message consumer instance as a second receiving channel and strongly associating it with the request identifier gives the reception of asynchronous messages a clear context and precise targeting, avoiding blind consumption or incorrect handling of messages. Configuring filtering rules based on request identifiers for the channel achieves precise message delivery and isolation, effectively preventing message crosstalk between different requests and ensuring the purity and correctness of processing logic.

[0024] S40, when the synchronization response result is received through the first receiving channel within the preset response time threshold, a distributed lock corresponding to the request identifier is acquired; In this embodiment, when the preset response time threshold has not yet been exhausted, and a valid network data packet from the second service node is successfully captured through the first receiving channel and parsed into a synchronous response result, this event signifies that the real-time processing path has achieved the expected result. At this point, the system faces a critical decision point: it must ensure that the processing of this response result and subsequent state update operations are exclusive and non-repeatable globally. To achieve this goal, the system needs to acquire a coordination and mutual exclusion mechanism across multiple potentially parallel processing instances. This mechanism is a distributed lock. This lock is not a physical entity, but a logical agreement. Its essence is to reserve a specific resource in a shared coordination service or storage component accessible to all relevant service instances, thereby declaring exclusive execution rights to a series of operations associated with that resource. The specific resource here is the current business request itself, and the request identifier is the unique identifier of that resource in the system. Therefore, acquiring a distributed lock corresponding to the request identifier essentially means attempting to establish an exclusive marker in shared storage, using the request identifier as the key basis. The specific action of establishing this marker typically involves initiating a write request with strict constraints to a coordinating component (such as Redis, ZooKeeper, or etcd). This constraint is crucial: the key-value pair can only be created (written) if the specified key (derived from the request identifier) ​​does not already exist. This operation is often referred to as an "atomic compare-set." After execution, the coordinating component returns a definitive result indicating whether the attempt succeeded (i.e., the exclusive marker was successfully established and the lock was acquired) or failed (i.e., the marker has already been established by another instance and the lock is already held). Technically, this is usually manifested as calling a Redis-like command like `SETkey value NX PX timeout`, where the key is derived from the request identifier, the `NX` parameter ensures that the key is only set if it does not exist, and the `PX` parameter sets an automatic expiration time for the lock to prevent deadlocks. This lock acquisition action is an instantaneous, non-blocking attempt, and its result directly determines whether the current instance has the right to continue executing subsequent result processing and state update logic, thus forming the first and crucial line of defense against duplicate processing.

[0025] The trigger condition for acquiring a lock needs to be precisely bound to the event of "successfully receiving and parsing a valid synchronization response result," which is typically implemented in a network callback function or the validation logic after a synchronization call returns. The generation strategy for distributed lock keys must ensure uniqueness and consistency. For example, a fixed prefix plus request identifier pattern can be used, such as "LOCK:" + requestId, ensuring that the key is globally unique within the lock service. Client libraries for acquiring locks can include Redisson, Curator, etc., which encapsulate complex logic such as retries and watchdog renewals. In specific implementations, the lock holding time (lease period) can be set slightly longer than the estimated result processing and state update time, for example, 5 seconds. The lock acquisition operation should include comprehensive exception handling, including scenarios such as network timeouts and lock service unavailability, typically designed for fast failure or a limited number of retries to avoid prolonged blocking. In extremely high-concurrency scenarios, finer-grained locks can be introduced, such as locking specific status fields of the request identifier rather than the entire request record, but this also increases complexity. Another implementation variant is to bundle the operation of acquiring the distributed lock with the logic of verifying the validity of the synchronization response result into a local transaction or atomic operation, but this requires the lock service to support more complex atomic instructions.

[0026] This embodiment introduces a strong mutual exclusion constraint for upcoming result processing and state update operations by immediately attempting to acquire a distributed lock based on the request identifier after successfully obtaining a synchronization response. This mechanism ensures that even in a distributed, multi-instance deployment environment where multiple service instances simultaneously receive the same synchronization response (though rare in ideal networks, it can occur considering scenarios like retries and network partitions), only one instance can successfully acquire the lock and execute subsequent critical write operations. This fundamentally eliminates the risk of duplicate data calculations, duplicate returns to upstream processes, or duplicate state updates that may result from concurrent processing of the same synchronization response. The lock's exclusivity transforms the uncertainty of parallel processing into serial deterministic processing, a core means of ensuring system state consistency and data integrity in concurrent environments. Furthermore, because lock acquisition is tentative and associated with an automatic expiration time, it also avoids the risk of the entire request being permanently locked due to the unexpected crash of the instance holding the lock, ensuring the system's self-recovery capability.

[0027] S50, when the distributed lock corresponding to the request identifier is successfully acquired, the synchronization response result is parsed, the final processing result is returned to the first service node based on the parsed synchronization response result, and the processing status corresponding to the request identifier is updated to the completed status. In this embodiment, when the system successfully acquires the distributed lock corresponding to the request identifier, it means that the current service instance has won the exclusive right to process the synchronous response result of the request, and can safely execute subsequent critical operations without worrying about interference from other instances. The first step is to process the received original synchronous response result. This result is usually a data structure conforming to a specific network protocol format, and may have been serialized. The parsing operation is the process of decoding, decomposing, and semantically extracting this original data. This includes identifying and verifying the protocol header information, deserializing the payload, and finally converting it into structured business information that the system can understand. The parsing process must be robust and able to handle different data formats or encodings that may be returned by downstream systems. The parsed information usually includes a business status code representing the state of the operation result, as well as the specific business data content generated by this call. Based on the parsed result, the final processing result to be returned to the first upstream service node needs to be constructed. This process is not a simple data forwarding, but often involves the adaptation and transformation of business logic. The system needs to convert or encapsulate the status codes and data structures from the downstream system, which may have specific meanings, into a response format expected by the upstream system and conforming to the interface contract between the two parties, according to preset rules or mapping relationships. For example, the downstream "0000" success code is mapped to the upstream "SUCCESS", and necessary data fields are filtered, reorganized, or calculated. This generation process ensures that the information returned to the upstream is accurate, complete, and consistent with its business understanding model. Subsequently, through the network communication link established or associated with the first receiving channel, the encapsulated final processing result is sent back to the first service node, completing the immediate feedback loop of this synchronous call. This return action should be timely and accurate to meet the upstream's requirement for low-latency response. After completing the response feedback to the upstream, the global state of this request must be finalized immediately. This involves modifying the processing state associated with the persistent request identifier. This operation must be performed under the protection of the currently successfully held distributed lock to ensure the exclusivity of the state update. The system needs to locate the corresponding data record in the storage medium and perform an atomic update operation, changing the value of the processing state field from the previous state (such as "initially unprocessed") to the "completed" state, which indicates that the process has ended. This "completed" status is a clear termination signal, announcing to any other part of the system that all necessary processing for this request has been completed, and no further substantive business operations should be performed on this request, whether via the synchronous path or any subsequent potential asynchronous path. This status update, together with the previous return result operation, constitutes a complete transaction under successful synchronous path processing.

[0028] In the post-lock acquisition process, response parsing can rely on libraries such as Jackson and Protobuf decoders, based on a predefined schema. For constructing the returned results, a strategy factory can be designed to load different result adapters for processing based on downstream interface types and business scenarios. When returning results upstream, appropriate network clients, such as RestTemplate or Feign clients, can be used according to the upstream protocol, ensuring retry or degradation strategies in case of network anomalies. When the update processing status is "completed," the database can be directly manipulated by executing an SQL statement such as `UPDATEcall_record SET status = 'COMPLETED' WHERE request_id = ?`, leveraging database transactions to guarantee atomicity. In another implementation, for optimal performance, the status update operation can be delegated to a reliable message queue, executed asynchronously by a dedicated consumer. However, this requires ensuring that the update message is reliably persisted before the lock is released, and that the lock holding time covers the time window for asynchronous update execution. The duration of lock holding is particularly critical at this stage and requires careful design. It must be longer than the time taken for the entire "parse-build-return-update" chain, but it cannot be too long to avoid affecting other asynchronous processing flows that may be waiting for the lock.

[0029] This implementation ensures the uniqueness and correctness of synchronous response processing in high-concurrency scenarios by parsing the response and returning the result under the protection of an exclusive lock. This prevents the risk of conflicting information being returned upstream or duplicate execution of business logic that might occur due to multiple instances processing the same response simultaneously. The parsed result is then adapted and returned to the upstream system, making the details of the downstream system transparent to the upstream, thus improving system encapsulation and architectural flexibility. Under the protection of the lock, the processing status is atomically updated to "completed," setting a globally visible termination flag for the entire request lifecycle. Any subsequent asynchronously arriving messages, upon attempting to process them, will automatically abandon processing upon querying this "completed" status, thereby achieving a "preemptive" termination of the asynchronous path by the synchronous path.

[0030] S60, when the synchronization response result is not received within the preset response time threshold, a waiting prompt message is returned to the first service node, and the processing status corresponding to the request identifier is recorded as a timeout waiting status; In this embodiment, when the timing mechanism associated with the first receiving channel indicates that the preset response time threshold has been exhausted, and no network data that can be parsed as a valid synchronous response result has been captured from the channel, the system determines that the synchronous call path has failed to complete within the maximum waiting time allowed for this business interaction. This timeout event is not a simple Boolean judgment; its trigger can originate from various underlying mechanisms, such as socket timeout exceptions provided by the operating system or network framework, timer interrupts set by the application layer, or error signals issued by timeout operators in reactive programming models. This event signifies that the attempt to obtain the result in real time has reached the time boundary, and the system must immediately execute contingency plans to prevent upstream services from falling into infinite waiting. The first action of the contingency plan is to return a clear waiting prompt message to the upstream first service node. This message is not the final result of the business, but an intermediate state notification designed to manage upstream expectations and maintain a connection-friendly connection. Its content needs to be carefully constructed to convey the core semantics that "the request has been received and is being processed, but the final conclusion is still pending." The specific form of the information can be a predefined text string, a structured JSON, or an XML response body, which typically includes a specific business status code representing "processing" or "pending," as well as an identifier of the original request for upstream tracking. This information is sent immediately via a network connection previously established with the upstream or temporarily established for this request. The second parallel and crucial action in the contingency plan is to re-mark the global processing status of this request within the system. The system needs to locate the status record bound to the request identifier in persistent storage and perform an update operation, changing its value from the previous state to "timeout waiting state." This new status value has a specific business meaning; it clearly records the fact that the synchronous real-time acquisition attempt for this request has officially ended and failed, and the business processing flow has now entered a stage of waiting for the final result from other means (i.e., asynchronous message channels). This status record is the cornerstone for whether subsequent asynchronous processing logic can be correctly triggered and for anti-duplicate judgment; it clearly advances the request's lifecycle from the "real-time processing stage" to the "asynchronous record-keeping stage."

[0031] Timeout checks can be implemented using Java's `Future.get(timeout, TimeUnit)` method, throwing a `TimeoutException` if the timeout is not met. Alternatively, when using asynchronous frameworks like Netty, a `ReadTimeoutHandler` can be added to the `ChannelPipeline`. Or, in reactive clients like Spring WebClient, the `.timeout(Duration)` operator can be used. The returned wait message is highly configurable; for example, it can load templates for different scenarios from a database or configuration center, and dynamically populate the template with variables such as request identifiers and timeout points. When sending this message, ensure the correct HTTP status code (e.g., 202 Accepted) and message body are used. When recording the "timeout wait status," the update operation must be atomic, typically achieved through a database `UPDATE` statement combined with optimistic locking version numbers or distributed locks (although a request-level distributed lock may not be held at this time, database row locks or CAS operations can guarantee correct updates). In another implementation that prioritizes maximum throughput, state update events can be published to an internal high-performance message queue, where a dedicated state update service asynchronously consumes and persists them. However, reliable delivery and at-least-once processing semantics must be guaranteed to prevent state loss. During logging, in addition to the state value itself, the precise timestamp of the timeout occurrence is typically recorded to provide data for monitoring and subsequent analysis.

[0032] This embodiment ensures deterministic system behavior and manageable user experience by immediately returning a waiting prompt to the upstream service after a synchronization path timeout. This mechanism allows upstream services to be released from blocking and waiting in a timely manner and receive clear guidance on what to do next, avoiding prolonged occupation of connection resources and a frozen user interface, effectively maintaining the responsiveness of the upstream system and the robustness of the overall service chain.

[0033] S70, when the asynchronous processing result is received through the second receiving channel, a distributed lock corresponding to the request identifier is acquired; In this embodiment, when a message consumer instance (the second receiving channel) successfully retrieves a new message from its subscribed message queue or topic, or receives a push notification from the message middleware, the first step is to decode and validate the message body to confirm that it conforms to the expected communication protocol. Subsequently, key association identifiers are extracted from the decoded structured data. These identifiers are typically stored in a specific field of the message header or a fixed location in the message payload during the message design phase. The extracted identifiers need to be compared with the business request context associated with the current consumer instance. This comparison process may be performed directly in memory using filtering parameters injected during consumer instance initialization, or it may be achieved by matching the identifiers with pre-stored context information after parsing the message. Once it is confirmed that the message indeed belongs to the specific request being listened to, the business data content carried by the message is formally recognized as the asynchronous processing result for this request. This result may include the final status of the downstream system's processing, detailed business output data, or additional callback parameters.

[0034] At this moment, the system triggers a mutual exclusion resource contention process similar to that of the synchronization path, aiming to acquire a distributed lock based on the request identifier. This action does not occur directly between the business application and the message middleware, but rather is redirected to an independent distributed coordination service or a shared storage system with atomic operation capabilities. The specific process for acquiring the lock is as follows: First, the request identifier is transformed according to the same or coordinated key generation rules as the synchronization path, generating a unique string within the lock service namespace as the lock key. Then, a conditional write request is initiated to the lock service. The core instruction of this request is to attempt to create an entry corresponding to the lock key in the lock service, but creation will only succeed if the key does not already exist. If creation succeeds, it means that the current instance has obtained exclusive rights to further process this request, i.e., it has successfully acquired the lock. If the key already exists, it indicates that another instance—perhaps an instance processing a synchronous response, or another consumer instance that received this asynchronous message earlier—has already acquired the lock, and the current acquisition attempt fails. This acquisition operation is instantaneous and is usually accompanied by an automatic lock expiration time setting to prevent deadlocks caused by holder failures. The entire process from receiving a message to attempting to acquire the lock constitutes the admission gateway for the asynchronous path to enter its critical processing stage.

[0035] When implementing this process, message reception and decoding can rely on callback functions of message middleware client libraries (such as KafkaConsumer, RabbitMQ Channel). Within the callback function, an idempotency check for duplicate message consumption can be performed first, which can be achieved through a global cache of processed message IDs separate from the lock service, followed by identifier extraction and matching. The specific client tools for acquiring the distributed lock can vary; for example, the Redisson client based on Redis can be used, which provides distributed lock objects that support automatic renewal and reentrancy. More complex lock queues can also be implemented using Zookeeper's ephemeral sequential nodes. Regarding the lock key generation strategy, global uniqueness and interoperability with the strategy used in the synchronous path must be ensured, for example, uniformly using the prefix "LOCK:" followed by a request identifier string. The lock holding time should be carefully set to cover the entire time required from successful lock acquisition to the complete processing and state update of the asynchronous result. Considering that asynchronous result processing may involve complex business logic and external I / O, this time is typically longer than the lock holding time in the synchronous path, for example, set to 10 to 30 seconds. In high-concurrency scenarios, one optimized implementation is to use non-blocking lock acquisition attempts. This involves attempting the lock once; if it fails, processing is immediately abandoned and message consumption is acknowledged (ensuring no infinite retries under at least one consumption semantic), relinquishing processing control to the instance already holding the lock. Another implementation logically binds lock acquisition with message consumption acknowledgment. When using a message model requiring manual acknowledgment, an ACK signal can be sent to the message broker only after successful lock acquisition. If lock acquisition fails, a strategy of re-entering the message queue or transferring it to a dead-letter queue is executed, providing stronger processing guarantees.

[0036] This embodiment incorporates concurrent asynchronous message processing into a globally unified mutual exclusion control system by immediately attempting to acquire a distributed lock based on the same request identifier when an asynchronous path is triggered. This ensures that, regardless of how or when the downstream system returns the final result, the critical result processing and state update logic for the same business request will only be executed once in the distributed environment. This effectively solves the problem of duplicate consumption caused by consumer group expansion or message re-delivery in message queue models.

[0037] S80, when the distributed lock corresponding to the request identifier is successfully acquired, and the processing status corresponding to the request identifier is found to be either timeout waiting state or initial unprocessed state, data persistence is performed based on the asynchronous processing result, and the processing status corresponding to the request identifier is updated to the completed state.

[0038] In this embodiment, after successfully acquiring a distributed lock for the request identifier, the system obtains a brief, exclusive time window to safely examine the global state of the request and decide on subsequent actions. At this point, an authoritative state query needs to be performed to determine whether the asynchronous result processing should continue. The goal of the query is to locate and read the current value recorded in the state record bound to the request identifier in persistent storage. This query operation must be completed within the validity period of the currently held distributed lock to ensure that no other parallel process can tamper with the state value between the query and any subsequent possible state updates. The query is typically implemented through a precise key-value lookup instruction, such as sending a SELECT statement to the database with the request identifier as the condition, or directly GETting the corresponding key from the distributed cache. The state value returned by the query is an enumeration or string with a predefined meaning. The system needs to compare and verify this with two specific, pre-agreed state values: "timeout waiting state" and "initial unprocessed state." The "timeout waiting state" indicates that the synchronous call path was previously abandoned due to a timeout, and the system is explicitly waiting for the asynchronous result to complete the supplementary entry. The "Initial Unprocessed State" indicates that since the request was created, the synchronous call path has never successfully returned any results, possibly because the call did not occur, failed immediately, or the asynchronous message arrived before any synchronous response. Only when the current state value is verified to belong to one of these two states does it mean that the asynchronous processing result is the missing and necessary final conclusion for the current request, and the process is authorized to proceed to the next step. Once verified, the system begins to process the received asynchronous processing result. This result is initially usually raw data in a network or message protocol format, which needs to be parsed to extract structured business information, such as operation result codes, business entity data, timestamps, etc. Subsequently, based on this information, a record that needs to be retained for a long time is generated; this process is called the execution of data persistence records. This is not just data dumping, but refers to formatting and associating key business information according to a predetermined data model, and saving it to non-volatile storage media through a reliable write operation. For example, writing transaction results to a transaction table in a relational database, or storing report files in object storage and generating indexes. This record constitutes the final evidence of the business facts of the request. Next, assuming the distributed lock protection remains effective, the system must perform a final atomic update on the state record of the same request. This is an operation that overwrites the previously queried state value, whether it is "timeout waiting state" or "initial unprocessed state," with the same final state value—"completed state." This update operation must be designed to be atomic, typically using conditional updates or CAS instructions in the database, to ensure that no update loss occurs even under extreme concurrency.Updating the status to "completed" is a globally finalized action, declaring that all business processing activities related to this request have concluded, and no new substantive business operations should be triggered, whether on synchronous or asynchronous paths. This update, together with the aforementioned data persistence record, constitutes a transaction under the successful processing of the asynchronous path.

[0039] State queries can be cached directly in application memory to improve speed, but a more common approach is to query the database, which serves as the sole source of truth, to ensure state consistency. Validation logic can be implemented as a simple value comparison function. The execution of persistent records varies. For simple state records, only a few fields in the database may need to be updated; for complex business data, multiple related tables may need to be written, or external file storage services may need to be called. In this case, local database transactions can be used to ensure the consistency between data persistence and state updates. In a microservice architecture, if persistence operations involve calling other services, distributed transaction patterns such as Saga should be considered. Another implementation variant is to design "validating state" and "executing persistent records" as a pluggable chain of processors, where the system selects different persistence logic processors to execute based on different queried state values. When updating the state to "completed," in addition to updating the state fields, a completion timestamp is usually also updated. To ensure atomicity, an SQL statement like `UPDATE table SET status = 'COMPLETED', finish_time = NOW() WHERE request_id = ? AND status IN ('TIMEOUT_WAITING', 'INIT')` can be used, relying on database row locks. In high-concurrency scenarios, this status update event can also be published to a reliable message stream, consumed by a dedicated service, and guaranteed to be eventually consistent, provided that the entire processing chain can be completed within the lock's validity period.

[0040] This embodiment, by performing state verification while holding a distributed lock, constitutes the final and most accurate decision-making checkpoint for preventing duplicate processing. It ensures that only requests truly in the "waiting for result" state will have their asynchronous results accepted and processed, while requests already successfully processed via the synchronous path, whose state has already been set to "completed," will be filtered out here, thus completely eliminating duplicate records. Structured data persistence recording based on asynchronous results ensures that even if real-time response fails, the final result of business operations can be completely and reliably saved, forming traceable and auditable data evidence, meeting the core requirement of eventual consistency in business operations.

[0041] In one embodiment, step S10 above includes: S101, Receive a cross-domain call request sent by the first service node, and parse the cross-domain call request to extract the business serial number and business payload data; S102, obtain the call timestamp, and concatenate the call timestamp, the service payload data, and the service serial number to obtain an initial feature string; S103, perform hash processing on the initial feature string to generate a request identifier; S104, construct a call record table entry in the storage medium with the request identifier as the key value, and generate a processing status corresponding to the request identifier in the call record table entry; S105, initialize the processing status in the call record table entry to the initial unprocessed state.

[0042] In this embodiment, the network endpoint listens for a data unit containing a specific protocol encapsulation. This data unit originates from an upstream business entity and is intended to trigger an operation involving external system collaboration; this data unit is a cross-domain call request. Receiving the request signifies completing the network transport layer handshake, packet reassembly, and protocol decoding, restoring it to a logical object that the application can process. A structured analysis of this logical object reveals two key elements. The first element is the business transaction number, a string or numeric sequence assigned by the upstream system to uniquely track this operation within its business scope, such as a customer transaction number in a bank transaction or an order number in an e-commerce platform. The second element is the business payload data, the core content of the request, containing the specific parameters and information necessary to execute the target operation, such as the recipient's account, amount, and currency in a transfer request. The extraction process requires field mapping and value retrieval based on the predefined interface contract between the two parties.

[0043] A high-precision reading of the current system clock is obtained, marking the exact moment the request entered the processing system; this is called the call timestamp. This timestamp is typically expressed in milliseconds or microseconds calculated from a fixed starting point (such as the Unix epoch). Subsequently, a string concatenation operation is performed, joining the character representations of the call timestamp, the business payload data (which may have been serialized), and the business serial number in a predefined, irreversible, and fixed order to form a longer composite string containing request characteristic information—the initial characteristic string. The fixed concatenation order is crucial, ensuring that the generated string is absolutely consistent for each identical request.

[0044] A cryptographic hash function, such as the SHA-256 algorithm, is applied to the generated initial feature string. This function accepts input of arbitrary length, performs deterministic mathematical calculations, and outputs a fixed-length (e.g., 256-bit) binary sequence, which is then converted into a hexadecimal or Base64 string format. This output string is defined as the request identifier for this cross-domain call. The one-wayness, collision resistance, and avalanche effect of the hash function ensure that even if the input business serial number or payload data differs only slightly, the generated request identifier will be completely different. Furthermore, it is impossible to deduce the original business data from the identifier, and the probability of generating the same identifier for different requests is extremely low, practically zero in engineering terms.

[0045] A storage medium is selected for persistent or temporary data storage, such as a table in a relational database, a collection in a document database, or a namespace in a distributed key-value store. Within this medium, a new data record is created or reserved using the generated request identifier as the primary or unique key; this record is the call record entry. This entry is a structured data container whose field structure is defined at creation time. Simultaneously, a field is allocated within this entry to record the progress of this call; this field is defined as the processing status corresponding to the request identifier. At this point, this field is assigned a specific, pre-agreed value that explicitly represents the "initial unprocessed state," such as the number 0 or the string "INIT." This is an atomic write operation designed to solidify the request's metadata and its lifecycle starting state in the storage system, providing a unique and authoritative initial reference point for all subsequent state transitions.

[0046] This embodiment extracts business elements from the request by parsing and concatenates a timestamp to generate a feature string, providing high-entropy, collision-resistant input material for creating a globally unique request identifier. Applying a cryptographic hash function to process this feature string not only generates an unpredictable and highly unique request identifier but also removes the direct association between the identifier and sensitive business data, balancing uniqueness and information hiding. A call record entry indexed by this unique identifier is created in the storage medium, and the state field is initialized synchronously. This completes the registration of the request identity in the system and the initialization of the state machine in one go, establishing an immutable original factual basis upon which subsequent dual-channel processing, state competition, and consistency judgments depend.

[0047] In one embodiment, step S20 above includes: S201, Encapsulate the request identifier into the call payload to generate a synchronous call request; S202, send the synchronization call request to the second service node to initiate a synchronization interface call, and use the logical path associated with the current synchronization interface call as the first receiving channel; S203, Start the timeout control timer corresponding to the first receiving channel, and the timeout duration of the timeout control timer is configured to a preset response time threshold; S204, within the timeout control timer indicating that the timeout has not expired, the system listens for and receives the synchronization response result from the second service node through the communication link corresponding to the first receiving channel.

[0048] In this embodiment, the request identifier, which serves as the core tracking key, is embedded into the set of business parameters to be sent, according to the data format and location requirements specified by the target interface protocol. This process is called encapsulation. For example, in a JSON-formatted request body, it is used as the value of the requestId field; or in a Protocol Buffers message structure, the corresponding string field is filled in. Encapsulation ensures that the identifier becomes an integral part of the call payload, forming a syntactically complete and semantically clear synchronous call request data structure together with other business parameters. This data structure is then serialized into a byte stream, ready for network transmission.

[0049] A serialized byte stream is sent via a transport layer protocol connection to the network endpoint of a pre-determined second service node through a network communication client instance. This sending action triggers the complete processing flow of the network stack, including possible DNS resolution, TCP connection establishment or multiplexing, TLS handshake, and application layer protocol request assembly and writing. This complete network interaction process, from the start of sending to the expected receipt of a response, is logically instantiated as a manageable object entity. This entity encapsulates the target address, protocol state, callback entry point, and result buffer of this call. This entity is defined as the first receiving channel. It represents a virtual path from the time the service sends a request to the time it receives a response.

[0050] Immediately upon initiating a network transmission, or immediately afterward, a timing component is initialized and bound to this first receiving channel entity. This timing component is the timeout control timer, which can be an operating system-level timer, a high-precision timer for a language runtime, or a scheduled task based on an event loop. Its core parameter—the timeout duration—is explicitly set to a specific value—a preset response time threshold—which determines the timer's trigger boundary. After the timer starts, it begins unidirectional timing, and its state (not timed out or timed out) becomes a key Boolean flag controlling subsequent listening behavior.

[0051] During the timeout period when the timeout control timer is in the non-timeout state, the system continuously monitors for data arrival through the underlying communication link (such as TCP Socket, HTTP / 2 Stream) maintained by the first receiving channel entity. Monitoring is typically performed by an asynchronous I / O framework or a blocking I / O thread, specifically by waiting for readable events on the socket file descriptor or checking the status of Future / Promise objects returned by asynchronous calls. When a data arrival event is detected, the raw byte data is immediately read from the link and reconstructed into a structured response object according to the deserialization rules corresponding to the sending time serialization. If the format of this reconstructed object conforms to the protocol agreement and passes the basic integrity check, it is recognized as a synchronous response result from the second service node. The entire process continues until the timer times out, forcibly ending the listening state.

[0052] This embodiment establishes a deterministic path for real-time, proactive result retrieval based on the request identifier by encapsulating it into the payload and sending it. The invocation process is abstracted as a first receiving channel, providing encapsulation boundaries and operation handles for managing the lifecycle of this network interaction. Starting a timer bound to this channel and configuring its timeout with a preset threshold introduces precise time constraints on waiting behavior, preventing unlimited resource consumption due to downstream latency. Focused listening within the timer's non-timeout window ensures the system can efficiently and controllably capture normal, immediate feedback from downstream systems, providing a clearly defined input source for subsequent immediate decision-making and response.

[0053] In one embodiment, step S30 above includes: S301, determine the corresponding asynchronous message subscription point based on the request identifier and the predefined message topic; S302, Create or associate a message consumer instance with the asynchronous message subscription point, and use the message consumer instance as a second receiving channel; S303, Configure a message filter for the second receiving channel, wherein the filtering conditions of the message filter are based on the request identifier; S304, Start the message listening function of the second receiving channel; S305, receive and filter asynchronous processing results from the second service node that meet the filtering conditions through the second receiving channel which is in operation.

[0054] In this embodiment, the request identifier is associated with a pre-declared and existing logical category label in the messaging system, i.e., a predefined message topic. This operation follows the naming and routing rules of the message middleware, and the result is an address identifier that uniquely locates the message flow related to this request within the message domain, i.e., the asynchronous message subscription point. For example, in a publish-subscribe model, this could be a specific topic name such as "PaymentResult.${requestId}"; in a queue model, this could be binding the request identifier as a routing key to a queue determined by a specific exchange. Determining this subscription point means clarifying which logical port of the messaging infrastructure the system needs to receive data from.

[0055] Based on a defined asynchronous message subscription point, a software object capable of consuming messages from that point is instantiated; this is the message consumer instance. Instantiation can employ two strategies: one is to create a completely new, independent consumer object for that subscription point; the other is to associate the current processing context with an existing shared consumer instance responsible for consuming a wider range of messages, enabling that shared instance to recognize and process messages directed to this specific subscription point. The core responsibilities of this instantiated or associated consumer object are connecting to the message broker, executing subscriptions, pulling or receiving messages, and callback processing logic. This object and its complete set of functionalities are abstractly defined as the second receiving channel. This channel logically complements and parallels the first receiving channel.

[0056] To prevent the second receiving channel from processing irrelevant messages, it must be equipped with a message filter. This filter is a judgment logic based on the request identifier. Filtering can be implemented at different levels: when the message broker supports it, the filtering conditions can be declared directly during the subscription phase, such as using RabbitMQ's header exchange to bind specific headers, or using RocketMQ's SQL expressions to filter message attributes; if the broker does not support it, then in the message processing callback function of the consumer instance, each message is explicitly parsed, and the identifier field is extracted and compared with the current request identifier. The filtering conditions based on the request identifier ensure that only messages strictly related to this request are passed to subsequent business logic.

[0057] Execute a specific instruction to bring the second receiving channel from a ready state to an active state. For a newly created consumer, this might be calling its start() or consume() method; for a shared consumer, this might be completing context binding and activating the listening logic for that specific request identifier. The start operation triggers the establishment of an underlying network connection, sending a subscription command to the message broker, or starting to poll the message queue, bringing the channel into a working state where it can receive messages.

[0058] When the second receiving channel is active, its underlying network connection continuously listens or its associated thread actively pulls message streams. Each arriving raw message, after decoding, is first judged by the configured message filter. Only messages that meet the filtering conditions—that is, messages whose identifier matches the current request identifier—are considered valid asynchronous processing results from the second service node and are allowed to proceed to subsequent result parsing and business processing. Messages that do not meet the conditions are directly ignored or acknowledged for consumption without triggering any business operations.

[0059] This embodiment determines the precise asynchronous message subscription point by using request identifiers and predefined topics, achieving accurate message addressing and business isolation. The consumer instance is abstracted as a second receiving channel, establishing a dedicated, event-driven result capture path independent of synchronous network requests. Configuring a filter based on the request identifier for the channel ensures the accuracy of message processing and prevents message crosstalk between different requests. Starting listening puts the path into an active-ready state. In the active state, the channel continuously performs receiving and filtering, forming a reliable and dedicated backup information path. This ensures that the processing results of downstream asynchronous transmissions can be accurately captured by the system, providing a controlled input source for business state completion after synchronization timeout.

[0060] In one embodiment, step S50 above includes: S501, upon successfully acquiring the distributed lock corresponding to the request identifier, parse the protocol body of the synchronization response result to obtain the business status code and business result data; S502, Based on the business status code and the preset business strategy, process the business result data to generate a final processing result that meets the expectations of the first service node; S503, return the final processing result to the first service node; S504, based on the currently successfully held distributed lock, perform an update operation on the call record table entry in the storage medium corresponding to the request identifier, and modify the processing status recorded in the call record table entry to the completed status.

[0061] In this embodiment, once the system confirms that it has successfully acquired an exclusive token with the current request identifier as the key in the distributed coordination service, it enters the mutually exclusive processing phase. First, the raw network data captured through the first receiving channel undergoes deep parsing. This data conforms to a specific application layer protocol format, such as an HTTP response body, gRPC messages, or a custom binary protocol packet. The parsing process includes stripping the protocol header, verifying data integrity, and performing deserialization to extract two structured core elements from the protocol body. The first element is the business status code, a code defined by the downstream system to concisely represent the success or failure status of this business-level call, such as "SUCCESS," "FAIL," or a numeric code. The second element is the business result data, a collection of specific business information returned by the downstream system when the status code indicates success; this could be a JSON object, a set of key-value pairs, or a block of binary data. The extraction operation ensures that the raw byte stream is converted into a structured object that can be accessed programmably in memory.

[0062] The system retrieves the parsed business status code and uses it as input to query a predefined and configurable set of rules, i.e., the preset business strategy. These strategies define how to map the state semantics of the downstream system to a state that the upstream system can understand, and how to perform necessary transformations, filtering, formatting, or enhancements on the business result data. For example, the strategy might stipulate that when the downstream returns a status code "200", it is mapped to "transaction successful" from the upstream, and only the "transaction serial number" and "account balance" fields are extracted from the business result data and reassembled according to a specific template. Based on the processing logic executed by the strategy, a new data object is generated, whose data structure and content conform to the interface contract pre-agreed with the first service node. This object is the final processing result. This result has completed the adaptation from the downstream format to the upstream format.

[0063] The generated final processing result data object is serialized and sent via a network programming interface, connected to the established or temporarily created communication connection with the first service node. This return operation is typically executed by an HTTP server response object, a callback function of an RPC framework, or a producer component of a message queue, aiming to deliver the processing conclusion to the upstream caller in a timely manner, completing the feedback loop of this synchronous call.

[0064] While the distributed lock remains in a valid holding state within the specified time window, the system accesses the storage medium, locates the specific data record indexed by the current request identifier as the key, and invokes the record entry. Subsequently, an atomic data modification command is executed on the field representing the processing status of that entry. This modification command directly sets the field's value from an arbitrary previous state (e.g., "Initially Unprocessed") to a specific value representing the end of the process, i.e., "Completed." This update operation must be performed under the protection of the lock to ensure that no other parallel process can intervene and modify the same record between querying the status and executing the update, thus guaranteeing absolute exclusivity and eventual consistency of the state change.

[0065] This embodiment ensures the atomicity and consistency of response processing and result transformation under high concurrency by parsing the response under exclusive lock protection and generating the final result according to the strategy. This prevents chaotic or erroneous transformation results from being returned upstream due to concurrent processing. Timely return of the adapted result upstream meets the timeliness requirements of real-time interaction and completes the core value delivery of the synchronous path.

[0066] In one embodiment, step S60 above includes: S601, monitor the timer bound to the first receiving channel, and generate a timeout interrupt signal when the timer reaches the preset response time threshold; S602, record the precise timeout moment corresponding to the timeout interrupt signal; S603, in response to the timeout interrupt signal, dynamically generate a waiting prompt message containing the service suspension code based on the request identifier and the precise timeout time; S604, the waiting prompt information is sent to the first service node; S605, Initiate a query request to the storage medium for the call record table entry with the request identifier as the key value; S606, after receiving a query response containing the call record table entry, the processing status and associated timeout timestamp field in the call record table entry are changed to timeout waiting status and precise timeout time.

[0067] In this embodiment, the internal count value of a timer component closely associated with the first receiving channel instance is continuously polled or checked via event callbacks. This timer is instantiated and started when the channel is created, and its count endpoint is preset to the number of timing units corresponding to a preset response time threshold. The monitoring logic determines whether the current count value has reached or exceeded this endpoint threshold. When the condition is met, the timer component or the monitoring logic generates a specific software event or sets a flag, which is defined as a timeout interrupt signal. This signal is not a user-visible output, but rather an internal trigger used by the system to indicate the state change that "the synchronization wait time window has been exhausted."

[0068] Capture the system clock reading of the processing node where the timeout interrupt signal is triggered. This reading is a high-precision timestamp, typically based on Coordinated Universal Time (UTC), accurate to milliseconds or microseconds. It records the absolute point in time when the timeout event occurred, rather than a time interval. This timestamp is extracted and stored in a memory variable or temporary structure as precise time evidence of this timeout event for subsequent related operations.

[0069] Driven by a captured timeout interruption signal, a message generation function is invoked. The function's input parameters include a unique identifier string for the current request and the previously recorded precise timeout moment. Internally, the function's logic dynamically synthesizes a structured message based on these two parameters, combined with a predefined text template or construction rules. This message contains a specific code indicating that the business process has been temporarily suspended (i.e., a business suspension code), as well as optional request identifier and timeout information. Dynamic generation ensures that each message uniquely corresponds to a specific request and timeout event point.

[0070] The generated waiting prompt information data structure is serialized into a byte stream conforming to the communication protocol between the two parties through the network stack serving the first receiving channel or the communication context maintained with the first service node, and this byte stream is transmitted to the first service node by calling the network sending interface. This operation aims to convey a clear process status notification to the upstream system, rather than the final business result.

[0071] This involves initiating a network or inter-process call to a storage medium such as a database or cache that serves as persistent storage. This call encapsulates a precise data retrieval instruction, using the current request identifier as the key index, and aims to locate and retrieve the corresponding complete data record from the storage medium—that is, to retrieve the record entry. This is an explicit point query operation.

[0072] After the storage medium processes the query request and returns a response packet containing all fields of the target call record table entry, the system parses the response packet, locating the processing status field and a timeout timestamp field specifically used to record timeout events. Subsequently, a write operation is performed, rewriting the value of the processing status field to a specific enumerated value or string representing the "timeout wait status," while simultaneously updating the value of the timeout timestamp field to the previously recorded precise timeout moment. This update operation is typically atomic, ensuring that both fields are modified simultaneously and consistently.

[0073] This embodiment uses a timer bound to the channel to determine timeouts and generate interrupt signals, providing a precise and controllable internal event-driven mechanism for process state transitions. Recording the timeout moment provides an auditable time anchor for the event. Based on the request identifier and the time, a prompt message is dynamically generated, ensuring the uniqueness and traceability of the feedback content. Timely sending of this information manages upstream expectations and releases connection resources. Querying the storage medium to obtain the current recorded state ensures that the object of subsequent state updates is definite and up-to-date. Atomically changing the processing state to timeout waiting and recording the timestamp accurately captures the time point of synchronous path failure at the persistence level and formally pushes the request lifecycle into the waiting stage for asynchronous recording, setting clear, data-driven state boundaries for dual-channel collaboration.

[0074] In one embodiment, step S80 above includes: S801, when successfully acquiring the distributed lock corresponding to the request identifier, based on the currently held distributed lock, send a lock query request to the storage medium for the call record table entry with the request identifier as the key value; S802, receive the query response returned by the storage medium, and obtain the current processing status recorded in the call record table entry from the query response; S803, verify that the current processing state is a timeout waiting state or an initial unprocessed state; S804. After successful verification, the asynchronous processing result is parsed and transformed to generate a structured business data record that conforms to a persistent format. S805, the structured business data record is written to the persistent storage unit; S806, based on the currently held distributed lock, perform an atomic update operation on the call record table entry in the storage medium, and set the value of the processing status field in the call record table entry to the completed status.

[0075] In this embodiment, once the system confirms that an exclusive token with the current request identifier as the key has been successfully established in the distributed coordination service, it obtains an operation window protected by mutual exclusion. Within this window, the system initiates a targeted data retrieval operation to persistent storage, which is encapsulated as a lock query request. The special feature of this request is that its execution context is explicitly associated with the currently held distributed lock, meaning that the storage medium can sense or ensure that this query occurs during the lock holding period, thus potentially imposing additional concurrency control, such as using a SELECT ... FOR UPDATE statement at the database level, or using read operations with atomicity guarantees in the distributed cache. The goal of the request is to precisely locate the data record with the request identifier as the primary key or unique index key, i.e., to call the record table entry and retrieve its complete or partial field content.

[0076] After processing the query request, the storage medium returns a structured response data packet. The system parses the various fields of the target call record entry from this response packet and extracts the field values ​​specifically representing the stage and result of the request process, i.e., the current processing status. This status value is a string or number with a predefined enumeration meaning, such as "TIMEOUT_WAITING" or "INIT".

[0077] After extracting the current processing status value, the system performs a Boolean logic check. This check compares the status value with two pre-defined specific status values ​​representing allowed asynchronous result supplementation: one is a "timeout waiting state," indicating that the synchronous path has given up due to timeout and is explicitly waiting for asynchronous supplementation; the other is an "initial unprocessed state," indicating that the request has not been processed by any path since its creation. The verification operation is performed by comparing the current status value with these two allowed values ​​for equality. Only when the comparison result is true, i.e., the current status equals one of the two, is the verification considered successful, and the process is authorized to proceed to the subsequent substantive processing stage.

[0078] After successful verification, the system begins processing the asynchronous processing results captured through the second receiving channel. The initial format of this result may be JSON, XML, or a binary message. Parsing involves decoding the message and extracting business-related fields, such as the operation result, data body, and timestamp. Transformation, based on the data model required by persistent storage, maps, formats, or calculates the extracted information to generate a structured business data record that fully conforms to the target storage table structure or document schema. For example, transaction information in the message might be converted into a single row in a database order table.

[0079] The generated structured business data records are written to a physical or logical storage unit designed for long-term, reliable data preservation through the corresponding data access interface. This unit can be a table in a relational database, a collection in a document database, a file in an object storage service, or a document in an indexing engine. The write operation must ensure data integrity and consistency and may involve transactions or at least one-write semantics.

[0080] Assuming the distributed lock holding state is still valid and has not timed out, the system sends another data modification instruction to the storage medium, targeting the same call record entry previously queried. This update operation is designed to be atomic, meaning that in a concurrent environment, the operation either succeeds completely or fails completely; partial updates are not possible. The core of the operation is to unconditionally set the value of the processing status field in the entry to a specific value representing the final completion of the process, i.e., "completed." This operation is typically implemented in the database using an UPDATE statement with version numbers or condition checks, or by performing a comparison and swap in a cache that supports CAS operations, ensuring that even under high concurrency, the transition from "timeout waiting" or "initially unprocessed" to "completed" is idempotent and a one-time event.

[0081] This embodiment, by performing lock queries and state verification under the protection of a distributed lock, constitutes a final consistency decision gate for asynchronous path processing. This ensures that only requests that truly require supplementary data are processed, while requests already completed by the synchronous path are securely filtered out. Asynchronous results are parsed and transformed to generate structured records, enabling the final business facts downstream to be persisted independently and completely, forming auditable data evidence. During the lock's duration, the global state is atomically updated to "completed," which has authoritative final declaration power. This not only completes the request lifecycle but also permanently blocks any possibility of subsequent processing, eliminating the risk of duplicate records and state inconsistencies at the source, achieving determinism and reliability throughout the entire process.

[0082] In one embodiment, a cross-domain interface collaborative invocation apparatus is provided, which corresponds one-to-one with the cross-domain interface collaborative invocation method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the cross-domain interface collaborative invocation device of the present invention. The modules include: request identifier initialization module 10, synchronous invocation channel module 20, asynchronous listening channel module 30, synchronous lock acquisition module 40, synchronous result processing module 50, timeout status processing module 60, asynchronous lock acquisition module 70, and asynchronous result persistence module 80. Detailed descriptions of each functional module are as follows: The request identifier initialization module 10 is used to receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state. The synchronous call channel module 20 is used to initiate a synchronous interface call to the second service node based on the request identifier as the first receiving channel, and to listen for the synchronous response result returned by the second service node within a preset response time threshold. The asynchronous listening channel module 30 is used to enable a message listening mechanism as a second receiving channel based on the request identifier, so as to receive the asynchronous processing results sent by the second service node; The synchronization lock acquisition module 40 is used to acquire the distributed lock corresponding to the request identifier when the synchronization response result is received through the first receiving channel within the preset response time threshold. The synchronization result processing module 50 is used to parse the synchronization response result when the distributed lock corresponding to the request identifier is successfully acquired, return the final processing result to the first service node based on the parsed synchronization response result, and update the processing status corresponding to the request identifier to the completed status. The timeout status processing module 60 is used to return a waiting prompt message to the first service node when the synchronization response result is not received within the preset response time threshold, and to record the processing status corresponding to the request identifier as a timeout waiting status. The asynchronous lock acquisition module 70 is used to acquire a distributed lock corresponding to the request identifier when the asynchronous processing result is received through the second receiving channel; The asynchronous result persistence module 80 is used to perform data persistence recording based on the asynchronous processing result and update the processing status corresponding to the request identifier to the completed status when the distributed lock corresponding to the request identifier is successfully acquired and the processing status corresponding to the request identifier is found to be either timeout waiting state or initial unprocessed state.

[0083] For specific limitations regarding the cross-domain interface collaborative invocation device, please refer to the aforementioned limitations on the cross-domain interface collaborative invocation method, which will not be repeated here. Each module in the aforementioned cross-domain interface collaborative invocation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0084] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a cross-domain interface cooperative invocation method on the server side.

[0085] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a cross-domain interface collaborative invocation method.

[0086] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state; Based on the request identifier, a synchronization interface call is initiated to the second service node as the first receiving channel, and the synchronization response result returned by the second service node is monitored within a preset response time threshold. Based on the request identifier, a message listening mechanism is enabled as a second receiving channel to receive the asynchronous processing results sent by the second service node; When the synchronization response result is received through the first receiving channel within the preset response time threshold, a distributed lock corresponding to the request identifier is acquired; Upon successfully acquiring the distributed lock corresponding to the request identifier, the synchronization response result is parsed, and the final processing result is returned to the first service node based on the parsed synchronization response result. The processing status corresponding to the request identifier is also updated to the completed status. If the synchronization response result is not received within the preset response time threshold, a waiting prompt message is returned to the first service node, and the processing status corresponding to the request identifier is recorded as a timeout waiting status. Upon receiving the asynchronous processing result through the second receiving channel, acquire the distributed lock corresponding to the request identifier; Upon successfully acquiring the distributed lock corresponding to the request identifier and finding that the processing status corresponding to the request identifier is either a timeout waiting state or an initial unprocessed state, data persistence is performed based on the asynchronous processing result, and the processing status corresponding to the request identifier is updated to the completed state.

[0087] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state; Based on the request identifier, a synchronization interface call is initiated to the second service node as the first receiving channel, and the synchronization response result returned by the second service node is monitored within a preset response time threshold. Based on the request identifier, a message listening mechanism is enabled as a second receiving channel to receive the asynchronous processing results sent by the second service node; When the synchronization response result is received through the first receiving channel within the preset response time threshold, a distributed lock corresponding to the request identifier is acquired; Upon successfully acquiring the distributed lock corresponding to the request identifier, the synchronization response result is parsed, and the final processing result is returned to the first service node based on the parsed synchronization response result. The processing status corresponding to the request identifier is also updated to the completed status. If the synchronization response result is not received within the preset response time threshold, a waiting prompt message is returned to the first service node, and the processing status corresponding to the request identifier is recorded as a timeout waiting status. Upon receiving the asynchronous processing result through the second receiving channel, acquire the distributed lock corresponding to the request identifier; Upon successfully acquiring the distributed lock corresponding to the request identifier and finding that the processing status corresponding to the request identifier is either a timeout waiting state or an initial unprocessed state, data persistence is performed based on the asynchronous processing result, and the processing status corresponding to the request identifier is updated to the completed state.

[0088] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0090] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0091] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0092] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A cross-domain interface coordination calling method, characterized in that, The method comprises the following steps: receiving a cross-domain call request sent by a first service node, generating a request identifier and a processing state corresponding to the request identifier based on the cross-domain call request, and initializing the processing state as an initial unprocessed state; initiating a synchronous interface call to a second service node as a first receiving channel based on the request identifier, and listening for a synchronous response result returned by the second service node within a preset response time threshold; starting a message listening mechanism as a second receiving channel based on the request identifier to receive an asynchronous processing result sent by the second service node; when the synchronous response result is received through the first receiving channel within the preset response time threshold, acquiring a distributed lock corresponding to the request identifier; when the distributed lock corresponding to the request identifier is successfully acquired, analyzing the synchronous response result, returning a final processing result to the first service node based on the analyzed synchronous response result, and updating the processing state corresponding to the request identifier to a completed state; when the synchronous response result is not received within the preset response time threshold, returning a waiting prompt information to the first service node, and recording the processing state corresponding to the request identifier as a timeout waiting state; when the asynchronous processing result is received through the second receiving channel, acquiring a distributed lock corresponding to the request identifier; when the distributed lock corresponding to the request identifier is successfully acquired and the processing state corresponding to the request identifier is queried as a timeout waiting state or an initial unprocessed state, performing data persistence recording based on the asynchronous processing result, and updating the processing state corresponding to the request identifier to a completed state.

2. The cross-domain interface coordination invoking method of claim 1, wherein, receiving a cross-domain call request sent by a first service node, generating a request identifier and a processing state corresponding to the request identifier based on the cross-domain call request, and initializing the processing state as an initial unprocessed state, comprising: receiving a cross-domain call request sent by a first service node, parsing the cross-domain call request to extract a business serial number and business payload data; acquiring a call timestamp, concatenating the call timestamp, the business payload data and the business serial number to obtain an initial feature string; generating a request identifier by hashing the initial feature string; constructing a call record table entry with the request identifier as a key value in a storage medium, and generating a processing state corresponding to the request identifier in the call record table entry; initializing the processing state in the call record table entry as an initial unprocessed state.

3. The cross-domain interface coordination invoking method of claim 1, wherein, initiating a synchronous interface call to a second service node as a first receiving channel based on the request identifier, and listening for a synchronous response result returned by the second service node within a preset response time threshold, comprising: encapsulating the request identifier into a call payload to generate a synchronous call request; sending the synchronous call request to the second service node to initiate the synchronous interface call, and taking a logical path associated with the current synchronous interface call as the first receiving channel; starting a timeout control timer corresponding to the first receiving channel, and the timeout duration of the timeout control timer is configured as a preset response time threshold; During the timeout period indicated by the timeout control timer, the synchronization response result from the second service node is monitored and received through the communication link corresponding to the first receiving channel.

4. The cross-domain interface coordination invoking method of claim 1, wherein, Based on the request identifier, a message listening mechanism is activated as a second receiving channel to receive asynchronous processing results sent by the second service node, including: Based on the request identifier and the predefined message topic, the corresponding asynchronous message subscription point is determined; Create or associate a message consumer instance with the asynchronous message subscription point, and use the message consumer instance as a second receiving channel; Configure a message filter for the second receiving channel, wherein the filtering conditions of the message filter are based on the request identifier; Start the message listening function of the second receiving channel; The asynchronous processing results that meet the filtering conditions from the second service node are received and filtered through the second receiving channel, which is in operation.

5. The cross-domain interface coordination invoking method of claim 1, wherein, Upon successfully acquiring the distributed lock corresponding to the request identifier, the synchronization response result is parsed, and based on the parsed synchronization response result, the final processing result is returned to the first service node. The processing status corresponding to the request identifier is then updated to the completed status, including: Upon successfully acquiring the distributed lock corresponding to the request identifier, the protocol body of the synchronization response result is parsed to obtain the business status code and business result data; Based on the business status code and the preset business strategy, the business result data is processed to generate a final processing result that meets the expectations of the first service node; The final processing result is returned to the first service node; Based on the currently successfully held distributed lock, perform an update operation on the call record table entry in the storage medium corresponding to the request identifier, and modify the processing status recorded in the call record table entry to the completed status.

6. The cross-domain interface coordination invoking method of claim 1, wherein, If the synchronization response result is not received within the preset response time threshold, a waiting prompt message is returned to the first service node, and the processing status corresponding to the request identifier is recorded as a timeout waiting status, including: Monitor the timer bound to the first receiving channel, and generate a timeout interrupt signal when the timer reaches the preset response time threshold; Record the precise timeout moment corresponding to the timeout interrupt signal; In response to the timeout interruption signal, a waiting prompt message containing the service suspension code is dynamically generated based on the request identifier and the precise timeout time. Send the waiting prompt message to the first service node; Initiate a query request to the storage medium for the call record table entry with the request identifier as the key value; Upon receiving a query response containing the aforementioned call record entry, the processing status and associated timeout timestamp field in the call record entry are changed to a timeout waiting status and a precise timeout moment.

7. The cross-domain interface coordination invoking method of claim 1, wherein, Upon successfully acquiring the distributed lock corresponding to the request identifier, and finding that the processing status corresponding to the request identifier is either a timeout waiting state or an initial unprocessed state, data persistence is performed based on the asynchronous processing result, and the processing status corresponding to the request identifier is updated to the completed state, including: Upon successfully acquiring the distributed lock corresponding to the request identifier, a lock query request for the call record table entry with the request identifier as the key is sent to the storage medium based on the currently held distributed lock. Receive the query response returned by the storage medium, and obtain the current processing status recorded in the call record table entry from the query response; Verify that the current processing state is either a timeout waiting state or an initial unprocessed state; After successful verification, the asynchronous processing result is parsed and transformed to generate a structured business data record that conforms to a persistent format; Write the structured business data records into the persistent storage unit; Based on the currently held distributed lock, an atomic update operation is performed on the call record table entry in the storage medium to set the value of the processing status field in the call record table entry to the completed status.

8. A cross-domain interface coordination calling apparatus, characterized in that, The cross-domain interface collaborative invocation device includes: The request identifier initialization module is used to receive a cross-domain call request sent by the first service node, generate a request identifier and a processing status corresponding to the request identifier based on the cross-domain call request, and initialize the processing status to an initial unprocessed state. The synchronous call channel module is used to initiate a synchronous interface call to the second service node based on the request identifier as the first receiving channel, and to listen for the synchronous response result returned by the second service node within a preset response time threshold. An asynchronous listening channel module is used to enable a message listening mechanism as a second receiving channel based on the request identifier, so as to receive the asynchronous processing results sent by the second service node; The synchronization lock acquisition module is used to acquire the distributed lock corresponding to the request identifier when the synchronization response result is received through the first receiving channel within the preset response time threshold. The synchronization result processing module is used to parse the synchronization response result when the distributed lock corresponding to the request identifier is successfully acquired, return the final processing result to the first service node based on the parsed synchronization response result, and update the processing status corresponding to the request identifier to the completed status. The timeout status processing module is used to return a waiting prompt message to the first service node when the synchronization response result is not received within the preset response time threshold, and to record the processing status corresponding to the request identifier as a timeout waiting status. An asynchronous lock acquisition module is used to acquire a distributed lock corresponding to the request identifier when the asynchronous processing result is received through the second receiving channel; The asynchronous result persistence module is used to perform data persistence recording based on the asynchronous processing result and update the processing status of the request identifier to the completed status when the distributed lock corresponding to the request identifier is successfully acquired and the processing status corresponding to the request identifier is found to be either timeout waiting state or initial unprocessed state.

9. A computer device, comprising: The computer device includes a memory, a processor, and a cross-domain interface cooperative calling program stored in the memory and executable on the processor, wherein when the cross-domain interface cooperative calling program is executed by the processor, it implements the steps of the cross-domain interface cooperative calling method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a cross-domain interface cooperative invocation program, which, when executed by the processor, implements the steps of the cross-domain interface cooperative invocation method as described in any one of claims 1-7.

Images