Cross-regional calling system and method for micro-service application and medium
By introducing a registry center and gateway into the microservice application system, and utilizing exit proxies and routing proxies to achieve cross-regional calls, the communication problem of microservice applications in different regions is solved, and the cross-regional collaboration needs of industries with strict network security requirements are met.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-03-13
AI Technical Summary
In industries with stringent cybersecurity requirements, microservice applications deployed in different regions often struggle to communicate directly, making it difficult to achieve cross-regional collaborative business needs.
By introducing a first-region registry center, a first-region gateway, a second-region registry center, and an upper-layer registry center into microservice application systems in different regions, and utilizing egress proxy instances and routing proxy instances to achieve cross-region calls, communication is ensured without changing firewall isolation policies.
This enables microservice applications deployed in different regions to make cross-regional calls without changing firewall isolation policies, meeting the network security requirements of industries such as finance and energy, and achieving cross-regional collaboration.
Smart Images

Figure CN121664552A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of microservice application architecture technology, and in particular to a cross-regional invocation system, method and medium for microservice applications. Background Technology
[0002] Microservice application architecture, with its loose coupling, independent deployment, and elastic scaling, has become the mainstream choice for building large-scale enterprise applications. In industries with strict network security requirements (such as finance and energy), networks are typically divided into multiple isolated zones, with direct connections between zones prohibited by firewall isolation policies. However, this makes it difficult for microservice applications deployed in different zones to communicate directly, thus posing a fundamental challenge to business needs requiring cross-regional collaboration. Summary of the Invention
[0003] To address the aforementioned issues, this application provides a cross-regional invocation system, method, and medium for microservice applications, enabling cross-regional invocation of microservice applications deployed in different regions, thereby meeting the cross-regional collaboration needs of industries with stringent network security requirements, such as finance and energy.
[0004] The embodiments of this application disclose the following technical solutions:
[0005] In a first aspect, this application discloses a cross-regional invocation system for microservice applications, the system comprising: a first region, a second region, and an upper-layer registry center;
[0006] The first region deploys a first microservice application, a first region gateway, and a first region registry center; the second region deploys a second microservice application, a second region gateway, and a second region registry center.
[0007] The first microservice application is used to send a query command to the first regional registry center; the query command indicates that the network address of the second microservice application is to be queried.
[0008] The first regional registry center is used to respond to the query command by sending an exit proxy instance corresponding to the second microservice application to the first microservice application; the network address of the exit proxy instance points to the first regional gateway.
[0009] The first microservice application is used to send a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked.
[0010] The first regional gateway is used to send the query command to the upper-layer registration center;
[0011] The upper-layer registration center is used to respond to the query command by sending a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway.
[0012] The first regional gateway is used to send the invocation instruction to the second regional gateway;
[0013] The second regional gateway is used to send the query command to the second regional registration center;
[0014] The second regional registry center is used to send the network address of the second microservice application to the second regional gateway in response to the query command;
[0015] The second regional gateway is used to send the invocation instruction to the network address of the second microservice application;
[0016] The second microservice application is configured to respond to the call instruction by sending a call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
[0017] Optionally, the first regional registration center is specifically used for:
[0018] Obtain a list of microservice applications outside the first region, and determine the gateway for the first region;
[0019] For each microservice application in the list of microservice applications outside the first region, create a corresponding egress proxy instance to obtain an egress proxy instance set; the network address of the egress proxy instance is the network address of the gateway in the first region, and the name of the egress proxy instance is the name of the microservice application;
[0020] From the set of export proxy instances, determine the export proxy instance named after the second microservice application.
[0021] Optionally, the system further includes a configuration center; the list of microservice applications outside the first region is obtained from the configuration center.
[0022] Optionally, the first regional registration center is specifically used to: identify the first regional gateway by recognizing registration information carrying a gateway identification tag.
[0023] Optionally, the first regional registration center is specifically used to: identify multiple first candidate gateways by recognizing registration information carrying gateway identification tags; and determine the first regional gateway from the multiple first candidate gateways through a heartbeat mechanism.
[0024] Optionally, the upper-level registration center is specifically used for:
[0025] Obtain a list of microservice applications for all regions, and determine the set of regional gateways for each of the regions.
[0026] For each microservice application in the list of microservice applications in all regions, create a corresponding routing proxy instance to obtain a set of routing proxy instances; the network address of the routing proxy instance is determined by the set of regional gateways of the region where the microservice application is located, and the name of the routing proxy instance is the name of the microservice application;
[0027] From the set of routing proxy instances, determine the routing proxy instance named after the second microservice application.
[0028] Optionally, the upper-layer registry center is further configured to: update the routing proxy instance set when the microservice application list of all regions changes, or when the regional gateway set of each of the regions changes.
[0029] Optionally, the second regional registry is specifically configured to: in response to the query instruction, search for the network address of the second microservice application from the set of local service instances maintained locally by the second regional registry; and send the network address of the second microservice application to the second regional gateway.
[0030] Secondly, this application discloses a cross-regional invocation method for microservice applications, applied to a cross-regional invocation system for microservice applications including a first region, a second region, and an upper-layer registry center. The first region deploys a first microservice application, a first region gateway, and a first region registry center; the second region deploys a second microservice application, a second region gateway, and a second region registry center; the method includes:
[0031] The first microservice application sends a query command to the first regional registry center; the query command instructs the user to query the network address of the second microservice application.
[0032] In response to the query command, the first regional registry center sends an exit proxy instance corresponding to the second microservice application to the first microservice application; the network address of the exit proxy instance points to the first regional gateway.
[0033] The first microservice application sends a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked.
[0034] The first regional gateway sends the query command to the upper-layer registration center;
[0035] In response to the query command, the upper-layer registration center sends a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway.
[0036] The first area gateway sends the invocation instruction to the second area gateway;
[0037] The second regional gateway sends the query command to the second regional registration center;
[0038] The second regional registry center is used to send the network address of the second microservice application to the second regional gateway in response to the query command;
[0039] The second regional gateway sends the invocation instruction to the network address of the second microservice application;
[0040] In response to the call instruction, the second microservice application sends a call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
[0041] Thirdly, this application discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a cross-regional invocation method for a microservice application as described in the second aspect.
[0042] Compared with the prior art, this application has the following beneficial effects:
[0043] This application discloses a cross-regional invocation system, method, and medium for microservice applications. The cross-regional invocation system for microservice applications provided by this application enables microservice applications deployed in different regions to make cross-regional invocations without changing the firewall isolation policy (setting firewalls between different regional gateways and between regional gateways and the upper-layer registry center), thereby meeting the business needs of cross-regional collaboration in industries with strict network security requirements such as finance and energy. Attached Figure Description
[0044] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0045] Figure 1 A signaling diagram of a cross-regional invocation system for a microservice application provided in an embodiment of this application;
[0046] Figure 2 A schematic diagram of a cross-regional invocation system for a microservice application provided in an embodiment of this application;
[0047] Figure 3 A flowchart for confirming the exit proxy instance corresponding to the second microservice application is provided in an embodiment of this application;
[0048] Figure 4 A flowchart for confirming the routing proxy instance corresponding to the second microservice application is provided in an embodiment of this application;
[0049] Figure 5 A flowchart illustrating a cross-regional invocation method for a microservice application provided in this application embodiment;
[0050] Figure 6 This is a schematic diagram of a computer-readable medium provided in an embodiment of this application. Detailed Implementation
[0051] As described earlier, in industries with stringent cybersecurity requirements (such as finance and energy), networks are typically divided into multiple isolated zones, with direct connections between zones prohibited by firewalls. However, this makes it difficult for microservice applications deployed in different zones to communicate directly, posing a fundamental challenge to business needs requiring cross-regional collaboration.
[0052] After research, the inventors have disclosed a cross-regional invocation system, method and medium for microservice applications. The cross-regional invocation system for microservice applications provided in this application enables microservice applications deployed in different regions to make cross-regional invocations without changing the firewall isolation policy (setting firewalls between different regional gateways and between regional gateways and the upper-layer registry center), thereby meeting the business needs of cross-regional collaboration in industries with strict network security requirements such as finance and energy.
[0053] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0054] See Figure 1This figure is a signaling diagram of a cross-regional invocation system for a microservice application provided in an embodiment of this application. The cross-regional invocation system for a microservice application includes: mutually isolated business regions (this application uses a first region and a second region as an example for explanation; in actual applications, it is sufficient to ensure that the number of business regions is greater than or equal to 2) and an upper-layer registry center.
[0055] The first and second regions represent two business areas that are physically or logically isolated from each other for security, compliance, or management requirements. A mandatory network isolation policy (such as a firewall) exists between the first and second regions, resulting in no direct network communication paths between the first microservice application and the second region gateway, or between the second microservice application and the first region gateway. The first region deploys the first microservice application (the concrete implementation unit of the business functions in this region), the first region gateway (the external communication exit and entry point for this region), and the first region registry (a local service directory serving this region); the second region deploys the second microservice application, the second region gateway, and the second region registry.
[0056] The upper-level registration center is deployed independently of each business area and is a global logical coordination component.
[0057] Next, taking the example of the first microservice application calling the second microservice application, we will explain in detail the cross-regional calls of microservice applications:
[0058] S101: The first microservice application sends a query command to the first regional registry center; the query command instructs the user to query the network address of the second microservice application.
[0059] When the first microservice application needs to call the second microservice application, the first microservice application needs to send a query command to the first regional registry center. The core content of this query command is to request the network address of the second microservice application.
[0060] S102: In response to the query command, the first regional registry center sends the egress proxy instance corresponding to the second microservice application to the first microservice application; the network address of the egress proxy instance points to the first regional gateway.
[0061] After receiving the query command, the first regional registry returned an exit proxy instance corresponding to the "second microservice application" to the first microservice application.
[0062] See Figure 2 This figure is a schematic diagram of a cross-regional invocation system for a microservice application provided in an embodiment of this application. See also... Figure 3 The figure is a flowchart illustrating the process of confirming an export proxy instance corresponding to a second microservice application, as provided in an embodiment of this application.
[0063] A1: The first-region registry center obtains a list of microservice applications outside the first region, and determines the first-region gateway.
[0064] The list of microservice applications outside the first region defines "which microservice applications originate from outside this region". In one specific implementation, such as... Figure 2 As shown, the cross-regional call system for service applications also includes a configuration center. The first regional registry can obtain a list of microservice applications outside the first region from the configuration center. For example, the list of microservice applications outside the first region could be: "Second Region: Second Microservice Application".
[0065] In one specific implementation, the first regional registry can identify the first regional gateway from all registration information by recognizing registration information carrying gateway identification tags (e.g., isproxy:true, isgateway:true).
[0066] It should be noted that, alternatively, multiple first-line candidate gateways can be identified from all registration information by recognizing those carrying gateway identifier tags. Then, a heartbeat mechanism is used to determine the healthy first-line regional gateway from among these candidate gateways. Thus, through the heartbeat mechanism, the first-line regional registry can eliminate faulty first-line regional gateways, thereby providing a high-availability foundation for the egress proxy instance.
[0067] A2: The first-region registry center creates a corresponding exit proxy instance for each microservice application in the list of microservice applications outside the first region, and obtains a set of exit proxy instances; the network address of the exit proxy instance is the network address of the first-region gateway, and the name of the exit proxy instance is the name of the microservice application.
[0068] For example, for a second microservice application in the list of microservice applications outside the first region, the corresponding egress proxy instance can be as follows: "Name: Second microservice application; Network address: Network address of the first region gateway; Metadata: Gateway identification tag". It is understood that the egress proxy instance includes a gateway identification tag (e.g., isproxy:true, isgateway:true).
[0069] A3: The first regional registry center determines the export proxy instance named after the second microservice application from the set of export proxy instances.
[0070] When the query command in step S101 arrives, since a corresponding export proxy instance for "Second Microservice Application" has already been created in step A2, it is only necessary to determine the specific export proxy instance named "Second Microservice Application" from the set of export proxy instances.
[0071] It is understandable that the network address of the outbound proxy instance points to the network address of the first regional gateway, not the actual network address of the second microservice application.
[0072] S103: The first microservice application sends a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked.
[0073] After receiving the egress proxy instance pointing to the first regional gateway, the first microservice application will send a call instruction to the first regional gateway. The core content of this call instruction is to request the invocation of the service of the second microservice application.
[0074] S104: The first regional gateway sends a query command to the upper-level registration center.
[0075] After receiving a call request from the first microservice application, the first regional gateway will send a query command to the upper-layer registry center.
[0076] S105: In response to the query command, the upper-layer registry center sends a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway.
[0077] After receiving the query command from the first regional gateway, the upper-layer registry center returns a routing proxy instance corresponding to the "second microservice application" to the first regional gateway.
[0078] See Figure 4 The figure is a flowchart illustrating how to confirm a routing proxy instance corresponding to a second microservice application, as provided in an embodiment of this application.
[0079] B1: The upper-layer registry center obtains a list of microservice applications for all regions, and determines the set of regional gateways for each region.
[0080] In one specific implementation, the upper-layer registry center can obtain a list of microservice applications for all regions from the configuration center. For example, the list of microservice applications for all regions could be: "First region: First microservice application; Second region: Second microservice application".
[0081] In one specific implementation, the first regional registry center can first identify the candidate gateway set for a single region by recognizing registration information carrying gateway identification tags (e.g., isproxy:true, isgateway:true) from all registration information within that region. Subsequently, a heartbeat mechanism is used to determine the healthy set of regional gateways from this candidate gateway set. For example, the set of regional gateways could be: "Second Region - [Regional Gateway B1, Regional Gateway B2...]".
[0082] B2: The upper-level registry center creates a corresponding routing proxy instance for each microservice application in the list of microservice applications in all regions, and obtains a set of routing proxy instances; the network address of the routing proxy instance is determined by the set of regional gateways in the region where the microservice application is located, and the name of the routing proxy instance is the name of the microservice application.
[0083] For example, for the second microservice application in the microservice application list across all regions, the corresponding routing proxy instance can be as follows: "Name: Second microservice application; Network address: Network address of the second region gateway; Metadata: Gateway identification tag". It is understood that the egress proxy instance includes a gateway identification tag (e.g., isproxy:true, isgateway:true).
[0084] B3: The upper-layer registry center determines the routing proxy instance named after the second microservice application from the set of routing proxy instances.
[0085] When the query command in step S104 arrives, since a corresponding routing proxy instance for "Second Microservice Application" has already been created in step B3, it is only necessary to determine the specific routing proxy instance named "Second Microservice Application" from the set of routing proxy instances.
[0086] It is understandable that the network address of the outbound proxy instance points to the network address of the second regional gateway, rather than the actual network address of the second microservice application.
[0087] It should be noted that when the list of microservice applications changes across all regions (e.g., a new microservice application is deployed), or when the set of regional gateways changes across all regions (e.g., a gateway instance stops heartbeat due to a failure and is removed from the regional gateway set by the upper-layer registry center), the set of routing proxy instances is updated. Therefore, the cross-regional call system for this microservice application can automatically and in real-time adapt to the online / offline status of microservice applications or gateway nodes, ensuring the accuracy and timeliness of cross-regional calls.
[0088] S106: The first area gateway sends a call instruction to the second area gateway.
[0089] After obtaining the routing proxy instance pointing to the second area gateway, the first area gateway sends a call instruction to the second area gateway.
[0090] It should be noted that during the sending of the call command, the call command can be encapsulated through a protocol to ensure the confidentiality and integrity of data when transmitted across public networks or dedicated lines in different regions.
[0091] S107: The second area gateway sends a query command to the second area registration center.
[0092] S108: In response to the query command, the second regional registry sends the network address of the second microservice application to the second regional gateway.
[0093] First, in response to the query command, the second regional registry center searches for the network address of the second microservice application from the set of local service instances maintained locally by the second regional registry center. Then, it sends the network address of the second microservice application to the second regional gateway.
[0094] Understandably, the network address of the second microservice application no longer carries a gateway identifier label (e.g., isproxy:true, isgateway:true).
[0095] S109: The second regional gateway sends a call instruction to the network address of the second microservice application.
[0096] S110: In response to the call instruction, the second microservice application sends the call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
[0097] The second microservice application responds to the call command by following a strictly symmetrical reverse path from the request path: first, the second microservice application returns the call response to the second regional gateway; then, the second regional gateway returns the call response to the first regional gateway; finally, the first regional gateway returns the call response to the first microservice application that initially initiated the call. This reverse return of the response ensures the integrity and closure of the entire call chain.
[0098] In summary, the embodiments of this application provide a cross-regional invocation system for microservice applications. The cross-regional invocation system for microservice applications provided by the embodiments of this application enables microservice applications deployed in different regions to make cross-regional invocations without changing the firewall isolation strategy (setting firewalls between different regional gateways, and setting firewalls between regional gateways and the upper-layer registry center), thereby meeting the business needs of cross-regional collaboration in industries with strict network security requirements such as finance and energy.
[0099] See Figure 5 This figure is a flowchart of a cross-regional invocation method for a microservice application provided in an embodiment of this application. The method is applied to a cross-regional invocation system for a microservice application comprising a first region, a second region, and an upper-layer registry center. The first region deploys a first microservice application, a first region gateway, and a first region registry center; the second region deploys a second microservice application, a second region gateway, and a second region registry center. The method includes:
[0100] S501: The first microservice application sends a query command to the first regional registry center; the query command instructs the user to query the network address of the second microservice application.
[0101] S502: In response to the query command, the first regional registry center sends the egress proxy instance corresponding to the second microservice application to the first microservice application; the network address of the egress proxy instance points to the first regional gateway.
[0102] In one specific implementation, the method for determining the egress proxy instance corresponding to the second microservice application is as follows: obtain a list of microservice applications outside the first region, and determine the gateway of the first region; create a corresponding egress proxy instance for each microservice application in the list of microservice applications outside the first region, and obtain a set of egress proxy instances; the network address of the egress proxy instance is the network address of the gateway of the first region, and the name of the egress proxy instance is the name of the microservice application; from the set of egress proxy instances, determine the egress proxy instance with the name of the second microservice application.
[0103] In one specific implementation, the cross-regional call system for microservice applications also includes: a configuration center; the list of microservice applications outside the first region is obtained from the configuration center.
[0104] In one specific implementation, determining the first regional gateway includes: identifying the first regional gateway by recognizing registration information carrying a gateway identification tag.
[0105] In one specific implementation, the first regional gateway is determined by identifying registration information carrying a gateway identifier tag, including: identifying multiple first candidate gateways by identifying registration information carrying a gateway identifier tag; and determining the first regional gateway from the multiple first candidate gateways through a heartbeat mechanism.
[0106] S503: The first microservice application sends a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked.
[0107] S504: The first regional gateway sends a query command to the upper-level registration center.
[0108] S505: In response to the query command, the upper-layer registry center sends a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway.
[0109] In one specific implementation, the routing proxy instance corresponding to the second microservice application is determined as follows: A list of microservice applications in all regions is obtained, and the set of regional gateways for each region is determined; a corresponding routing proxy instance is created for each microservice application in the list of microservice applications in all regions, resulting in a set of routing proxy instances; the network address of the routing proxy instance is determined through the set of regional gateways in the region where the microservice application is located, and the name of the routing proxy instance is the name of the microservice application; from the set of routing proxy instances, the routing proxy instance named after the second microservice application is determined.
[0110] In one specific implementation, the method further includes updating the set of routing proxy instances when the microservice application manifest changes in all regions, or when the set of regional gateways for each of the aforementioned regions changes.
[0111] S506: The first area gateway sends a call instruction to the second area gateway.
[0112] S507: The second area gateway sends a query command to the second area registration center.
[0113] S508: Second regional registry center, used to send the network address of the second microservice application to the second regional gateway in response to a query command.
[0114] In one specific implementation, in response to a query command, sending the network address of the second microservice application to the second regional gateway includes: in response to the query command, searching for the network address of the second microservice application from the set of local service instances maintained locally by the second regional registry center; and sending the network address of the second microservice application to the second regional gateway.
[0115] S509: The second regional gateway sends a call instruction to the network address of the second microservice application.
[0116] S510: The second microservice application responds to the call instruction and sends the call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
[0117] In summary, the embodiments of this application provide a method for cross-regional invocation of microservice applications. The cross-regional invocation method for microservice applications provided by the embodiments of this application enables microservice applications deployed in different regions to make cross-regional invocations without changing the firewall isolation strategy (setting firewalls between different regional gateways, and setting firewalls between regional gateways and upper-layer registration centers), thereby meeting the business needs of cross-regional collaboration in industries with strict network security requirements such as finance and energy.
[0118] See Figure 6This figure is a schematic diagram of a computer-readable medium provided in an embodiment of this application. The computer-readable medium 600 stores a computer program 611, which, when executed by a processor, implements the above-described... Figure 5 The steps for cross-regional method calls in microservice applications.
[0119] It should be noted that, in the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0120] It should be noted that the machine-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.
[0121] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.
[0122] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.
[0123] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this application. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.
[0124] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.
Claims
1. A cross-regional invocation system for microservice applications, characterized in that, The system includes: a first area, a second area, and an upper-level registration center; The first region deploys a first microservice application, a first region gateway, and a first region registry center; the second region deploys a second microservice application, a second region gateway, and a second region registry center. The first microservice application is used to send a query command to the first regional registry center; the query command indicates that the network address of the second microservice application is to be queried. The first regional registry center is used to respond to the query command by sending an exit proxy instance corresponding to the second microservice application to the first microservice application; the network address of the exit proxy instance points to the first regional gateway. The first microservice application is used to send a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked. The first regional gateway is used to send the query command to the upper-layer registration center; The upper-layer registration center is used to respond to the query command by sending a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway. The first regional gateway is used to send the invocation instruction to the second regional gateway; The second regional gateway is used to send the query command to the second regional registration center; The second regional registry center is used to send the network address of the second microservice application to the second regional gateway in response to the query command; The second regional gateway is used to send the invocation instruction to the network address of the second microservice application; The second microservice application is configured to respond to the call instruction by sending a call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
2. The system according to claim 1, characterized in that, The first regional registration center is specifically used for: Obtain a list of microservice applications outside the first region, and determine the gateway for the first region; For each microservice application in the list of microservice applications in the non-first region, create a corresponding exit proxy instance to obtain a set of exit proxy instances; The network address of the outbound proxy instance is the network address of the first regional gateway, and the name of the outbound proxy instance is the name of the microservice application. From the set of export proxy instances, determine the export proxy instance named after the second microservice application.
3. The system according to claim 2, characterized in that, The system also includes a configuration center; the list of microservice applications outside the first region is obtained from the configuration center.
4. The system according to claim 2, characterized in that, The first regional registration center is specifically used to: identify the first regional gateway by recognizing registration information carrying a gateway identification tag.
5. The system according to claim 4, characterized in that, The first regional registration center is specifically used to: identify multiple first candidate gateways by recognizing registration information carrying gateway identification tags; and determine the first regional gateway from the multiple first candidate gateways through a heartbeat mechanism.
6. The system according to claim 1, characterized in that, The upper-level registration center is specifically used for: Obtain a list of microservice applications for all regions, and determine the set of regional gateways for each of the regions. For each microservice application in the list of microservice applications in all regions, create a corresponding routing proxy instance to obtain a set of routing proxy instances; The network address of the routing proxy instance is determined by the set of regional gateways in the region where the microservice application is located, and the name of the routing proxy instance is the name of the microservice application. From the set of routing proxy instances, determine the routing proxy instance named after the second microservice application.
7. The system according to claim 6, characterized in that, The upper-layer registry center is also used to update the routing proxy instance set when the microservice application list of all regions changes, or when the regional gateway set of each of the regions changes.
8. The system according to claim 1, characterized in that, The second regional registry is specifically used to: respond to the query instruction, search for the network address of the second microservice application from the local service instance set maintained locally by the second regional registry; and send the network address of the second microservice application to the second regional gateway.
9. A method for cross-regional invocation in a microservice application, characterized in that, A cross-regional invocation system is applied to a microservice application that includes a first region, a second region, and an upper-layer registry center. The first region is where a first microservice application, a first region gateway, and a first region registry center are deployed. The second region deploys a second microservice application, a second region gateway, and a second region registry center; the method includes: The first microservice application sends a query command to the first regional registry center; the query command instructs the user to query the network address of the second microservice application. In response to the query command, the first regional registry center sends an exit proxy instance corresponding to the second microservice application to the first microservice application; the network address of the exit proxy instance points to the first regional gateway. The first microservice application sends a call instruction to the first regional gateway; the call instruction indicates that the service of the second microservice application is invoked. The first regional gateway sends the query command to the upper-layer registration center; In response to the query command, the upper-layer registration center sends a routing proxy instance corresponding to the second microservice application to the first regional gateway; the network address of the routing proxy instance points to the second regional gateway. The first area gateway sends the invocation instruction to the second area gateway; The second regional gateway sends the query command to the second regional registration center; The second regional registry center is used to send the network address of the second microservice application to the second regional gateway in response to the query command; The second regional gateway sends the invocation instruction to the network address of the second microservice application; In response to the call instruction, the second microservice application sends a call response result to the second regional gateway, so that the second regional gateway sends the call response result to the first microservice application through the first regional gateway.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a cross-regional invocation method for a microservice application as described in claim 9.