Multi-activity system and method based on cloud native

Abstract

The invention relates to a multi-activity system and method based on cloud native, the system comprises a plurality of data centers which are logically isolated, and each of the plurality of data centers is deployed with a plurality of load balancing nodes, a plurality of gateway nodes and a plurality of database nodes which are realized based on cloud native; wherein a plurality of load balancing nodes deployed on each data center form a load balancing node cluster crossing a plurality of data centers; a plurality of gateway nodes deployed on each data center form a gateway node cluster crossing a plurality of data centers; a plurality of database nodes deployed on each data center form a database node cluster crossing a plurality of data centers. In this way, independent deployment does not need to be carried out on each data center, stock services do not need to be transformed, and therefore the effect of reducing the construction cost and the deployment difficulty can be achieved.

Description

Technical Field

[0001] The present application relates to the technical field of data backup and disaster recovery, and in particular to a multi-active system and method based on cloud native. Background Art

[0002] With the continuous development of data backup and disaster recovery technologies, solutions that use multiple data centers to achieve high availability across data centers have emerged and have been widely used in many fields.

[0003] In the related art, multiple physically isolated data centers are usually deployed in different physical areas, and then the services or resources in multiple data centers are unitized (i.e., set) to achieve high availability across data centers. However, this solution requires the deployment of physically isolated related hardware in each data center and the transformation of a large number of existing services, which leads to high construction costs and great deployment difficulties. Summary of the invention

[0004] The present application provides a cloud-native based multi-active system and method to solve the problems of high construction cost and difficult deployment of high-availability solutions across data centers in related technologies.

[0005] In a first aspect, an embodiment of the present application provides a multi-active system based on cloud native, the system comprising a plurality of logically isolated data centers, each of the plurality of data centers being deployed with a plurality of load balancing nodes, a plurality of gateway nodes, and a plurality of database nodes based on cloud native implementation;

[0006] The multiple load balancing nodes deployed on each data center form a load balancing node cluster across the multiple data centers, and the load balancing node cluster is used to perform load balancing distribution on service requests accessing the multiple data centers;

[0007] The multiple gateway nodes deployed on each data center form a gateway node cluster across the multiple data centers, and the gateway node cluster is used to receive the service request and forward the service request to a target service instance matching the service request in a target data center, wherein the target data center is a data center among the multiple data centers that is closest to the gateway node receiving the service request;

[0008] The multiple database nodes deployed on each data center form a database node cluster across the multiple data centers, and the database node cluster is used to respond to the target service instance to perform data read and write operations to obtain a response result corresponding to the service request.

[0009] Optionally, each of the multiple data centers is further deployed with multiple service registration nodes based on cloud native implementation;

[0010] The multiple service registration nodes deployed on each data center form a service registration node cluster across the multiple data centers, and the service registration node cluster is used to receive a query request sent by the gateway node, and return the identification information of the target service instance and the candidate data center where the target service instance is set in response to the query request, wherein the query request carries the service request;

[0011] The gateway node cluster is further used to determine the target data center from the candidate data centers and forward the service request to the target service instance in the target data center.

[0012] Optionally, the target service instance is set in other data centers among the multiple data centers except the target data center, and the gateway node cluster is used to forward the service request to the target service instance in other data centers when the target service instance in the target data center fails.

[0013] Optionally, each of the multiple data centers is further deployed with multiple management nodes and multiple working nodes based on cloud native implementation;

[0014] The multiple management nodes deployed on each data center form a management node cluster across the multiple data centers, and the multiple working nodes deployed on each data center form a working node cluster across the multiple data centers;

[0015] The management node cluster is used to receive configuration files and service images pushed by the publishing system, and determine the directional scheduling results of each service based on the configuration files, and start the service instances of each service on the directed working nodes based on the directional scheduling results of each service and the service images, wherein the configuration files are pre-configured with declaration information corresponding to each service, and the declaration information corresponding to the same service declares that the working nodes used to start their own service instances belong to different data centers, and each working node in the working node cluster is used to provide the resources required to start the service instance. Optionally, the working nodes in the working node cluster belonging to the same data center have the same label information, and the working nodes in different data centers have different label information;

[0016] The management node cluster is used to determine the tag information selected by each service according to the polling strategy, and to determine the directional scheduling result according to the tag information selected by each service and the declaration information corresponding to each service in the configuration file, wherein the directional scheduling result is used to characterize the data center to which the working node that starts the service instance of each service belongs.

[0017] Optionally, the database node cluster includes a primary database node and multiple standby database nodes;

[0018] The master database node performs read and write operations on data, each of the multiple standby database nodes supports read operations on data, and the data on the master database node is kept synchronized with the data on the multiple standby database nodes.

[0019] Optionally, the database node cluster is used to utilize a primary database node or a standby database node of the target data center to perform a data read operation in response to the target service instance performing a data read operation.

[0020] In a second aspect, an embodiment of the present application further provides a multi-active method based on cloud native, which is applied to the multi-active system based on cloud native in the first aspect, and the method includes:

[0021] The load balancing node cluster performs load balancing distribution on service requests accessing multiple data centers;

[0022] The gateway node cluster receives the service request and forwards the service request to a target service instance matching the service request in a target data center, wherein the target data center is a data center among the multiple data centers that is closest to the gateway node that receives the service request;

[0023] The database node cluster performs data read and write operations in response to the target service instance, and obtains a response result corresponding to the service request.

[0024] Optionally, each of the multiple data centers is further deployed with multiple service registration nodes based on cloud native implementation, wherein the multiple service registration nodes deployed on each data center form a service registration node cluster across the multiple data centers;

[0025] The gateway node cluster receives the service request and forwards the service request to a target service instance matching the service request in a target data center, including:

[0026] The gateway node cluster receives the service request, determines the target data center from the candidate data centers, and forwards the service request to the target service instance in the target data center, wherein the candidate data center is returned by the service registration node cluster in response to a query request sent by the gateway node.

[0027] Optionally, each of the multiple data centers is further deployed with multiple management nodes and multiple working nodes based on cloud native implementation, wherein the multiple management nodes deployed on each data center constitute a management node cluster spanning the multiple data centers, and the multiple working nodes deployed on each data center constitute a working node cluster spanning the multiple data centers; the method further includes:

[0028] The management node cluster receives the configuration files and service images pushed by the publishing system, determines the directional scheduling results of each service according to the configuration files, and starts the service instances of each service on the directed working nodes according to the directional scheduling results of each service and the service images, wherein the configuration files are pre-configured with declaration information corresponding to each service, and the declaration information corresponding to the same service declares that the working nodes used to start their own service instances belong to different data centers, and each working node in the working node cluster is used to provide resources required to start the service instance.

[0029] The cloud-native-based multi-active system provided in an embodiment of the present application includes multiple logically isolated data centers, and each of the multiple data centers is deployed with multiple load balancing nodes, multiple gateway nodes and multiple database nodes based on cloud native implementation; wherein the multiple load balancing nodes deployed on each data center constitute a load balancing node cluster across the multiple data centers, and the load balancing node cluster is used to load balance the service requests accessing the multiple data centers; the multiple gateway nodes deployed on each data center constitute a gateway node cluster across the multiple data centers, and the gateway node cluster is used to receive the service request and forward the service request to a target service instance matching the service request in a target data center, wherein the target data center is the data center among the multiple data centers that is closest to the gateway node that receives the service request; the multiple database nodes deployed on each data center constitute a database node cluster across the multiple data centers, and the database node cluster performs data read and write operations in response to the target service instance to obtain a response result corresponding to the service request. Since the multiple load balancing nodes, multiple gateway nodes, and multiple database nodes deployed on each data center are all implemented based on cloud native, the load balancing node cluster composed of the load balancing nodes, the gateway node cluster composed of the gateway nodes, and the database node cluster composed of the database nodes all have the ability to span multiple data centers without the need for independent deployment for each data center and the need to transform existing services, thereby reducing construction costs and deployment difficulty. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0031] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0032] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0033] Figure 1 A schematic diagram of the structure of a cloud-native multi-active system provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of the construction phase of a cloud-native same-city active-active system provided in an embodiment of the present application;

[0035] Figure 3 An overall architecture diagram of an insurance business same-city active-active system provided in an embodiment of the present application;

[0036] Figure 4 A flowchart of a cloud-native multi-active method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0038] The disclosure below provides many different embodiments or examples to realize the different structures of the present application. In order to simplify the disclosure of the present application, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present application. In addition, the present application can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0039] In order to solve the problem of high construction cost and difficult deployment of high-availability solutions across data centers in related technologies, the present application provides a cloud-native based multi-active system and method that can reduce construction cost and deployment difficulty.

[0040] See also Figure 1 , Figure 1 A schematic diagram of a multi-active system based on cloud native provided in an embodiment of the present application. Figure 1 As shown, the multi-active system based on cloud native may include multiple logically isolated data centers 100, and each of the multiple data centers 100 is deployed with multiple load balancing nodes 1101, multiple gateway nodes 1201 and multiple database nodes 1301 based on cloud native implementation;

[0041] Among them, Availability Zone (AZ) refers to the data center of a cloud service provider in a geographical area. Each availability zone is an independent data center with its own power, cooling and network resources, and is designed to provide redundancy and fault tolerance.

[0042] Multiple load balancing nodes 1101 deployed on each data center 100 form a load balancing node cluster 110 across multiple data centers 100. The load balancing node cluster 110 is used to perform load balancing distribution on service requests accessing multiple data centers 100.

[0043] The multiple gateway nodes 1201 deployed on each data center 100 form a gateway node cluster 120 across multiple data centers 100. The gateway node cluster 120 is used to receive a service request and forward the service request to a target service instance matching the service request in a target data center, wherein the target data center is a data center 100 among the multiple data centers 100 that is closest to the gateway node 1201 receiving the service request.

[0044] The multiple database nodes 1301 deployed on each data center 100 form a database node cluster 130 across multiple data centers 100. The database node cluster 130 is used to respond to the target service instance to perform data read and write operations and obtain a response result corresponding to the service request.

[0045] Specifically, the above-mentioned cloud native (i.e. Cloud Native) is a software development concept and methodology that aims to make full use of the elasticity, scalability and distributed characteristics of the cloud computing environment to improve the speed, stability and reliability of software delivery, while reducing costs and improving efficiency. Cloud native is not just about migrating applications to the cloud, but about rethinking and designing applications to adapt to a dynamic, elastic and distributed cloud environment. The above-mentioned multi-active system is a distributed system architecture in which multiple data centers provide services to the outside world at the same time, and the service status of each data center is the same, and can respond to user requests in real time. This architecture has the characteristics of high availability, fault tolerance and load balancing, and is particularly suitable for scenarios that require extremely high availability and low latency.

[0046] It should be noted that the number of data centers 100 in the multi-active system can be 2, 3, 4, etc., which can be set according to actual business needs, and this application does not make specific restrictions. Among them, the number of load balancing nodes 1101, the number of gateway nodes 1201, and the number of database nodes 1301 deployed on each data center 100 can also be set according to actual needs, and this application does not make specific restrictions.

[0047] All load balancing nodes 1101 deployed on each data center 100 can form a load balancing node cluster 110 across multiple data centers 100, that is, the load balancing nodes 1101 in different data centers do not need to be physically isolated, but only need to be logically isolated. The load balancing node cluster 110 can be used to load balance the service requests accessing multiple data centers 100, such as distributing the service requests according to load balancing strategies such as polling, weighted polling, least connection, random, etc., to improve safe and fast traffic distribution services.

[0048] All gateway nodes 1201 deployed on each data center 100 can form a gateway node cluster 120 across multiple data centers 100, that is, the gateway nodes 1201 in different data centers do not need to be physically isolated, but only need to be logically isolated. The gateway node cluster 120 can be used to receive a service request and forward the service request to a target service instance matching the service request in a target data center that is closest to the gateway node 1201 receiving the service request.

[0049] All database nodes 1301 deployed on each data center 100 can form a database node cluster 130 across multiple data centers 100, that is, the database nodes 1301 in different data centers do not need to be physically isolated, but only need to be logically isolated. The database node cluster 130 can be used to respond to the target service instance to perform data read and write operations and obtain a response result corresponding to the service request. The response result is then returned to the corresponding gateway node 1201 and transmitted to the user, thereby realizing business access and processing.

[0050] In this embodiment, since the multiple load balancing nodes, multiple gateway nodes and multiple database nodes deployed on each data center are all implemented based on cloud native, the load balancing node cluster composed of the load balancing nodes, the gateway node cluster composed of the gateway nodes, and the database node cluster composed of the database nodes all have the ability to span multiple data centers without the need for independent deployment for each data center and the need to transform existing services, thereby achieving the effect of reducing construction costs and deployment difficulty.

[0051] Further, see Figure 1 , each of the multiple data centers 100 is also deployed with multiple service registration nodes 1401 based on cloud native implementation;

[0052] Among them, multiple service registration nodes 1401 deployed on each data center 100 form a service registration node cluster 140 across multiple data centers 100, and the service registration node cluster 140 is used to receive the query request sent by the gateway node 1201, and return the identification information of the target service instance and the candidate data center where the target service instance is set in response to the query request, wherein the query request carries the service request;

[0053] The gateway node cluster 120 is further configured to determine a target data center from the candidate data centers and forward the service request to a target service instance in the target data center.

[0054] Specifically, the number of service registration nodes 1401 deployed on each data center 100 can be set according to actual needs, and this application does not make specific restrictions. All service registration nodes 1401 deployed on each data center 100 can form a service registration node cluster 140 across multiple data centers 100, that is, the service registration nodes 1401 in different data centers do not require physical isolation, but only need to be logically isolated. The service registration node cluster 140 can be used to receive a query request sent by the gateway node 1201, and in response to the query request, return the identification information (such as name, type, etc.) of the target service instance corresponding to the service request and the candidate data center where the target service instance is set. At this time, the gateway node cluster 120 can also be used to determine the target data center from the candidate data centers, and forward the service request to the target service instance in the target data center.

[0055] For example, assuming that the target service instance corresponding to a service request is service instance A, and only data center 1 and data center 2 are equipped with the service instance A among data center 1, data center 2 and data center 3, and when registering the service, this information has been pre-stored in the service registration node, so that the service registration node cluster can respond to the service request and return service instance A and data center 1 and data center 2 equipped with service instance A to the corresponding gateway node. In this way, when the gateway node receives information such as service instance A and data center 1 and data center 2 equipped with service instance A, it can determine the target data center closest to itself from data center 1 and data center 2, and forward the service request to the target service instance in the target data center.

[0056] In this embodiment, the service registration node can be used to achieve local access to the service, and cross-data center calls can be avoided as much as possible, thereby reducing response time and improving response efficiency.

[0057] Furthermore, target service instances are set in other data centers among the multiple data centers 100 except the target data center, and the gateway node cluster 120 is used to forward service requests to target service instances in other data centers when the target service instance in the target data center fails.

[0058] It should be noted that since the same service usually has equivalent service instances in multiple data centers, there may be cross-data center calls. If most of the calls are to cross data centers, the response time will increase significantly, which will have a serious impact on performance and user experience. Therefore, local access is required to reduce cross-data center calls. In other words, the service request initiated is preferentially provided by the service instance of the data center where the initiator is located to reduce cross-data center calls. However, when the service instance of the data center where the initiator is located (equivalent to the target data center) is unavailable, the service instances of other data centers can be accessed to ensure that the service can be called normally. It can be understood that the service instance of the data center where the initiator is located is determined as the target service instance in the target data center closest to itself. When there is no available service instance in the data center where the initiator is located, the available service instances in other data centers are used as the target service instances in the target data center.

[0059] Further, see Figure 1 , each of the multiple data centers 100 is further deployed with multiple management nodes 1501 and multiple working nodes 1601 based on cloud native implementation;

[0060] Among them, multiple management nodes 1501 deployed on each data center 100 form a management node cluster 150 across multiple data centers 100, and multiple working nodes 1601 deployed on each data center 100 form a working node cluster 160 across multiple data centers 100;

[0061] The management node cluster 150 is used to receive the configuration files and service images pushed by the publishing system, and determine the directional scheduling results of each service according to the configuration files, and start the service instances of each service on the directed working nodes 1601 according to the directional scheduling results and service images of each service, wherein the declaration information corresponding to each service is pre-configured in the configuration file, and the working nodes 1601 declared in the declaration information corresponding to the same service for starting their own service instances belong to different data centers 100, and each working node 1601 in the working node cluster 160 is used to provide the resources required to start the service instance. Specifically, the number of management nodes 1501 and working nodes 1601 deployed on each data center 100 can be set according to actual needs, and this application does not make specific restrictions. All management nodes 1501 deployed on each data center 100 can form a management node cluster 150 across multiple data centers 100, that is, the management nodes 1501 in different data centers do not require physical isolation, but only need to be logically isolated. All the working nodes 1601 deployed on each data center 100 can form a working node cluster 160 across multiple data centers 100, that is, the working nodes 1601 in different data centers do not need to be physically isolated, but only need to be logically isolated. The management node cluster 150 and the working node cluster 160 can be implemented based on the container orchestration platform Kubernetes (abbreviated as K8S), which can be used for container service orchestration and management.

[0062] The management node cluster 150 can be used to receive configuration files and service images pushed by the publishing system, and determine the directional scheduling results of each service based on the configuration files, and then start the service instances of each service on the directed working node 1601 based on the directional scheduling results and service images of each service. Among them, the declaration information corresponding to each service (i.e., Deployment) is pre-configured in the configuration file here. The data center to which the working node 1601 used to start its own service instance declared in the declaration information corresponding to the same service belongs is different. It should be noted that the Deployment here is an application programming interface (Application Programming Interface, referred to as API) object of Kubernetes, which can provide a declarative update method. The desired application state can be described through Deployment, such as which image version should be deployed and how many copies of the application should have, so that the Deployment controller will change the actual state to match the declared expected state.

[0063] In this embodiment, directional scheduling of services can be achieved through the management node to ensure that there are surviving service instances in each data center.

[0064] Further, the working nodes 1601 belonging to the same data center in the working node cluster 160 have the same label information, and the working nodes 1601 belonging to different data centers have different label information;

[0065] The management node cluster 150 is used to determine the label information selected by each service according to the polling strategy, and to determine the directed scheduling result according to the label information selected by each service and the declaration information corresponding to each service in the configuration file, wherein the directed scheduling result is used to represent the data center to which the working node 1601 that starts the service instance of each service belongs.

[0066] Since the working nodes 1601 belonging to the same data center have the same label information, and the working nodes 1601 belonging to different data centers have different label information, the working nodes 1601 of different data centers can be distinguished according to the label information. After the management node 1501 in the management node cluster 150 determines the label information selected by each service according to the polling strategy, the data center to which the working node 1601 that starts the service instance of each service belongs can be determined according to the label information selected by each service and the declaration information corresponding to each service in the configuration file, and then the service instance can be started on the working node 1601 of the corresponding data center.

[0067] As an optional implementation, two independent deployments are set up for the same service to control service instances in different data centers respectively, and the node selector is used to solve this problem. The specific solution is as follows:

[0068] 1) Each service uses an independent deployment in different data centers. Although the service code and functions are exactly the same and logically it is one service, in fact, the underlying K8S is physically independent and behaves as different services.

[0069] 2) The working nodes are grouped according to data centers, and the working nodes of different data centers are labeled with different labels. For example, the working nodes of data center 1 are labeled with zone=idc1, and the working nodes of data center 2 are labeled with zone=idc2.

[0070] 3) Use K8S's node selector in the deployment to specify which worker nodes to start the service instance on. For example, if the node selector label set on the deployment of data center 1 is idc1, then the service instance of the deployment will only be started on the worker node labeled idc1 (that is, the worker node of data center 1), and so on.

[0071] This directional scheduling solution ensures that services in different data centers have a preset number of service instances and will not affect each other.

[0072] Further, the database node cluster 130 includes a primary database node and a plurality of standby database nodes;

[0073] The primary database node performs read and write operations on data, each of the multiple standby database nodes supports read operations on data, and the data on the primary database node is synchronized with the data on the multiple standby database nodes.

[0074] Specifically, the database node cluster 130 is built in a master-slave mode, with the master database node and the standby database node deployed in different data centers respectively. Real-time data synchronization is achieved through the master-slave database technology, and each data center has full data. No matter which data center's service writes data to the database node, it only writes to the same master database node to avoid data conflicts caused by multiple writes.

[0075] In this way, data conflicts can be reduced, complexity can be reduced, and it can be ensured that when a data center fails, another data center can take over the traffic without loss.

[0076] Furthermore, the database node cluster 130 is used to perform the data read operation using the primary database node or the standby database node of the target data center in response to the target service instance performing the data read operation.

[0077] In this way, when the primary database node or the standby database node performs data read operations, the target service instance of the nearest data center can be used to minimize cross-data center read operations, thereby reducing the impact on performance.

[0078] In order to better illustrate that the cloud-native multi-active system provided in the embodiment of the present application can reduce the construction cost and deployment difficulty, the cloud-native dual-active system in the same city is used as an example for explanation. When building a cloud-native dual-active system in the same city, the following five stages are mainly involved, such as Figure 2 As shown:

[0079] 1) Preparation stage: This stage mainly involves program and technical research and testing to determine feasibility.

[0080] 2) Infrastructure construction stage: This stage mainly focuses on sorting out system links to ensure that the cloud products used in the links support multi-data center deployment and that multi-data center deployment is already in place in actual deployment.

[0081] 3) Service transformation stage: This stage is the core and includes the following transformation work:

[0082] a) Identify and promote latency-sensitive service transformation: Identify latency-sensitive services and transform them (generally changing synchronous processing to asynchronous processing, serial processing to parallel processing, etc.) to reduce the impact. Generally, this can be analyzed through the full-link system.

[0083] b) Identify and promote single-point service transformation: To achieve active-active dual-service, services must be deployed in multiple instances. This step is to find single-point services that do not support multi-instance deployment and transform them (generally from stateful services to stateless services, etc.).

[0084] c) Publishing system transformation: mainly to implement the same service in the publishing system, use independent deployments to start service instances in different data centers, and dispatch service instances in different data centers to the working nodes on the corresponding data centers to achieve directional scheduling.

[0085] d) Service mesh local access transformation: To reduce cross-data center access, business services are transformed for local access, so that services give priority to calling service instances in the same data center. In order to reduce the cost of transformation, this solution uses servicemesh to achieve local access, that is, business services are connected to the service mesh, and local access is achieved through the service mesh. Other services connected to the service mesh automatically have local access capabilities.

[0086] 4) Deployment phase: This phase mainly involves adjusting systems and services from single data center deployment to multi-data center deployment.

[0087] a) Multi-active deployment of key components and systems: The key components and systems involved are shown in the following table:

[0088]

[0089]

[0090]

[0091] b) Database multi-active deployment: Adjust the database's active and standby nodes from the same data center to different data centers.

[0092] c) Multi-active deployment of services: Use the multi-deployment solution mentioned above to deploy services to different data centers.

[0093] 5) Exercise phase: mainly conducts data center-level fault exercises.

[0094] Through the above five stages, the construction of a cloud-native dual-active system in the same city can be realized. By using cloud-native capabilities, the system's data center-level multi-active can be achieved with extremely low resource and labor costs, and can be verified under normal conditions, greatly improving the system's disaster recovery capabilities.

[0095] For ease of understanding, here we take the insurance business's active-active system in the same city as an example to explain. The overall architecture of the system is as follows: Figure 3 As shown, the system includes an entry layer, a gateway layer, a business service layer, a basic service layer and a data layer. Among them, the entry layer can include multiple public network load balancers (Cloud Load Balancer, referred to as CLB), which form a load balancing node cluster across data center 1 and data center 2 (i.e., two logically isolated clusters). Regardless of which region the user accesses the load balancing node cluster, the user can use the same address to access it. Since the public network CLB is deployed in both data center 1 and data center 2, the failure of one of the data centers will not affect user access.

[0096] The gateway layer can include multiple different types of gateway nodes (i.e., cloud servers), which form a gateway node cluster across data center 1 and data center 2 (i.e., two logically isolated multi-active gateway clusters). The gateway nodes in each multi-active gateway cluster can be API gateways, cloud function gateways, border gateways, and B-side gateways, etc.

[0097] The business service layer can include multiple business service nodes, which form a cross-data center business service cluster (i.e., two logically isolated multi-active business service clusters). These business service nodes can be set according to the actual business needs of the insurance business, such as setting up business service nodes for insurance, renewal, payment, claims, user operations, etc. Since business services usually require peer instances in both data center 1 and data center 2, these business service nodes are deployed in both data center 1 and data center 2.

[0098] The basic service layer may include multiple basic service nodes, which form a cross-data center basic service cluster (i.e., two logically isolated multi-active basic service clusters). Each multi-active basic service cluster may include a unified service registration center, a distributed message center, a nearby access control center, a cloud K8S cluster, a configuration center, etc. The unified service registration center here can be understood as the service registration node mentioned above, which is used to store the registration information of various services on the corresponding data center. The distributed message center here is implemented using cloud TDMQ, and the message nodes are deployed across data centers. When one of the data centers fails, the message nodes in the normal data center can transparently receive service requests. The nearby access control center here can be understood as the management node mentioned above, which is used to receive the configuration files and service images pushed by the publishing system, and determine the directional scheduling results of each service according to the configuration files, and start the service instances of each service on the directed working nodes according to the directional scheduling results and service images of each service. The cloud K8S cluster here can be understood as the working node mentioned above, which is used to provide the resources required to start the service instance. Since basic services usually need to have peer instances in data center 1 and data center 2, these basic service nodes are deployed in data center 1 and data center 2. The entire basic service cluster appears to the outside world as a unified large cluster, and changes in service deployment are transparent to upper-level applications.

[0099] The data layer can include multiple database nodes, which form a database node cluster across data center 1 and data center 2 (i.e., two logically isolated cloud storage clusters). Each cloud storage cluster can be set up with a primary / backup database and object storage. The primary / backup databases span data centers, data is synchronized in real time, and can use the same virtual IP address (VIP) to provide services. The write point is unique and the read is close.

[0100] In this way, after the user initiates a service application, he can access the service application through any public network CLB, and then forward the service request to the gateway node through the public network CLB. After receiving the service request, the gateway node can determine the registration record of the service application through the unified service registration center, and determine the service instance of the data center closest to the user end through the nearest access control center, and then start the corresponding cloud K8S cluster node to call the service instance. In the process of calling the service instance, read and write operations on the database will be involved. When reading data, you can perform read operations on the primary database node or the backup database node of the data center closest to the user end; when writing data, you can perform write operations on the primary database node to achieve dual-active in the same city for insurance business.

[0101] The implementation process of the same-city active-active system for this insurance business is relatively simple. It only requires some deployment adjustments of systems, components and services. Because deployment adjustments are routine operations and do not involve changes in business logic, the process has low risk and has almost no impact on the business.

[0102] See also Figure 4 , Figure 4 A flowchart of a multi-active method based on cloud native is provided in an embodiment of the present application, such as Figure 4 As shown, the cloud-native-based multi-active method may include the following steps:

[0103] Step 401: The load balancing node cluster performs load balancing distribution on service requests accessing multiple data centers;

[0104] Step 402: The gateway node cluster receives the service request and forwards the service request to a target service instance in a target data center that matches the service request, wherein the target data center is a data center among multiple data centers that is closest to the gateway node that receives the service request;

[0105] Step 403: The database node cluster performs data read and write operations in response to the target service instance, and obtains a response result corresponding to the service request.

[0106] It should be noted that the number of data centers in the multi-active system can be 2, 3, 4, etc., which can be set according to actual business needs, and this application does not make specific restrictions. Among them, the number of load balancing nodes, the number of gateway nodes, and the number of database nodes deployed in each data center can also be set according to actual needs, and this application does not make specific restrictions.

[0107] All load balancing nodes deployed in each data center can form a load balancing node cluster across multiple data centers, that is, the load balancing nodes in different data centers do not need to be physically isolated, but only need to be logically isolated. The load balancing node cluster can be used to load balance service requests accessing multiple data centers, such as distributing service requests according to load balancing strategies such as polling, weighted polling, least connection, random, etc., to improve safe and fast traffic distribution services.

[0108] All gateway nodes deployed in each data center can form a gateway node cluster across multiple data centers, that is, the gateway nodes in different data centers do not need to be physically isolated, but only need to be logically isolated. The gateway node cluster can be used to receive service requests and forward the service requests to the target service instance that matches the service request in the target data center closest to the gateway node receiving the service request.

[0109] All database nodes deployed in each data center can form a database node cluster across multiple data centers, that is, the database nodes in different data centers do not need to be physically isolated, but only need to be logically isolated. The database node cluster can be used to respond to the target service instance to perform data read and write operations and obtain the response result corresponding to the service request. The response result is then returned to the corresponding gateway node and transmitted to the user, thereby realizing business access and processing.

[0110] In this embodiment, since the multiple load balancing nodes, multiple gateway nodes and multiple database nodes deployed on each data center are all implemented based on cloud native, the load balancing node cluster composed of the load balancing nodes, the gateway node cluster composed of the gateway nodes, and the database node cluster composed of the database nodes all have the ability to span multiple data centers without the need for independent deployment for each data center and the need to transform existing services, thereby achieving the effect of reducing construction costs and deployment difficulty.

[0111] Furthermore, multiple service registration nodes based on cloud native implementation are deployed on each of the multiple data centers, wherein the multiple service registration nodes deployed on each data center form a service registration node cluster across multiple data centers;

[0112] The above step 402, in which the gateway node cluster receives the service request and forwards the service request to a target service instance in the target data center that matches the service request, includes:

[0113] The gateway node cluster receives the service request, determines a target data center from the candidate data centers, and forwards the service request to the target service instance in the target data center, wherein the candidate data center is returned by the service registration node cluster in response to the query request sent by the gateway node.

[0114] Specifically, the number of service registration nodes deployed on each data center can be set according to actual needs, and this application does not make specific restrictions. All service registration nodes deployed on each data center can form a service registration node cluster across multiple data centers, that is, the service registration nodes in different data centers do not require physical isolation, but only need to be logically isolated. The service registration node cluster can be used to receive query requests sent by the gateway node, and in response to the query request, return the identification information (such as name, type, etc.) of the target service instance corresponding to the service request and the candidate data center where the target service instance is set. At this time, the gateway node cluster can also be used to determine the target data center from the candidate data centers, and forward the service request to the target service instance in the target data center.

[0115] For example, assuming that the target service instance corresponding to a service request is service instance A, and only data center 1 and data center 2 are equipped with the service instance A among data center 1, data center 2 and data center 3, and when registering the service, this information has been pre-stored in the service registration node, so that the service registration node cluster can respond to the service request and return service instance A and data center 1 and data center 2 equipped with service instance A to the corresponding gateway node. In this way, when the gateway node receives information such as service instance A and data center 1 and data center 2 equipped with service instance A, it can determine the target data center closest to itself from data center 1 and data center 2, and forward the service request to the target service instance in the target data center.

[0116] In this embodiment, the service registration node can be used to achieve local access to the service, and cross-data center calls can be avoided as much as possible, thereby reducing response time and improving response efficiency.

[0117] Furthermore, each of the multiple data centers is further deployed with multiple management nodes and multiple working nodes based on cloud native implementation, wherein the multiple management nodes deployed on each data center constitute a management node cluster spanning multiple data centers, and the multiple working nodes deployed on each data center constitute a working node cluster spanning multiple data centers; the method further includes:

[0118] The management node cluster receives the configuration file and service image pushed by the publishing system, and determines the directional scheduling results of each service according to the configuration file, and starts the service instance of each service on the directed working node according to the directional scheduling results and service images of each service, wherein the declaration information corresponding to each service is pre-configured in the configuration file, and the data center to which the working node declared in the declaration information corresponding to the same service for starting its own service instance belongs is different, and each working node in the working node cluster is used to provide the resources required to start the service instance. Specifically, the number of management nodes and working nodes deployed on each data center can be set according to actual needs, and this application does not make specific restrictions. All management nodes deployed on each data center can form a management node cluster across multiple data centers, that is, the management nodes in different data centers do not require physical isolation, but only logical isolation. All working nodes deployed on each data center can form a working node cluster across multiple data centers, that is, the working nodes in different data centers do not require physical isolation, but only logical isolation. The management node cluster and the working node cluster can be implemented based on the container orchestration platform Kubernetes (abbreviated as K8S), and Kubernetes can be used for container service orchestration and management.

[0119] The management node cluster can be used to receive configuration files and service images pushed by the publishing system, and determine the directional scheduling results of each service based on the configuration files, and then start the service instances of each service on the directed working nodes based on the directional scheduling results and service images of each service. Among them, the declaration information corresponding to each service (i.e., Deployment) is pre-configured in the configuration file here. The working nodes declared in the declaration information corresponding to the same service for starting their own service instances belong to different data centers. It should be noted that the Deployment here is an API object of Kubernetes, which can provide a declarative update method. The desired application state can be described through Deployment, such as which image version should be deployed and how many copies of the application should have, so that the Deployment controller will change the actual state to match the declared expected state.

[0120] In this embodiment, directional scheduling of services can be achieved through the management node to ensure that there are surviving service instances in each data center.

[0121] According to one aspect of the present application, a computer program product or a computer program is provided, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps of the above-mentioned cloud-native-based multi-active method.

[0122] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0123] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0124] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0125] The above description is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A multi-active system based on cloud native, characterized in that: The system includes a plurality of logically isolated data centers, each of which is deployed with a plurality of load balancing nodes, a plurality of gateway nodes, and a plurality of database nodes based on cloud native implementation; The multiple load balancing nodes deployed on each data center form a load balancing node cluster across the multiple data centers, and the load balancing node cluster is used to perform load balancing distribution on service requests accessing the multiple data centers; The multiple gateway nodes deployed on each data center form a gateway node cluster across the multiple data centers, and the gateway node cluster is used to receive the service request and forward the service request to a target service instance matching the service request in a target data center, wherein the target data center is a data center among the multiple data centers that is closest to the gateway node receiving the service request; The multiple database nodes deployed on each data center form a database node cluster across the multiple data centers, and the database node cluster is used to respond to the target service instance to perform data read and write operations to obtain a response result corresponding to the service request.

2. The system according to claim 1, characterized in that A plurality of service registration nodes based on cloud native implementation are also deployed on each of the plurality of data centers; The multiple service registration nodes deployed on each data center form a service registration node cluster across the multiple data centers, and the service registration node cluster is used to receive a query request sent by the gateway node, and return the identification information of the target service instance and the candidate data center where the target service instance is set in response to the query request, wherein the query request carries the service request; The gateway node cluster is further used to determine the target data center from the candidate data centers and forward the service request to the target service instance in the target data center.

3. The system according to claim 1, characterized in that The target service instance is set in other data centers among the multiple data centers except the target data center, and the gateway node cluster is used to forward the service request to the target service instance in other data centers when the target service instance in the target data center fails.

4. The system according to claim 1, characterized in that Multiple management nodes and multiple working nodes based on cloud native implementation are also deployed on each of the multiple data centers; The multiple management nodes deployed on each data center form a management node cluster across the multiple data centers, and the multiple working nodes deployed on each data center form a working node cluster across the multiple data centers; The management node cluster is used to receive configuration files and service images pushed by the publishing system, and determine the targeted scheduling results of each service based on the configuration files, and start the service instance of each service on the targeted working node based on the targeted scheduling results of each service and the service image, wherein the configuration file is pre-configured with declaration information corresponding to each service, and the declaration information corresponding to the same service declares that the working node used to start its own service instance belongs to a different data center, and each working node in the working node cluster is used to provide resources required to start the service instance.

5. The system according to claim 4, characterized in that The working nodes in the working node cluster belonging to the same data center have the same label information, and the working nodes in different data centers have different label information; The management node cluster is used to determine the tag information selected by each service according to the polling strategy, and to determine the directional scheduling result according to the tag information selected by each service and the declaration information corresponding to each service in the configuration file, wherein the directional scheduling result is used to characterize the data center to which the working node that starts the service instance of each service belongs.

6. The system according to claim 1, characterized in that The database node cluster includes a primary database node and multiple standby database nodes; The master database node performs read and write operations on data, each of the multiple standby database nodes supports read operations on data, and the data on the master database node is kept synchronized with the data on the multiple standby database nodes.

7. The system according to claim 1, characterized in that The database node cluster is used to utilize the primary database node or the standby database node of the target data center to perform the data read operation in response to the target service instance performing the data read operation.

8. A multi-active method based on cloud native, characterized in that: The method is applied to the multi-active system based on cloud native according to any one of claims 1 to 7, and the method comprises: The load balancing node cluster performs load balancing distribution on service requests accessing multiple data centers; The gateway node cluster receives the service request and forwards the service request to a target service instance matching the service request in a target data center, wherein the target data center is a data center among the multiple data centers that is closest to the gateway node that receives the service request; The database node cluster performs data read and write operations in response to the target service instance, and obtains a response result corresponding to the service request.

9. The method according to claim 8, characterized in that A plurality of service registration nodes based on cloud native implementation are also deployed on each of the plurality of data centers, wherein the plurality of service registration nodes deployed on each data center form a service registration node cluster across the plurality of data centers; The gateway node cluster receives the service request and forwards the service request to a target service instance matching the service request in a target data center, including: The gateway node cluster receives the service request, determines the target data center from the candidate data centers, and forwards the service request to the target service instance in the target data center, wherein the candidate data center is returned by the service registration node cluster in response to a query request sent by the gateway node.

10. The method according to claim 8, characterized in that Multiple management nodes and multiple working nodes based on cloud native implementation are also deployed on each of the multiple data centers, wherein the multiple management nodes deployed on each data center form a management node cluster across the multiple data centers, and the multiple working nodes deployed on each data center form a working node cluster across the multiple data centers; the method also includes: The management node cluster receives the configuration files and service images pushed by the publishing system, determines the directional scheduling results of each service according to the configuration files, and starts the service instances of each service on the directed working nodes according to the directional scheduling results of each service and the service images, wherein the configuration files are pre-configured with declaration information corresponding to each service, and the declaration information corresponding to the same service declares that the working nodes used to start their own service instances belong to different data centers, and each working node in the working node cluster is used to provide resources required to start the service instance.

Images