Micro-service cross-region calling method and device, electronic equipment and program product

Abstract

This invention discloses a method, apparatus, electronic device, and program product for cross-region microservice invocation, relating to the field of distributed technology. The method includes: initiating a mapping relationship retrieval request to a dynamic configuration center; obtaining a first mapping set and a second mapping set from the dynamic configuration center; querying the first mapping set to obtain the target service deployment partition corresponding to the target distributed service; if the partition matches the partition to which the service consumer belongs, initiating a call request to the target distributed service through a remote procedure call strategy; if they do not match, querying the second mapping set to obtain the cross-region service gateway corresponding to the target distributed service, and initiating a call request to the cross-region service gateway. This invention solves the technical problem in related technologies where, in distributed microservice architectures with complex business call relationships, a single consumer may need to subscribe to multiple regional registry centers, leading to high memory resource consumption during cross-region service invocation.

Description

Technical Field

[0001] This invention relates to the field of distributed technology or other related fields, and more specifically, to a method and apparatus for cross-regional microservice invocation, an electronic device, and a program product. Background Technology

[0002] In distributed microservice architectures, as businesses expand globally, service clusters often need to be deployed across geographical regions to achieve goals such as providing services locally, reducing network latency, and enhancing disaster recovery capabilities. This cross-regional service deployment brings challenges to service discovery and load balancing, making the efficient and flexible management of service call paths between different regions a pressing issue.

[0003] In related technologies, the main technical solution for cross-regional service invocation is the multi-subscription registry center model for service consumers. In this model, the service consumer needs to subscribe to the registry centers of all potential service providers in their respective regions to obtain service provider information. However, this solution has significant limitations: First, it incurs high network overhead. In cases of complex business invocation relationships, a single consumer may need to subscribe to registry centers in multiple regions. This not only increases the network burden on the registry center to push service provider information across regions but may also cause consumer nodes to consume excessive memory resources due to receiving a large number of service lists. Second, it lacks flexibility: when the deployment location of a service provider changes, the consumer needs to manually update the registry center's subscription settings, increasing maintenance costs.

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

[0005] This invention provides a method, apparatus, electronic device, and program product for cross-region microservice invocation, to at least solve the technical problem in related technologies where, when making cross-region service invocations in a distributed microservice architecture, a single consumer may need to subscribe to multiple regional registry centers, leading to high memory resource consumption, especially when business invocation relationships are complex.

[0006] To achieve the above objectives, according to one aspect of this application, a method for cross-region microservice invocation is provided, applied to a service consumer in a distributed system, comprising: initiating a mapping relationship acquisition request to a dynamic configuration center, acquiring a first mapping set and a second mapping set from the dynamic configuration center, wherein the first mapping set includes mapping relationships between distributed services and service deployment partitions, and the second mapping set includes mapping relationships between cross-region service gateways and service deployment partitions; querying the first mapping set to obtain a target service deployment partition corresponding to a target distributed service; if the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, initiating an invocation request to the target distributed service through a remote procedure call strategy; if the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, querying the second mapping set to obtain a cross-region service gateway corresponding to the target distributed service, initiating an invocation request to the cross-region service gateway to the target distributed service, and invoking the target distributed service through the cross-region service gateway.

[0007] Optionally, before initiating a mapping relationship retrieval request to the dynamic configuration center, the method further includes: establishing a dynamic configuration center that associates all service deployment partitions; for each service deployment partition, pushing the partition identifier of the service deployment partition and the service information of the distributed services registered in the service deployment partition to the dynamic configuration center through the registration center in the service deployment partition; the dynamic configuration center generating the first mapping set based on the partition identifier of each service deployment partition and the service information of each distributed service; pushing the partition identifier and domain name information of the service deployment partition to the dynamic configuration center through the cross-regional service gateway in the service deployment partition; and the dynamic configuration center generating the second mapping set based on the partition identifier and domain name information of each service deployment partition.

[0008] Optionally, after establishing a dynamic configuration center that associates all service deployment partitions, the microservice cross-region invocation method further includes: obtaining the registry center link information of the service provider in each service deployment partition; and controlling the service consumer to maintain a long connection with the registry center of the service provider in each service deployment partition based on the registry center link information.

[0009] Optionally, after initiating a call request to the target distributed service to the cross-regional service gateway, the microservice cross-regional call method further includes: upon receiving an abnormal service call, determining that the target distributed service has encountered an anomaly, wherein the abnormal service call includes at least: an update to the service deployment partition to which the target distributed service belongs; generating a forced cache refresh instruction, resubscribing to the mapping relationship from the dynamic configuration center, and obtaining the latest first mapping set and second mapping set; and initiating a call request to the target distributed service based on the latest first mapping set and second mapping set.

[0010] Optionally, the microservice cross-region invocation method further includes: the dynamic configuration center generating snapshot files for the first mapping set and the second mapping set; the dynamic configuration center outputting the snapshot files to the target disk at predetermined intervals; in the event of a failure detected in the dynamic configuration center, restarting the dynamic configuration center, reading the latest snapshot file from the target disk, subscribing to the partition identifier and the service information of the latest distributed services registered in the service deployment partition from the registry center in each service deployment partition, and obtaining the updated first mapping set.

[0011] Optionally, the dynamic configuration center is deployed in a cluster. The microservice cross-region invocation method further includes: if a failure is detected in the dynamic configuration center of any server in the target cluster, stop the operation of that server and switch to another healthy server to host the dynamic configuration center, and the healthy server provides services to each service consumer.

[0012] Optionally, the microservice cross-region invocation method further includes: pre-configuring a first cross-region service gateway and a second cross-region service gateway in the service deployment partition, and using the first cross-region service gateway as the primary gateway and the second cross-region service gateway as the backup gateway; in the event that the primary gateway in the service deployment partition fails, routing the invocation request initiated by the service consumer to the backup gateway, and invoking the target distributed service through the backup gateway.

[0013] According to another aspect of the present invention, a microservice cross-region invocation apparatus is also provided, applied to a service consumer in a distributed system, comprising: a mapping set acquisition unit, configured to initiate a mapping relationship acquisition request to a dynamic configuration center, and acquire a first mapping set and a second mapping set from the dynamic configuration center, wherein the first mapping set includes a mapping relationship between distributed services and service deployment partitions, and the second mapping set includes a mapping relationship between a cross-region service gateway and a service deployment partition; a query unit, configured to query the first mapping set to obtain a target service deployment partition corresponding to a target distributed service; a first invocation request initiation unit, configured to initiate an invocation request to the target distributed service through a remote procedure call strategy when the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs; and a second invocation request initiation unit, configured to query the second mapping set to obtain a cross-region service gateway corresponding to the target distributed service when the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, and initiate an invocation request to the cross-region service gateway to invoke the target distributed service through the cross-region service gateway.

[0014] Optionally, the microservice cross-region invocation device further includes: a configuration center building unit, used to build a dynamic configuration center associated with all service deployment partitions before initiating a mapping relationship retrieval request to the dynamic configuration center; a first push module, used to push the partition identifier of each service deployment partition and the service information of the distributed services registered in the service deployment partition to the dynamic configuration center through the registry center in the service deployment partition; a first mapping set generation module, used by the dynamic configuration center to generate the first mapping set based on the partition identifier of each service deployment partition and the service information of each distributed service; a second push module, used to push the partition identifier and domain name information of the service deployment partition to the dynamic configuration center through the cross-region service gateway in the service deployment partition; and a second mapping set generation module, used by the dynamic configuration center to generate the second mapping set based on the partition identifier and domain name information of each service deployment partition.

[0015] Optionally, the microservice cross-region invocation device further includes: a registry center link acquisition module, used to acquire registry center link information of the service provider in each service deployment partition; and a long connection establishment module, used to control the service consumer to maintain a long connection with the registry center of the service provider in each service deployment partition based on the registry center link information.

[0016] Optionally, the microservice cross-regional invocation device further includes: a service exception determination unit, configured to determine that the target distributed service is abnormal upon receiving an abnormal service invocation after initiating an invocation request to the cross-regional service gateway for the target distributed service, wherein the abnormal service invocation includes at least: an update to the service deployment partition to which the target distributed service belongs; a cache refresh unit, configured to generate a forced cache refresh instruction, resubscribe to the mapping relationship from the dynamic configuration center, and obtain the latest first mapping set and second mapping set; and an invocation request rewrite initiation unit, configured to initiate an invocation request to the target distributed service based on the latest first mapping set and second mapping set.

[0017] Optionally, the microservice cross-region invocation device further includes: a snapshot generation unit, used by the dynamic configuration center to generate a snapshot file from the first mapping set and the second mapping set; a file output unit, used by the dynamic configuration center to output the snapshot file to the target disk at a predetermined interval frequency; and a configuration center restart unit, used to restart the dynamic configuration center when a failure is detected, and read the latest snapshot file from the target disk, subscribe to the partition identifier and the service information of the latest distributed services registered in the service deployment partition from the registry center in each of the service deployment partitions, and obtain the updated first mapping set.

[0018] Optionally, the dynamic configuration center is deployed in a cluster. The microservice cross-regional invocation device further includes: a configuration center switching unit, which is used to stop the operation of any server in the target cluster when the dynamic configuration center of any server is detected to be faulty, and switch another healthy server to host the dynamic configuration center, so that the healthy server provides services to each service consumer.

[0019] Optionally, the microservice cross-region invocation device further includes: a gateway setting unit, configured to pre-configure a first cross-region service gateway and a second cross-region service gateway in the service deployment partition, and designate the first cross-region service gateway as the primary gateway and the second cross-region service gateway as a backup gateway; and a backup gateway activation unit, configured to route the invocation request initiated by the service consumer to the backup gateway when a failure is detected in the primary gateway in the service deployment partition, and invoke the target distributed service through the backup gateway.

[0020] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the microservice cross-regional invocation method described above.

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

[0022] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the microservice cross-regional invocation method described in any one of the above embodiments.

[0023] In this disclosure, a mapping relationship retrieval request is initiated to the dynamic configuration center to obtain a first mapping set and a second mapping set. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions. The first mapping set is queried to obtain the target service deployment partition corresponding to the target distributed service. If the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, a call request to the target distributed service is initiated through a remote procedure call strategy. If the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, the second mapping set is queried to obtain the cross-region service gateway corresponding to the target distributed service, and a call request to the cross-region service gateway is initiated to the cross-region service gateway to call the target distributed service.

[0024] Based on the above-mentioned publicly available information, the consumer server can query the partition where the service is located and the cross-region gateway to be called through the dynamic configuration center. This reduces the need for the service consumer to subscribe to multiple registry centers, reduces cross-region network traffic, reduces the pressure on the registry center to synchronize the service list, and avoids memory bloat caused by the need to store a large number of service provider lists on the service consumer. This reduces memory resource usage and optimizes resource utilization efficiency, thereby solving the technical problem in related technologies where, when making cross-region service calls in a distributed microservice architecture, a single consumer may need to subscribe to registry centers in multiple regions, leading to high memory resource consumption, especially when business call relationships are complex. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a microservice cross-region invocation method is shown.

[0027] Figure 2 This is a flowchart of an optional microservice cross-region invocation method according to an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of an optional microservice adaptive cross-region load balancing based on a dynamic configuration center and a partition service gateway according to an embodiment of the present invention.

[0029] Figure 4 This is a schematic diagram of an optional microservice cross-regional invocation device according to an embodiment of the present invention;

[0030] Figure 5 This is a structural block diagram of an electronic device that executes a microservice cross-regional invocation method according to an embodiment of this application. Detailed Implementation

[0031] 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.

[0032] 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.

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

[0034] Service Deployment Partition (Area) refers to different regions where microservices are deployed based on geographical location or logical requirements. This is used to achieve geographical dispersion and logical isolation of services, thereby improving service availability and response speed.

[0035] Remote Procedure Call (RPC) is a communication protocol that allows function calls to be executed between different computers. It is typically used in microservice architectures for inter-service communication to enable inter-process interaction in distributed systems.

[0036] Distributed microservices, or simply services, are small service modules that run independently in a distributed computing environment. Each service is built around a specific business function and can interact with other services through network interfaces to decompose and refactor complex business logic.

[0037] A service provider, or simply provider, is a node responsible for providing running instances of services. In a microservice architecture, it typically refers to a server or virtual machine that owns and publishes services, which can be invoked by service consumers.

[0038] Service consumers, or simply consumers, are clients or services that need to call services. They rely on the services provided by the service provider to perform business processing and are the request initiators in a microservice architecture.

[0039] In a microservice architecture, a Service Registry (or simply Registry) is a central directory service used to store and manage metadata for service instances. Service providers register their information with the registry when they start up, and service consumers discover services and make calls by querying the registry.

[0040] A Cross-Region Service Gateway (Gateway) serves as a unified entry point for service calls between different regions. It is responsible for forwarding cross-regional requests to the correct target service, simplifying the calling logic of service consumers, and achieving global load balancing for service calls.

[0041] Dynamic Configuration Center (DCC) is a centralized service used to store and distribute dynamic configuration information in a microservice architecture, including the mapping relationship between service deployment regions and service gateways. This enables service consumers to obtain service location information in real time and thus intelligently select the invocation method.

[0042] It should be noted that the microservice cross-region invocation method and apparatus in this disclosure can be used in the field of distributed technology to implement microservice adaptive cross-region load balancing based on dynamic configuration center and partition service gateway, and can also be used in any field other than distributed technology to implement microservice adaptive cross-region load balancing based on dynamic configuration center and partition service gateway. This disclosure does not limit the application field of the microservice cross-region invocation method and apparatus.

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

[0044] It should be noted that in this disclosure, customer information is collected and analyzed, and users are provided with corresponding operation entry points to choose whether to agree to or reject the automated decision results; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0045] The following embodiments of the present invention can be applied to various systems / applications / devices that enable cross-regional microservice calls. The present invention is applicable to distributed computing scenarios, particularly cross-regional deployments and global business scenarios oriented towards large-scale microservice architectures, in application environments that handle global user requests and achieve high availability and low-latency responses.

[0046] This invention significantly improves the efficiency and flexibility of cross-regional microservice calls by integrating a Dynamic Configuration Center (DCC) and a Regional Service Gateway. By reducing the number of subscriptions a service consumer needs to multiple registries, this invention reduces cross-regional network traffic and alleviates the pressure on the registry to synchronize service lists. It avoids memory bloat caused by the need for consumers to store large lists of service providers, optimizing resource utilization efficiency, especially in scenarios with large-scale services and intensive calls.

[0047] This invention enables automatic decoupling between consumers, service providers, and cross-regional registration centers. Even if the service location or gateway information changes, the service call path can be adaptively adjusted without manual intervention, thereby improving the robustness and responsiveness of the system.

[0048] By simplifying the service call logic, this invention makes it easier to add and manage new service partitions or gateways, and promotes the horizontal scaling and dynamic adjustment of the system during global deployment.

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

[0050] Example 1

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

[0052] The microservice cross-region invocation method embodiment provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a microservice cross-region invocation method is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU (Microcontroller Unit) or a programmable gate array (FPGA)) is shown as 102a, 102b, ..., 102n. It also includes a memory 104 for storing data and a transmission device 106 for communication functions. In addition, it may include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0053] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0054] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the microservice cross-region invocation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned microservice cross-region invocation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0055] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0056] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0057] To achieve the above objectives, according to one aspect of this application, a method for cross-regional microservice invocation is provided, which is applied to the service consumer end of a distributed system.

[0058] Under the aforementioned operating environment, this application provides the following: Figure 2 The microservice cross-region call method is shown. Figure 2This is a flowchart of an optional microservice cross-region invocation method according to an embodiment of the present invention, such as... Figure 2 As shown, the method includes the following steps S201 to S204. The present invention will be described in detail below with reference to each implementation step.

[0059] Optionally, before initiating a mapping relationship retrieval request to the dynamic configuration center, the process further includes: establishing a dynamic configuration center that associates all service deployment partitions; for each service deployment partition, pushing the partition identifier of the service deployment partition and the service information of the distributed services registered in the service deployment partition to the dynamic configuration center through the registry center in the service deployment partition; the dynamic configuration center generating a first mapping set based on the partition identifier of each service deployment partition and the service information of each distributed service; pushing the partition identifier and domain name information of the service deployment partition to the dynamic configuration center through the cross-regional service gateway in the service deployment partition; and the dynamic configuration center generating a second mapping set based on the partition identifier and domain name information of each service deployment partition.

[0060] To centrally manage the deployment information and invocation strategies of microservices globally, this embodiment may include establishing a Dynamic Configuration Center (DCC). This DCCC is associated with all service deployment partitions worldwide. Such centralized configuration management effectively avoids the waste of network resources when repeatedly subscribing to and pushing service information. For each service deployment partition, the local registry can proactively push the partition's unique identifier and detailed information about all registered distributed services within that partition to the DCCC, including but not limited to service names, versions, statuses, IP addresses, and port numbers. This helps maintain the real-time and accuracy of service information in the DCCC, thereby ensuring the efficiency of subsequent service invocations.

[0061] Based on the received partition identifier and service information, DCC generates a first mapping set, which can be defined as the {service-area} mapping set. This binds each service to its active deployment area, providing service consumers with an instant view of service location, enabling them to quickly locate the target service. Similarly, cross-region service gateways located in each service deployment partition can push partition identifiers and gateway domain name information to DCC, helping DCC to monitor traffic entry points in each partition in real time, which is crucial for automating cross-region service calls. Based on the received gateway domain name information and partition identifier, the Dynamic Configuration Center generates a second mapping set, which can be defined as the {gateway-area} mapping set. This set provides consumers with gateway address information for cross-region service calls, helping them quickly locate the correct cross-region service gateway and complete the service call when they need to call services in other partitions.

[0062] The Dynamic Configuration Center (DCC) acts as an intelligent hub, managing and controlling global microservice deployment information and service call paths, thereby greatly simplifying the configuration requirements and call logic for service consumers. It supports dynamic service migration and flexible gateway adjustments without the need for frequent updates and synchronization of consumer-side configurations, enhancing system adaptability and maintainability.

[0063] Step S201: Initiate a mapping relationship retrieval request to the dynamic configuration center, and obtain the first mapping set and the second mapping set from the dynamic configuration center. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions.

[0064] It should be noted that in this embodiment, the service consumer can proactively initiate a request to the dynamic configuration center to retrieve the first and second mapping sets stored therein. The first mapping set contains the correspondence between all distributed services and their respective service deployment partitions, helping the service consumer understand the current geographical or logical deployment location of each service. The second mapping set focuses on the association between cross-regional service gateways and service deployment partitions, providing links on how to access services in different regions, guiding the service consumer to make efficient calls through the nearest gateway.

[0065] Step S202: Query the first mapping set to obtain the target service deployment partition corresponding to the target distributed service.

[0066] When a service consumer plans to invoke a specific distributed service, the query operation can focus on resolving the current location information of the target service, i.e., the target service deployment partition. This helps in subsequent decisions about whether to directly invoke the service via local RPC or whether indirect access through a cross-region service gateway is necessary. By accurately matching services and partitions, the service consumer can ensure that it takes the most appropriate call path, thereby promoting smooth transactions and reducing latency. Dynamically obtaining service location and call gateway information helps simplify the complexity of cross-region service calls, while also improving system response speed and overall performance.

[0067] Step S203: If the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, initiate a call request to the target distributed service through the remote procedure call strategy.

[0068] In this embodiment, when the target distributed service and the service consumer are deployed within the same service deployment partition, the service consumer can choose to directly call the target service using an efficient Remote Procedure Call (RPC) strategy, instead of relaying it through a cross-regional service gateway. This direct calling method can significantly reduce network latency, help improve transaction processing speed and user experience, and alleviate the burden of cross-regional communication, ensuring high performance and low latency in service calls.

[0069] Step S204: If the target service deployment partition is inconsistent with the service deployment partition of the service consumer, query the second mapping set to obtain the cross-region service gateway corresponding to the target distributed service, initiate a call request to the cross-region service gateway to the target distributed service, and call the target distributed service through the cross-region service gateway.

[0070] In scenarios where the target service deployment partition differs from the service consumer's partition, the service consumer cannot directly call the target service via RPC. However, by querying the previously obtained second mapping set, the cross-region service gateway for the corresponding service deployment partition can be identified. The service consumer can then initiate a call request to this cross-region service gateway, leveraging its routing capabilities to indirectly access and invoke the target distributed service. This helps maintain the stability and security of service calls, ensuring effective management even in cross-region communication through appropriate gateways, avoiding the risks of network instability and increased latency that may result from direct cross-region RPC calls. It also helps optimize service call paths under various network conditions, improving overall system performance and reliability. Under consistent partition deployments, the service consumer can directly utilize the RPC mechanism for high-speed calls; in inconsistent deployments, a cross-region service gateway acts as a proxy, ensuring the continuity of service calls and the application of best practices.

[0071] Through the above steps, a mapping relationship retrieval request can be initiated to the dynamic configuration center to obtain a first mapping set and a second mapping set. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions. The first mapping set is queried to obtain the target service deployment partition corresponding to the target distributed service. If the target service deployment partition is consistent with the service deployment partition of the service consumer, a call request to the target distributed service is initiated through a remote procedure call strategy. If the target service deployment partition is inconsistent with the service deployment partition of the service consumer, the second mapping set is queried to obtain the cross-region service gateway corresponding to the target distributed service, and a call request to the cross-region service gateway is initiated to invoke the target distributed service. In this embodiment, the consumer server can query the partition where the service is located and the cross-region gateway to be called through the dynamic configuration center. This reduces the subscription of the service consumer to multiple registration centers, reduces cross-region network traffic, reduces the pressure on the registration center to synchronize the service list, and avoids memory bloat caused by the service consumer needing to store a large number of service provider lists. This reduces memory resource usage and optimizes resource utilization efficiency, thereby solving the technical problem in related technologies where, when making cross-region service calls in a distributed microservice architecture, a single consumer may need to subscribe to registration centers in multiple regions, leading to high memory resource consumption, especially when business call relationships are complex.

[0072] It should be noted that the construction of the dynamic configuration center in this embodiment is not limited to collecting and processing service and gateway information distributed in various service deployment partitions around the world, but can also be further expanded to help optimize the communication efficiency and stability between the service consumer end and the service provider end's registration center.

[0073] Optionally, after setting up a dynamic configuration center that associates all service deployment partitions, the microservice cross-region call method also includes: obtaining the registry center link information of the service provider in each service deployment partition; and controlling the service consumer to maintain a long connection with the registry center of the service provider in each service deployment partition based on the registry center link information.

[0074] After the dynamic configuration center is successfully established, this embodiment can involve obtaining the link information of the registry centers of service providers in all service deployment partitions, which helps service consumers accurately locate service providers in each region. Based on the collected registry center link information, this embodiment can control the service consumer to maintain a long-lived connection with the registry center in each service deployment partition. The use of long-lived connections can reduce the network overhead of frequent connection and disconnection operations, which helps improve call speed and system responsiveness. At the same time, this continuous connection state can capture the latest status of service providers in a timely manner, including information on added, modified, or offline services, thereby helping service consumers make more timely and effective call decisions. This not only enhances the scope of the dynamic configuration center but also introduces a long-lived connection mechanism, which can further optimize the communication efficiency between service consumers and registry centers in various regions, reduce unnecessary network latency, and support a smoother and more stable global microservice call environment.

[0075] In this embodiment, specific countermeasures are provided for abnormal service calls encountered after initiating a call to the target distributed service through the cross-regional service gateway. Optionally, after initiating a call request to the target distributed service through the cross-regional service gateway, the microservice cross-regional call method further includes: upon receiving an abnormal service call, determining that the target distributed service has encountered an abnormality, wherein the abnormal service call includes at least: an update to the service deployment partition to which the target distributed service belongs; generating a forced cache refresh instruction, resubscribing to the mapping relationship from the dynamic configuration center, and obtaining the latest first mapping set and second mapping set; and initiating a call request to the target distributed service based on the latest first mapping set and second mapping set.

[0076] It should be noted that abnormal service calls can cover a variety of situations, one of the key scenarios being: the service deployment partition to which the target distributed service belongs is updated, meaning the actual location of the service may have changed, but the information held by the service consumer has not been updated in sync, resulting in call failure or anomalies.

[0077] When an abnormal service call is detected (e.g., the state or location of the target distributed service has changed), a command to force-refresh the cache is generated to handle call anomalies caused by partition updates. This aims to clear outdated or incorrect mapping information and pave the way for subsequent resubscription. Based on the generated command, the service consumer can proactively retrieve the latest first and second mapping sets from the dynamic configuration center. After obtaining the latest mappings, the service consumer can re-initiate a call request to the target distributed service based on this information. At this point, because the information is up-to-date, the probability of encountering similar anomalies again is greatly reduced, which helps improve the call success rate and overall system robustness. It also helps the service consumer recover quickly when encountering abnormal service calls, maintaining the continuity and efficiency of service calls, and ensuring good adaptability even in changing network conditions or dynamic service deployment environments.

[0078] In this embodiment, the dynamic configuration center is not only responsible for real-time processing and updating of service information and gateway information from around the world, but also for snapshot file generation and fault recovery, thereby enhancing system stability and data security. Optionally, the microservice cross-region invocation method further includes: the dynamic configuration center generating snapshot files from the first mapping set and the second mapping set; the dynamic configuration center outputting the snapshot files to the target disk at predetermined intervals; and, in the event of a detected failure in the dynamic configuration center, restarting the dynamic configuration center, reading the latest snapshot file from the target disk, and subscribing to the partition identifier and the latest distributed service information registered in the service deployment partition from the registry center in each service deployment partition to obtain the updated first mapping set.

[0079] The Dynamic Configuration Center can periodically generate snapshot files from the currently stored first and second mapping sets. These snapshot files may contain the latest service deployment partition-to-service mappings up to the time of generation, as well as the mappings between partitions and cross-region service gateways. Regularly generating snapshot files helps preserve critical data state and provides a data source for potential anomaly recovery. At pre-defined intervals, the Dynamic Configuration Center can output these snapshot files to specified target disks. The selection of target disks considers data persistence and redundancy; they can be highly reliable storage spaces that help prevent data loss and ensure rapid recovery when necessary.

[0080] When a failure is detected in the Dynamic Configuration Center, such as a hardware failure, software crash, or other unforeseen interruption, the Dynamic Configuration Center can be restarted immediately. During the restart process, the system can read the latest snapshot file from the target disk and use it as a basis to restore critical mapping information. Next, subscribing to partition identifiers and the latest distributed service information from the registry centers in each service deployment partition helps the Dynamic Configuration Center rebuild the first mapping set, ensuring it contains the latest and most accurate service deployment information. This facilitates rapid response to system failures, reduces the impact on service calls, avoids data consistency issues, and improves the overall reliability and robustness of the system.

[0081] This embodiment not only realizes real-time management and updating of service information, but also introduces a mechanism for generating and using snapshot files, which helps to quickly restore its functionality and rebuild the first mapping set when the dynamic configuration center fails, thereby ensuring the continuity and stability of the service call process.

[0082] Optionally, deploying the dynamic configuration center in a cluster helps improve the overall availability and data processing capabilities of the system. Each server in the cluster has the same responsibility: to maintain and update the first and second mapping sets, providing real-time partition and service information to service consumers.

[0083] Optionally, the microservice cross-region invocation method also includes: if a failure is detected in the dynamic configuration center of any server in the target cluster, stop the operation of that server and switch to another healthy server to host the dynamic configuration center, so that the healthy server provides services to each service consumer.

[0084] The fault detection mechanism can quickly identify which server's dynamic configuration center is malfunctioning. It can then shut down the faulty server, preventing it from consuming resources or interfering with the cluster's normal operation. After confirming a server failure, the system automatically switches to a healthy server in the cluster, making it the primary server for the dynamic configuration center. This healthy server can take over all tasks from the faulty server without interruption, including providing real-time partition and service information to service consumers. After switching to the healthy server, it assumes the role of the dynamic configuration center, continuing to perform its original data processing, information updates, and service provision functions. Service consumers can seamlessly continue communicating with it to obtain the necessary mappings between service deployment partitions and service gateways, ensuring the continuity and stability of service calls.

[0085] By implementing cluster deployment and failover mechanisms, this embodiment helps to build a highly available dynamic configuration center platform, which can reduce the risk of service interruption due to single point of failure, and at the same time improve the robustness and response speed of the system in global microservice call scenarios.

[0086] In addition, in this embodiment, a strategy of pre-setting primary and backup cross-region service gateways is adopted to enhance the reliability and response speed of service calls. Optionally, the microservice cross-region call method further includes: pre-configuring a first cross-region service gateway and a second cross-region service gateway in the service deployment partition, with the first cross-region service gateway serving as the primary gateway and the second cross-region service gateway serving as the backup gateway; in the event of a failure of the primary gateway in the service deployment partition, the call request initiated by the service consumer is routed to the backup gateway, and the target distributed service is called through the backup gateway.

[0087] Within a service deployment partition, a first cross-region service gateway and a second cross-region service gateway can be predefined. The first cross-region service gateway is designated as the primary gateway, while the second cross-region service gateway serves as a backup gateway. This allows the system to prioritize service calls using the primary gateway during normal operation and quickly switch to the backup gateway when the primary gateway becomes unavailable, thus ensuring the continuity of service calls. When the monitoring system detects a failure in the primary cross-region service gateway within the service deployment partition, it can immediately identify this situation and automatically transfer all subsequent call requests initiated by the service consumer from the primary gateway to the backup gateway. Based on real-time monitoring results, service call failures due to primary gateway failures can be effectively avoided, helping to maintain stable communication between the service consumer and the target distributed service.

[0088] When the primary gateway fails, the backup gateway takes over its role and begins processing call requests from service consumers. The backup gateway can execute cross-region service calls with equal efficiency, ensuring that the target distributed service is invoked without affecting business process execution. This helps reduce service call latency and improve user experience. By pre-setting primary and backup cross-region service gateways and implementing automatic request transfer in the event of a primary gateway failure, this embodiment aims to build a more robust and flexible microservice call system.

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

[0090] Figure 3 This is a schematic diagram of an optional microservice adaptive cross-region load balancing based on a dynamic configuration center and a partition service gateway according to an embodiment of the present invention, such as... Figure 3As shown, it includes a dynamic configuration center (DCC), three service deployment partitions (area_A, area_B, and area_C). In service deployment partition area_A, a registry and each service node (including a service consumer and a service provider (corresponding to the distributed microservice service1)) are deployed. In service deployment partition area_A, a registry, a cross-region service gateway (gatewayB), and a service provider (service2) are deployed. In service deployment partition area_C, a registry, a cross-region service gateway (gatewayC), and a service provider (service3) are deployed.

[0091] In this embodiment of the invention, a global dynamic configuration center (DCC) can be built first. Each registry in an area can push its own partition identifier and the service information registered in that area to the DCC and keep them synchronized in real time. That is, there will be a complete service-area mapping relationship in the DCC: {area_A:[service1],area_B:[service2],area_C:[service3]}.

[0092] Each gateway in an Area can also push its own partition identifier and domain name to DCC. Therefore, DCC will have a complete gateway-area mapping relationship {area_A:gateway_A,area_B:gateway_B,area_C:gateway_C}.

[0093] It's important to note that the Dynamic Configuration Center (DCC) contains two sets of data: service-area mappings and gateway-area mappings. The gateway-area mapping set is limited in number because there's a one-to-one correspondence between gateways and areas. Data is only pushed to the DCC once during application deployment initialization, and it won't be pushed again unless the gateway fails and restarts. Therefore, this data doesn't involve high concurrency. However, the service-area mappings are dynamic. Service nodes can come online or go offline at any time, leading to high concurrency scenarios, such as when a large number of service nodes are deployed simultaneously. Therefore, in this embodiment, the DCC's information synchronization with the registry is based on a client component that works with the registry. These client components themselves have a certain level of high-concurrency processing capability, ensuring data synchronization consistency. Compared to the traditional direct consumer registration and subscription method, DCC actually reduces registry read / write concurrency. This is because each service often corresponds to hundreds of providers, and each consumer may subscribe to hundreds of services. Therefore, in the traditional multi-registration, multi-subscription model, each registry needs to push tens of thousands of provider URLs to n consumers (including consumers in the same area and consumers in different areas) in real time. With the solution in this embodiment, only provider URLs need to be pushed to consumers in the same area, and service information under the root directory needs to be pushed to a single DCC (the data volume of services is orders of magnitude larger than that of provider URLs), thus significantly reducing the amount of data pushed. Although DCC, as a client, needs to subscribe to multiple registries, the amount of data it subscribes to from the registry side is orders of magnitude smaller than that from the registry server, thus DCC can meet the needs of high-concurrency scenarios.

[0094] Furthermore, this embodiment also has corresponding control over the production time of different services. By staggering the production time and deploying them in batches, all services are prevented from going online and offline at the same time, and the concurrency is controlled within a safe range (note that this measure is usually to avoid the registry from experiencing a surge in CPU and I / O due to a surge in push volume, which would affect performance).

[0095] It should be noted that in this embodiment, the consumer only needs to subscribe to the registry within its own area, and simultaneously pulls the service-area and gateway-area mapping tables from DCC in real time. Furthermore, the consumer service call process is generalized and abstracted, adaptively adjusting the service call method based on the service deployment area during the service call initiation process: first, it determines the area where the target service is located and compares it with its own area identifier; if the target service and the consumer itself are deployed in the same area, the service call is initiated via RPC; otherwise, the service is called via HTTP through the corresponding gateway in the target service deployment area. This process is transparent and imperceptible to the consumer.

[0096] For high availability scenarios in Dynamic Configuration Center (DCC) failures, in this embodiment, both service-area and gateway-area data are stored in DCC memory. DCC can output snapshot files to disk every 30 seconds. If DCC fails and restarts, it will first read the latest snapshot file from disk to initialize data, and then subscribe to the registry for data updates, ensuring the fastest possible registry response time. Secondly, DCC is deployed in a cluster, with more than one server operating. When one DCC server fails, the consumer automatically switches to another working server, ensuring high availability for DCC.

[0097] To address the issue of real-time data changes on DCC for service consumers, this embodiment can be implemented using a listener-subscription approach. If the consumer subscribes directly to the provider URL from the registry, the registry response is in the millisecond range, and the graceful shutdown capability of the provider ensures a closed loop for transactions in transit.

[0098] Additionally, it should be noted that while the consumer's data subscription and updates from DCC also have millisecond-level response times, due to the existence of two sequential subscription relationships (consumer <- DCC <- registry), service changes do indeed cause a slight delay for the consumer. Therefore, this embodiment designs a service call retry mechanism: the consumer first calls the gateway corresponding to the target service according to the mapping relationship in the current cache. If the service happens to change at this time, for example, its deployment service's deployment area is updated, a no provider exception will occur in this transaction. When the consumer call returns this exception, it will force a cache refresh and resubscribe to the latest data from DCC, and then retry (the number of retries is configurable, and tiered retry intervals can be set, for example, the first retry occurs 50ms after the no provider exception, and the subsequent intervals are 100ms, 200ms, etc., and the cache is refreshed and resubscribed before each retry), ensuring a closed loop for transactions in transit.

[0099] In this embodiment of the invention, a partition identifier area can be added to each service node (including consumer and provider), and a cross-region service gateway can be built as the cross-region traffic entry point within the partition. At the same time, a dynamic configuration center DCC is built to dynamically save the partition mapping relationship of each service and gateway. When the consumer calls a service, it dynamically senses the partition where each service is located and the corresponding gateway address based on DCC, and calls the service provider within the same partition through RPC, and calls the cross-partition service provider through the gateway.

[0100] This embodiment effectively solves the global traffic partitioning load balancing problem in large-scale global microservice deployment scenarios. By building a partition gateway to enable cross-region service calls, it replaces the traditional multi-subscription approach of the registry center, greatly reducing the push pressure on the registry center. At the same time, it decouples the consumer from the cross-region registry center and provider, reducing the communication cost and memory overhead between the consumer and the cross-region provider. The consumer dynamically perceives the area where the service is located and its corresponding gateway address through DCC. Even if the service deployment area changes or the gateway domain name changes, the consumer can detect it in real time and adaptively switch the service call method without human intervention. This achieves complete decoupling between the consumer and provider, greatly reducing the coupling between different business systems and improving flexible deployment capabilities.

[0101] This invention eliminates the need for service consumers to directly subscribe to multiple registry centers, reducing direct communication with service providers. This lowers service call latency, saves consumer memory resources, and improves overall system response speed and scalability. Furthermore, a dynamic configuration center (DCC) can be introduced, allowing service consumers to obtain the mapping relationship of the service's partition and gateway information in real time. Even if the service deployment area or gateway domain name changes, it can quickly adapt, ensuring the continuity and efficiency of service calls without manual intervention.

[0102] Furthermore, this embodiment can help to rationally allocate resources by reducing unnecessary cross-region subscriptions and communications, reduce potential performance bottlenecks caused by cross-region calls, and improve the overall efficiency of service calls.

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

[0104] Example 2

[0105] The microservice cross-region invocation device provided in this embodiment includes multiple implementation units, each of which corresponds to the implementation steps in the above embodiment one. Its specific implementation method and beneficial effects can be referred to the foregoing method embodiment, and will not be repeated here.

[0106] According to another aspect of the present invention, a microservice cross-regional invocation device is also provided, which is applied to the service consumer end of a distributed system.

[0107] Figure 4 This is a schematic diagram of an optional microservice cross-regional invocation device according to an embodiment of the present invention, such as... Figure 4 As shown, the microservice cross-regional invocation device may include: a mapping set acquisition unit 41, a query unit 42, a first invocation request initiation unit 43, and a second invocation request initiation unit 44.

[0108] The mapping set acquisition unit 41 is used to initiate a mapping relationship acquisition request to the dynamic configuration center and obtain a first mapping set and a second mapping set from the dynamic configuration center. The first mapping set includes the mapping relationship between the distributed service and the service deployment partition, and the second mapping set includes the mapping relationship between the cross-region service gateway and the service deployment partition.

[0109] The query unit 42 is used to query the first mapping set to obtain the target service deployment partition corresponding to the target distributed service.

[0110] The first call request initiating unit 43 is used to initiate a call request to the target distributed service through a remote procedure call strategy when the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs.

[0111] The second call request initiating unit 44 is used to query the second mapping set to obtain the cross-regional service gateway corresponding to the target distributed service when the target service deployment partition and the service consumer's service deployment partition are inconsistent, and to initiate a call request to the target distributed service to the cross-regional service gateway, and call the target distributed service through the cross-regional service gateway.

[0112] The aforementioned microservice cross-region invocation device can initiate a mapping relationship retrieval request to the dynamic configuration center through the mapping set acquisition unit 41, and obtain a first mapping set and a second mapping set from the dynamic configuration center. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions. The query unit 42 queries the first mapping set to obtain the target service deployment partition corresponding to the target distributed service. If the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, the first invocation request initiation unit 43 initiates an invocation request to the target distributed service through a remote procedure call strategy. If the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, the second invocation request initiation unit 44 queries the second mapping set to obtain the cross-region service gateway corresponding to the target distributed service, initiates an invocation request to the cross-region service gateway to the target distributed service, and invokes the target distributed service through the cross-region service gateway. In this embodiment, the consumer server can query the partition where the service is located and the cross-region gateway to be called through the dynamic configuration center. This reduces the subscription of the service consumer to multiple registration centers, reduces cross-region network traffic, reduces the pressure on the registration center to synchronize the service list, and avoids memory bloat caused by the service consumer needing to store a large number of service provider lists. This reduces memory resource usage and optimizes resource utilization efficiency, thereby solving the technical problem in related technologies where, when making cross-region service calls in a distributed microservice architecture, a single consumer may need to subscribe to registration centers in multiple regions, leading to high memory resource consumption, especially when business call relationships are complex.

[0113] Optionally, the microservice cross-region invocation device further includes: a configuration center building unit, used to build a dynamic configuration center associated with all service deployment partitions before initiating a mapping relationship retrieval request to the dynamic configuration center; a first push module, used to push the partition identifier of each service deployment partition and the service information of the distributed services registered in the service deployment partition to the dynamic configuration center through the registry center in the service deployment partition; a first mapping set generation module, used by the dynamic configuration center to generate a first mapping set based on the partition identifier of each service deployment partition and the service information of each distributed service; a second push module, used to push the partition identifier and domain name information of the service deployment partition to the dynamic configuration center through the cross-region service gateway in the service deployment partition; and a second mapping set generation module, used by the dynamic configuration center to generate a second mapping set based on the partition identifier and domain name information of each service deployment partition.

[0114] Optionally, the microservice cross-region invocation device further includes: a registry center link acquisition module, used to acquire the registry center link information of the service provider in each service deployment partition; and a long connection establishment module, used to control the service consumer to maintain a long connection with the registry center of the service provider in each service deployment partition based on the registry center link information.

[0115] Optionally, the microservice cross-regional invocation device further includes: a service exception determination unit, used to determine that the target distributed service is abnormal after receiving an abnormal service invocation after initiating an invocation request to the cross-regional service gateway for the target distributed service, wherein the abnormal service invocation includes at least: an update to the service deployment partition to which the target distributed service belongs; a cache refresh unit, used to generate a forced cache refresh instruction, resubscribe to the mapping relationship from the dynamic configuration center, and obtain the latest first mapping set and second mapping set; and an invocation request rewrite initiation unit, used to initiate an invocation request to the target distributed service based on the latest first mapping set and second mapping set.

[0116] Optionally, the microservice cross-region invocation device further includes: a snapshot generation unit, used by the dynamic configuration center to generate snapshot files from the first mapping set and the second mapping set; a file output unit, used by the dynamic configuration center to output the snapshot files to the target disk at a predetermined interval; and a configuration center restart unit, used to restart the dynamic configuration center when a failure is detected, and to read the latest snapshot file from the target disk, subscribe to the partition identifier and the service information of the latest distributed services registered in the service deployment partition from the registry center in each service deployment partition, so as to obtain the updated first mapping set.

[0117] Optionally, the dynamic configuration center is deployed in a cluster. The microservice cross-regional invocation device also includes a configuration center switching unit, which is used to stop the operation of any server in the target cluster when a failure is detected in the dynamic configuration center of any server, and switch to another healthy server to host the dynamic configuration center, so that the healthy server can provide services to each service consumer.

[0118] Optionally, the microservice cross-region invocation device further includes: a gateway setting unit, used to pre-configure a first cross-region service gateway and a second cross-region service gateway in the service deployment partition, and use the first cross-region service gateway as the primary gateway and the second cross-region service gateway as the backup gateway; and a backup gateway activation unit, used to route the invocation request initiated by the service consumer to the backup gateway when a failure is detected in the primary gateway in the service deployment partition, and invoke the target distributed service through the backup gateway.

[0119] The aforementioned microservice cross-regional invocation device may also include a processor and a memory. The aforementioned mapping set acquisition unit 41, query unit 42, first invocation request initiation unit 43, second invocation request initiation unit 44, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0120] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, adaptive cross-region load balancing of microservices can be achieved based on a dynamic configuration center and a partition service gateway.

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

[0122] Example 3

[0123] Embodiments of this application may provide an electronic device. Figure 5 This is a structural block diagram of an electronic device for executing a microservice cross-regional invocation method according to an embodiment of this application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0124] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the microservice cross-region invocation method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned microservice cross-region invocation method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0125] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: Initiate a mapping relationship retrieval request to the dynamic configuration center; retrieve a first mapping set and a second mapping set from the dynamic configuration center, wherein the first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-regional service gateways and service deployment partitions; query the first mapping set to obtain the target service deployment partition corresponding to the target distributed service; if the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, initiate a call request to the target distributed service through a remote procedure call strategy; if the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, query the second mapping set to obtain the cross-regional service gateway corresponding to the target distributed service, initiate a call request to the cross-regional service gateway to the target distributed service, and call the target distributed service through the cross-regional service gateway.

[0126] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0127] Those skilled in the art will understand that all or part of the steps in the various microservice cross-region invocation methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0128] Example 4

[0129] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the microservice cross-regional invocation method provided in Embodiment 1.

[0130] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute the microservice cross-regional invocation method of any one of the above embodiments.

[0131] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0132] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the microservice cross-regional invocation method described in various embodiments of this application.

[0133] This application also provides a computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the microservice cross-regional invocation method described in various embodiments of this application.

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

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

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

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

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

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

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

Claims

1. A method for cross-region microservice invocation, characterized in that, Service consumers applied in distributed systems include: A mapping relationship retrieval request is initiated to the dynamic configuration center, and a first mapping set and a second mapping set are obtained from the dynamic configuration center. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions. Query the first mapping set to obtain the target service deployment partition corresponding to the target distributed service; If the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs, a call request to the target distributed service is initiated through a remote procedure call strategy. If the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, the second mapping set is queried to obtain the cross-region service gateway corresponding to the target distributed service, and a call request to the target distributed service is initiated to the cross-region service gateway to call the target distributed service.

2. The microservice cross-region invocation method according to claim 1, characterized in that, Before sending a request to the dynamic configuration center to obtain the mapping relationship, the process also includes: Establish a dynamic configuration center that associates all service deployment partitions; For each service deployment partition, the partition identifier of the service deployment partition and the service information of the distributed services registered in the service deployment partition are pushed to the dynamic configuration center through the registration center in the service deployment partition; The dynamic configuration center generates the first mapping set based on the partition identifier of each service deployment partition and the service information of each distributed service; The cross-region service gateway in the service deployment partition pushes the partition identifier and domain name information of the service deployment partition to the dynamic configuration center. The dynamic configuration center generates the second mapping set based on the partition identifier and domain name information of each service deployment partition.

3. The microservice cross-region invocation method according to claim 2, characterized in that, After setting up a dynamic configuration center that associates all service deployment partitions, the methods for cross-partition microservice calls also include: Obtain the registry center link information for the service provider in each service deployment partition; Based on the registry center link information, the service consumer is controlled to maintain a long connection with the registry center of the service provider in each service deployment partition.

4. The microservice cross-region invocation method according to claim 1, characterized in that, After initiating a call request to the target distributed service to the cross-region service gateway, the microservice cross-region call method further includes: Upon receiving an abnormal service call, it is determined that the target distributed service has encountered an anomaly, wherein the abnormal service call includes at least the following: the service deployment partition to which the target distributed service belongs has been updated; Generate a forced cache refresh command to resubscribe to the mapping relationship from the dynamic configuration center and obtain the latest first mapping set and second mapping set; Based on the latest first mapping set and the second mapping set, a request to invoke the target distributed service is initiated.

5. The microservice cross-region invocation method according to claim 1, characterized in that, Microservice cross-region call methods also include: The dynamic configuration center generates a snapshot file from the first mapping set and the second mapping set; The dynamic configuration center outputs snapshot files to the target disk at predetermined intervals. If a failure is detected in the dynamic configuration center, the dynamic configuration center is restarted, and the latest snapshot file is read from the target disk. The partition identifier and the service information of the latest distributed services registered in the service deployment partition are subscribed from the registry center in each service deployment partition to obtain the updated first mapping set.

6. The microservice cross-region invocation method according to claim 5, characterized in that, The dynamic configuration center is deployed in a cluster, and the method for cross-region microservice invocation also includes: If a failure is detected in the dynamic configuration center of any server in the target cluster, that server is stopped from working, and another healthy server is switched to host the dynamic configuration center, which then provides services to each service consumer.

7. The microservice cross-region invocation method according to claim 1, characterized in that, Microservice cross-region call methods also include: In the service deployment partition, a first cross-region service gateway and a second cross-region service gateway are pre-configured, with the first cross-region service gateway serving as the primary gateway and the second cross-region service gateway serving as the backup gateway. If a failure is detected in the primary gateway of the service deployment partition, the call request initiated by the service consumer is routed to the backup gateway, and the target distributed service is invoked through the backup gateway.

8. A microservice cross-regional invocation device, characterized in that, Service consumers applied in distributed systems include: The mapping set acquisition unit is used to initiate a mapping relationship acquisition request to the dynamic configuration center and acquire a first mapping set and a second mapping set from the dynamic configuration center. The first mapping set includes the mapping relationship between distributed services and service deployment partitions, and the second mapping set includes the mapping relationship between cross-region service gateways and service deployment partitions. The query unit is used to query the first mapping set to obtain the target service deployment partition corresponding to the target distributed service; The first call request initiating unit is used to initiate a call request to the target distributed service through a remote procedure call strategy when the target service deployment partition is consistent with the service deployment partition to which the service consumer belongs. The second call request initiating unit is used to query the second mapping set to obtain the cross-regional service gateway corresponding to the target distributed service when the target service deployment partition is inconsistent with the service deployment partition to which the service consumer belongs, and to initiate a call request to the target distributed service to the cross-regional service gateway, and call the target distributed service through the cross-regional service gateway.

9. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the microservice cross-regional invocation method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the microservice cross-regional invocation method according to any one of claims 1 to 7.

Images