CN113766004A - Disaster recovery system, method and storage medium based on multi-cloud platform - Google Patents
Disaster recovery system, method and storage medium based on multi-cloud platform Download PDFInfo
- Publication number
- CN113766004A CN113766004A CN202110854627.3A CN202110854627A CN113766004A CN 113766004 A CN113766004 A CN 113766004A CN 202110854627 A CN202110854627 A CN 202110854627A CN 113766004 A CN113766004 A CN 113766004A
- Authority
- CN
- China
- Prior art keywords
- cloud platform
- public cloud
- layer
- user access
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 74
- 238000000034 method Methods 0.000 title claims abstract description 31
- 238000003860 storage Methods 0.000 title claims abstract description 13
- 238000012545 processing Methods 0.000 claims abstract description 52
- 238000009826 distribution Methods 0.000 claims description 20
- 238000012544 monitoring process Methods 0.000 claims description 14
- 230000008569 process Effects 0.000 claims description 13
- 230000003993 interaction Effects 0.000 claims description 12
- 238000004891 communication Methods 0.000 claims description 11
- 230000007613 environmental effect Effects 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 10
- 230000005540 biological transmission Effects 0.000 claims description 6
- 238000007726 management method Methods 0.000 description 37
- 238000004519 manufacturing process Methods 0.000 description 21
- 230000006870 function Effects 0.000 description 16
- 230000002159 abnormal effect Effects 0.000 description 7
- 238000002360 preparation method Methods 0.000 description 5
- 230000036961 partial effect Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 238000000926 separation method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000005553 drilling Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000005304 joining Methods 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the application discloses a disaster recovery system and method based on a multi-cloud platform and a storage medium, which are used for improving the reliability of the disaster recovery system. The embodiment of the application comprises the following steps: the system comprises a first public cloud platform, a second public cloud platform and a flow management module; the flow management module is used for receiving and dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform; the first public cloud platform is used for processing network services according to the stored service data and the first user access flow; the second public cloud platform is used for processing the network service according to the backed-up service data and the second user access flow distributed by the flow management module; the first public cloud platform and the second public cloud platform are used for synchronizing real-time service data generated in respective network service processing.
Description
Technical Field
The embodiment of the application relates to the field of disaster recovery systems, in particular to a disaster recovery system and method based on a multi-cloud platform and a storage medium.
Background
In recent years, with the development of the internet, more and more operation data are generated, which are the basis of each network service process of a system, and if a disaster occurs in a database for storing the operation data, the operation of the system is in a state of being broken down. Disaster recovery, called disaster recovery for short, refers to a systematic data emergency mode established in advance by using scientific technical means and methods to deal with the occurrence of disasters.
Some systems establish a disaster recovery backup environment according to a production environment, specifically backup all services and data to a data center, and use the data center as a basis of the disaster recovery backup environment, when the production environment is seriously abnormal and cannot be used normally, switch a user access flow which should be accessed to the production environment to the disaster recovery backup environment, so that the user access flow of a user passes through the services and data backed up by the disaster recovery backup environment, and complete the service of the user access flow.
However, the existing disaster recovery environment is a disaster recovery environment that is not put into use, and is only used for backing up all services and data of the current production environment, and if such a disaster recovery environment is not subjected to a large amount of debugging, flow switching is directly performed, and an unknown operation error condition is easily generated, so that service recovery is uncontrollable, and reliability of a disaster recovery system is reduced.
Disclosure of Invention
The first aspect of the embodiment of the application provides a disaster recovery system based on a multi-cloud platform, which is characterized by comprising:
the system comprises a first public cloud platform, a second public cloud platform and a flow management module, wherein the flow management module, the first public cloud platform and the second public cloud platform are associated with each other;
the flow management module is used for receiving user access flow, dividing the user access flow into first user access flow and second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
the first public cloud platform is used for carrying out network service processing according to the stored service data and the first user access flow to obtain first real-time service data;
the second public cloud platform is used for processing the network service according to the backed-up service data and the second user access flow to obtain second real-time service data and transmitting the second real-time service data to the first public cloud platform;
the first public cloud platform is further used for storing the first real-time service data and the second real-time service data and synchronizing the first real-time service data and the second service data to the second public cloud platform in real time.
Optionally, the first public cloud platform includes a first access layer, a first Web layer, a first service layer, and a first data layer, where the first access layer is configured to allocate the first user access traffic to the first Web layer, and the first Web layer, the first service layer, and the first data layer are configured to receive and process the first user access traffic sent by the first access layer;
the second public cloud platform comprises a second access layer, a second Web layer, a second service layer and a second data layer, wherein the second access layer is used for distributing the second user access flow to the second Web layer, and the second Web layer, the second service layer and the second data layer are used for receiving and processing the second user access flow sent by the second access layer.
Optionally, the first public cloud platform further includes a first independent middleware layer and a second independent middleware layer;
the first independent middleware layer is used for coordinating and connecting network service processing and data transmission of the first access layer, the first Web layer, the first service layer and the first data layer;
the second independent middleware layer is used for coordinating and connecting network service processing and data transmission of the second access layer, the second Web layer, the second service layer and the second data layer.
Optionally, the first independent middleware layer includes a first registry module, a first configuration center module, and a first message queue module, where the first registry module is configured to implement basic function services of the first public cloud platform, the basic services include unified naming service, configuration management, distributed lock, cluster management, soft load, publish/subscribe, and naming service, the first configuration center module is configured to store and manage configuration information of the first public cloud platform, and the first message queue module is configured to implement asynchronous messages, application decoupling, traffic clipping, and message communication of the first public cloud platform;
the second independent middleware layer comprises a second registration center module, a second configuration center module and a second message queue module, the second registration center module is used for achieving basic function services of the second public cloud platform, the basic services comprise unified naming services, configuration management, distributed locks, cluster management, soft loads, publishing/subscribing and naming services, the second configuration center module is used for storing and managing configuration information of the second public cloud platform, and the second message queue module is used for achieving asynchronous messages, application decoupling, traffic peak clipping and message communication of the second public cloud platform.
Optionally, the disaster recovery system further includes a cloud-crossing cluster middleware layer, where the cloud-crossing cluster middleware layer deploys at least one middleware node on the first public cloud platform and the second public cloud platform respectively;
the cross-cloud cluster middleware layer is further used for achieving information interaction among the first Web layer, the first service layer, the first data layer, the second Web layer, the second service layer and the second data layer.
Optionally, the cross-cloud cluster middleware layer includes a third registry module, a third configuration center module, and a third message queue module, where the third registry module is configured to implement basic function services of the first public cloud platform and the second public cloud platform, the basic services include unified naming service, configuration management, distributed locks, cluster management, soft loads, publish/subscribe, and naming service, the third configuration center module is configured to store and manage configuration information of the first public cloud platform and the second public cloud platform, and the third message queue module is configured to implement asynchronous messages, application decoupling, traffic clipping, and message communication of the first public cloud platform and the second public cloud platform.
Optionally, the disaster recovery system further includes a data layer synchronization module, where the data layer synchronization module is respectively associated with the first data layer and the second data layer, and the data layer synchronization module is configured to implement real-time synchronization between data of the first data layer and data of the second data layer.
Optionally, the traffic management module includes a traffic receiving module, a traffic distribution module, and a cloud platform monitoring module;
the flow distribution module is respectively associated with the flow receiving module, the cloud platform monitoring module, the first public cloud platform and the second public cloud platform, the flow receiving module is used for receiving user access flows of at least two regions, the flow distribution module is used for distributing the user access flows of the at least two regions in real time according to preset distribution rules, the cloud platform monitoring module is used for monitoring the environmental response states of the first public cloud platform and the second public cloud platform in real time and transmitting the environmental response states to the flow distribution module, and the flow distribution module is further used for switching and distributing the user access flows of the at least two regions in real time according to the environmental response states.
A second aspect of the embodiments of the present application provides a disaster recovery method based on a multi-cloud platform, which is characterized in that the method is applied to a disaster recovery system based on a multi-cloud platform, the disaster recovery system based on a multi-cloud platform includes a first public cloud platform and a second public cloud platform, the first public cloud platform includes a first database, the second public cloud platform includes a second database, and the method includes:
accessing user access flow;
dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
executing network service processing operation aiming at the first user access flow through the first public cloud platform to obtain first real-time service data;
executing network service processing operation aiming at the second user access flow through a second public cloud platform to obtain second real-time service data;
storing the first real-time service data and the second real-time service data to a first database of the first public cloud platform, and synchronizing the first real-time service data and the second real-time service data to a second database of the second public cloud platform in real time.
A second aspect of the embodiments of the present application provides a computer-readable storage medium, wherein a program is stored on the computer-readable storage medium, and when the program is executed on a computer, the method according to the second aspect is performed.
According to the technical scheme, the embodiment of the application has the following advantages:
the system comprises a first public cloud platform, a second public cloud platform and a flow management module, wherein the flow management module, the first public cloud platform and the second public cloud platform are associated with each other. The flow management module is used for receiving the user access flow, dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform. The first public cloud platform is used for carrying out network service processing according to the stored service data and the first user access flow to obtain first real-time service data. And the second public cloud platform is used for carrying out network service processing according to the backed-up service data and the second user access flow distributed by the flow management module to obtain second real-time service data, and transmitting the second real-time service data to the first public cloud platform. The first public cloud platform is further used for storing first real-time service data and second real-time service data and synchronizing the first real-time service data and the second service data to the second public cloud platform in real time. The disaster recovery backup system performs main network service processing on the first public cloud platform, and performs partial service processing after backing up the service and data of the first public cloud platform through the second public cloud platform. The flow management module controls the allocation of the user access flow, so that the second public cloud platform is put into use, the occurrence of abnormal conditions generated when the flow switching is carried out by the disaster recovery system is reduced, and the reliability of the disaster recovery system is improved.
Drawings
Fig. 1 is a schematic structural diagram of an embodiment of a disaster recovery system based on a multi-cloud platform in the embodiment of the present application;
fig. 2 is a schematic structural diagram of another embodiment of a disaster recovery system based on an independent deployment mode middleware layer in the embodiment of the present application;
fig. 3 is a schematic structural diagram of another embodiment of a disaster recovery system based on a cross-cloud cluster mode middleware layer in the embodiment of the present application;
fig. 4 is a schematic flow chart of an embodiment of a disaster recovery method based on a multi-cloud platform in the embodiment of the present application;
fig. 5 is a schematic flowchart of an embodiment of a disaster recovery device based on a cloud platform in the embodiment of the present application.
Detailed Description
The technical solutions in the present application will be described clearly and completely with reference to the accompanying drawings in the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The embodiment of the application discloses a disaster recovery system and method based on a multi-cloud platform and a storage medium, which are used for improving the reliability of the disaster recovery system.
Referring to fig. 1 to 3, an embodiment of the present application provides a disaster recovery system based on a multi-cloud platform, including:
the system comprises a first public cloud platform 1, a second public cloud platform 2 and a flow management module 3, wherein the flow management module, the first public cloud platform and the second public cloud platform are associated with each other;
the flow management module 3 is configured to receive user access flow, divide the user access flow into a first user access flow and a second user access flow based on a preset proportion, allocate the first user access flow to the first public cloud platform 1, and allocate the second user access flow to the second public cloud platform 2;
the first public cloud platform 1 is used for performing network service processing according to the stored service data and the first user access flow to obtain first real-time service data;
the second public cloud platform 2 is configured to perform the network service processing according to the backed-up service data and the second user access traffic to obtain second real-time service data, and transmit the second real-time service data to the first public cloud platform 1;
the first public cloud platform 1 is further configured to store the first real-time service data and the second real-time service data, and synchronize the first real-time service data and the second service data to the second public cloud platform 2 in real time.
In this embodiment, two public cloud platforms, that is, cloud platforms of two public cloud manufacturers are used, one of the two public cloud platforms is a main production environment platform, and the other is a second disaster-backup environment platform, and the traffic management module 3 respectively enables the production environment platform and the disaster-backup environment platform to respectively bear user access traffic. The production environment platform may be either one of the first public cloud platform 1 and the second public cloud platform 2, and the disaster-preparation environment platform is the other.
The second public cloud platform 2 is not necessarily completely the same in structure as the first public cloud platform 1, and serves as a cloud platform of the disaster-preparation environment platform, and the main purpose is to switch the user access traffic to the disaster-preparation environment platform according to a preset fault drilling scheme when the cloud platform serving as the production environment platform is abnormal and cannot run. At this time, the disaster-backup environment platform temporarily undertakes the business service work of user traffic access. When the production environment platform releases the exception, the flow management module 3 plans the allocation of the user access flow again. The cloud platform serving as a disaster-backup environment platform can be constructed more simply than the cloud platform serving as a production environment platform.
It should be noted that the second public cloud platform 2 may have the same structure as the first public cloud platform 1, and the two public cloud platforms may exchange the identities of the disaster preparation environment platform and the production environment platform under necessary conditions, which is more beneficial to resource allocation. For example, the production environment platform is a first public cloud platform 1, and the disaster-tolerant environment platform is a second public cloud platform 2.
When the first public cloud platform 1 generates abnormal operation failure or user access flow with partial area can not normally process network service processing on the first public cloud platform 1, the first public cloud platform 1 can immediately carry out integral recovery or partial recovery, and the user access flow which can not normally process network service processing on the first public cloud platform 1 is distributed to the second public cloud platform 2 for processing network service. And waiting for exception elimination of the first public cloud platform 1, and resetting the allocation mode of the user access flow.
In the whole recovery process of the production environment platform, two most key measurement indexes are provided; one is RTO (Recovery Time Objective); the other is RPO (Recovery Point Objective). The RTO is a time period from when a system is abnormal and a service is suspended after a disaster occurs to when the system is restored to a state that can support operations of each department and restore operations, and is called as RTO. The RPO is not limited herein, and means how much the system and production data should be restored to support the business operation of each department, and how much the system and production data should be restored to, and the degree of update may be backup data of the last week or real-time data of the last transaction. The disaster-tolerant backup environment platform has the functions of reducing two indexes of RTO and RPO and temporarily bearing the work of business processing when the production environment platform is recovered, so that the structure of the disaster-tolerant backup environment platform can be simplified compared with the production environment platform which needs to keep a large amount of operation for a long time. If a disaster recovery environment platform with the same structure as the production environment platform is created, the cost performance is low although two indexes of RTO and RPO are not needed to be considered.
In this embodiment, the first public cloud platform is configured to perform network service processing according to the stored service data and the first user access traffic to obtain first real-time service data. The first public cloud platform is used as a production environment platform, firstly, a database is established, service data and user data required by platform operation are stored as service data, and the first public cloud platform calls the service data in a network service processing process. And when the second public cloud platform is used as the disaster recovery and backup environment platform and is set up, the data in the first public cloud platform database can be backed up at one time. When the first public cloud platform carries out network service processing, the generated first real-time service data can be backed up to the second public cloud platform, otherwise, when the second public cloud platform carries out network service processing, the generated second real-time service data can also be backed up to the first public cloud platform. The first real-time service data and the second real-time service data can be synchronously updated by two public cloud platforms in real time, and can also be periodically updated by setting a data updating node.
Secondly, the normal disaster recovery environment does not bear the user access traffic, i.e. does not bear the business service, so that the normal disaster recovery environment belongs to the cold disaster recovery environment, the investment for the amount is only to prevent small-probability events, and the input-output ratio is too low. The disaster recovery environment platform of this embodiment bears a part of user access traffic, so that not only can the infrastructure cost of a part of systems be shared, but also a part of main production environment resources are replaced by disaster recovery environment resources, and uncertainty in traffic switching can be avoided.
Optionally, the first public cloud platform includes a first access layer 4, a first Web layer 5, a first service layer 6, and a first data layer 7, where the first access layer 4 is configured to allocate the first user access traffic to the first Web layer 5, and the first Web layer 5, the first service layer 6, and the first data layer 7 are configured to receive and process the first user access traffic sent by the first access layer 4;
the second public cloud platform comprises a second access layer 8, a second Web layer 9, a second service layer 10 and a second data layer 11, wherein the second access layer 8 is used for distributing the second user access traffic to the second Web layer 9, and the second Web layer 9, the second service layer 10 and the second data layer 11 are used for receiving and processing the second user access traffic sent by the second access layer.
In this embodiment, the two access layers (the first access layer 4 and the second access layer 8) have similar functions, the two Web layers (the first Web layer 5 and the second Web layer 9) have similar functions, the two service layers (the first service layer 6 and the second service layer 10) have similar functions, and the two data layers (the first data layer 7 and the second data layer 11) have similar functions, which will be described in detail below:
the access layer, the Web layer, the service layer and the data layer are mainly set according to regions, and the access layer, the Web layer, the service layer and the data layer of the data layer can be set in different regions for management respectively.
And (3) flow control and switching: the access layer controls the data center accessed by the user by adopting a DNS + region (the domestic DNS service can be accurate to province/region + operator). The traffic management module 3 will generally allocate the user access traffic to the access layers of the first public cloud platform 1 and the second public cloud platform 2, and determine which access layer to input according to the domain name and the operator.
Taking the domain name of www.XX.com as an example, assuming that the entry IP of the a cloud vendor (first public cloud platform 1) is 1.1.1.1, and the entry IP of the B cloud vendor (second public cloud platform 2) is 2.2.2.2, users of one or more operators in a certain area (e.g., the guangdong) normally access business services on the a cloud vendor. At this time, the domain name resolution of the corresponding guangdong mobile www.XX.com is not 1.1.1.1, and if it is necessary to switch the user access traffic covered by the area to the service provided by the B cloud vendor, a record of a www.XX.com 1.1.1.1 (record of the IP address of the storage domain) may be added. Therefore, refined flow management and control and flow switching of multiple data centers can be realized.
In this embodiment, the Web layer, the service layer, and the data layer are configured to receive and process user access traffic sent by the access layer in this area. The Web layer can provide the service on the webpage for the user according to the user access flow sent by the user, and the service layer and the data layer provide the service content and necessary data for the user.
Web broker (Nginx) independent deployment: in order to cooperate with the traffic switching of the DNS, the same Nginx service needs to be deployed on two cloud data centers, the synchronization of domain name configuration is realized, and the service points to respective web layer services. After the DNS cuts traffic, the access layer performs routing processing on the traffic by Nginx after acquiring user access traffic. DNS + nginx (or other web proxy component) is the basic component to accomplish traffic switching.
The web layer (web-api) and the service layer (dubbo-provider) in the embodiment, whether api or provider, are deployed independently on two cloud platforms. Because the service itself is stateless, different numbers of instances can be deployed differently depending on the different locations of the two cloud platforms. In the case of the cross-cloud cluster middleware deployment scheme, the user access traffic processed by the service layer may come from the access layers of the two data centers. If independently deployed middleware is employed, the service layer provides only user access traffic for the local access layer. Both service layers can not care about the deployment mode of the middleware cluster, but the configuration of the configuration center needs to be kept consistent, which is the function of middle domain name transformation.
Optionally, the first public cloud platform further includes a first independent middleware layer 12 and a second independent middleware layer 13;
the first independent middleware layer 12 is configured to coordinate network service processing and data transmission for interfacing the first access layer 4, the first Web layer 5, the first service layer 6, and the first data layer 7;
the second independent middleware layer 13 is configured to coordinate network service processing and data transmission for joining the second access layer 8, the second Web layer 9, the second service layer 10, and the second data layer 11.
Optionally, the first independent middleware layer 12 includes a first registry module 14, a first configuration center module 15, and a first message queue module 16, where the first registry module 14 is configured to implement basic function services of the first public cloud platform 1, the basic services include unified naming service, configuration management, distributed locks, cluster management, soft loads, publish/subscribe, and naming service, the first configuration center module 15 is configured to store and manage configuration information of the first public cloud platform 1, and the first message queue module 16 is configured to implement asynchronous messages, application decoupling, traffic clipping, and message communication of the first public cloud platform 1;
the second independent middleware layer 13 includes a second registry module 17, a second configuration center module 18, and a second message queue module 19, where the second registry module 17 is configured to implement basic function services of the second public cloud platform 2, the basic services include unified naming service, configuration management, distributed locks, cluster management, soft loads, publish/subscribe, and naming service, the second configuration center module 18 is configured to store and manage configuration information of the second public cloud platform 2, and the second message queue module 19 is configured to implement asynchronous messages, application decoupling, traffic clipping, and message communication of the second public cloud platform 2.
In this embodiment, the first public cloud platform 1 and the second public cloud platform 2 may adopt distributed middleware layers that are independently deployed, that is, a set of complete middleware is deployed on both sides of the first public cloud platform 1 and the second public cloud platform 2, and the service layer provides only user access traffic of the local access layer and performs information interaction in a network service process among respective web layers, service layers, and data layers, and does not perform information interaction in the network service process among the cloud platforms.
In this embodiment, the middleware layer mainly includes a registry module (zookeeper), a message queue module (rocketmq/kafka), a configuration center module (nacos), and the like.
The first registry module 14 and the second registry module 17 are respectively configured to provide basic services such as unified naming service, configuration management, distributed lock, and the like to the first public cloud platform 1 and the second public cloud platform 2, and based on these basic services, functions such as cluster management, soft load, publish/subscribe, naming service, and the like can be implemented.
Firstly, when the service of the cloud platform is started, the information of the service provider is actively reported to a registration center module of a middleware layer for service registration. When the service caller is started, the service providing or information is pulled down from the registry module to the local cache of the service caller. When the service needs to be called, the address list of the service provider is found from the local cache list, and a server is selected to initiate remote calling based on some load balancing strategy (random, polling, etc.). The registry module is a distributed coordination service that implements these functions.
The first configuration center module 15 and the second configuration center module 18 are respectively used for storing and managing configuration information of the first public cloud platform 1 and the second public cloud platform 2. Specifically, the configuration center module: in the system development process, some parameters, variables and the like which need to be changed are usually separated from codes and independently managed, and exist in the form of independent configuration files. The aim is to better adapt the static system components or deliveries to the actual physical operating environment. Configuration management is typically included in the system deployment process, and this step is done by a cloud platform administrator or operation and maintenance personnel. Configuration changes are one of the effective means to adjust the behavior of the system at runtime. The configuration center module can be used as a configuration center for storing and managing configuration information.
The first message queue module 16 and the second message queue module 19 are respectively used for realizing asynchronous message, application decoupling, traffic peak clipping and message communication of the first public cloud platform 1 and the second public cloud platform 2. With the message queue module, only the message is needed to be concerned whether the message reaches the queue, and as for who wants to subscribe, the message queue module is a downstream matter, thereby undoubtedly greatly reducing the workload of development and joint debugging. Since the middleware layer in this embodiment is in an independent deployment manner, a broadcast information synchronization module needs to be added between the first message queue module 16 and the second message queue module 19, so that the broadcast information of the two public cloud platforms can be synchronized with each other.
The configuration of the middleware (mainly referring to connection configuration) needs to optimize the IP into a domain name, so that the same configuration can be deployed in two data centers, and specific domain name resolution is resolved to a corresponding middleware IP address by respective local DNS.
The above middleware layer is independently deployed, and a cross-cloud cluster type middleware layer is described below.
Optionally, the disaster recovery system further includes a cross-cloud cluster middleware layer 20, where the cross-cloud cluster middleware layer 20 deploys at least one middleware node on the first public cloud platform 1 and the second public cloud platform 2 respectively;
the cross-cloud cluster middleware layer 20 is further configured to implement information interaction between the first Web layer 5, the first service layer 6, the first data layer 7, the second Web layer 9, the second service layer 10, and the second data layer 11.
Optionally, the cross-cloud cluster middleware layer 20 includes a third registry module 21, a third configuration center module 22, and a third message queue module 23, where the third registry module 21 is configured to implement basic function services of the first public cloud platform 1 and the second public cloud platform 2, the basic services include unified naming service, configuration management, distributed lock, cluster management, soft load, publish/subscribe, and naming service, the third configuration center module 22 is configured to store and manage configuration information of the first public cloud platform 1 and the second public cloud platform 2, and the third message queue module 23 is configured to implement asynchronous message, application decoupling, traffic peak clipping, and message communication of the first public cloud platform 1 and the second public cloud platform 2.
The cross-cloud cluster middleware layer can enable user access flow processed by the public cloud platform to come from access layers of the two public cloud platforms, and information interaction between the public cloud platforms can be carried out when the service layer and the web layer carry out network business service. The same or different number of middleware nodes are deployed between the first public cloud platform 1 and the second public cloud platform 2 according to needs, a set of cross-cloud cluster middleware layer 20 is formed, and network service services of the first public cloud platform 1 and the second public cloud platform 2 of different cloud manufacturers only access local middleware nodes. The network business services of the first public cloud platform 1 and the second public cloud platform 2 are logically in one area, and the dependence and calling relation between the network business services cannot be changed.
Second, the cross-cloud cluster middleware layer 20 also functions as a data interaction between the first public cloud platform 1 and the second public cloud platform 2. The data interaction method is mainly embodied in that the cross-cloud cluster middleware layer 20 is connected with the first Web layer 5 and the first service layer 6 of the first public cloud platform 1 and is also connected with the second Web layer 9 and the second service layer 10 of the second public cloud platform 2, so that after the data processing is carried out on the first public cloud platform 1 and the second public cloud platform 2, the data interaction can be carried out on the first Web layer 5, the first service layer 6, the second Web layer 9 and the second service layer 10 through the cross-cloud cluster middleware layer 20.
The cross-cloud cluster middleware layer 20 transmits the interaction demand generated by the first public cloud platform 1 in the operation to the second public cloud platform 2 in the manner, that is, the first user access flow of the first public cloud platform 1 can not only perform network service processing through a plurality of structural layers (a Web layer, a service layer, a data layer and the like) of the platform, but also perform network service processing to a plurality of structural layers of the second public cloud platform 2, and the second public cloud platform 2 can also perform the operation in the same way. Secondly, besides the interactive processing of the user access flow, the broadcast information of the two public cloud platforms can also be transmitted through the cross-cloud cluster middleware layer 20, so that the broadcast information of the two public cloud platforms can be synchronized, and a broadcast synchronization module does not need to be added on the message queue module like the two middleware layers in an independent deployment mode.
The cross-cloud cluster middleware layer 20 associates the two public cloud platforms, so that the two public cloud platforms realize strong interaction capacity on data processing, the interaction capacity, the linkage capacity and the coordination capacity of the two public cloud platforms are enhanced, and finally the reliability of the disaster recovery system is enhanced.
Optionally, the disaster recovery system further includes a data layer synchronization module 24, where the data layer synchronization module is respectively associated with the first data layer 7 and the second data layer 11, and the data layer synchronization module 24 is configured to implement real-time synchronization between data of the first data layer 7 and data of the second data layer 11.
Optionally, the traffic management module 3 includes a traffic receiving module 25, a traffic distributing module 26, and a cloud platform monitoring module 27;
the flow distribution module 26 is respectively associated with the flow receiving module 25, the cloud platform monitoring module 27, the first public cloud platform 1 and the second public cloud platform 2, the flow receiving module 25 is configured to receive user access flows of at least two regions, the flow distribution module 26 is configured to distribute the user access flows of the at least two regions in real time according to preset distribution rules, the cloud platform monitoring module 27 is configured to monitor environmental response states of the first public cloud platform 1 and the second public cloud platform 2 in real time and transmit the environmental response states to the flow distribution module 26, and the flow distribution module 26 is further configured to switch and distribute the user access flows of the at least two regions in real time according to the environmental response states.
In this embodiment, public cloud platforms of two cloud manufacturers are used, and the first public cloud platform 1 and the second public cloud platform 2 need to be in data butt joint, otherwise, the service cannot be normally operated. Synchronization of data is required by the data layer synchronization module 24.
The most important point of the disaster recovery system of the multi-cloud platform is to ensure the integrity and consistency of data. In this embodiment, data exchange is performed in a manner of combining data synchronization and read-write separation.
Data synchronization: in order to maintain the consistency of data, when the disaster-backup environment is built, the second public cloud platform 2 may adopt a one-time full-scale synchronization of data of the first public cloud platform 1, and then data generated in the operation process of the second public cloud platform 2 and the first public cloud platform 1 adopt a real-time synchronization mode, so that the second public cloud platform 2 and the first public cloud platform 1 need to have the same data resource. The real-time synchronization refers to that data are copied from a first public cloud platform 1 (a second public cloud platform 2) to a database of a second public cloud platform 2 (the first public cloud platform 1) through a data layer synchronization module 24 among different public cloud platforms, and the data are kept consistent, so that the real-time flow of the data of key services is realized.
Read-write separation: in order to utilize the resources of the data layers of the two public cloud platforms as much as possible, improve the concurrency performance of the data layers and reduce the loss caused by network delay between the cross-clouds, the service can adopt a read-write separation mode to perform read-write operation on the database. The dependence and data are synchronized in real time, the data of the data layers of the two public cloud platforms are basically consistent, service reading operation is carried out locally, and the second public cloud platform 2 accesses the data layer of the first public cloud platform 1 to operate when writing operation is needed.
In this embodiment, the flow management module 3 of the disaster recovery system specifically includes a flow receiving module 25, a flow distribution module 26, and a cloud platform monitoring module 27, where the flow receiving module 25 is configured to receive user access flows sent by each area, and the cloud platform monitoring module 27 determines whether there is a problem in a service of a certain area by monitoring environmental response states of the first public cloud platform 1 and the second public cloud platform 2 in real time, and transmits the information to the flow distribution module 26, so that the flow distribution module 26 can perform flow switching on the user access flows of the area.
Referring to fig. 4, an embodiment of the present application provides a disaster recovery method based on a multi-cloud platform, which is applied to a disaster recovery system based on a multi-cloud platform, where the disaster recovery system based on a multi-cloud platform includes a first public cloud platform and a second public cloud platform, the first public cloud platform includes a first database, and the second public cloud platform includes a second database, and includes:
401. accessing user access flow;
when the disaster recovery system accesses the user access flow, the user access flow needs to be preprocessed.
402. Dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
the disaster recovery system divides user access flow into first user access flow and second user access flow based on a preset proportion, distributes the first user access flow to a first public cloud platform, and distributes the second user access flow to a second public cloud platform. The disaster recovery backup system can monitor the interfaces of the first public cloud platform and the second public cloud platform in real time, and when the situation that the corresponding interface of a certain area is abnormal is detected, the user access flow which should be input into the public cloud platform needs to be switched to the other public cloud platform.
403. Executing network service processing operation aiming at the first user access flow through the first public cloud platform to obtain first real-time service data;
404. executing network service processing operation aiming at the second user access flow through a second public cloud platform to obtain second real-time service data;
the disaster recovery backup system executes network service processing operation on the first user access flow through the first public cloud platform to obtain first real-time service data, and executes network service processing operation on the second user access flow through the second public cloud platform to obtain second real-time service data.
405. Storing the first real-time service data and the second real-time service data to a first database of the first public cloud platform, and synchronizing the first real-time service data and the second real-time service data to a second database of the second public cloud platform in real time.
The disaster recovery backup system also needs to store the first real-time service data and the second real-time service data to the first database and synchronize the first real-time service data and the second real-time service data to the second database in real time.
In this embodiment, first, user access flows of a plurality of areas are accessed, then, the user access flows are divided according to a preset rule in a preset proportion, and then, the divided first user access flows and the divided second user access flows are respectively distributed to a first public cloud platform and a second public cloud platform.
It should be noted that, the user access traffic is divided and allocated according to a preset ratio according to a preset rule, and the division may be performed according to data volumes of the user access traffic received in different regions.
For example: city a, city B, city C, and city D all have access to user access traffic. The first public cloud platform serves as a production environment platform, the second public cloud platform serves as a disaster preparation environment platform, a large proportion of user access flow needs to be distributed to the first public cloud platform, and a small proportion of user access flow needs to be distributed to the second public cloud platform. At this time, the user access traffic of the 4 cities with the minimum access traffic is distributed to the second public cloud platform, and the user access traffic of the other three cities is distributed to the first public cloud platform.
In addition to the above allocation method, the user access traffic may be divided and allocated according to other division rules and allocation rules, which are not limited herein.
And after the first public cloud platform and the second public cloud platform respectively receive the first user access flow and the second user access flow, calling the service data in the respective databases to perform network service processing. During the network traffic processing, real-time service data is generated. The first public cloud platform can perform real-time data synchronization, and the generated first real-time service data is updated to the second public cloud platform. And the second public cloud platform can carry out real-time data synchronization and update the generated second real-time service data to the first public cloud platform. Therefore, the data of the two public cloud platforms are ensured to be the same.
In this embodiment, the traffic management module is used to receive the user access traffic, divide the user access traffic into a first user access traffic and a second user access traffic based on a preset proportion, allocate the first user access traffic to the first public cloud platform, and allocate the second user access traffic to the second public cloud platform.
And the first public cloud platform is used for carrying out network service processing according to the stored service data and the first user access flow to obtain first real-time service data. And the second public cloud platform is used for carrying out network service processing according to the backed-up service data and the second user access flow distributed by the flow management module to obtain second real-time service data. The first real-time service data and the second real-time service data are stored in a first database of the first public cloud platform, and the first real-time service data and the second real-time service data are synchronized in real time to a second database of the second public cloud platform. The disaster recovery backup system performs main network service processing on the first public cloud platform, and performs partial service processing after backing up the service and data of the first public cloud platform through the second public cloud platform. The flow management module controls the allocation of the user access flow, so that the second public cloud platform is put into use, the occurrence of abnormal conditions generated when the flow switching is carried out by the disaster recovery system is reduced, and the reliability of the disaster recovery system is improved.
A second aspect of the embodiments of the present application provides a computer-readable storage medium, wherein a program is stored on the computer-readable storage medium, and when the program is executed on a computer, the method according to the second aspect is performed.
Referring to fig. 5, an embodiment of the present application provides a disaster recovery device based on a cloud platform, including:
a processor 501, an input/output unit 502, a memory 503, and a bus 504;
the processor 501 is connected with an input/output unit 502, a memory 503 and a bus 504;
the processor 501 specifically performs the following operations:
accessing user access flow;
dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
executing network service processing operation aiming at the first user access flow through the first public cloud platform to obtain first real-time service data;
executing network service processing operation aiming at the second user access flow through a second public cloud platform to obtain second real-time service data;
and storing the first real-time service data and the second real-time service data to the first database, and synchronizing the first real-time service data and the second real-time service data to the second database in real time.
In this embodiment, the functions of the processor 501 correspond to the steps in the embodiment shown in fig. 4, and are not described herein again.
An embodiment of the present application further provides a computer-readable storage medium, where a program is stored on the computer-readable storage medium, and when the program is executed on a computer, the method as shown in fig. 4 is performed.
In the present application, the terms "upper", "lower", "left", "right", "front", "rear", "top", "bottom", "inner", "outer", "middle", "vertical", "horizontal", "lateral", "longitudinal", and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the drawings, and are used only for explaining relative positional relationships between the respective members or components, and do not particularly limit specific mounting orientations of the respective members or components.
Moreover, some of the above terms may be used to indicate other meanings besides the orientation or positional relationship, for example, the term "on" may also be used to indicate some kind of attachment or connection relationship in some cases. The specific meaning of these terms in this application will be understood by those of ordinary skill in the art as appropriate.
Furthermore, the terms "mounted," "disposed," "provided," "connected," and "connected" are to be construed broadly. For example, it may be a fixed connection, a removable connection, or a unitary construction; can be a mechanical connection, or an electrical connection; may be directly connected, or indirectly connected through intervening media, or may be in internal communication between two devices, elements or components. The specific meaning of the above terms in the present application can be understood by those of ordinary skill in the art as appropriate.
In addition, the structures, the proportions, the sizes, and the like, which are illustrated in the accompanying drawings and described in the present application, are intended to be considered illustrative and not restrictive, and therefore, not limiting, since those skilled in the art will understand and read the present application, it is understood that any modifications of the structures, changes in the proportions, or adjustments in the sizes, which are not necessarily essential to the practice of the present application, are intended to be within the scope of the present disclosure without affecting the efficacy and attainment of the same.
Claims (10)
1. The utility model provides a disaster recovery system based on many cloud platforms which characterized in that includes:
the system comprises a first public cloud platform, a second public cloud platform and a flow management module, wherein the flow management module, the first public cloud platform and the second public cloud platform are associated with each other;
the flow management module is used for receiving user access flow, dividing the user access flow into first user access flow and second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
the first public cloud platform is used for carrying out network service processing according to the stored service data and the first user access flow to obtain first real-time service data;
the second public cloud platform is used for processing the network service according to the backed-up service data and second user access flow to obtain second real-time service data and transmitting the second real-time service data to the first public cloud platform;
the first public cloud platform is further used for storing the first real-time service data and the second real-time service data and synchronizing the first real-time service data and the second service data to the second public cloud platform in real time.
2. The disaster recovery system of claim 1, wherein the first public cloud platform comprises a first access layer, a first Web layer, a first service layer, and a first data layer, wherein the first access layer is configured to distribute the first user access traffic to the first Web layer, and the first Web layer, the first service layer, and the first data layer are configured to receive and process the first user access traffic sent by the first access layer;
the second public cloud platform comprises a second access layer, a second Web layer, a second service layer and a second data layer, wherein the second access layer is used for distributing the second user access flow to the second Web layer, and the second Web layer, the second service layer and the second data layer are used for receiving and processing the second user access flow sent by the second access layer.
3. The disaster recovery system of claim 2, wherein the first public cloud platform further comprises a first independent middleware layer and a second independent middleware layer;
the first independent middleware layer is used for coordinating and connecting network service processing and data transmission of the first access layer, the first Web layer, the first service layer and the first data layer;
the second independent middleware layer is used for coordinating and connecting network service processing and data transmission of the second access layer, the second Web layer, the second service layer and the second data layer.
4. The disaster recovery system of claim 3, wherein the first independent middleware layer comprises a first registry module, a first configuration center module and a first message queue module, the first registry module is configured to implement basic functional services of the first public cloud platform, the basic services include unified naming services, configuration management, distributed locks, cluster management, soft loads, publish/subscribe and naming services, the first configuration center module is configured to store and manage configuration information of the first public cloud platform, and the first message queue module is configured to implement asynchronous messages, application decoupling, traffic clipping and message communication of the first public cloud platform;
the second independent middleware layer comprises a second registration center module, a second configuration center module and a second message queue module, the second registration center module is used for achieving basic function services of the second public cloud platform, the basic services comprise unified naming services, configuration management, distributed locks, cluster management, soft loads, publishing/subscribing and naming services, the second configuration center module is used for storing and managing configuration information of the second public cloud platform, and the second message queue module is used for achieving asynchronous messages, application decoupling, traffic peak clipping and message communication of the second public cloud platform.
5. The disaster recovery system of claim 2, further comprising a cross-cloud cluster middleware layer that deploys at least one middleware node on the first public cloud platform and the second public cloud platform, respectively;
the cross-cloud cluster middleware layer is further used for achieving information interaction among the first Web layer, the first service layer, the first data layer, the second Web layer, the second service layer and the second data layer.
6. The disaster recovery system of claim 5, wherein the cross-cloud cluster middleware layer comprises a third registry module, a third configuration center module and a third message queue module, the third registry module is configured to implement basic function services of the first public cloud platform and the second public cloud platform, the basic services include unified naming service, configuration management, distributed lock, cluster management, soft load, publish/subscribe and naming service, the third configuration center module is configured to store and manage configuration information of the first public cloud platform and the second public cloud platform, and the third message queue module is configured to implement asynchronous messages, application decoupling, traffic peak clipping and message communication of the first public cloud platform and the second public cloud platform.
7. The disaster recovery system according to any one of claims 2 to 6, further comprising a data layer synchronization module, wherein the data layer synchronization module is respectively associated with the first data layer and the second data layer, and the data layer synchronization module is configured to implement real-time synchronization of data of the first data layer and data of the second data layer.
8. The disaster recovery system of any one of claims 1 to 7, wherein the traffic management module comprises a traffic receiving module, a traffic distribution module, and a cloud platform monitoring module;
the flow distribution module is respectively associated with the flow receiving module, the cloud platform monitoring module, the first public cloud platform and the second public cloud platform, the flow receiving module is used for receiving user access flows of at least two regions, the flow distribution module is used for distributing the user access flows of the at least two regions in real time according to preset distribution rules, the cloud platform monitoring module is used for monitoring the environmental response states of the first public cloud platform and the second public cloud platform in real time and transmitting the environmental response states to the flow distribution module, and the flow distribution module is further used for switching and distributing the user access flows of the at least two regions in real time according to the environmental response states.
9. The utility model provides a disaster recovery method based on many cloud platforms, its characterized in that is applied to disaster recovery system based on many cloud platforms, disaster recovery system based on many cloud platforms includes first public cloud platform and second public cloud platform, first public cloud platform includes first database, second public cloud platform includes the second database, includes:
accessing user access flow;
dividing the user access flow into a first user access flow and a second user access flow based on a preset proportion, distributing the first user access flow to the first public cloud platform, and distributing the second user access flow to the second public cloud platform;
executing network service processing operation aiming at the first user access flow through the first public cloud platform to obtain first real-time service data;
executing network service processing operation aiming at the second user access flow through a second public cloud platform to obtain second real-time service data;
storing the first real-time service data and the second real-time service data to a first database of the first public cloud platform, and synchronizing the first real-time service data and the second real-time service data to a second database in real time.
10. A computer-readable storage medium having a program stored thereon, which when executed on a computer performs the method as claimed in claim 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110854627.3A CN113766004A (en) | 2021-07-27 | 2021-07-27 | Disaster recovery system, method and storage medium based on multi-cloud platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110854627.3A CN113766004A (en) | 2021-07-27 | 2021-07-27 | Disaster recovery system, method and storage medium based on multi-cloud platform |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113766004A true CN113766004A (en) | 2021-12-07 |
Family
ID=78788010
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110854627.3A Pending CN113766004A (en) | 2021-07-27 | 2021-07-27 | Disaster recovery system, method and storage medium based on multi-cloud platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113766004A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113765705A (en) * | 2021-08-12 | 2021-12-07 | 深圳市珍爱捷云信息技术有限公司 | Traffic switching method and traffic management server for cross-public-cloud dual-active structure |
| CN114816790A (en) * | 2022-04-11 | 2022-07-29 | 深圳乐信软件技术有限公司 | Data processing method, device, equipment and medium for tangential measurement process |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103390041A (en) * | 2013-07-18 | 2013-11-13 | 杭州东信北邮信息技术有限公司 | Method and system for providing data service based on middleware |
| CN107124459A (en) * | 2017-04-28 | 2017-09-01 | 南京大学 | It is controllable in sequence of threads evaluation and test middleware based on cloud platform |
| CN110175089A (en) * | 2019-05-17 | 2019-08-27 | 国电南瑞科技股份有限公司 | A kind of dual-active disaster recovery and backup systems with read and write abruption function |
| CN110795280A (en) * | 2019-09-11 | 2020-02-14 | 杭州衣科信息技术有限公司 | Remote double-activity disaster recovery system based on mysql asynchronous and bidirectional |
| CN111131299A (en) * | 2019-12-31 | 2020-05-08 | 上海依图网络科技有限公司 | Trans-gatekeeper data transmission method, device, medium and system based on kubernets platform |
| CN112003716A (en) * | 2019-12-12 | 2020-11-27 | 军事科学院系统工程研究院网络信息研究所 | Data center dual-activity implementation method |
| CN112804332A (en) * | 2021-01-14 | 2021-05-14 | 广州虎牙科技有限公司 | Message processing system, method, device, equipment and computer readable storage medium |
-
2021
- 2021-07-27 CN CN202110854627.3A patent/CN113766004A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103390041A (en) * | 2013-07-18 | 2013-11-13 | 杭州东信北邮信息技术有限公司 | Method and system for providing data service based on middleware |
| CN107124459A (en) * | 2017-04-28 | 2017-09-01 | 南京大学 | It is controllable in sequence of threads evaluation and test middleware based on cloud platform |
| CN110175089A (en) * | 2019-05-17 | 2019-08-27 | 国电南瑞科技股份有限公司 | A kind of dual-active disaster recovery and backup systems with read and write abruption function |
| CN110795280A (en) * | 2019-09-11 | 2020-02-14 | 杭州衣科信息技术有限公司 | Remote double-activity disaster recovery system based on mysql asynchronous and bidirectional |
| CN112003716A (en) * | 2019-12-12 | 2020-11-27 | 军事科学院系统工程研究院网络信息研究所 | Data center dual-activity implementation method |
| CN111131299A (en) * | 2019-12-31 | 2020-05-08 | 上海依图网络科技有限公司 | Trans-gatekeeper data transmission method, device, medium and system based on kubernets platform |
| CN112804332A (en) * | 2021-01-14 | 2021-05-14 | 广州虎牙科技有限公司 | Message processing system, method, device, equipment and computer readable storage medium |
Non-Patent Citations (2)
| Title |
|---|
| 王景艳: "基于铁路主数据中心云化基础设施的灾备关键技术研究", 《铁路计算机应用》, pages 2 - 5 * |
| 肖良华: "云数据中心双活技术浅析", 《金融电子化》, pages 2 - 3 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113765705A (en) * | 2021-08-12 | 2021-12-07 | 深圳市珍爱捷云信息技术有限公司 | Traffic switching method and traffic management server for cross-public-cloud dual-active structure |
| CN114816790A (en) * | 2022-04-11 | 2022-07-29 | 深圳乐信软件技术有限公司 | Data processing method, device, equipment and medium for tangential measurement process |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7076691B1 (en) | Robust indication processing failure mode handling | |
| CN100549960C (en) | The troop method and system of the quick application notification that changes in the computing system | |
| US7843811B2 (en) | Method of solving a split-brain condition | |
| CN109542611A (en) | Database, that is, service system, database dispatching method, equipment and storage medium | |
| CN112214338A (en) | Internet of things cloud platform based on flexible deployment of micro-services | |
| US9201747B2 (en) | Real time database system | |
| CN105025084A (en) | A cloud storage system based on synchronization agents and mixed storage | |
| CN111130835A (en) | Data center dual-active system, switching method, device, equipment and medium | |
| CN113766004A (en) | Disaster recovery system, method and storage medium based on multi-cloud platform | |
| CN103581276A (en) | Cluster management device and system, service client side and corresponding method | |
| CN103677967A (en) | Remote data service system of data base and task scheduling method | |
| CN113037560A (en) | Service flow switching method and device, storage medium and electronic equipment | |
| CN104811476A (en) | Highly-available disposition method facing application service | |
| CN109324942B (en) | Double-activity processing method, device, system, equipment and storage medium for microservice | |
| CN112732491B (en) | Data processing system and business data processing method based on data processing system | |
| CN105069152A (en) | Data processing method and apparatus | |
| CN100518132C (en) | Distributing traffic information storage file system | |
| CN115695139A (en) | Method for enhancing micro-service system architecture based on distributed robust | |
| CN104753987B (en) | A kind of distributed conversation management method and system | |
| CN111158949A (en) | Configuration method, switching method and device of disaster recovery architecture, equipment and storage medium | |
| CN107508700B (en) | Disaster recovery method, device, equipment and storage medium | |
| CN113127499B (en) | Block chain-based micro-service method, equipment and medium | |
| CN116112569B (en) | Micro-service scheduling method and management system | |
| CN114615268B (en) | Service network, monitoring node, container node and equipment based on Kubernetes cluster | |
| CN114598711B (en) | Data migration method, device, equipment and medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |