Service calling and responding method and device, equipment, medium and service calling system

Abstract

The embodiment of the invention discloses a service calling and responding method and device, equipment, a medium and a service calling system.The service calling method comprises the steps that a service calling request is obtained, and the service calling request comprises a to-be-called service and a target service partition to which the to-be-called service belongs; generating a task identifier according to the service calling request, generating a request packet according to the task identifier, sending the request packet to a partition interface of a target service partition so as to determine a target service node corresponding to the request packet through the partition interface, and sending the request packet to the target service node, generating a response packet corresponding to the request packet through the target service node; and receiving the response packet sent by the partition interface. According to the technical scheme provided by the invention, specifically, the same task identifier is used in the distributed service calling process, so that the data consistency can be improved, and the service calling accuracy is improved.

Description

Technical Field

[0001] This invention relates to the field of distributed services, and more particularly to service invocation and response methods, apparatus, devices, media, and service invocation systems. Background Technology

[0002] With the globalization of financial services and the diversification of customer needs, single services are no longer sufficient to support complex business scenarios, such as cross-border payments and overseas investments. The coordinated use of multiple services has become a necessity for business execution. Driven by security requirements, financial institutions have created independent partitions based on their geographical locations, with each partition deploying dedicated data and services to meet localized operational needs. However, globalized businesses (such as remittances from Asia-Pacific customers to Europe and the United States) require cross-partition service calls.

[0003] However, current cross-partition service calls lack a unified transaction coordination and data synchronization mechanism. When making service calls across partitions, the initiating node and the service node are located in different partitions, and the identification systems within the partitions are not unified, which leads to data chaos and inconsistency, affecting the efficiency of service calls. Summary of the Invention

[0004] This invention provides a service invocation and response method, apparatus, device, medium, and service invocation system. Through the technical solutions of the embodiments of this invention, cross-partition service invocation can be realized while ensuring data consistency during the service invocation process.

[0005] In a first aspect, embodiments of the present invention provide a service invocation method, including:

[0006] Obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0007] Based on the service call request, a task identifier is generated, a request packet is generated based on the task identifier, and the request packet is sent to the partition interface of the target service partition. The partition interface is used to determine the target service node corresponding to the request packet, and the request packet is sent to the target service node. The target service node generates a response packet corresponding to the request packet.

[0008] Receive the response packet sent by the partition interface.

[0009] Secondly, embodiments of the present invention provide a service response method, including:

[0010] The partition interface receives a request packet sent by the partition interface. The request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node.

[0011] A service response is generated based on the request packet, and a response packet is generated based on the service response and the task identifier.

[0012] The response packet is sent to the initiating node through the partition interface.

[0013] Thirdly, embodiments of the present invention provide a service invocation system, including an initiating partition and at least one service partition that does not communicate with the initiating partition. The initiating partition includes an initiating node, and the service partition includes a service node and a partition interface.

[0014] The initiating node is used to obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0015] The initiating node is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, and send the request packet to the partition interface of the target service partition.

[0016] The partition interface of the target service partition is used to determine the target service node based on the request packet and send the request packet to the target service node;

[0017] The target service node is used to generate a service response based on the request packet, generate a response packet based on the service response and the task identifier, and send the response packet to the partition interface;

[0018] The partition interface is used to send the response packet to the initiating node.

[0019] Fourthly, embodiments of the present invention provide a service invocation apparatus, comprising:

[0020] The request acquisition module is used to acquire service invocation requests, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0021] The identifier generation module is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, send the request packet to the partition interface of the target service partition, determine the target service node corresponding to the request packet through the partition interface, send the request packet to the target service node, and generate a response packet corresponding to the request packet through the target service node.

[0022] A receiving module is used to receive the response packet sent by the partition interface.

[0023] Fifthly, embodiments of the present invention provide a service response apparatus, comprising:

[0024] The receiving module is used to receive request packets sent by the partition interface, wherein the request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node.

[0025] The generation module is used to generate a service response based on the request packet, and to generate a response packet based on the service response and the task identifier;

[0026] The sending module is used to send the response packet to the initiating node through the partition interface.

[0027] Sixthly, embodiments of the present invention provide an electronic device, the electronic device comprising:

[0028] At least one processor; and,

[0029] A memory communicatively connected to the at least one processor; wherein,

[0030] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the service invocation method or service response method as described in any one of the embodiments of the present invention.

[0031] In a seventh aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the service invocation method or service response method described in any one of the embodiments of the present invention.

[0032] This invention provides a service invocation and response method, apparatus, device, medium, and service invocation system. The invocation method includes: obtaining a service invocation request, wherein the service invocation request includes a service to be invoked and a target service partition to which the service to be invoked belongs; generating a task identifier based on the service invocation request; generating a request packet based on the task identifier; sending the request packet to a partition interface of the target service partition to determine the target service node corresponding to the request packet through the partition interface; sending the request packet to the target service node; generating a response packet corresponding to the request packet through the target service node; and receiving the response packet sent by the partition interface. Specifically, in this invention, by generating a globally unique task identifier based on the service invocation request and maintaining the consistency of the task identifier throughout the entire service invocation process, data synchronization and state alignment at each stage of the service invocation process are achieved, ultimately ensuring the security and data consistency of business operations. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart of a service invocation method provided in Embodiment 1 of the present invention;

[0035] Figure 2 A flowchart of a service invocation method is provided for Embodiment 2 of the present invention;

[0036] Figure 3 A flowchart of a service response method provided in Embodiment 3 of the present invention;

[0037] Figure 4 This is a schematic diagram of the structure of a service invocation system provided in Embodiment 4 of the present invention;

[0038] Figure 5 A schematic diagram of a service invocation system provided in an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of the service invocation device provided in Embodiment 5 of the present invention;

[0040] Figure 7 This is a schematic diagram of the structure of a service response device provided in Embodiment Six of the present invention;

[0041] Figure 8 This is a schematic diagram of the structure of an electronic device provided in Embodiment 7 of the present invention. Detailed Implementation

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

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

[0044] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0045] Example 1

[0046] Figure 1 The flowchart of a service invocation method provided in Embodiment 1 of the present invention is applicable to the field of distributed services and also to the field of financial technology. The method is applicable to the situation of invoking distributed services across partitions. The method can be implemented by a service invocation device, which can be composed of software and / or hardware and configured in a computer or server, especially in the initiating node of the initiating partition, to complete the service invocation process.

[0047] like Figure 1 As shown, it includes:

[0048] Step 110: Obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs.

[0049] This invention specifically applies to cross-partition service call scenarios where data is not interconnected, and specifically to the implementation of this method by the initiating node that initiates the service call request. "Data not interconnected" specifically means that the services provided by nodes within a partition can only be called by other nodes within the same partition; nodes in other partitions cannot directly call the service (i.e., service calls are restricted to within the partition). The service call request is a business requirement instruction received by the initiating node, containing specific information about the service to be called (such as service type, parameters, and target service) and the identifier of the target service partition, used to specify the partition where the service is located. The initiating partition refers to the physical or logical partition where the node initiating this service call request (the initiating node) is located; the service partition is the partition where the service node providing the called service is located, and the service node is used to provide specific call services, such as forwarding and storage. The target service partition is the specific partition to which the service to be called in the current service call request belongs, i.e., the service to be called is actually provided by the service node within the target service partition.

[0050] Step 120: Generate a task identifier based on the service call request, generate a request packet based on the task identifier, send the request packet to the partition interface of the target service partition, determine the target service node corresponding to the request packet through the partition interface, send the request packet to the target service node, and generate a response packet corresponding to the request packet through the target service node.

[0051] The task identifier is a globally unique identifier generated by the initiating node based on the service call request. It remains unique throughout the entire call process, ensuring data association and consistency at each stage (such as request sending, service processing, and response return). The request packet is a standardized data packet (e.g., an HTTP protocol data packet) formed by the initiating node encapsulating the service call request and the task identifier. It carries complete request information during cross-partition transmission. The partition interface of the target service partition is the core component for its external communication. Its main function is to support cross-partition data interaction and ensure that the request packet is accurately transmitted from the initiating partition to the target service partition.

[0052] Specifically, the target service partition typically contains multiple service nodes providing the service to be invoked. The partition interface of the target service partition, based on the name of the service to be invoked in the request packet (e.g., "cross-border remittance service"), and in conjunction with a load balancing strategy, selects the target service node from among the multiple service nodes to actually execute the call, and finally forwards the request packet to the target service node. The service response is the result data generated by the target service node after completing the service processing, containing key information such as the service execution status (e.g., success / failure) and business return values ​​(e.g., transaction voucher number and account balance change information). The response packet is a standardized data packet formed by the target service node encapsulating the service response and task identifier. By binding the service response with the task identifier, it ensures that the initiating node can quickly match the corresponding call flow through the task identifier during the return transmission. Finally, the response packet is forwarded through the partition interface and eventually reaches the initiating node, completing the entire service call loop.

[0053] Optionally, the service call request may also include a timestamp and a business sequence number;

[0054] The step of generating a task identifier based on the service call request includes:

[0055] A random identifier is generated, and the partition identifiers of the initiating partition and the target service partition are determined according to the service call request. A first call identifier and a second call identifier are obtained, wherein the first call identifier represents the call task, and the second call identifier represents the call service that makes up the call task. A first task identifier is generated based on the partition identifier of the initiating partition, the random identifier, the timestamp, the service sequence number, and the first call identifier. A second task identifier is generated based on the partition identifier of the target service partition, the random identifier, the timestamp, the service sequence number, and the second call identifier. The first task identifier and the second task identifier constitute the task identifier.

[0056] The partition identifier is a unique identifier for a partition, such as a partition code or region code. It serves as a key field in task identifier generation, ensuring that the task identifier can be associated with the specific call source (initiating partition) and execution target (target service partition). The random identifier code is a random number or random string generated by the initiating node. It increases the randomness and uniqueness of the task identifier, avoiding task identifier conflicts caused by duplicate fixed fields (such as timestamps and partition identifiers), and improving the accuracy of task tracking in cross-partition calls. For a call task, an initiating node is required, and multiple services to be called must be invoked. The first call identifier and the second call identifier represent the overall call task and the call service of the call task, respectively. For example, if the call task forwards multiple data through a service node, the first call identifier is used to identify the call task, and the second call identifier is used to identify the call service that forwards any data within the call task.

[0057] The first task identifier is used as the overall identifier of the calling task, and the second task identifier is the identifier of the calling service of the calling task. Furthermore, for each calling service of the calling task, the first task identifier and the second task identifier corresponding to the calling service can be encapsulated in a data packet to distinguish the calling service corresponding to the data packet.

[0058] Specifically, identifier templates for a first task identifier and a second task identifier can be preset. Then, based on the identifier template of the first task identifier, a first task identifier is generated according to the partition identifier of the initiating partition, a random identifier code, a timestamp, a business sequence number, and a first call identifier. Similarly, based on the identifier template of the second task identifier, a second task identifier is generated according to the partition identifier of the initiating partition, the partition identifier of the target service partition, a random identifier code, a timestamp, a business sequence number, and a second call identifier. By utilizing the multi-dimensional characteristics of the service call request, task identifiers can be generated, ensuring a one-to-one correspondence between task identifiers and service call requests, thereby guaranteeing the uniqueness of task identifiers and improving data consistency.

[0059] For example, partition identifiers: partition 1, partition 2, partition 3 are R1, R2, R3 respectively, and so on;

[0060] Node ID: Since the initiating node does not specify the exact node ID of the target service node, the identifier of the target service node can be randomly generated by the initiating node or generated in a fixed order (such as N1, N2, N3, etc. within partition R1).

[0061] The first and second call identifiers are labeled M - main transaction and S - sub-transaction, respectively.

[0062] The timestamp can be the system's year, month, day, hour, and minute;

[0063] Used to identify the execution node of the service to be invoked this time;

[0064] Master-sub-transaction identifier: M - master transaction, S - sub-transaction;

[0065] Year, month, day, hour, and minute: Retrieves the system's year, month, day, hour, and minute;

[0066] Business sequence number: generated by the sequence number generator of the initiating node (which can be implemented based on a database field), with a value of 0000000001 to 9999999999 (the number of digits can be adjusted according to the actual business).

[0067] For example, the first task identifier "R1N1M2024121508120000000001" is formed by concatenating the initiating partition identifier (R1), the initiating node number (N1), the first call identifier (M), the timestamp (202412150812), and the business sequence number (0000000001) to form a globally unique call task identifier. The second task identifier "R2N1S2024121508120000000001" is formed by concatenating the target service partition identifier (R2), the target service node number (N1), the second call identifier (S), the timestamp (202412150812), and the business sequence number (0000000001).

[0068] Step 130: Receive the response packet sent by the partition interface.

[0069] Specifically, the service call process can be completed by parsing the received response packet.

[0070] This invention provides a service invocation method, comprising: obtaining a service invocation request, wherein the service invocation request includes a service to be invoked and a target service partition to which the service to be invoked belongs; generating a task identifier based on the service invocation request, generating a request packet based on the task identifier, sending the request packet to a partition interface of the target service partition to determine a target service node corresponding to the request packet through the partition interface, sending the request packet to the target service node, generating a response packet corresponding to the request packet through the target service node; and receiving the response packet sent by the partition interface. Specifically, in this invention, by generating a globally unique task identifier based on the service invocation request and maintaining the consistency of the task identifier throughout the entire service invocation process, data synchronization and state alignment at each stage of the service invocation process are achieved, ultimately ensuring the security and data consistency of business operations.

[0071] Example 2

[0072] Figure 2 The flowchart of a service invocation method is provided for Embodiment 2 of the present invention. Based on the above embodiment, the method further defines the method of generating a request packet according to the task identifier and sending the request packet to the partition interface of the target service partition.

[0073] like Figure 2 As shown, it includes:

[0074] Step 210: Obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs.

[0075] Step 220: Generate a task identifier based on the service call request.

[0076] Step 230: Determine the network address of the partition interface of the target service partition according to the preset network routing table.

[0077] The network routing table is a pre-configured routing rule table for the initiating node, which records the mapping relationship between the partition interfaces of different service partitions and the corresponding network addresses (such as IP, domain name and port).

[0078] Step 240: Generate a request header based on the network address and task identifier, and generate a request body based on the service content of the service to be invoked.

[0079] Specifically, the task identifier can be encapsulated in the request header, and the task identifier should remain unchanged during the task invocation process to ensure data consistency at each stage of the invocation process.

[0080] For example, the content of the request packet header is as follows:

[0081] The request header uses the standard HTTP protocol format and carries core metadata and transaction tracing information for cross-partition service calls. The first line contains the request method and path (POST / api / v1 / *****).

[0082] HTTP / 1.1 explicitly defines the operation type as resource creation; the Host field (api.*****.com) specifies the gateway address of the target service partition, enabling cross-partition routing. Key transaction tracing fields include: a first task identifier (e.g., R1N1M2024121508120000000001) serving as a globally unique transaction ID across partitions, used to coordinate the entire lifecycle management of distributed transactions; and a second task identifier (e.g., R2N1S2024121508120000000001) identifying the sub-transaction sequence number, supporting phase splitting and state rollback of long transactions. Furthermore, the packet header reserves space for "other transaction field information," which can be expanded with business-related attributes such as timeout periods and retry policies, enhancing the protocol's flexibility.

[0083] For example, the content of the requested package body is shown below:

[0084] The request packet is organized in JSON format and adopts a layered design of "core business area + dynamic extension area" to meet the business data transmission requirements of cross-partition service calls. The core business area (BUSI_AREA) contains core transaction attributes such as TRXAMT (transaction amount, accurate to cents), CURRTYPE (transaction currency, such as CNY), TRXSQM (main transaction serial number, globally unique), and TRXSQS (sub-transaction serial number, shard identifier), ensuring consistency in cross-partition data parsing; business parameters such as ACTBRNO (accounting outlet number) and CHNLNO (channel number) further supplement the transaction context. The extension area (FIELD_1, FIELD_2, etc.) supports adding dynamic business parameters (such as channel identifier, risk control identifier) ​​as needed, and adapts to the parameter extension needs of different business scenarios through a dynamic validation mechanism, balancing standardization and flexibility.

[0085] Step 250: Generate a request packet based on the request packet header and request packet body, send the request packet to the partition interface of the target service partition, determine the target service node corresponding to the request packet through the partition interface, send the request packet to the target service node, and generate a response packet corresponding to the request packet through the target service node.

[0086] Specifically, by encapsulating the task identifier in the request packet, the task identifier is guaranteed to remain unchanged during task invocation, thereby improving data consistency.

[0087] Optionally, the partition interface that sends the request packet to the target service partition includes:

[0088] Specifically, there is a preset calling order among the services to be called; the sending time of the request packet of each service to be called is determined according to the calling order.

[0089] Specifically, due to business needs, there is a preset calling order among the services to be called. Therefore, it is necessary to send the request packets of each service to be called in parallel or serially according to the calling order, so as to ensure that the calling task proceeds normally.

[0090] Step 260: Receive the response packet sent by the partition interface.

[0091] This invention provides a service invocation method. By using a pre-configured routing rule table, the network address of the partition interface of the target service partition can be accurately determined, improving the efficiency and accuracy of service invocation. At the same time, by encapsulating the task identifier in the request packet, the consistency of the task identifier can be maintained throughout the entire service invocation process, thereby achieving data synchronization and state alignment at each stage of the service invocation process, and ultimately ensuring the security and data consistency of business operations.

[0092] Example 3

[0093] Figure 3 The flowchart of a service response method provided in Embodiment 3 of the present invention is applicable to the field of distributed services and also to the field of financial technology. The method is applicable to the situation of responding to distributed services across partitions. The method can be implemented by a service invocation device, which can be composed of software and / or hardware and configured in a computer or server, especially in the target service node of the service partition, to complete the service response process.

[0094] like Figure 3 As shown, it includes:

[0095] Step 310: Receive the request packet sent by the partition interface, wherein the request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node.

[0096] Specifically, the request packet includes a service identifier for the service invocation request. This service identifier is a unique identifier for the service to be invoked. Since the target service partition can execute multiple services to be invoked, and different services require different service nodes, the partition interface of the target service partition needs to determine candidate service nodes based on the service identifiers of the services to be invoked. These candidate service nodes are the nodes that provide the services to be invoked. The target service node for executing this service invocation needs to be determined from the candidate service nodes according to a load balancing strategy.

[0097] Specifically, the partitioning interface can improve the efficiency of service calls by determining the relatively optimal target service node.

[0098] Optionally, the current load status of each candidate service node is obtained, and the target service node is determined based on the current load status; the request packet is sent to the target service node based on the network address of the target service node.

[0099] The current load status can be an indicator of the candidate service node's current operating status, used to assess its ability to handle new requests. This can include: CPU utilization, memory usage, disk I / O, network bandwidth, and the length of the task queue being processed.

[0100] Furthermore, to improve the processing efficiency of service calls, the candidate service node with the most optimal current load can be selected as the target service node. Then, based on the target service node's network address, the request packet is forwarded to the target service node. It should be noted that the partition interface includes the service content of the service to be called for all service nodes within the service partition, as well as the network addresses of each service node.

[0101] Step 320: Generate a service response based on the request packet, and generate a response packet based on the service response and the task identifier.

[0102] Specifically, a service response is generated based on the service content of the request packet; a response header is generated based on the task identifier; a response body is generated based on the service response; and a response packet is generated based on the response header and response body.

[0103] Specifically, the target service node will re-encapsulate the task identifier in the request packet into the response packet header, thereby ensuring the continuity of the task identifier during the task call response phase and thus ensuring data consistency.

[0104] Step 330: Send the response packet to the initiating node through the partition interface.

[0105] Specifically, the target service node sends the encapsulated response packet to the partition interface, and the partition interface sends the response packet to the initiating node through the source address of the initiating node encapsulated in the response packet, thus completing the service call.

[0106] This invention provides a service response method. Specifically, by encapsulating a task identifier in both the request and response packets, the method ensures data independence and consistency at each stage of cross-region service calls, thereby guaranteeing reliable data retrieval. Furthermore, by utilizing the load balancing mechanism of the partitioned interface, the most suitable target service node for completing the currently invoked service can be determined, improving service call efficiency.

[0107] Example 4

[0108] Figure 4 This is a schematic diagram of the structure of a service invocation system provided in Embodiment 4 of the present invention. Figure 4 As shown, the system includes: an initiating partition, and at least one service partition that does not communicate with the initiating partition. The initiating partition includes an initiating node, and the service partition includes a service node and a partition interface.

[0109] The initiating node is used to obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0110] The initiating node is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, and send the request packet to the partition interface of the target service partition.

[0111] The partition interface of the target service partition is used to determine the target service node based on the request packet and send the request packet to the target service node;

[0112] The target service node is used to generate a service response based on the request packet, generate a response packet based on the service response and the task identifier, and send the response packet to the partition interface;

[0113] The partition interface is used to send the response packet to the initiating node.

[0114] Initiating partition 410, and at least one service partition that is not interconnected with the initiating partition, wherein the initiating partition includes initiating node 430, and the service partition includes service node 440 and partition interface 450.

[0115] The initiating node 430 is used to obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0116] The initiating node 430 is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, and send the request packet to the partition interface of the target service partition.

[0117] The partition interface 450 of the target service partition is used to determine the target service node based on the request packet and send the request packet to the target service node;

[0118] The target service node 440 is used to generate a service response based on the request packet, generate a response packet based on the service response and the task identifier, and send the response packet to the partition interface.

[0119] The partition interface 450 is used to send the response packet to the initiating node.

[0120] Optionally, the initiating node 430 is specifically used for:

[0121] The initiating node generates a random identifier code;

[0122] The initiating node determines the partition identifiers of the initiating partition and the target service partition, respectively;

[0123] The initiating node obtains a first call identifier and a second call identifier, wherein the first call identifier represents the call task and the second call identifier represents the call service that makes up the call task;

[0124] A first task identifier is generated based on the partition identifier, random identifier code, timestamp, service sequence number, and first call identifier of the initiating partition;

[0125] A second task identifier is generated based on the partition identifier, random identifier code, timestamp, service sequence number, and second call identifier of the target service partition.

[0126] The first task identifier and the second task identifier constitute the task identifier.

[0127] Optionally, the initiating node 430 is specifically used for:

[0128] The network address of the partition interface of the target service partition is determined according to the preset network routing table;

[0129] A request header is generated based on the network address and task identifier, and a request body is generated based on the service content of the service to be invoked.

[0130] A request packet is generated based on the request packet header and request packet body, and the request packet is sent to the partition interface of the target service partition.

[0131] Optionally, partition interface 450 is specifically used for:

[0132] The partition interface of the target service partition parses the request packet to determine the service identifier of the service to be invoked;

[0133] Based on the service identifier of the service to be invoked, each candidate service node is determined, wherein the candidate service node is the node that provides the service to be invoked;

[0134] The target service node is determined from the candidate service nodes, and the request packet is sent to the target service node.

[0135] Optionally, partition interface 450 is specifically used for:

[0136] Obtain the current load status of each candidate service node, and determine the target service node based on the current load status;

[0137] The request packet is sent to the target service node based on the network address of the target service node.

[0138] Optionally, target service node 440 is specifically used for:

[0139] The target service node generates a service response based on the service content of the request packet;

[0140] Generate a response header based on the task identifier, and generate a response body based on the service response.

[0141] A response packet is generated based on the response packet header and response packet body.

[0142] Optionally, the initiating node 430 is specifically used for:

[0143] Based on the calling order, determine the sending time of the request packet for each service to be called.

[0144] For example, Figure 5This is a schematic diagram of a service invocation system provided in an embodiment of the present invention. Specifically, the main transaction node (initiating node) of a partition may work together with several other partition sub-transaction nodes (service nodes) to complete a three-phase distributed transaction TCC mode processing.

[0145] Regarding the invocation of task S1: Node C, as the initiator of the distributed transaction (initiating node), first generates the main transaction ID (first task identifier) ​​through its transaction framework runtime component.

[0146] The subtask IDs (secondary task identifiers) of nodes D, E, and F are defined as “R1N1M2024121508120000000001” and “R2N1S2024121508120000000002”.

[0147] "R3N2S2024121508120000000003" and "R4N3S2024121508120000000004". After encapsulating the task identifier and call parameters into a request packet via the HTTP protocol, node C sends the request packet to the interfaces of partitions 2, 3, and 4 respectively, according to the partition to which the target node belongs. The request packet is then forwarded to the corresponding service nodes (nodes D, E, and F) through the partition interfaces. After receiving the HTTP data packet, the transaction framework runtime component of each target node parses the transaction identifier in the packet header, extracts information such as partition ownership and task level to bind the local transaction context, completes the participant role processing, and finally returns a service response containing the execution result, forming a cross-partition call closed loop.

[0148] Regarding the invocation of task S2: Node F, as the initiator of the distributed transaction (initiating node), first generates the main transaction ID (first task identifier) ​​through its transaction framework runtime component.

[0149] The task IDs "R4N1M2024121508120000000001" and the subtask IDs (second task identifiers) "R1N1S2024121508120000000002" and "R3N2S2024121508120000000003" of nodes A and E are used. After encapsulating the task identifiers and call parameters into a request packet via the HTTP protocol, node F sends the request packet to the interfaces of partitions 1 and 3 according to the partition to which the target node belongs. The request packet is then forwarded to the corresponding service nodes (nodes A and E) through the partition interfaces. After receiving the HTTP data packet, the transaction framework running component of each target node parses the transaction identifier in the packet header, extracts information such as partition ownership and task level to bind the local transaction context, completes the participant role processing, and finally returns a service response containing the execution result, forming a cross-partition call closed loop.

[0150] Regarding the task S3 invocation: Node D, as a distributed transaction participant (the initiating node, located in partition 2), first generates the relevant identifiers for the invocation task based on its own partition identifier (R2N1), thus generating the primary task identifier (secondary task identifier) ​​for this invocation.

[0151] The system uses the identifier "R2N1M2024121508120000000002" and generates a subtask identifier "R3N2S2024121508120000000003" for the target node E (located in partition 3). After encapsulating the task identifier and call parameters into a request packet via HTTP, node D sends the request packet to the partition interface of partition 3, where target node E belongs. The packet is then forwarded to service node E via the partition interface. Node E's transaction framework runtime component receives the HTTP data packet, parses the transaction identifier in the header, extracts information such as partition affiliation (partition 3) and task level (subtask) to bind to the local transaction context, completes participant role processing, and finally returns a service response containing the execution result, completing the cross-partition call process from node D to node E.

[0152] This invention provides a service invocation system. The system generates a globally unique identifier by integrating multi-dimensional information such as the initiating partition, the target service partition, the timestamp, and the business sequence number through a task identifier. This identifier runs through the entire cross-partition invocation process, enabling each node in the initiating partition and the target service partition to be associated with the invocation process through the same identifier. This effectively avoids cross-partition data confusion and ensures data consistency and traceability throughout the entire service invocation process.

[0153] Furthermore, embodiments of the present invention may include the following technical effects:

[0154] 1. Transaction consistency guarantee

[0155] By generating a unique global task identifier across partitions, all participating services and data operations in both the initiating and target service partitions can be unified under the same transaction, ensuring the atomicity of the transaction. Regardless of how many partitions the call crosses, this task identifier remains constant throughout the entire service call process (such as the request initiation in the initiating partition and the service execution in the target service partition), making the operations in each partition appear as an indivisible whole. Simultaneously, transmitting the task identifier and context information (such as timestamps and business sequence numbers) via HTTP protocol messages ensures accurate transmission and identification of the Try, Confirm, and Cancel phases of the transaction across different partitions, avoiding cross-partition data confusion and ultimately guaranteeing the consistency of the global transaction state.

[0156] 2. Scalability and flexibility

[0157] A globally unique task identifier can be used uniformly across the initiating partition and multiple target service partitions, supporting cross-partition management and coordination of large-scale distributed transactions and significantly improving the system's horizontal scalability. Combined with the HTTP protocol as a universal carrier for cross-partition communication (supporting mutual access between service nodes in multiple partitions), task identifiers and context information can be efficiently transmitted to service nodes in different partitions (such as the initiating node of the Asia-Pacific partition and the partition interface of the Europe and America partition), without relying on specific partition's private protocols or interfaces. This enhances the system's compatibility with multiple partitions and various service types, making the architecture more flexible and easier to integrate.

[0158] 3. Fault recovery and fault tolerance

[0159] Global task identifiers can associate transaction status information (such as execution progress and success / failure status) with business data of each partition (such as request parameters of the initiating partition and response results of the target service partition) and persist them to centralized storage (such as a database or cache). Even if some service nodes or partitions are abnormal due to network failures, node downtime, or other reasons, the entire transaction status can still be quickly traced through task identifiers (such as locating which partition's service is not responding), supporting operations such as reconciliation and compensation. In addition, based on task identifiers and context information (such as timestamps and business sequence numbers), fault tolerance mechanisms such as timeout retries (such as automatically resending requests when the target service node does not respond), automatic compensation (such as reversing when deductions are successful but crediting fails) or manual intervention can be designed to comprehensively improve the system's fault tolerance and operational stability.

[0160] Example 5

[0161] Figure 6 A schematic diagram of the structure of the service invocation device provided in the embodiments of the present invention includes:

[0162] The request acquisition module 510 is used to acquire a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs;

[0163] The identifier generation module 520 is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, send the request packet to the partition interface of the target service partition, determine the target service node corresponding to the request packet through the partition interface, send the request packet to the target service node, and generate a response packet corresponding to the request packet through the target service node.

[0164] The receiving module 530 is used to receive the response packet sent by the partition interface.

[0165] This invention provides a service invocation apparatus. The apparatus proceeds by: acquiring a service invocation request, wherein the service invocation request includes a service to be invoked and a target service partition to which the service to be invoked belongs; generating a task identifier based on the service invocation request; generating a request packet based on the task identifier; sending the request packet to a partition interface of the target service partition to determine the target service node corresponding to the request packet through the partition interface; sending the request packet to the target service node; generating a response packet corresponding to the request packet through the target service node; and receiving the response packet sent by the partition interface. Specifically, in this invention, by generating a globally unique task identifier based on the service invocation request and maintaining the consistency of the task identifier throughout the entire service invocation process, data synchronization and state alignment at each stage of the service invocation process are achieved, ultimately ensuring the security and data consistency of business operations.

[0166] Optionally, the identifier generation module 520 includes:

[0167] The random code generation and partition identifier determination unit is used to generate random identifier codes and determine the partition identifiers of the initiating partition and the target service partition according to the service call request.

[0168] The acquisition unit is used to acquire a first call identifier and a second call identifier, wherein the first call identifier represents a call task and the second call identifier represents a call service that constitutes the call task;

[0169] The first generation unit is used to generate a first task identifier based on the partition identifier, random identifier code, timestamp, service sequence number and first call identifier of the initiating partition;

[0170] The second generation unit is used to generate a second task identifier based on the partition identifier, random identifier code, timestamp, service sequence number and second call identifier of the target service partition;

[0171] The third generation unit is used to form a task identifier from the first task identifier and the second task identifier.

[0172] Optionally, the identifier generation module 520 includes:

[0173] The address determination unit is used to determine the network address of the partition interface of the target service partition according to a preset network routing table.

[0174] The generation unit is used to generate a request header based on the network address and task identifier, and to generate a request body based on the service content of the service to be invoked.

[0175] The sending unit is used to generate a request packet based on the request packet header and request packet body, and send the request packet to the partition interface of the target service partition.

[0176] The service invocation apparatus provided in this embodiment of the invention can execute the service invocation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0177] Example 6

[0178] Figure 7 This is a schematic diagram of a service response device according to Embodiment Six of the present invention, comprising:

[0179] The receiving module 610 is used to receive a request packet sent by the partition interface, wherein the request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node.

[0180] The generation module 620 is used to generate a service response based on the request packet, and to generate a response packet based on the service response and the task identifier;

[0181] The sending module 630 is used to send the response packet to the initiating node through the partition interface.

[0182] The generation module 620 is specifically used to generate a service response based on the service content of the request packet;

[0183] Generate a response header based on the task identifier, and generate a response body based on the service response.

[0184] A response packet is generated based on the response packet header and response packet body.

[0185] This invention provides a service response device. Specifically, by encapsulating a task identifier in the request and response packets, it ensures data independence and consistency at each stage of cross-region service calls, guaranteeing reliable data access. Furthermore, through the load balancing mechanism of the partitioned interface, the most suitable target service node for completing the currently invoked service can be determined, improving service call efficiency.

[0186] Example 7

[0187] Figure 8A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0188] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory 12 or a random access memory 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from storage unit 18 into the random access memory 13. The random access memory 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, read-only memory 12, and random access memory 13 are interconnected via a bus 14. An input / output interface 15 is also connected to the bus 14.

[0189] Multiple components in electronic device 10 are connected to input / output interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0190] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 11 executes the various methods and processes described above, such as the service invocation method or service response method described in any of the embodiments of the present invention.

[0191] In some embodiments, the recommended banking service method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the service invocation method or service response method described in any of the embodiments of the present invention above may be performed. Alternatively, in other embodiments, processor 11 may be configured by any other suitable means (e.g., by means of firmware) to perform the service invocation method or service response method described in any of the embodiments of the present invention.

[0192] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), systems-on-a-chip (SoCs), complex programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0193] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0194] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EP memory or flash memory), optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0195] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube or liquid crystal display, a monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0196] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0197] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system. This addresses the shortcomings of traditional physical hosts and cloud host services, such as high management difficulty and weak business scalability.

[0198] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0199] This disclosure also provides a computer program product, including a computer program and / or indicating that, when executed by a processor, the computer program implements the recommended methods for banking operations as provided in any embodiment of this application. In implementing the computer program product, computer program code for performing the operations of the embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN).

[0200] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service invocation method, characterized in that, include: Obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs; Based on the service call request, a task identifier is generated, a request packet is generated based on the task identifier, and the request packet is sent to the partition interface of the target service partition. The partition interface is used to determine the target service node corresponding to the request packet, and the request packet is sent to the target service node. The target service node generates a response packet corresponding to the request packet. Receive the response packet sent by the partition interface.

2. The method according to claim 1, characterized in that, The service call request also includes a timestamp and a service sequence number; The step of generating a task identifier based on the service call request includes: Generate a random identifier code, and determine the partition identifier of the initiating partition and the target service partition respectively according to the service call request; Obtain a first call identifier and a second call identifier, wherein the first call identifier represents a call task and the second call identifier represents a call service that constitutes the call task; A first task identifier is generated based on the partition identifier, random identifier code, timestamp, service sequence number, and first call identifier of the initiating partition; A second task identifier is generated based on the partition identifier, random identifier code, timestamp, service sequence number, and second call identifier of the target service partition; The first task identifier and the second task identifier constitute the task identifier.

3. The method according to claim 1, characterized in that, The step of generating a request packet based on the task identifier and sending the request packet to the partition interface of the target service partition includes: The network address of the partition interface of the target service partition is determined according to the preset network routing table; A request header is generated based on the network address and task identifier, and a request body is generated based on the service content of the service to be invoked. A request packet is generated based on the request packet header and request packet body, and the request packet is sent to the partition interface of the target service partition.

4. The method according to claim 1, characterized in that, There is a preset calling order among the services to be called; The partition interface that sends the request packet to the target service partition includes: Based on the calling order, determine the sending time of the request packet for each service to be called.

5. A service response method, characterized in that, include: The partition interface receives a request packet sent by the partition interface. The request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node. A service response is generated based on the request packet, and a response packet is generated based on the service response and the task identifier. The response packet is sent to the initiating node through the partition interface.

6. The method according to claim 5, characterized in that, The step of generating a service response based on the request packet, and generating a response packet based on the service response and the task identifier, includes: Generate a service response based on the service content of the request packet; Generate a response header based on the task identifier, and generate a response body based on the service response. A response packet is generated based on the response packet header and response packet body.

7. A service invocation system, characterized in that, It includes an initiating partition and at least one service partition that does not communicate with the initiating partition. The initiating partition includes an initiating node, and the service partition includes a service node and a partition interface. The initiating node is used to obtain a service invocation request, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs; The initiating node is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, and send the request packet to the partition interface of the target service partition. The partition interface of the target service partition is used to determine the target service node based on the request packet and send the request packet to the target service node; The target service node is used to generate a service response based on the request packet, generate a response packet based on the service response and the task identifier, and send the response packet to the partition interface; The partition interface is used to send the response packet to the initiating node.

8. A service invocation device, characterized in that, include: The request acquisition module is used to acquire service invocation requests, wherein the service invocation request includes the service to be invoked and the target service partition to which the service to be invoked belongs; The identifier generation module is used to generate a task identifier based on the service call request, generate a request packet based on the task identifier, send the request packet to the partition interface of the target service partition, determine the target service node corresponding to the request packet through the partition interface, send the request packet to the target service node, and generate a response packet corresponding to the request packet through the target service node. A receiving module is used to receive the response packet sent by the partition interface.

9. A service response device, characterized in that, include: The receiving module is used to receive request packets sent by the partition interface, wherein the request packet is generated by the initiating node based on the service call request and the partition interface is used to determine the target service node based on the request packet and send the request packet to the target service node. The generation module is used to generate a service response based on the request packet, and to generate a response packet based on the service response and the task identifier; The sending module is used to send the response packet to the initiating node through the partition interface.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the service invocation method or service response method according to any one of claims 1-4 or 5-6.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the service invocation method or service response method according to any one of claims 1-4 or 5-6.

Images