A dual-registration-center-based micro-service information dual-writing system, method and device

Abstract

The present specification relates to the field of software development, and particularly to a dual-registration-center-based microservice information dual-write system, method and device. The system comprises: a dual-registration-center cluster, comprising a plurality of registration center instances, part of the plurality of registration center instances being deployed in a local data center, and the remaining part being deployed in a remote data center; a dual-registration-center proxy cluster in communication with the dual-registration-center cluster, wherein each registration center proxy cluster is respectively deployed in a data center, used to receive a request initiated by a microservice application, and synchronously write the request to each registration center cluster; receive microservice information returned by each registration center cluster; and determine whether the request initiated by the microservice application is responded to according to the returned microservice information. The present specification provides a registration center proxy service for dual writing to the dual-registration-center cluster, which has higher real-time performance and less access to the existing cluster.

Description

Technical Field

[0001] This specification relates to the field of software development, and in particular to a microservice information dual-write system, method and apparatus based on dual registration centers. Background Technology

[0002] In a microservice architecture, each microservice application is registered with a registry center during deployment. When a request involves multiple microservice calls, the microservice initiating the call will retrieve information about all microservices from the registry center, process the request based on its content, and finally complete the remote call to the microservice.

[0003] Current industry technologies typically deploy two registry clusters and add a synchronization service to synchronize microservice information from the primary cluster to the backup cluster in real time, ensuring consistency between the two clusters. If one cluster fails, the other can still provide service, thus guaranteeing registry availability. However, this method has the following drawbacks: First, when applications are deployed in two data centers, if applications in both centers access the primary registry node, cross-center access to the registry can occur, increasing unnecessary network consumption. Second, the added synchronization service needs to synchronize all microservice information from the primary cluster, which increases the access pressure on the primary cluster. In extreme cases, this could lead to a situation where the primary cluster fails, leaving the backup cluster without the latest microservice information. Summary of the Invention

[0004] To address the issues of network consumption and increased host cluster access pressure caused by cross-center access to the registry in the prior art, this specification provides a microservice information dual-write system, method, and apparatus based on dual registry centers.

[0005] This specification provides a microservice information dual-write system based on dual registration centers. The system includes: a dual registration center cluster, comprising multiple registration center instances, wherein some instances are deployed in a local data center and the remaining instances are deployed in a remote data center; a dual registration center proxy cluster, wherein each registration center proxy cluster is deployed in a separate data center, used to receive requests initiated by microservice applications and synchronously write the requests to each registration center cluster; receive microservice information returned by each registration center cluster; and determine whether the requests initiated by the microservice applications have been responded to based on the returned microservice information.

[0006] According to one aspect of the embodiments of this specification, the priority registration center cluster of the local data center is determined based on the arrangement order of the address information of multiple registration center instances recorded in the configuration file of the registration center agent cluster.

[0007] According to one aspect of an embodiment of this specification, the method is applied to the dual registry agent cluster, comprising: receiving a request initiated by a microservice application; synchronously writing the request to each registry cluster; receiving microservice information returned by each registry cluster; and determining whether the request initiated by the microservice application has been responded to based on the returned microservice information.

[0008] According to one aspect of the embodiments of this specification, when the request initiated by the microservice application is a service fetch request, determining whether the request initiated by the microservice application has received a response based on the returned microservice information includes: determining whether the priority registration center cluster has returned microservice information; if yes, determining that the priority registration center cluster is operating normally and sending the microservice information of the priority registration center cluster to the microservice application; if no, determining that the priority registration center cluster is operating abnormally and sending an error message indicating that the service fetch failed to the microservice application.

[0009] According to one aspect of the embodiments of this specification, when the request initiated by the microservice application is a timed renewal request, determining whether the request initiated by the microservice application has received a response based on the returned microservice information includes: determining whether all registry center clusters have returned microservice information; if so, determining that the renewal was successful and sending a renewal success message to the microservice application; if not, determining that the renewal failed and sending a renewal failure error message to the microservice application.

[0010] According to one aspect of the embodiments of this specification, receiving microservice information returned by each registry cluster further includes: periodically pulling microservice information from each registry cluster within a preset period; comparing whether the microservice information of each registry cluster is consistent; if not, comparing the microservice information of each registry cluster with the microservice information of the previous period in the current period to determine whether the microservice information of each registry cluster has changed; if so, identifying the clusters that have not changed as abnormal clusters and the clusters that have changed as normal clusters; removing the abnormal clusters and sending the requests initiated by the microservice applications to the normal clusters.

[0011] According to one aspect of the embodiments of this specification, the method further includes: when the dual registry agent cluster receives microservice information returned by the dual registry cluster, the microservice information returned by the priority registry cluster is read first.

[0012] According to one aspect of the embodiments of this specification, when the registry agent cluster starts, the method further includes: configuring the addresses of all registry clusters, wherein the instance addresses of the registry clusters in the local center are given priority; and loading all instance information in all registry clusters.

[0013] This specification also discloses a microservice information dual-write device based on dual registration centers. The device includes: a receiving unit for receiving a request initiated by a microservice application; a dual-write unit for synchronously writing the request to each registration center cluster; a microservice information receiving unit for receiving microservice information returned by each registration center cluster; and a determining unit for determining whether the request initiated by the microservice application has been responded to based on the returned microservice information.

[0014] This specification also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the microservice information dual-write method based on dual registration centers.

[0015] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the microservice information dual-write method based on dual registration centers.

[0016] This manual provides a registry agent service for dual-registration clusters, which offers higher real-time performance and requires less access to the existing cluster. Attached Figure Description

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

[0018] Figure 1 The diagram shown is a schematic of a microservice information dual-write system based on a dual-registration center, according to an embodiment of this specification.

[0019] Figure 2 The diagram shown is a flowchart of a microservice information dual-write method based on dual registration centers, according to an embodiment of this specification.

[0020] Figure 3 The diagram shown is a flowchart of a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification.

[0021] Figure 4 The diagram shown is a flowchart of a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification.

[0022] Figure 5 The diagram shown is a flowchart of a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification.

[0023] Figure 6 The diagram shown is a flowchart of a method for loading a registry center instance according to an embodiment of this specification;

[0024] Figure 7 The diagram shown is a structural schematic of a microservice information dual-write device based on a dual-registration center, according to an embodiment of this specification.

[0025] Figure 8 The diagram shown is a schematic representation of the microservice information dual-write device based on a dual-registration center, as described in this specification.

[0026] Figure 9 The diagram shown is a schematic of a microservice application initiating a service fetch request according to an embodiment of this specification.

[0027] Figure 10 The diagram shown is a schematic of a microservice application initiating a renewal request according to an embodiment of this specification.

[0028] Figure 11 The diagram shown is a comparative service illustration of an embodiment of this specification;

[0029] Figure 12 The diagram shown is a structural schematic of a computer device according to an embodiment of this specification.

[0030] Explanation of symbols in the attached drawings:

[0031] 100. Dual registration center cluster;

[0032] 110. Multiple registry center instances;

[0033] 200. Dual registration center agent cluster;

[0034] 701. Receiving Unit;

[0035] 702, Double-write unit;

[0036] 703. Microservice Information Receiving Unit;

[0037] 7031, First Judgment Module;

[0038] 7032, Second Judgment Module;

[0039] 7033, Service Comparison Module;

[0040] 704. Determine the unit;

[0041] 1202. Computer equipment;

[0042] 1204, Processor;

[0043] 1206. Memory;

[0044] 1208. Drive mechanism;

[0045] 1210. Input / output module;

[0046] 1212. Input devices;

[0047] 1214. Output devices;

[0048] 1216. Presentation equipment;

[0049] 1218. Graphical User Interface;

[0050] 1220. Network interface;

[0051] 1222. Communication link;

[0052] 1224. Communication bus. Detailed Implementation

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

[0054] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings 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 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, apparatus, product, or device 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 devices.

[0055] This specification provides the operational steps of the methods described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual system or device products, the methods shown in the embodiments or drawings can be executed sequentially or in parallel.

[0056] It should be noted that the microservice information dual-writing system and method based on dual registration centers described in this specification can be used in the field of software development as well as in the field of financial technology. This specification does not limit the application fields of the microservice information dual-writing system, method and device based on dual registration centers.

[0057] Figure 1 The diagram illustrates a microservice information dual-write system based on a dual-registration center, as described in this specification. The system includes a dual-registration center cluster 100, a dual-registration center proxy cluster 200, and dual data centers. The dual-registration center cluster 100 comprises multiple registration center instances 110, some of which are deployed in a local data center, while the remaining instances are deployed in a remote data center. The dual data centers include a local data center and a remote data center, with each data center deploying one registration center cluster and one registration center proxy cluster.

[0058] Each of the dual registry agent clusters 200 is deployed in a data center to receive requests initiated by microservice applications and synchronously write the requests to each registry cluster; receive microservice information returned by each registry cluster; and determine whether the requests initiated by the microservice applications have been responded to based on the returned microservice information.

[0059] The microservice information dual-write system based on dual registration centers described in this specification also includes dual data centers, namely Data Center 1 and Data Center 2. The dual registration center clusters are deployed across the two data centers. Each registration center cluster is deployed on Data Center 1 and Data Center 2 respectively.

[0060] In some embodiments of this specification, the priority registry cluster in the local data center is determined based on the arrangement order of the address information of multiple registry instances recorded in the configuration file of the registry proxy cluster. In these embodiments, the registry proxy cluster sequentially records the address information of all registry instances in both registry clusters through the configuration file. The address information of the registry instances includes, but is not limited to, any one of DNS or IP addresses. The address information of all registry instances in the dual registry clusters forms a complete string, thus forming the configuration file. The registry instances in the first half of the string are deployed in the local data center, and the registry instances in the second half are deployed in a remote data center. Furthermore, the registry cluster containing the registry instances deployed in the local data center is determined as the priority registry cluster (also referred to as the primary registry cluster, or registry cluster 1 in subsequent diagrams). This specification provides a registry proxy service for dual-write operations to dual registry clusters, resulting in higher real-time performance and fewer accesses to existing clusters.

[0061] Figure 2 The diagram shown is a flowchart of a microservice information dual-write method based on dual registration centers according to an embodiment of this specification, which specifically includes the following steps:

[0062] Step 201: Receive requests initiated by microservice applications. In a microservice architecture, each microservice application is registered with a registry center during deployment. When a client request involves multiple microservice calls, the initiating microservice retrieves information about all microservices from the registry center, processes the request based on its content, and finally completes the remote microservice call. Therefore, the requests received in this step are requests to call microservices registered in the registry center.

[0063] In the embodiments described in this specification, the request initiated by the microservice application further includes: a renewal request.

[0064] Step 202: Synchronously write the request to each registry center cluster. In this step, the dual registry center proxy cluster will synchronously write the request received from the microservice application to the dual registry center proxy cluster.

[0065] Step 203: Receive microservice information returned by each registry cluster. After step 202 writes the request to each registry cluster, each registry returns microservice information to the registry proxy cluster. Therefore, in this step, the registry proxy cluster receives the microservice information returned by each registry cluster.

[0066] Step 204: Based on the returned microservice information, determine whether the request initiated by the microservice application received a response. In this step, based on the data returned by each registry cluster in the dual registry cluster, determine whether the registry cluster has failed and whether the microservice has encountered an anomaly.

[0067] In some embodiments of this specification, it can be determined whether an access request initiated by a microservice application belongs to the local area; if so, the access request is preferentially read by the registry cluster in the local data center, realizing local priority access. This can improve the access speed and efficiency of microservice applications and optimize access performance.

[0068] Figure 3 The diagram shown is a flowchart illustrating a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification. This specification applies to situations where a microservice application initiates a service fetch request, and specifically includes the following steps:

[0069] Step 301: Determine if the priority registry cluster has returned microservice information. In this step, the registry agent continuously checks the microservice information returned by the dual registry clusters. The main focus of this step is determining whether the priority registry cluster has returned microservice information.

[0070] Step 302: If yes, confirm that the priority registry cluster is running normally and send the microservice information of the priority registry cluster to the microservice application. If the priority registry cluster returns microservice information, the registry proxy cluster will then return the priority registry microservice information to the microservice application.

[0071] Step 303: If not, determine that the priority registry cluster is malfunctioning and send an error message indicating service retrieval failure to the microservice application. In this step, if the priority registry cluster does not return microservice information, the priority registry cluster is considered malfunctioning, and the registry proxy cluster returns an error message indicating service retrieval failure to the microservice application.

[0072] Figure 4 The diagram shown is a flowchart illustrating a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification. This specification applies to situations where a microservice application initiates a timed renewal request, and specifically includes the following steps:

[0073] Step 401: Determine whether all registry center clusters have returned microservice information. In this step, the microservice application periodically sends renewal service information during runtime. Similar to step 301, the registry center proxy cluster determines whether both registry center clusters have returned microservice information.

[0074] Step 402: If yes, confirm successful renewal and send a successful renewal message to the microservice application. In this step, the renewal is confirmed to be successful when the registry agent cluster receives microservice information from both registry clusters.

[0075] Step 403: If not, confirm the renewal failure and send a renewal failure error message to the microservice application. In this step, the renewal is confirmed to have failed if the registry proxy cluster receives microservice information from only one registry cluster, or receives no microservice information from any registry cluster. Renewal failure indicates an anomaly in the service within the registry cluster. Based on the registry clusters that did not receive microservice information, the registry cluster experiencing the anomaly can be identified. After identifying the anomaly, the registry proxy cluster sends the renewal failure error message to the microservice application.

[0076] Figure 5 The diagram shown is a flowchart illustrating a method for determining whether a request initiated by a microservice application has received a response, according to an embodiment of this specification. Specifically, it includes the following steps:

[0077] Step 501: Periodically retrieve microservice information from each registry cluster within a preset period. In this step, the registry proxy cluster periodically writes microservice information retrieval requests to the dual registry cluster. This allows the retrieval of microservice information returned by each registry cluster within a predetermined time period.

[0078] Step 502: Compare the microservice information of each registry cluster to see if they are consistent. In this embodiment, microservice information includes: microservice name, number of instances, instance status, etc. Therefore, this step compares whether the microservice information returned by registry cluster 1 and registry cluster 2 is completely consistent. If they are completely consistent, it means that the microservice information of the two registry clusters is synchronized and has consistency.

[0079] Step 503: If not, compare the microservice information of each registry cluster with the microservice information of the previous period to determine whether the microservice information of each registry cluster has changed. In this step, if the microservice information returned by each registry is not completely consistent, it indicates that an anomaly has occurred in the registry cluster.

[0080] Furthermore, the microservice information returned by the dual registry cluster in the previous cycle is used as a comparison standard. The microservice information returned by the dual registry cluster in the current cycle is compared with the microservice information returned in the previous cycle to determine whether the microservice information has changed between the two cycles. In the embodiments of this specification, as time changes, the data related to "time" in the microservice information returned by the dual registry cluster in each cycle will inevitably change. Therefore, if the microservice information returned by the dual registry cluster does not change within two cycles, it can be determined that the registry cluster that has not changed has an anomaly.

[0081] Step 504: If not, identify the unchanged clusters as abnormal clusters. Identify the changed clusters as normal clusters. Therefore, the abnormal and normal clusters in the dual registry cluster can be determined.

[0082] Step 505: Remove the abnormal cluster and send requests initiated by the microservice application to the normal cluster. In this step, alarm information is generated based on the abnormal cluster, and the address of the registry cluster in the registry proxy cluster is modified to remove the address of the abnormal registry cluster. This ensures that the microservice application can retrieve the correct microservice information returned by the normal registry cluster in subsequent requests, guaranteeing the continuity of business calls.

[0083] Figure 6 The diagram shown is a flowchart of a method for loading a registry center instance according to an embodiment of this specification, which specifically includes the following steps:

[0084] Step 601: Configure the addresses of all registry center clusters, prioritizing the instance addresses of the registry center cluster located in the local data center. In this embodiment, the registry center proxy service pre-configures the addresses of multiple registry center instances in two registry center clusters. Furthermore, the registry center proxy cluster prioritizes the addresses of registry center instances deployed in the local data center.

[0085] For example, registry cluster 1 is deployed in a local data center (data center 1) and a remote data center (data center 2). Registry cluster 1 includes three registry instances, two of which are deployed in the local data center and the other in the remote data center. In this step, the registry proxy cluster configures the addresses of the three registry instances in registry cluster 1, prioritizing the address of the registry instance deployed in the local data center, or assigning priority to the address of the registry instance deployed in the local data center.

[0086] Correspondingly, Registry Center Cluster 2 is deployed in a local data center (Data Center 1) and a remote data center (Data Center 2). Registry Center Cluster 2 includes three registry center instances, two of which are deployed in the remote data center and the other is deployed in the local data center.

[0087] Step 602: Load information for all instances in the entire registry cluster. During the startup process of the registry agent service, information for all instances in the dual registry cluster is loaded, with the registry instance in the local center being accessed first.

[0088] like Figure 7 The diagram shown is a structural schematic of a microservice information dual-write device based on a dual registry center, according to an embodiment of this specification. The diagram illustrates the basic structure of the device. The functional units and modules can be implemented in software, or using general-purpose chips or specific chips to implement microservice information dual-write based on a dual registry center. The device specifically includes:

[0089] The receiving unit 701 is used to receive requests initiated by microservice applications;

[0090] The dual-write unit 702 is used to synchronously write the request to each registration center cluster;

[0091] The microservice information receiving unit 703 is used to receive microservice information returned by each registry cluster;

[0092] The determination unit 704 is used to determine whether the request initiated by the microservice application has been responded to based on the returned microservice information.

[0093] Compared to existing methods for synchronizing multiple registry centers, this manual provides a registry center proxy service that performs dual writes to two registry center clusters. This results in higher real-time performance, fewer accesses to the existing clusters, and avoids performance degradation caused by synchronization. In addition, this method periodically compares the microservice information of the two registry center clusters, provides real-time alerts for abnormal registry center cluster information, and removes abnormal registry center addresses from the registry center proxy cluster, thereby improving the availability of the registry center cluster.

[0094] As one embodiment of this specification, reference may also be made to, for example, Figure 8 The diagram shown is a schematic representation of the microservice information dual-write device based on dual registration centers in this embodiment.

[0095] As one embodiment of this specification, the microservice information receiving unit 703 further includes:

[0096] The first judgment module 7031 is used to determine whether the priority registration center cluster returns microservice information;

[0097] The second judgment module 7032 is used to determine whether all registry center clusters return microservice information;

[0098] The service comparison module 7033 is used to periodically retrieve microservice information from each registry cluster within a preset period.

[0099] Figure 9 The diagram illustrates a service retrieval request initiated by a microservice application according to an embodiment of this specification. In the diagram, the registry proxy cluster continuously assesses the microservice information returned by the two registry clusters. If the primary registry cluster does not return microservice information, it returns an error indicating a retrieval failure to the microservice application. If the primary registry cluster returns microservice information, it returns the information to the microservice application's registry.

[0100] Figure 10 The diagram illustrates a microservice application initiating a renewal request according to an embodiment of this specification. In the diagram, the registry proxy cluster continuously evaluates the microservice information returned by the two registry clusters. If one registry cluster fails to renew the service, it returns a renewal failure error to the microservice application; if both registry clusters successfully renew the service, it returns a renewal success message to the microservice application.

[0101] Figure 11The diagram illustrates a comparative service in one embodiment of this specification. By analyzing abnormal results, abnormal registry clusters are removed from the registry proxy cluster. When a microservice application requests a registry proxy, the registry proxy cluster, which previously handled two registry clusters, now only forwards requests to one registry cluster. The bold line in the diagram indicates this step. Through the processing described in this specification, situations where a registry cluster becomes "dead" can be detected promptly, thereby preventing microservice applications from fetching incorrect microservice information.

[0102] like Figure 12 The diagram illustrates a computer device provided in an embodiment of this specification. The microservice information dual-write method based on dual registry centers described in this specification can be applied to the computer device. The computer device 1202 may include one or more processors 1204, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 1202 may also include any memory 1206 for storing information of any kind, such as code, settings, data, etc. Without limitation, for example, memory 1206 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 1202. In one case, when processor 1204 executes associated instructions stored in any memory or combination of memories, the computer device 1202 can perform any operation of the associated instructions. The computer device 1202 also includes one or more drive mechanisms 1208 for interacting with any memory, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0103] Computer device 1202 may also include an input / output module 1210 (I / O) for receiving various inputs (via input device 1212) and providing various outputs (via output device 1214). A specific output mechanism may include a presentation device 1216 and an associated graphical user interface (GUI) 1218. In other embodiments, the input / output module 1210 (I / O), input device 1212, and output device 1214 may be omitted, and the device may function solely as a computer device within a network. Computer device 1202 may also include one or more network interfaces 1220 for exchanging data with other devices via one or more communication links 1222. One or more communication buses 1224 couple the components described above together.

[0104] Communication link 1222 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 1222 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0105] Corresponding to Figures 2 to 6 In addition to the methods described above, embodiments of this specification also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the methods described above.

[0106] This specification also provides computer-readable instructions, wherein when a processor executes the instructions, the program therein causes the processor to perform the following... Figures 2 to 6 The method shown.

[0107] It should be understood that in the various embodiments of this specification, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0108] It should also be understood that, in the embodiments of this specification, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this specification generally indicates that the preceding and following related objects have an "or" relationship.

[0109] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this specification.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this specification, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, or they may be electrical, mechanical, or other forms of connection.

[0112] 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 network units. Some or all of the units can be selected to achieve the purpose of the embodiments described in this specification, depending on actual needs.

[0113] Furthermore, the functional units in the various embodiments of this specification 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.

[0114] 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 this specification, 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 this specification. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] This specification uses specific embodiments to illustrate the principles and implementation methods of this specification. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this specification. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this specification. Therefore, the content of this specification should not be construed as a limitation of this specification.

Claims

1. A microservice information dual-write system based on dual registration centers, characterized in that, The system includes: A dual registry cluster consists of multiple registry instances, with some instances deployed in the local data center and the remaining instances deployed in a remote data center. A dual-registry center proxy cluster communicates with the dual-registry center cluster. Each registry center proxy cluster is deployed in a separate data center to receive requests initiated by microservice applications and synchronously write the requests to both registry center clusters. It also receives microservice information returned by each registry center cluster and determines whether the requests initiated by the microservice applications have received a response based on the returned microservice information. The system consists of two data centers: a local data center and a remote data center. Each data center deploys a registry agent cluster.

2. The microservice information dual-write system based on dual registration centers according to claim 1, characterized in that, Based on the arrangement order of the address information of multiple registration center instances recorded in the configuration file of the registration center agent cluster, the priority registration center cluster of the local data center is determined.

3. A microservice information dual-write method based on dual registration centers, characterized in that, The method is applied to the dual-registration-center proxy cluster in the microservice information dual-write system based on dual registration centers as described in any one of claims 1-2, including: Receive requests initiated by microservice applications; The request is synchronously written to each registration center cluster; Receive microservice information returned by each registry cluster; Based on the returned microservice information, determine whether the request initiated by the microservice application has been responded to.

4. The microservice information dual-write method based on dual registration centers according to claim 3, characterized in that, When the request initiated by the microservice application is a service fetch request, determining whether the request initiated by the microservice application has received a response based on the returned microservice information includes: Determine whether the priority registry cluster returns microservice information; If so, confirm that the priority registration center cluster is running normally, and send the microservice information of the priority registration center cluster to the microservice application; If not, determine that the priority registration center cluster is malfunctioning and send an error message indicating that the service retrieval failed to the microservice application.

5. The microservice information dual-write method based on dual registration centers according to claim 3, characterized in that, When the request initiated by the microservice application is a timed renewal request, determining whether the request initiated by the microservice application has received a response based on the returned microservice information includes: Determine whether all registry center clusters return microservice information; If so, confirm successful renewal and send a successful renewal message to the microservice application; If not, confirm that the renewal failed and send a renewal failure error message to the microservice application.

6. The microservice information dual-write method based on dual registration centers according to claim 3, characterized in that, The receipt of microservice information returned by each registration center cluster further includes: Retrieve microservice information from each registry cluster at preset intervals; Compare whether the microservice information of each registry cluster is consistent; If not, compare the microservice information of each registry cluster with the microservice information of the previous period in the current period to determine whether the microservice information of each registry cluster has changed. If so, the clusters that have not changed are identified as abnormal clusters, and the clusters that have changed are identified as normal clusters; Remove the abnormal cluster and send the requests initiated by the microservice application to the normal cluster.

7. The microservice information dual-write method based on dual registration centers according to claim 6, characterized in that, The method further includes: When the dual registry agent cluster receives microservice information returned by the dual registry cluster, the microservice information returned by the priority registry cluster is read first.

8. The microservice information dual-write method based on dual registration centers according to claim 7, characterized in that, When the registry agent cluster starts, the method further includes: Configure the addresses of all registry clusters, prioritizing the instance addresses of the local registry cluster. Load information about all instances in all registry clusters.

9. A microservice information dual-write device based on dual registration centers, characterized in that, The device employs the method according to any one of claims 3 to 8, comprising: The receiving unit is used to receive requests initiated by microservice applications; The dual-write unit is used to synchronously write the request to each registration center cluster. The microservice information receiving unit is used to receive microservice information returned by each registry cluster; The determination unit is used to determine whether a request initiated by a microservice application has been responded to, based on the returned microservice information.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 3 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method according to any one of claims 3 to 8.

Images