Multi-activity disaster recovery system and method under cloud native architecture, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, and provides a multi-activity disaster recovery system and method under a cloud native architecture, electronic equipment and a storage medium, and the system comprises a flow receiving module which is used for receiving a flow request, converting a protocol of the flow request into a standard protocol, and analyzing the flow request to obtain an analysis result; the flow distribution module is used for determining a concurrent scene to which the flow request belongs, determining a corresponding flow distribution tool based on the concurrent scene, and distributing the flow to each unit by applying the flow distribution tool and the analysis result; and the flow monitoring module is used for monitoring the flow of each unit and carrying out secondary shunting on the flow of any unit based on a preset routing rule under the condition that the flow of any unit is monitored to exceed a threshold value. According to the invention, the shunting tool can be dynamically selected according to different concurrent scenes, the system resources are saved, the traffic of different protocols can be accessed, and the universality of the system is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a multi-active disaster recovery system, method, electronic device and storage medium under a cloud native architecture. Background Art

[0002] As cloud computing and microservices architecture become increasingly mature, cloud-native applications have become a key driver of enterprise digital transformation. In order to ensure that such applications can maintain high availability and strong fault tolerance in complex and changing cloud environments, cross-domain multi-active disaster recovery technology is particularly important. AppActive, a cloud-native middleware designed specifically for business applications, came into being to help enterprises cope with various potential system risks and challenges by building a high-availability, multi-active and disaster recovery architecture.

[0003] However, the current AppActive adopts a unified strategy for traffic diversion, and does not perform intelligent scheduling based on the actual characteristics of the traffic and the status of system resources, which can easily lead to high-performance diversion tools being used to handle low-concurrency traffic, resulting in a waste of system resources. In addition, during the fault data diversion process, AppActive often uses a fixed diversion method, which causes a single unit to be overloaded, while other units are idle. This unbalanced processing capacity affects the efficiency and effectiveness of overall fault recovery. Summary of the invention

[0004] The present invention provides a multi-active disaster recovery system, method, electronic device and storage medium under a cloud native architecture, so as to solve the defects of uneven resource allocation and low fault data processing efficiency in the multi-active disaster recovery system under the existing cloud native architecture.

[0005] The present invention provides a multi-active disaster recovery system under a cloud native architecture, comprising: A flow receiving module, used for receiving a flow request, converting the protocol of the flow request into a standard protocol, and then parsing the flow request to obtain a parsing result; A traffic distribution module, used to determine the concurrent scenario to which the traffic request belongs, determine the corresponding diversion tool based on the concurrent scenario, and apply the diversion tool and the analysis result to distribute the traffic to each unit; The flow monitoring module is used to monitor the flow of each unit, and when it is monitored that the flow of any unit exceeds a threshold, the flow of any unit is secondary diverted based on a preset routing rule.

[0006] According to a multi-active disaster recovery system under a cloud native architecture provided by the present invention, the traffic distribution module includes: A tool determination unit, used to determine the concurrent scenario to which the traffic request belongs, and determine a corresponding diversion tool based on the concurrent scenario; A mode determination unit, configured to apply a traffic analysis tool to determine the business scenario to which the traffic request belongs, and determine a diversion mode based on the business scenario; A flow distribution unit is used to distribute the flow to each unit based on the diversion tool and the analysis result according to the diversion mode and diversion granularity.

[0007] According to a multi-active disaster recovery system under a cloud native architecture provided by the present invention, the tool determination unit is specifically used for: Obtain the number of requests for the traffic corresponding to the traffic request at the same time; When the number of requests exceeds a preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a high concurrency scenario, and it is determined that the diversion tool corresponding to the high concurrency scenario is a load balancer; When the number of requests does not exceed the preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a low concurrency scenario, and it is determined that the diversion tool corresponding to the low concurrency scenario is DNS polling.

[0008] According to a multi-active disaster recovery system under a cloud-native architecture provided by the present invention, the diversion mode includes any one of proportional diversion and diversion by business attributes, and the diversion granularity includes any one of diversion by domain name and diversion by URI prefix.

[0009] A multi-active disaster recovery system in a cloud native architecture provided by the present invention also includes: A fault handling module is used to, upon receiving a fault handling request, search for corresponding fault data in the queues of each unit and perform call processing based on the fault index carried in the fault handling request, wherein a queue index is added to the queue of each unit, the queue index is established based on the fault data, and the queue index corresponds to the fault index.

[0010] According to a multi-active disaster recovery system under a cloud native architecture provided by the present invention, the queue index is established based on at least one of a timestamp index, a severity level index, and a fault classification index of the fault data.

[0011] According to a multi-active disaster recovery system in a cloud native architecture provided by the present invention, the system is used to replicate and synchronize applications between different data centers, and the data centers are provided with multiple data centers. The system also includes: The central monitoring module is used to monitor the operation of each data center and call other data centers for processing when a failure is detected in the running data center.

[0012] The present invention also provides a multi-active disaster recovery method under a cloud native architecture, comprising: receiving a flow request, converting a protocol of the flow request into a standard protocol, and parsing the flow request to obtain a parsing result; Determine the concurrent scenario to which the traffic request belongs, determine a corresponding traffic diversion tool based on the concurrent scenario, and apply the traffic diversion tool and the analysis result to distribute the traffic to each unit; The traffic of each unit is monitored, and when it is monitored that the traffic of any unit exceeds a threshold, the traffic of any unit is secondary diverted based on a preset routing rule.

[0013] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, a multi-active disaster recovery method under any of the above-mentioned cloud native architectures is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, a multi-active disaster recovery method under any of the above-mentioned cloud native architectures is implemented.

[0015] The present invention also provides a computer program product, including a computer program, which, when executed by a processor, implements a multi-active disaster recovery method under any of the above-mentioned cloud native architectures.

[0016] The multi-active disaster recovery system, method, electronic device and storage medium under the cloud native architecture provided by the present invention can realize the effective utilization of resources by dynamically selecting the diversion tool according to the concurrent scenario to which the traffic request belongs, avoiding the waste of resources during high concurrency and the idleness of resources during low concurrency. This flexibility enables the system to better adapt to the needs of different business scenarios. Moreover, the system is designed with a unified interface that can convert other protocols into standard protocols, thereby realizing the processing of traffic requests of different protocols, improving the universality of the system, so that the system can be applied to different scenarios. In addition, the traffic monitoring module can monitor the traffic conditions of each unit in real time, and automatically perform secondary diversion of the traffic data in the unit according to the routing rules when an overload is found, effectively avoiding overload of a single unit, alleviating the burden of the unit, and thus improving the efficiency of fault processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1It is a structural diagram of the AppActive business model provided by the present invention; Figure 2 It is a structural diagram of a multi-active disaster recovery system under a cloud native architecture provided by the present invention; Figure 3 It is a flow chart of a multi-active disaster recovery method under a cloud native architecture provided by the present invention; Figure 4 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

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

[0020] AppActive is an open source middleware for building cloud-native high-availability multi-active disaster-tolerant architecture for business applications. It is designed to help build high-availability, multi-active and disaster-tolerant architectures for cloud-native applications. AppActive can help developers replicate and synchronize applications between different data centers and cloud service providers, thereby providing high availability and fault tolerance. Even if a data center or cloud service provider fails, AppActive can ensure the continuity of application services and the consistency of data, effectively improving business reliability and user experience. This feature makes AppActive an indispensable technical component for many companies when building cloud-native applications.

[0021] However, although AppActive has shown great potential in promoting high availability and disaster recovery capabilities of cloud-native applications, it still has certain defects. First, AppActive uses the same diversion tool for different traffic flows, which will cause a waste of system resources and make the diversion tool with better performance used to handle low-concurrency traffic. Secondly, AppActive needs to set up a separate interface for each protocol, which not only increases the complexity of the system, but also increases the cost of transformation and maintenance, and reduces development efficiency. Furthermore, in the process of fault data diversion, AppActive often uses a fixed diversion method, which leads to too much fault data in a single unit, causing load on the unit, while other units are idle, affecting the progress of fault data processing. In addition, AppActive is currently unable to set processing priorities according to the urgency of the fault data, which will result in emergency failures not being responded to in a timely manner, thus affecting the normal operation of the business and user experience.

[0022] In this regard, the present invention overcomes the above defects by modifying the open source multi-active disaster recovery component AppActive to obtain a multi-active disaster recovery system under a cloud native architecture. The specific modifications include: first, different diversion tools can be selected according to high-concurrency or low-concurrency scenarios to avoid wasting system resources; second, the interface is modified and a unified interface is designed so that the system interface is applicable to traffic requests of different protocols; and the present invention can perform secondary diversion within the unit, and perform secondary diversion of the data in the overloaded unit according to the routing rules to alleviate the burden of the unit and improve the efficiency of fault handling; the present invention can add a queue index within the unit, and call the specified fault in the unit according to the queue index, and can quickly call the fault that needs to be handled urgently; in addition, the present invention sets up multiple data centers, each data center realizes data synchronization, and monitors the operation of the data center in real time. If a running data center fails, it can call other data centers directly for processing, ensuring the timeliness of fault handling.

[0023] The following is a brief introduction to the AppActive architecture. Figure 1 is a schematic diagram of the structure of the AppActive business model provided by the present invention, such as Figure 1 As shown in the figure, the overall architecture of AppActive covers the data plane and the control plane, and manages application traffic and data throughout the entire process. It mainly consists of data plane code, control plane code, and application demo. The core of AppActive's business model is divided into four parts, including: Configuration: Management and control plane - disaster recovery configuration. Based on the Configuration module, the application can quickly perform disaster recovery resource definition management, basic disaster recovery strategy configuration, and complete daily initialization access and operation and maintenance functions.

[0024] Execute: Management and control plane - disaster recovery execution. Based on the Execute module, core actions are executed in drills or disaster scenarios to ensure business continuity and promote rapid business recovery.

[0025] ApplicationTraffic: Data plane - application traffic. Based on the Configuration module configuration, the north-south and east-west traffic of the application is uniformly managed in the Traffic module. In daily scenarios, the stability and experience of business traffic are guaranteed, and the traffic is closed within the unit. In disaster scenarios, based on the core actions of the Execute module, traffic is scheduled at the minute level.

[0026] Data: Data plane - data. Based on the Data module, the business can quickly perform data redundancy backup to ensure data recovery in disaster scenarios.

[0027] Among them, in the ApplicationTraffic module, the module construction is centered around three parts: (1) Bridge: Business component bridge. When an application completes a business request, it will involve multiple middleware components, such as entry gateway, microservices, messages, databases, etc. The core function of Bridge is to adapt these components to achieve the purpose of multi-active traffic control, which depends on the downstream Rule module.

[0028] (2) Rule: Multi-active rule. When an application performs multi-active disaster recovery, it involves the definition of IDC (Internet Data Center), machine node, traffic rule, and grayscale rule. A series of multi-active rule descriptions are used to ensure the smooth launch and daily use of the multi-active application.

[0029] (3) Channel: Data channel. The multi-active rules will be dynamically adjusted in daily and disaster scenarios, involving data interaction between different channels.

[0030] In terms of traffic types, based on the traffic request link, from top to bottom, traffic can be divided into the following layers: (1) Access layer: Ingress traffic requests. Generally, there is a gateway at the entry of business applications. In AppActive, the access layer is responsible for receiving external traffic requests and distributing the requests to the corresponding backend services based on configuration and policies. AppActive provides a standard traffic control plug-in at this layer to smoothly support the ingress traffic control of applications.

[0031] (2) Service layer: The synchronous calling method of internal applications is generally RESTful direct call or standard microservice framework. The service layer is the core part of AppActive that handles business logic. It can be composed of multiple microservices, which communicate with each other synchronously or asynchronously. AppActive provides standard microservice control plug-ins at this layer to adapt to different microservice calling methods.

[0032] (3) Message layer: The asynchronous calling method of internal applications is generally a general MQ, such as RocketMQ, Kafka, etc. AppActive provides a standard MQ control plug-in at this layer to adapt to different message forms.

[0033] (4) Data layer: Applications access databases, which are generally MySQL, NoSQL, and Oracle. In AppActive, the data layer involves multiple database instances, which are distributed in different data centers or cloud service providers. AppActive provides standard database control plug-ins at this layer to ensure data quality and adapt to different database forms.

[0034] In addition, AppActive also includes a control plane (or configuration and management plane) for configuring, monitoring and managing the entire architecture. This plane can include components such as the configuration center, monitoring center, and alarm system, which are used to configure disaster recovery strategies, monitor system status, and alarm for abnormal situations.

[0035] It can be understood that the multi-active disaster recovery system under the cloud native architecture provided by the present invention is obtained by modifying the existing AppActive on the basis of the existing AppActive. The modification performed by the present invention will be specifically introduced below.

[0036] Figure 2 is a schematic diagram of the structure of the multi-active disaster recovery system under the cloud native architecture provided by the present invention, such as Figure 2 As shown, the system includes: The flow receiving module 210 is used to receive a flow request, convert the protocol of the flow request into a standard protocol, and then parse the flow request to obtain a parsing result; The traffic distribution module 220 is used to determine the concurrent scenario to which the traffic request belongs, determine the corresponding diversion tool based on the concurrent scenario, and apply the diversion tool and the analysis result to distribute the traffic to each unit; The traffic monitoring module 230 is used to monitor the traffic of each unit, and when it is detected that the traffic of any unit exceeds a threshold, perform secondary diversion on the traffic of any unit based on a preset routing rule.

[0037] It should be noted that in AppActive, the access layer is the entrance to all traffic in the unit. It can parse the request protocol and correctly guide the request traffic to the corresponding application service SLB (Server Load Balancer) of the correct unit according to the set diversion mode and diversion granularity. Here, the purpose of parsing the request protocol is to understand the content and purpose of the request so that it can be processed in the correct way later. By parsing the request protocol, the access layer can obtain key data such as the request, request parameters, and request body.

[0038] A unit usually refers to a logically or physically relatively independent service or application deployment unit. The unit can be one or more service instances based on a microservice architecture, or one or more application instances deployed in a specific data center or cloud service provider. The application service load balancer (SLB) is a key component in the unit. It is responsible for distributing the received request traffic to the specific service instances on the backend. By directing the traffic to the SLB, the access layer achieves load balancing and dynamic distribution of the traffic, ensuring the stability and scalability of the backend service.

[0039] Specifically, the access layer may include a traffic receiving module and a traffic distribution module, wherein the traffic receiving module is used to receive traffic requests, convert the protocol of the traffic requests into a standard protocol, and then parse the traffic requests; the traffic distribution module is used to determine the concurrent scenario to which the traffic request belongs, and select the corresponding diversion tool based on the concurrent scenario.

[0040] In a multi-active scenario, traffic will be sliced ​​according to a certain dimension and diverted to different units. Here, the dimension refers to the basis or condition for determining the traffic distribution strategy. It can be a comprehensive consideration of multiple factors, such as the user's region, device type, request type, user identity, etc. Based on these dimensions, the system can divide the traffic into different subsets or slices. The system supports multiple diversion modes, such as proportional diversion and diversion by business attributes. The specific diversion mode to be selected depends on the needs of the business scenario. Therefore, the traffic distribution module can also be used to determine the business scenario to which the traffic request belongs, and select the diversion mode according to different business scenarios.

[0041] In addition, the management layer of the system may include a traffic monitoring module, which is responsible for real-time monitoring and analysis of the traffic conditions of each unit. The traffic monitoring module can capture and collect the traffic data of each unit in real time through probes or listeners deployed in the network. These data include but are not limited to key indicators such as request volume, concurrency, response time, and error rate. The collected traffic data is statistically analyzed to calculate key information such as the real-time load conditions, traffic trends, and abnormal fluctuations of each unit. The traffic monitoring module allows users to set traffic thresholds according to business needs. When the traffic of a unit is detected to exceed the threshold, the module can provide decision support for secondary diversion according to preset routing rules or algorithms. That is, based on factors such as the current load situation, traffic distribution, and business priority, a secondary diversion plan is intelligently formulated to relieve the pressure of overloaded units.

[0042] The system provided by the embodiment of the present invention can achieve effective utilization of resources by dynamically selecting diversion tools according to the concurrent scenarios to which the traffic requests belong, avoiding waste of resources during high concurrency and idle resources during low concurrency. This flexibility enables the system to better adapt to the needs of different business scenarios. Moreover, the system is designed with a unified interface that can convert other protocols into standard protocols, thereby realizing the processing of traffic requests of different protocols, improving the universality of the system so that the system can be applied to different scenarios. In addition, the traffic monitoring module can monitor the traffic conditions of each unit in real time, and automatically perform secondary diversion of the traffic data in the unit according to the routing rules when an overload is found, effectively avoiding overload of a single unit, alleviating the burden of the unit, and thus improving the efficiency of fault handling.

[0043] Based on any of the above embodiments, the flow distribution module 220 includes: A tool determination unit 221, configured to determine a concurrent scenario to which the traffic request belongs, and determine a corresponding diversion tool based on the concurrent scenario; A mode determination unit 222 is used to apply a traffic analysis tool to determine the business scenario to which the traffic request belongs, and determine a diversion mode based on the business scenario; The traffic distribution unit 223 is used to distribute the traffic to each unit based on the diversion tool and the analysis result according to the diversion mode and diversion granularity.

[0044] Specifically, in a multi-active scenario, the system can automatically select different diversion tools according to the actual situation to achieve efficient use of system resources. The traffic distribution module includes a tool determination unit. First, the tool determination unit determines the concurrent scenario to determine the corresponding diversion tool.

[0045] Furthermore, the tool determination unit 221 is specifically used for: Obtain the number of requests for the traffic corresponding to the traffic request at the same time; When the number of requests exceeds a preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a high concurrency scenario, and it is determined that the diversion tool corresponding to the high concurrency scenario is a load balancer; When the number of requests does not exceed the preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a low concurrency scenario, and it is determined that the diversion tool corresponding to the low concurrency scenario is DNS polling.

[0046] Specifically, a preset threshold can be set in the tool determination unit, and the number of requests for each type of traffic at the same time is counted. If the number of requests exceeds the preset threshold, it is judged as a high-concurrency scenario. At this time, a load balancer can be used to distribute traffic, thereby ensuring the availability and stability of the service; if the number of requests does not exceed the preset threshold, it is judged as a low-concurrency scenario. For this scenario, a simple DNS polling can be used for traffic distribution. In this way, low-concurrency services will not affect the diversion process of high-concurrency services, thereby improving the efficiency of system diversion. In an embodiment of the present invention, by selecting different diversion tools according to high-concurrency or low-concurrency scenarios, waste of system resources can be avoided.

[0047] After selecting the diversion tool to access the traffic, the traffic can be distributed to different units. When distributing traffic, it can be further distributed according to the diversion mode and diversion granularity. The diversion mode is ultimately reflected in the routing rules. The routing rule is a configuration that defines which unit a certain traffic should belong to. It should be understood that the specific diversion mode can first use traffic analysis tools (such as Wireshark, TCPdump, etc.) to judge the business scenario, and then infer the business scenario of the network application by capturing network data packets and analyzing the network traffic protocol, port, traffic distribution and other information, and then select the diversion mode according to different business scenarios. The diversion mode includes proportional diversion and diversion by business attributes, as follows: (1) Divert by proportion. In some business scenarios where personalized processing of users or devices is required, such as e-commerce software, social software, audio and video software, etc., the personalized characteristics of users or devices have a greater impact on the business. Therefore, different processing is required for different users or devices. In this case, traffic can be diverted by user or by device number. Users, devices, etc. can be abstracted into an ID, and then the ID is divided into multiple intervals. The size of each interval can be determined according to business needs and system scale. For example, the ID space can be divided into 10 intervals, and the ID range of each interval is 1-10, 11-20, 21-30, etc. Map each interval to a different unit, and each unit is responsible for processing a certain range of IDs. Determine the interval to which the request belongs based on the ID of the request, and then forward the request to the corresponding unit for processing. Since the size of each interval is consistent with the capacity ratio of each unit, global load balancing can be achieved.

[0048] (2) Divert traffic by business attributes. In some business scenarios where traffic needs to be processed differently, such as gaming software and CDN, the attributes of traffic have a greater impact on the business, so different traffic needs to be processed differently. That is, divert traffic by traffic attributes, such as directing crawler traffic to a specific unit, or divert traffic by province. Crawlers, provinces, etc. can all be abstracted into a label, so traffic with different label values ​​can be directed to different units. This diversion mode can support physical isolation of traffic with different business attributes.

[0049] In addition, the granularity of traffic diversion refers to the degree of segmentation of traffic distribution when diverting traffic. The granularity of traffic diversion can include diversion by domain name and diversion by URI prefix. Diversion by domain name means distinguishing different applications according to different domain names, for example, the domain name of application App1 is App1.example.com, and the domain name of App2 is App2.example.com. Diversion by URI prefix means distinguishing different applications according to different URI prefixes, for example, the domain names of applications App1 and App2 are both App.example.com, but the traffic with the / App1 prefix in the URI is directed to App1, and the traffic with the / App2 prefix is ​​directed to App2.

[0050] After the above steps, after determining the diversion tool, diversion mode and diversion granularity, the diversion tool can be used according to the analysis results to distribute the flow to each unit according to the corresponding diversion mode and diversion granularity.

[0051] Based on any of the above embodiments, the embodiments of the present invention use a protocol adapter to design a unified interface so that different protocols can be accessed using the same interface, thereby improving the universality of the system so that the system can be applicable to different scenarios. Here, the above-mentioned traffic receiving module is the interface module, which is the portal for the system to interact with the outside. It defines what types of requests the system can receive and how to process these requests. Traffic requests refer to data requests sent from external systems (such as clients, other servers, etc.) to the system. These data requests may be based on different protocols (such as HTTP, TCP, etc.), but through the conversion of the protocol adapter, they can all be converted into a format that is uniformly processed within the system (i.e., standard protocol) and interact through a unified interface.

[0052] Specifically, first, a standard protocol can be determined, and a standard protocol can be selected as the interface protocol in the access layer. In the embodiment of the present invention, the HTTP protocol can be selected as the standard protocol; secondly, a protocol adapter is used to convert other protocols into the standard protocol for processing; further, according to the standard protocol (i.e., the HTTP protocol), a unified interface is defined, including resource URI, HTTP method and request parameters, etc. The traffic of other protocols can use the standard protocol access interface, and a unified interface is used in the access layer for response.

[0053] Among them, according to the standard protocol (HTTP protocol), the unified interface method is defined as follows: (1) Resource URI: specifies the identifier of the resource to be accessed, such as / users, / orders, etc. (2) HTTP method: specifies the operation to be performed on the resource, such as GET, POST, PUT, DELETE, etc. (3) Request header: used to pass additional information about the request, such as Content-Type, Authorization, etc. (4) Request parameters: data contained in the request, passed in the form of key-value pairs, such as username=xxx&password=xxx, etc. (5) Request body: used to transmit request data, such as JSON, XML, binary data, etc. (6) Response status code: indicates the status of the request, such as 200 OK, 404 NotFound, etc. (7) Response header: contains metadata related to the response, such as Content-Type, Content-Length, etc. (8) Response body: contains response data, such as JSON, XML, HTML, etc.

[0054] Through the above steps, the interface definition is complete. Traffic can use the standard protocol (HTTP protocol) to access the interface, and use the unified interface definition for requests and responses. At the same time, the client's request data can be transmitted through the request header, request parameters, and request body, and the server's response data can be returned through the response status code, response header, and response body.

[0055] It is understandable that the access layer of the system supports a rich set of traffic request protocols at Layer 4 and Layer 7 to meet the needs of users in various scenarios such as the Internet and the Internet of Things. For example, the access layer supports the HTTP protocol by default, and parses the domain name and URI from the HTTP protocol for forwarding routing; the access layer also supports the HTTPS protocol, providing centralized domain name certificate management to meet the user's requirements for reliable and secure transmission. If the user configures the domain name certificate at the access layer, the application SLB does not need to configure the certificate. In addition, in addition to supporting the HTTP and HTTPS protocols, the access layer also supports other HTTP-based protocols, such as SOAP. The access layer has great scalability in terms of protocols, and can quickly support special protocols in the form of plug-ins, such as MQTT and COAP in the Internet of Things scenario.

[0056] Based on any of the above embodiments, in order to ensure that the traffic can be closed in the unit, each layer of the access layer, application layer, and data layer will perform routing error correction or unit protection. In order to identify the traffic, it is necessary to clarify the unit type and diversion ID to which the traffic belongs, which is called routing parameters, so that the correct unit to which the traffic belongs can be calculated through routing rules. Therefore, the routing parameters need to be passed along the request path, which is called routing transparent transmission. The specific introduction is as follows: (1) Access layer routing transparent transmission

[0057] When the browser initiates a service request, it needs to carry routing parameters in the request. Routing parameters can be in cookies, head, or body. Cookies are recommended. The access layer can parse the HTTP request, obtain the routing parameters, and route them to the correct application SLB. At the same time, the application server can still obtain the native routing parameters from the request.

[0058] (2) Application layer routing transparent transmission

[0059] When the traffic reaches the application server, the multi-active plug-in extracts the routing parameters from the HTTP request and saves them to the context. The application may initiate an RPC call or asynchronous message in the next step, so the routing parameters also need to be transmitted transparently at the RPC and message levels.

[0060] (3) RPC routing transparent transmission

[0061] When the application initiates an RPC call, the RPC client can extract the routing parameters from the context and follow the RPC request to the remote service provider. The Provider client recognizes the routing parameters in the Request and also saves them to the call context. The transmission process of routing parameters in RPC is transparent to the user.

[0062] (4) Message routing transparent transmission

[0063] When sending a message, the MQ client will obtain the routing parameters from the current context and add them to the message attributes. When the MQ client consumes a message, it can retrieve the routing parameters from the message attributes and also save them to the call context. The transmission process of routing parameters in MQ is transparent to the user.

[0064] (5) Data layer routing transparent transmission

[0065] Dirty data writing can cause serious consequences, so it is necessary to ensure that the data is stored in the correct unit's DB. Multi-Active provides a DRIVER plug-in to reject requests from non-units.

[0066] Based on any of the above embodiments, in a disaster recovery scenario, each unit is independent in an ideal scenario, but in reality there are some cross-unit business scenarios. In order to meet these scenarios, the system needs to provide unit collaboration capabilities. Specifically, it includes: (1) Center call

[0067] In some specific business scenarios, to ensure strong data consistency, specific services can only be provided in specific central units, and all calls to central services will be directly routed to the central unit for completion. The remote multi-active product uses CSB components and RPC multi-active plug-ins to complete the coordinated calls between service units to meet the integrity of the business.

[0068] (2) Unit protection

[0069] The product ensures the global correctness of business logic and will not cause inconsistent unit business logic due to flow switching operations. The system has error correction and protection capabilities for erroneous traffic at all levels from top to bottom to ensure that the business flows correctly according to unit rules.

[0070] (3) Access layer error correction

[0071] The traffic enters the access layer, and the access layer determines the unit to which the traffic belongs by requesting additional routing parameters. Traffic that is not from this unit will be proxied to the correct target unit, ensuring the correctness of the access layer inlet traffic.

[0072] (4) RPC error correction

[0073] When calling RPC services, the RPC multi-active Plugin on the Consumer side will correctly route the service call based on the requested unit information. For incorrect traffic service calls, the RPC multi-active Plugin will calculate the correct target unit and call the target unit service across units to ensure the consistency of the service flow logic. At the same time, the RPC multi-active Plugin on the Provider side will perform a secondary check on the incoming request to ensure the correctness of the service call. Through the double check mechanism, the RPC multi-active Plugin implements error correction for RPC calls to ensure the correctness of service calls.

[0074] Based on any of the above embodiments, the system also provides a horizontal expansion function. When the business carrying capacity of the existing unit has reached the upper limit and cannot be expanded, the system can provide a simple and fast unit horizontal expansion capability: the expansion of new units across the country is not restricted by geographical location; the number of new units expanded is not limited, and the stability and performance of the unit are not affected by the number of units; two forms of unit expansion are provided, namely, remote units with independent DBs and same-city units with shared DBs.

[0075] Based on any of the above embodiments, the modified AppActive of the embodiment of the present invention can select ERSS (Emergency Support Automation System), EACS (Emergency Action Command Automation System), EIMS (Emergency Information Management System), ESM (Emergency Material Management System), ERS (Emergency Rescue System) and other systems for connection to achieve multi-active disaster recovery. In addition, AppActive can also be used in e-commerce, finance, logistics and other fields to help enterprises ensure business continuity.

[0076] Based on any of the above embodiments, considering that AppActive in the prior art does not provide a method for adaptive connection with other platforms, the embodiment of the present invention performs adaptive transformation on AppActive and the connected platform to form a cross-domain multi-active disaster recovery technology component under the cloud native architecture. The following is a specific transformation method: (1) First, the Gateway of platform A needs to be modified so that the gateway supported by platform A is consistent with the gateway used by AppActive. Here, the platform connected to AppActive is called platform A (platform A can be ERSS, EACS, EIMS, ESM, ERS and other system platforms).

[0077] Specifically, the request is repackaged at the gateway layer of platform A, and filtering rules are added to ensure that the request made at the gateway layer of platform A meets the requirements of AppActive, that is, some key information in the request is extracted and processed to meet the needs of AppActive. For example, if the gateway layer of platform A is spirng-cloud-gateway, after extracting the employee-related 4A account in the request, the extracted 4A account is placed in the header of the request and passed to the gateway layer of AppActive, so that AppActive can obtain this key information and forward it according to the corresponding routing rules. Here, 4A account refers to a key account information used for identity authentication and authorization.

[0078] (2) Modify the source code of AppActive's routing rules

[0079] Secondly, since AppActive's routing rules only support judgments based on digital intervals, which does not match the current business status of platform A, it is necessary to modify the AppActive routing rule judgment source code to support the routing of 4A accounts on platform A. For example, in the AppActive routing judgment source code, you can obtain the 4A account information in the request header, add the judgment logic for the 4A account, use the 4A account as the key parameter for routing, and route the request to the corresponding downstream service so that AppActive can obtain this key information. In this way, AppActive's routing rules can support the judgment of 4A accounts.

[0080] (3) Switching and transformation of the application layer

[0081] AppActive application layer switching supports cross-machine room forwarding of different application names in different machine rooms. However, since the dual-center PaaS platform only supports application clusters with the same name, in order to adapt to this situation, the components of the AppActive application layer can be reconstructed so that applications with different names can be forwarded to each other on the PaaS platform. During actual operation, application clusters with different names will be replaced with the name of the current cluster environment and executed, so that applications with different names can be forwarded to each other on the PaaS platform.

[0082] (4) Carry out traffic switching transformation

[0083] Since AppActive currently does not provide a front-end page to implement traffic switching, the AppActive interface can be developed to obtain an AppActive traffic switching interface that supports the work number of platform A. Specifically, you can first introduce the classes and interfaces you need to use, then automatically inject instances into the corresponding classes, and call the traffic switching method in the traffic switching service to switch traffic.

[0084] (5) Use nacos-sync to synchronize service information between the two centers

[0085] Use nacos-sync to synchronize the information between data center A and data center B to ensure that both centers can access the same services. For example, if a certain data is deregistered in center A, nacos-sync will synchronize the deregistration information of the corresponding data to center B, thereby ensuring that the service information of the two data centers is always consistent. When center A fails, since the data of center A and center B are synchronized, the tasks of center A can be continued directly through center B. This method can improve the availability and fault tolerance of the emergency support automation platform, and can also ensure the normal operation of the system in a multi-active scenario in different locations.

[0086] When the Gateway and application layer make service calls across centers, they will match the services to be called according to the pre-defined routing rules and search for the corresponding services in the current nacos service registration center. In this way, multi-active calls across centers can be achieved, ensuring that the emergency support automation platform can operate normally when making service calls between different data centers.

[0087] The embodiments of the present invention provide a method and example for adapting AppActive to other platforms, so that the application of AppActive can be implemented in the field, avoiding the problems of untimely emergency event handling and unguaranteed results caused by system dispersion, and greatly improving the efficiency of emergency event handling.

[0088] Based on any of the above embodiments, nacos (Dynamic Naming and Configuration Service) also supports the use of Clustered mode (i.e., cluster mode) to synchronize service information between multiple centers. In Clustered mode, multiple Nacos instances form a cluster, each of which can receive and process requests and share the same database. When an instance modifies the service information, it will immediately synchronize the change information to other instances, thereby achieving service information synchronization between multiple centers. Therefore, in a multi-center scenario, it can ensure that fault events are handled in a timely manner.

[0089] Specifically, applications can be deployed in multiple data centers through container orchestration technology. Use containerization technology, such as Docker, to package applications into container images, and then use container orchestration technology, such as Kubernetes or DockerSwarm, to deploy container images to clusters in multiple data centers. Configure application load balancing in the container orchestration tool to ensure that traffic is balanced across multiple data centers. Configure data replication and synchronization based on application needs to ensure data consistency across multiple data centers.

[0090] Furthermore, the multi-active disaster recovery system is used to replicate and synchronize applications between different data centers, and the data centers are provided with multiple ones. The system also includes: The central monitoring module 250 is used to monitor the operation of each data center and, when a failure is detected in a running data center, call other data centers for processing.

[0091] Specifically, you can use monitoring tools to monitor the load of the center and detect the data execution volume in a center in real time, such as Zabbix, Nagios, etc. These tools can monitor the usage of server CPU, memory, network and other resources in real time, so as to know the data execution volume in a single center.

[0092] When the amount of data execution in a single center is too much, some of the data can be transferred to other centers for execution through load balancing technology to achieve the purpose of load balancing. In actual operation, load balancers can be used to achieve load balancing. When the amount of data execution in a single center is too much, some requests can be transferred to other centers to achieve load balancing. Commonly used load balancers include Nginx, HAProxy, etc.

[0093] Furthermore, each data center may include multiple units, and a load balancer may also be used in each unit. After traffic is distributed according to the diversion rules, if too many emergency events are allocated to a single unit, the unit may be diverted for a second time according to another diversion rule, and the emergency events may be transferred to other units for processing through the load balancer. When there is too much fault data in a single unit, the embodiment of the present invention can transfer the data corresponding to the unit with a large load to other units through secondary diversion, so as to avoid the timeliness of fault event processing being affected by too much data in a single unit.

[0094] Through the above steps, you can deploy applications in multiple data centers and achieve high availability and load balancing through container orchestration technology.

[0095] Based on any of the above embodiments, full-stack monitoring technology can be used to monitor the various components and services of the multi-active disaster recovery system in real time, thereby achieving fault diagnosis and performance optimization. Full-stack monitoring technology can collect and analyze a large amount of data to help administrators and operation and maintenance personnel make decisions and optimizations. For example, full-stack monitoring technologies such as Prometheus.Grafana or ELK can be used to achieve real-time monitoring and fault diagnosis of the system, so that when a system failure occurs, it can respond quickly and transfer data to other centers for continued processing, avoiding interruption or loss of data being processed.

[0096] Based on any of the above embodiments, the system further includes: The fault handling module 240 is used to search for corresponding fault data in the queue of each unit and perform call processing based on the fault index carried in the fault handling request when a fault handling request is received. The queue of each unit is added with a queue index, which is established based on the fault data and corresponds to the fault index.

[0097] Specifically, a queue can be established in each unit, and a queue index can be added to the queue. The queue index can be an index established based on the timestamp of the fault data, or an index established based on the classification number of the fault data. For example, establishing an index based on the timestamp of the fault data includes the following steps: creating a Kafka topic, the topic name can be named according to the timestamp, and then writing the fault data to the corresponding topic according to the timestamp, and consuming the fault data in the topic in the order of the timestamp. Therefore, when the operation and maintenance system issues a request for a certain fault that needs to be handled urgently, the index of the fault that needs to be solved urgently is carried in the request sent, or when the operation and maintenance system detects that the fault data at a certain point in time needs to be handled, and requests the system to give priority to processing a certain timestamp or a certain category of fault data, the system sends a request with a queue index to the unit, finds the corresponding fault data in the unit's queue and calls it for priority processing.

[0098] The following is an introduction to the types of indexes that can be created: Timestamp index: Sort the data by timestamp. The earlier the data enters the unit, the higher the queue. The later the data enters the unit, the lower the queue. In this way, when processing fault data, the data with earlier timestamps can be processed first to ensure the timeliness of data processing.

[0099] Severity index: Sort the data by severity. Data with higher severity levels are placed at the front of the queue, and data with lower severity levels are placed at the back of the queue. In this way, when processing fault data, data with higher severity levels can be processed first to ensure the priority of fault processing.

[0100] Fault classification index: Sort the data by fault classification, and put the data of the same classification together. In this way, when processing fault data, the data of the same classification can be processed first, which improves processing efficiency.

[0101] Combined index: You can combine the above multiple indexes to use, for example, sort by severity level first, and then sort by timestamp. This can ensure that data processing is timely while giving priority to data with higher severity levels.

[0102] It should be understood that a suitable indexing method may be selected according to specific scenarios to improve data processing efficiency.

[0103] In the embodiment of the present invention, by adding a queue index in a unit and calling a designated fault in the unit according to the queue index, faults that need to be handled urgently can be handled preferentially.

[0104] Based on any of the above embodiments, Figure 3 is a flow chart of the multi-active disaster recovery method under the cloud native architecture provided by the present invention, such as Figure 3 As shown, the method includes: Step 310, receiving a flow request, converting the protocol of the flow request into a standard protocol, and parsing the flow request to obtain a parsing result; Step 320, determining the concurrent scenario to which the traffic request belongs, and determining a corresponding diversion tool based on the concurrent scenario, and applying the diversion tool and the analysis result to distribute the traffic to each unit; Step 330 , monitor the traffic of each unit, and when it is detected that the traffic of any unit exceeds a threshold, perform secondary diversion on the traffic of any unit based on a preset routing rule.

[0105] It should be noted that the method provided in the embodiment of the present invention can be applied to a multi-active disaster recovery system under a cloud-native architecture. Other embodiments or specific implementation methods of the multi-active disaster recovery method under a cloud-native architecture provided by the present invention can refer to the above-mentioned system embodiments and will not be repeated here.

[0106] The method provided by the embodiment of the present invention can achieve effective utilization of resources and avoid waste of resources during high concurrency and idle resources during low concurrency by dynamically selecting diversion tools according to the concurrent scenario to which the traffic request belongs. This flexibility enables the system to better adapt to the needs of different business scenarios. Moreover, the system is designed with a unified interface that can convert other protocols into standard protocols, thereby processing traffic requests of different protocols, improving the universality of the system so that the system can be applied to different scenarios. In addition, by monitoring the traffic conditions of each unit in real time, the traffic data in the unit can be automatically diverted for a second time according to the routing rules when an overload is found, effectively avoiding overload of a single unit, alleviating the burden on the unit, and thus improving the efficiency of fault handling.

[0107] Figure 4 An example of a physical structure diagram of an electronic device is shown in FIG. Figure 4 As shown, the electronic device may include: a processor 410, a communication interface 420, a memory 430 and a communication bus 440, wherein the processor 410, the communication interface 420, and the memory 430 communicate with each other through the communication bus 440. The processor 410 may call the logic instructions in the memory 430 to execute the multi-active disaster recovery method under the cloud native architecture, the method comprising: receiving a flow request, converting the protocol of the flow request into a standard protocol, parsing the flow request to obtain a parsing result; determining the concurrent scenario to which the flow request belongs, and determining the corresponding diversion tool based on the concurrent scenario, applying the diversion tool and the parsing result to distribute the flow to each unit; monitoring the flow of each unit, and in the case where the flow of any unit is monitored to exceed the threshold, performing secondary diversion on the flow of any unit based on a preset routing rule.

[0108] In addition, the logic instructions in the above-mentioned memory 430 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the relevant technology or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0109] On the other hand, the present invention also provides a computer program product, which includes a computer program, and the computer program can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the multi-active disaster recovery method under the cloud native architecture provided by the above methods, and the method includes: receiving a traffic request, and converting the protocol of the traffic request into a standard protocol, parsing the traffic request to obtain a parsing result; determining the concurrent scenario to which the traffic request belongs, and determining a corresponding diversion tool based on the concurrent scenario, and applying the diversion tool and the parsing result to distribute the traffic to each unit; monitoring the traffic of each unit, and when it is monitored that the traffic of any unit exceeds a threshold, performing secondary diversion on the traffic of any unit based on preset routing rules.

[0110] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it is implemented to execute the multi-active disaster recovery method under the cloud native architecture provided by the above-mentioned methods. The method includes: receiving a traffic request, and after converting the protocol of the traffic request into a standard protocol, parsing the traffic request to obtain a parsing result; determining the concurrent scenario to which the traffic request belongs, and determining a corresponding diversion tool based on the concurrent scenario, and applying the diversion tool and the parsing result to distribute the traffic to each unit; monitoring the traffic of each unit, and when it is monitored that the traffic of any unit exceeds a threshold, performing secondary diversion on the traffic of any unit based on preset routing rules.

[0111] 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 displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0112] 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 necessary general hardware system, and of course, can also be implemented 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.

[0113] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-active disaster recovery system under a cloud native architecture, characterized in that: include: A flow receiving module, used for receiving a flow request, converting the protocol of the flow request into a standard protocol, and then parsing the flow request to obtain a parsing result; A traffic distribution module, used to determine the concurrent scenario to which the traffic request belongs, determine the corresponding diversion tool based on the concurrent scenario, and apply the diversion tool and the analysis result to distribute the traffic to each unit; The flow monitoring module is used to monitor the flow of each unit, and when it is monitored that the flow of any unit exceeds a threshold, the flow of any unit is secondary diverted based on a preset routing rule.

2. The multi-active disaster recovery system under the cloud native architecture according to claim 1, characterized in that: The flow distribution module comprises: A tool determination unit, used to determine the concurrent scenario to which the traffic request belongs, and determine a corresponding diversion tool based on the concurrent scenario; A mode determination unit, configured to apply a traffic analysis tool to determine the business scenario to which the traffic request belongs, and determine a diversion mode based on the business scenario; A flow distribution unit is used to distribute the flow to each unit based on the diversion tool and the analysis result according to the diversion mode and diversion granularity.

3. The multi-active disaster recovery system under the cloud native architecture according to claim 2, characterized in that: The tool determination unit is specifically used for: Obtain the number of requests for the traffic corresponding to the traffic request at the same time; When the number of requests exceeds a preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a high concurrency scenario, and it is determined that the diversion tool corresponding to the high concurrency scenario is a load balancer; When the number of requests does not exceed the preset threshold, it is determined that the concurrency scenario to which the traffic request belongs is a low concurrency scenario, and it is determined that the diversion tool corresponding to the low concurrency scenario is DNS polling.

4. The multi-active disaster recovery system under the cloud native architecture according to claim 2, characterized in that: The diversion mode includes any one of diversion by proportion and diversion by business attribute, and the diversion granularity includes any one of diversion by domain name and diversion by URI prefix.

5. The multi-active disaster recovery system under the cloud native architecture according to claim 1, characterized in that: Also includes: A fault handling module is used to, upon receiving a fault handling request, search for corresponding fault data in the queues of each unit and perform call processing based on the fault index carried in the fault handling request, wherein a queue index is added to the queue of each unit, the queue index is established based on the fault data, and the queue index corresponds to the fault index.

6. The multi-active disaster recovery system under the cloud native architecture according to claim 5, characterized in that: The queue index is established based on at least one of a timestamp index, a severity index, and a fault classification index of the fault data.

7. The multi-active disaster recovery system under the cloud native architecture according to any one of claims 1 to 6, characterized in that: The system is used to replicate and synchronize applications between different data centers, where a plurality of data centers are provided. The system further includes: The central monitoring module is used to monitor the operation of each data center and call other data centers for processing when a failure is detected in the running data center.

8. A multi-active disaster recovery method under a cloud native architecture, characterized in that: include: receiving a flow request, converting a protocol of the flow request into a standard protocol, and parsing the flow request to obtain a parsing result; Determine the concurrent scenario to which the traffic request belongs, determine a corresponding traffic diversion tool based on the concurrent scenario, and apply the traffic diversion tool and the analysis result to distribute the traffic to each unit; The traffic of each unit is monitored, and when it is detected that the traffic of any unit exceeds a threshold, the traffic of any unit is secondary diverted based on a preset routing rule.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the multi-active disaster recovery method under the cloud native architecture as claimed in claim 8 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, the multi-active disaster recovery method under the cloud native architecture as claimed in claim 8 is implemented.

Images