Multi-active disaster recovery system and method under cloud native architecture, electronic device and storage medium

Abstract

The application relates to the technical field of computers and provides a multi-active disaster recovery system and method under a cloud native architecture, electronic equipment and a storage medium, wherein the system comprises: a traffic receiving module, which is used for receiving a traffic request, converting the protocol of the traffic request into a standard protocol, analyzing the traffic request to obtain an analysis result, a traffic distribution module, which is used for determining a concurrent scene to which the traffic request belongs, determining a corresponding distribution tool based on the concurrent scene, and distributing traffic to each unit by applying the distribution tool and the analysis result, and a traffic monitoring module, which is used for monitoring the traffic of each unit and performing secondary distribution of the traffic of any unit based on a preset routing rule when the traffic of any unit exceeds a threshold value. The application can dynamically select a distribution tool according to different concurrent scenes, saves system resources, can access traffic of different protocols, and improves the universality of the system.

Description

TECHNICAL FIELD

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

[0002] In today's increasingly mature cloud computing and microservice architecture, 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, has emerged to help enterprises cope with various potential system risks and challenges by building a highly available, multi-active and disaster recovery architecture.

[0003] However, the current AppActive adopts a unified strategy for traffic splitting, without intelligent scheduling based on the actual characteristics of the traffic and the system resource state, which can easily lead to high-performance splitting tools being used to handle low-concurrency traffic, resulting in waste of system resources. In addition, during the fault data splitting process, AppActive often causes a single unit to be overloaded due to the use of a fixed splitting method, while other units are in an idle state. This uneven processing capacity affects the efficiency and effectiveness of overall fault recovery. SUMMARY

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

[0005] The present application provides a multi-active disaster recovery system under a cloud native architecture, comprising:

[0006] A traffic receiving module for receiving traffic requests and converting the protocols of the traffic requests to standard protocols before parsing the traffic requests to obtain parsing results;

[0007] A traffic allocation module for determining the concurrency scenario to which the traffic requests belong and determining the corresponding splitting tool based on the concurrency scenario, and applying the splitting tool and the parsing results to allocate traffic to each unit;

[0008] A traffic monitoring module for monitoring the traffic of each unit and, in the event that the traffic of any unit exceeds a threshold value, performing secondary splitting of the traffic of the any unit based on a preset routing rule.

[0009] According to the multi-active disaster recovery system under a cloud native architecture provided by the present application, the traffic allocation module comprises:

[0010] a tool determination unit configured to determine a concurrent scenario to which the traffic request belongs, and determine a corresponding shunting tool based on the concurrent scenario;

[0011] a mode determination unit configured to determine a service scenario to which the traffic request belongs by applying a traffic analysis tool, and determine a shunting mode based on the service scenario;

[0012] a traffic distribution unit configured to distribute traffic to each unit according to the shunting mode and shunting granularity based on the shunting tool and the resolution result.

[0013] According to the multi-active disaster recovery system under the cloud native architecture provided by the application, the tool determination unit is specifically configured to:

[0014] acquire a request number of the traffic corresponding to the traffic request at the same time;

[0015] determine that the concurrent scenario to which the traffic request belongs is a high-concurrency scenario when the request number exceeds a preset threshold, and determine that the shunting tool corresponding to the high-concurrency scenario is a load balancer;

[0016] determine that the concurrent scenario to which the traffic request belongs is a low-concurrency scenario when the request number does not exceed the preset threshold, and determine that the shunting tool corresponding to the low-concurrency scenario is DNS polling.

[0017] According to the multi-active disaster recovery system under the cloud native architecture provided by the application, the shunting mode includes any one of proportional shunting and service attribute shunting, and the shunting granularity includes any one of domain name shunting and URI prefix shunting.

[0018] According to the multi-active disaster recovery system under the cloud native architecture provided by the application, the system further comprises:

[0019] a fault processing module configured to, when a fault processing request is received, find corresponding fault data in the queue of each unit and perform call processing based on a fault index carried in the fault processing request, wherein a queue index is added to the queue of each unit, the queue index is established based on fault data, and the queue index corresponds to the fault index.

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

[0021] According to the multi-active disaster recovery system under the cloud native architecture provided by the application, the system is used for replicating and synchronizing application programs between different data centers, a plurality of data centers are provided, and the system further comprises:

[0022] A central monitoring module is configured to monitor the operation of each data center, and in the event that a running data center is found to have a fault, other data centers are called to handle the fault.

[0023] The application further provides a multi-active disaster recovery method under a cloud native architecture, comprising:

[0024] A traffic request is received, and a protocol of the traffic request is converted into a standard protocol, and then the traffic request is parsed to obtain a parsing result;

[0025] A concurrent scenario to which the traffic request belongs is determined, and a corresponding shunting tool is determined based on the concurrent scenario, and the shunting tool and the parsing result are applied to distribute traffic to each unit;

[0026] The traffic of each unit is monitored, and in the event that the traffic of any unit exceeds a threshold value, the traffic of the any unit is secondarily shunted based on a preset routing rule.

[0027] The application further provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the multi-active disaster recovery method under the cloud native architecture when executing the computer program.

[0028] The application further provides a non-transitory computer-readable storage medium having a computer program stored thereon, and the computer program is executable by a processor to implement the multi-active disaster recovery method under the cloud native architecture.

[0029] The application further provides a computer program product comprising a computer program, and the computer program is executable by a processor to implement the multi-active disaster recovery method under the cloud native architecture.

[0030] The multi-active disaster recovery system and method under the cloud native architecture provided by the application can effectively utilize resources, avoid waste of resources in high concurrency and idling of resources in low concurrency, and the flexibility makes the system better adapt to the needs of different business scenarios. Moreover, the system designs a unified interface, which can convert other protocols into a standard protocol, thereby realizing processing of traffic requests of different protocols and 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 of each unit in real time, and when overload is found, the traffic data in the unit is automatically secondarily shunted according to the routing rule, effectively avoiding overload of a single unit and relieving the burden of the unit, thereby improving the processing efficiency of faults. BRIEF DESCRIPTION OF DRAWINGS

[0031] In order to make the technical solutions in the present application or the related art clearer, the accompanying drawings needed in the embodiments or the related art description will be briefly introduced. Obviously, the accompanying drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative work on the premise of the accompanying drawings.

[0032] Figure 1 is a structural schematic diagram of an AppActive service model provided by the present application;

[0033] Figure 2 is a structural schematic diagram of a multi-live disaster recovery system under a cloud native architecture provided by the present application;

[0034] Figure 3 is a flow schematic diagram of a multi-live disaster recovery method under a cloud native architecture provided by the present application;

[0035] Figure 4 is a structural schematic diagram of an electronic device provided by the present application. DETAILED DESCRIPTION

[0036] In order to make the technical solutions in the present application or the related art clearer, the accompanying drawings needed in the embodiments or the related art description will be briefly introduced. Obviously, the accompanying drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative work on the premise of the accompanying drawings.

[0037] AppActive is an open-source middleware for building cloud-native high-availability multi-live disaster recovery architecture for business applications. It aims to help build high-availability, multi-live and disaster recovery architecture for cloud-native applications. AppActive can help developers replicate and synchronize applications between different data centers and cloud service providers, 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 the reliability of the business and user experience. This feature makes AppActive an indispensable technical component for many enterprises when building cloud-native applications.

[0038] However, although AppActive shows great potential in promoting high availability and disaster recovery capability of cloud-native applications, it still has some defects. First, AppActive uses the same shunting tool for different flows, which wastes system resources and makes the shunting tool with better performance used to handle low-concurrency flows. Second, AppActive needs to set an interface for each protocol, which not only increases the complexity of the system, but also increases the cost of transformation and maintenance and reduces the development efficiency. Third, in the process of shunting fault data, AppActive often causes excessive fault data in a single unit due to the use of a fixed shunting method, which causes load on the unit, while other units are in an idle state, affecting the processing progress of the fault data. In addition, AppActive currently cannot set processing priorities according to the urgency of fault data, which may cause urgent faults to be not responded in time, thereby affecting the normal operation of the business and user experience.

[0039] To this end, the application transforms the open source multi-live disaster recovery component AppActive to obtain a multi-live disaster recovery system under a cloud-native architecture, thereby overcoming the above-mentioned defects. The specific transformation includes: first, different shunting tools can be selected according to high-concurrency or low-concurrency scenarios to avoid wasting system resources; second, the interface is transformed and a unified interface is designed to make the system interface applicable to flow requests of different protocols; and third, the application can perform secondary shunting within a unit to relieve the burden of the unit and improve the processing efficiency of faults by performing secondary shunting on the data in the overloaded unit according to routing rules; the application can add a queue index within the unit and call the specified fault in the unit according to the queue index to quickly call the fault that needs to be handled urgently; in addition, the application sets up multiple data centers, each of which realizes data synchronization and simultaneously monitors the running status of the data center, so that if the running data center fails, another data center can be called to directly handle the fault, thereby ensuring the timeliness of fault handling.

[0040] The architecture of AppActive will be briefly introduced below. Figure 1 is a structural schematic diagram of the AppActive business model provided by the application, as Figure 1 shown, the overall architecture of AppActive covers the data plane and the control plane, and manages application flows and data throughout the process, which mainly consists of data plane code, control plane code and application Demo. AppActive is divided into four parts on the business model, including:

[0041] Configuration: Control plane - disaster recovery configuration. Based on the Configuration module, the application can quickly manage disaster recovery resource definition, basic disaster recovery strategy configuration, and complete daily initialization access and operation and maintenance functions.

[0042] Execute: Control plane - disaster recovery execution. Based on the Execute module, in the rehearsal or disaster scenario, the core action is executed to ensure business continuity and promote rapid business recovery.

[0043] 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 the daily scenario, the stability and experience of business traffic are ensured, and the traffic is closed in the unit. In the disaster scenario, based on the core action of the Execute module, the traffic is scheduled at the minute level.

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

[0045] Among them, in the ApplicationTraffic module, three parts are built around the module:

[0046] (1) Bridge: Business component bridge. When an application completes a business request, it will involve multiple middleware components, such as entry gateway, microservice, message, database, 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.

[0047] (2) Rule: Multi-active rules. When the application performs multi-active disaster recovery, it involves IDC (Internet Data Center) definition, machine node definition, traffic rule definition, gray rule definition, a series of multi-active rule descriptions, and guarantees for smooth online and daily use of multi-active applications.

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

[0049] In terms of traffic type, based on the traffic request link, from top to bottom, the traffic can be divided into the following layers:

[0050] (1) Access Layer: Ingress traffic request, general business application entrance will have a layer of gateway. In AppActive, the access layer is responsible for receiving external traffic requests and distributing the requests to the corresponding backend services according to the configuration and policy. AppActive provides standard traffic control plugins in this layer to support the ingress traffic control of the application smoothly.

[0051] (2) Service Layer: Synchronous calling mode of internal application, generally restful direct calling or standard microservice framework. The service layer is the core part of AppActive that handles business logic, which can be composed of multiple microservices that communicate with each other in a synchronous or asynchronous manner. AppActive provides standard microservice control plugins in this layer to adapt to different microservice calling modes.

[0052] (3) Message Layer: Asynchronous calling mode of internal application, generally general MQ, such as RocketMQ, Kafka, etc. AppActive provides standard MQ control plugins in this layer to adapt to different message forms.

[0053] (4) Data Layer: Application access to database, database generally has mysql, nosql, Oracle. In AppActive, the data layer involves multiple database instances distributed in different data centers or cloud service providers. AppActive provides standard database control plugins in this layer to ensure data quality and adapt to different database forms.

[0054] In addition, AppActive also includes a control surface (or called configuration and management layer) for configuring, monitoring and managing the entire architecture. This layer can include configuration center, monitoring center, alarm system and other components to realize the configuration of disaster recovery strategy, monitoring of system state and alarm of abnormal conditions.

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

[0056] Figure 2 is a structural diagram of the multi-active disaster recovery system under the cloud native architecture provided by the application, as Figure 2 shown, the system comprises:

[0057] The traffic receiving module 210 is configured to receive a traffic request, convert the protocol of the traffic request into a standard protocol, and analyze the traffic request to obtain an analysis result.

[0058] The traffic distribution module 220 is configured to determine a concurrent scenario to which the traffic request belongs, determine a corresponding shunting tool based on the concurrent scenario, and distribute traffic to each unit by applying the shunting tool and the resolution result.

[0059] The traffic monitoring module 230 is configured to monitor the traffic of each unit, and perform secondary shunting on the traffic of any unit based on a preset routing rule when it is monitored that the traffic of the any unit exceeds a threshold.

[0060] It should be noted that in AppActive, the access layer is the entrance of all traffic of a unit, which can parse a 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 shunting mode and shunting granularity. Here, the purpose of parsing the request protocol is to understand the content and purpose of the request so as to be able to process it in the correct way subsequently. By parsing the request protocol, the access layer can obtain key data such as the request, request parameters, and request body.

[0061] A unit generally refers to a logically or physically relatively independent service or application deployment unit, which can be one or more service instances based on a micro-service 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, which is responsible for distributing the received request traffic to specific service instances in the back end. By guiding the traffic to the SLB, the access layer achieves load balancing and dynamic distribution of traffic, ensuring the stability and scalability of the back-end service.

[0062] Specifically, the access layer can include a traffic receiving module and a traffic distribution module. The traffic receiving module is configured to receive a traffic request, convert the protocol of the traffic request into a standard protocol, and parse the traffic request. The traffic distribution module is configured to determine a concurrent scenario to which the traffic request belongs, and select a corresponding shunting tool based on the concurrent scenario.

[0063] In a multi-active scenario, traffic will be sliced according to a certain latitude and shunted to different units. Here, latitude refers to a basis or condition for determining a traffic distribution strategy, which can be a comprehensive consideration of multiple factors, such as the user's region, device type, request type, user identity, etc. According to these latitudes, the system can divide the traffic into different subsets or slices. The system supports multiple shunting modes, such as proportional shunting and business attribute shunting, and the specific selection of the shunting mode depends on the needs of the business scenario. Therefore, the traffic distribution module can also be configured to determine a business scenario to which the traffic request belongs, and select a shunting mode according to different business scenarios.

[0064] In addition, the management layer of the system can include a traffic monitoring module responsible for real-time monitoring and analyzing the traffic of each unit. The traffic monitoring module can capture and collect traffic data of each unit in real time through probes or listeners deployed in the network, including but not limited to request volume, concurrency, response time, error rate, and other key indicators. Statistical analysis of the collected traffic data calculates 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 module detects that the traffic of a unit exceeds the threshold, it can provide decision support for secondary shunting according to pre-set routing rules or algorithms. That is, according to the current load conditions, traffic distribution, and business priority, etc., the secondary shunting scheme is intelligently formulated to alleviate the pressure on the overloaded unit.

[0065] The system provided by the embodiments of the present application can realize effective utilization of resources by dynamically selecting a shunting tool according to the concurrent scenario to which the traffic request belongs, avoid waste of resources during high concurrency and idle of resources during low concurrency, and the flexibility makes the system better adapt to the needs of different business scenarios. Moreover, the system designs a unified interface that can convert other protocols into standard protocols, thereby realizing processing of traffic requests of different protocols and 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 of each unit in real time and automatically perform secondary shunting of the traffic data in the unit according to the routing rules when an overload is found, effectively avoiding overload of a single unit and relieving the burden of the unit, thereby improving the processing efficiency of faults.

[0066] Based on any of the above embodiments, the traffic distribution module 220 includes:

[0067] The tool determination unit 221 is configured to determine the concurrent scenario to which the traffic request belongs and determine the corresponding shunting tool based on the concurrent scenario;

[0068] The mode determination unit 222 is configured to determine the business scenario to which the traffic request belongs by applying a traffic analysis tool and determine the shunting mode based on the business scenario;

[0069] The traffic distribution unit 223 is configured to distribute traffic to each unit according to the shunting mode and shunting granularity based on the shunting tool and the analysis result.

[0070] Specifically, in the multi-live scenario, the system can automatically select different shunting tools according to the actual situation to achieve efficient utilization of system resources. The traffic distribution module includes a tool determination unit. First, the concurrent scenario is determined by the tool determination unit to determine the corresponding shunting tool.

[0071] Further, the tool determination unit 221 is specifically configured to:

[0072] acquire a request number of the traffic at the same time corresponding to the traffic request;

[0073] in a case where the request number exceeds a preset threshold, judging that a concurrent scenario to which the traffic request belongs is a high-concurrency scenario, and determining that a shunting tool corresponding to the high-concurrency scenario is a load balancer;

[0074] in a case where the request number does not exceed the preset threshold, judging that the concurrent scenario to which the traffic request belongs is a low-concurrency scenario, and determining that a shunting tool corresponding to the low-concurrency scenario is DNS polling.

[0075] Specifically, a preset threshold can be set in the tool determination unit, the request number of each traffic at the same time is counted, if the request number exceeds the preset threshold, it is judged as a high-concurrency scenario, at this time, a load balancer can be used for traffic distribution, so as to ensure the availability and stability of the business; if the request number 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, the low-concurrency business will not affect the shunting process of the high-concurrency business, so as to improve the efficiency of system shunting. In the embodiment of the application, by selecting different shunting tools according to the high-concurrency or low-concurrency scenario, the waste of system resources can be avoided.

[0076] After the shunting tool is selected to access the traffic, the traffic can be distributed to different units. When distributing the traffic, the distribution can be further performed according to the shunting mode and the shunting granularity. The shunting mode is finally reflected in the routing rule, and the routing rule is a configuration which defines to which unit a certain traffic should belong. It should be understood that the specific shunting mode can be determined by using a traffic analysis tool (such as Wireshark, TCPdump, etc.) to judge the business scenario, then by capturing network packets, analyzing the protocol, port, traffic distribution and other information of the network traffic, to infer the business scenario of the network application, and then selecting the shunting mode according to different business scenarios. The shunting mode includes proportional shunting and business attribute shunting, and the specific shunting modes are as follows:

[0077] (1) Proportional distribution, in some business scenarios that need to be personalized to users or devices, such as e-commerce software, social software, audio and video software, etc., the individual characteristics of users or devices have a greater impact on the business, so different processing is needed for different users or devices. In this case, you can distribute 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 size, for example, the ID space can be divided into 10 intervals, each interval has an ID range of 1-10, 11-20, 21-30, etc. Each interval is mapped to a different unit, and each unit is responsible for processing a certain range of IDs. According to the ID of the request, determine the interval to which it belongs, and then forward the request to the corresponding unit for processing. Since the size of each interval and the capacity of each unit are proportional, global load balancing can be achieved.

[0078] (2) Distribution by business attribute, in some business scenarios that require different processing of traffic, such as game software, CDN, etc., in these scenarios, the attributes of traffic have a greater impact on the business, so different processing is needed for different traffic. That is, traffic is distributed by traffic attribute, such as introducing crawler traffic into a specific unit, or distributing by province. Crawlers, provinces, etc. can be abstracted into a tag, so different tag values can be introduced into different units. This distribution mode can support physical isolation of traffic with different business attributes.

[0079] In addition, the distribution granularity refers to the degree of subdivision of traffic allocation when distributing traffic. The distribution granularity can include distribution by domain name and distribution by URI prefix, where distribution by domain name refers to distinguishing different applications by different domain names, such as the domain name of application App1 is App1.example.com and the domain name of App2 is App2.example.com. Distribution by URI prefix refers to distinguishing different applications by different URI prefixes, such as the domain names of applications App1 and App2 are both App.example.com, but the traffic with the / App1 prefix in the URI is introduced into App1, and the traffic with the / App2 prefix is introduced into App2.

[0080] After the above steps, after determining the distribution tool, distribution mode and distribution granularity, the traffic can be allocated to each unit according to the analysis result using the distribution tool, according to the corresponding distribution mode and distribution granularity.

[0081] Based on any of the above embodiments, the embodiments of the present application design a unified interface by using a protocol adapter, so that different protocols can use the same interface for access, improving the universality of the system so that the system can be applied to different scenarios. Here, the traffic receiving module described above is the interface module, which is the portal for the system to interact with the outside world, and it defines which types of requests the system can receive and how to process these requests. Traffic requests refer to data requests sent to the system from external systems (such as clients, other servers, etc.), which 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 unified format for internal processing (i.e. standard protocol), and interact through a unified interface.

[0082] Specifically, first, a standard protocol can be determined, and a standard protocol is selected as an interface protocol in the access layer, and the embodiments of the present application can select the HTTP protocol as the standard protocol; second, a protocol adapter is used to convert other protocols into a 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., and the traffic of other protocols can use the standard protocol to access the interface, and the unified interface is used in the access layer to respond.

[0083] Among them, according to the standard protocol (HTTP protocol), the unified interface method is defined as follows:

[0084] (1) Resource URI: specifies the identifier of the resource to be accessed, such as / users, / orders, etc.

[0085] (2) HTTP method: specifies the operation to be performed on the resource, such as GET, POST, PUT, DELETE, etc.

[0086] (3) Request header: used to pass additional information about the request, such as Content-Type, Authorization, etc.

[0087] (4) Request parameter: data contained in the request, passed in the form of key-value pairs, such as username=xxx&password=xxx, etc.

[0088] (5) Request body: used to pass request data, such as JSON, XML, binary data, etc.

[0089] (6) Response status code: indicates the status of the request, such as 200 OK, 404 NotFound, etc.

[0090] (7) Response Header: contains metadata related to the response, such as Content-Type, Content-Length, etc.

[0091] (8) Response Body: contains response data, such as JSON, XML, HTML, etc.

[0092] Through the above steps, the interface definition is completed. Traffic can access the interface using standard protocols (HTTP protocol) and use a unified interface definition for requests and responses. At the same time, the client's request data can be passed through request headers, request parameters, and request bodies, and the server's response data can be returned through response status codes, response headers, and response bodies.

[0093] It can be understood that the access layer of the system supports four-layer and seven-layer rich traffic request protocols to meet the diverse needs of users in Internet, Internet of Things, and other scenarios. For example, the access layer supports HTTP protocol by default, parses the domain name and URI from the HTTP protocol, and performs forwarding routing; the access layer also supports HTTPS protocol, provides centralized domain name certificate management, and meets the requirements of reliable transmission and secure transmission of users. If the user configures the domain name certificate in the access layer, the application SLB does not need to configure the certificate again. In addition, the access layer supports other HTTP-based protocols such as SOAP in addition to HTTP and HTTPS protocols. The access layer has great extensibility in protocols and can quickly support special protocols in the form of plug-ins, such as MQTT and COAP in Internet of Things scenarios.

[0094] Based on any of the above embodiments, in order to ensure that the traffic can be closed-loop within the unit, the access layer, the application layer, and the data layer each layer will perform routing error correction or unit protection. In order to identify the traffic, the unit type and the shunt id to which the traffic belongs need to be determined, which is called routing parameter, so that the correct unit to which the traffic belongs can be calculated through routing rules. Therefore, the routing parameter needs to be transmitted along with the request path, which is called routing transmission. The specific introduction is as follows:

[0095] (1) Access layer routing transmission

[0096] When the browser initiates a business request, the routing parameter needs to be carried in the request. The routing parameter can be in cookie, head, or body, and cookie is recommended. The access layer can parse the HTTP request, get the routing parameter, and route to the correct application SLB, while the application server can still get the original routing parameter from the request.

[0097] (2) Application layer routing transmission

[0098] Traffic arrives at the application server, the multi-active providing plug-in extracts the routing parameters from the HTTP request and saves them to the context. The next step application can initiate RPC calls or asynchronous messages, so the routing parameters also need to be transparently passed in the RPC and message layer.

[0099] (3) RPC routing transparent transmission

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

[0101] (4) Message routing transparent transmission

[0102] When the MQ client sends a message, it will get the routing parameters from the current context and add them to the message properties. When the MQ client consumes a message, it can take out the routing parameters from the message properties and also save them to the call context. The routing parameter transmission process in MQ is transparent to the user.

[0103] (5) Data layer routing transparent transmission

[0104] Data dirty writing can cause serious consequences, so you need to ensure that the data falls into the correct unit DB. Multi-active provides DRIVER plug-in to reject requests from non-unit.

[0105] Based on any of the above embodiments, in the disaster recovery scenario, each unit is independent in the ideal scenario, but in fact there will be some cross-unit scenario business scenarios. In order to meet these scenarios, the system needs to provide unit cooperation capabilities. Specifically, it includes:

[0106] (1) Center call

[0107] Some specific business scenarios require that specific services be provided only in specific center units to ensure data strong consistency. All calls to the center service will be directly routed to the center unit to complete. The cross-region multi-active product uses the CSB component and the RPC multi-active plug-in to complete the cooperative call between service units, meeting the integrity of the business.

[0108] (2) Unit protection

[0109] The product guarantees the global correctness of the business logic and will not cause unit business logic inconsistency problems due to stream cutting operations. Each layer of the system from top to bottom has error correction protection capabilities for incorrect traffic, ensuring that the business is correctly transferred according to the unitization rules.

[0110] (3) Access layer error correction

[0111] Traffic enters the access layer, which determines the unit to which the traffic belongs by using the routing parameters attached to the request. Traffic that is not in its own unit will be proxied to the correct target unit, thus ensuring the correctness of the ingress traffic to the access layer.

[0112] (4) RPC error correction

[0113] During RPC service calls, the RPC multi-active plugin on the Consumer side performs correct routing for the service call based on the requested unit information. For incorrect traffic service calls, the RPC multi-active plugin calculates the correct target unit and calls the target unit service across units, ensuring the consistency of service flow logic. Simultaneously, on the Provider side, the RPC multi-active plugin performs a second verification on incoming requests to ensure the correctness of the service call. Through this dual verification mechanism, the RPC multi-active plugin achieves error correction for RPC calls, guaranteeing the correctness of service calls.

[0114] Based on any of the above embodiments, the system also provides a horizontal scaling function. When the service capacity of the existing unit has reached its limit and cannot be expanded, the system can provide a simple and quick horizontal scaling capability for the unit: the expansion of new units nationwide is not limited by region; the number of new units expanded is unlimited, and the stability and performance of the unit are not affected by the number of units; two types of unit expansion are provided, namely, remote units with independent DB and local units with shared DB.

[0115] Based on any of the above embodiments, the modified AppActive of this invention can connect to systems such as ERSS (Emergency Support Automation System), EACS (Emergency Action Command Automation System), EIMS (Emergency Information Management System), ESM (Emergency Supplies Management System), and ERS (Emergency Rescue System) to achieve multi-active disaster recovery in case of failure. In addition, AppActive can also be used in e-commerce, finance, logistics, and other fields to help enterprises ensure business continuity.

[0116] Based on any of the above embodiments, considering that AppActive does not provide a method for adapting to other platforms in the prior art, this embodiment of the invention adapts AppActive to the connected platforms to form a cross-domain multi-active disaster recovery technology component under a cloud-native architecture. The specific modification method is as follows:

[0117] (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 referred to as Platform A (Platform A can be a system platform such as ERSS, EACS, EIMS, ESM, ERS, etc.).

[0118] Specifically, the request is re-encapsulated at the gateway layer of the A platform, and a filtering rule is added to ensure that the request at the gateway layer of the A platform 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 the A platform is spirng-cloud-gateway, the employee-related 4A account in the request is extracted, and the extracted 4A account is placed in the header of the request and transmitted to the gateway layer of AppActive, so that AppActive can obtain these key information and forward it according to the corresponding routing rules. Here, the 4A account refers to a key account information used for identity authentication and authorization.

[0119] (2) Modification of AppActive routing rule judgment source code

[0120] Secondly, since the routing rules of AppActive only support judgment based on numerical intervals, which does not match the current business status of the A platform, it is necessary to modify the routing rule judgment source code of AppActive to support the routing of 4A accounts of the A platform. For example, in the routing judgment source code of AppActive, the 4A account information in the request header can be obtained, and the judgment logic of the 4A account can be added, and the 4A account can be used as a key parameter for routing, and the request can be routed to the corresponding downstream service, so that AppActive can obtain these key information. Thus, the routing rules of AppActive can support the judgment of 4A accounts.

[0121] (3) Switching modification of application layer

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

[0123] (4) Traffic switching modification

[0124] Since the current AppActive does not provide a front-end page to implement the switching of traffic actions, the interface of AppActive can be developed to obtain an AppActive traffic switching interface supporting the worker number of platform A as a dimension. Specifically, the classes, interfaces and the like required for use can be introduced first, and then the instance is automatically injected into the corresponding class, and the traffic switching method in the traffic switching service is called to switch the traffic.

[0125] (5) Use nacos-sync to synchronize service information between dual centers

[0126] The nacos-sync is used for information synchronization between data center A and data center B, so that the same service can be accessed by both centers. For example, if a certain data is unregistered in center A, the nacos-sync will synchronize the unregistration information of the corresponding data to center B, so that the service information of the two centers always remains consistent. When center A fails, since the data of center A and center B is synchronized, the task of center A can be directly executed through center B, which can improve the availability and fault tolerance of the emergency guarantee automation platform, and also ensures the normal operation of the system in the multi-active scene.

[0127] When the Gateway and the application layer make service calls across centers, the service to be called is matched according to the pre-defined routing rules, and the corresponding service is searched in the current nacos service registration center. In this way, multi-active calling across centers can be realized, and the emergency guarantee automation platform can be ensured to operate normally when making service calls between different data centers.

[0128] The embodiments of the application provide a method and an example for adapting AppActive to other platforms, so that the application of AppActive can be implemented in the field, avoiding problems such as untimely handling of emergency events and unguaranteed effects caused by system dispersion, and greatly improving the efficiency of handling emergency events.

[0129] Based on any of the above embodiments, nacos (Dynamic Naming and Configuration Service) also supports using Clustered mode (i.e. cluster mode) for service information synchronization between multiple centers. In the Clustered mode, multiple Nacos instances form a cluster, and each instance can receive and process requests and share the same database. When an instance modifies the service information, the change information is immediately synchronized to other instances, thereby realizing service information synchronization between multiple centers. Therefore, in the multi-center scenario, the fault event can be handled in time.

[0130] Specifically, the application program can be deployed in multiple data centers through container orchestration technology. Using containerization technology such as Docker, the application program is packaged into a container image, and then using container orchestration technology such as Kubernetes or DockerSwarm, the container image is deployed into a cluster of multiple data centers. The load balancing of the application program is configured in the container orchestration tool to ensure that the traffic is balanced among multiple data centers, and the data replication and synchronization are configured according to the needs of the application program to ensure the data consistency among multiple data centers.

[0131] Further, the multi-active disaster recovery system is used for replicating and synchronizing the application program among different data centers, and the system further comprises:

[0132] The center monitoring module 250 is used for monitoring the operation of each data center, and calling other data centers for processing in case of failure of the data center being operated.

[0133] Specifically, the load of the center can be monitored using a monitoring tool to detect the data execution amount in a center in real time, such as Zabbix, Nagios, etc. These tools can monitor the use of resources such as CPU, memory, network, etc. of the server in real time, so as to know the data execution amount in a single center.

[0134] When the data execution amount of a single center is too much, part of the data can be transferred to other centers for execution through load balancing technology to achieve load balancing. In actual operation, a load balancer can be used to achieve load balancing. When the data execution amount of a single center is too much, part of the request can be transferred to other centers, thereby achieving load balancing. Common load balancers include Nginx, HAProxy, etc.

[0135] Further, each data center can include multiple units, and a load balancer can also be used in each unit. After the traffic is distributed according to the distribution rule, if the emergency events allocated to a single unit are too much, the unit can be secondarily distributed according to another distribution rule, and the load balancer can transfer part of the emergency events to other units for processing. The embodiment of the application can transfer the data corresponding to the unit with heavy load to other units through secondary distribution when the data in a single unit is too much, thereby avoiding the influence of too much data in a single unit on the timeliness of processing emergency events.

[0136] Through the above steps, the application program can be deployed in multiple data centers, and high availability and load balancing can be achieved through container orchestration technology.

[0137] Based on any of the above embodiments, the all-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. The all-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, the all-stack monitoring technology such as Prometheus.Grafana or ELK can be used to realize real-time monitoring and fault diagnosis of the system, so that when the system fails, the system can quickly respond, transfer the data to other centers for further processing, and avoid interruption or loss of data being processed.

[0138] Based on any of the above embodiments, the system further comprises:

[0139] The fault processing module 240 is configured to, in response to receiving a fault processing request, find corresponding fault data in the queue of each unit based on a fault index carried in the fault processing request and perform calling processing, wherein the queue of each unit is added with a queue index, the queue index is established based on fault data, and the queue index corresponds to the fault index.

[0140] 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 a timestamp of fault data occurrence or an index established according to a classification number of fault data. For example, establishing an index based on a timestamp of fault data occurrence includes the following steps: creating a Kafka topic, the topic name can be named according to the timestamp, and then writing the fault data into the corresponding topic according to the timestamp, and consuming the fault data in the topic according to the timestamp order. Thus, when the operation and maintenance system issues a request for urgent processing of a certain fault, the request carries the index of the fault that needs to be urgently solved, or when the operation and maintenance system detects that the fault data at a certain time point needs to be processed, the system requests to process the fault data of a certain timestamp or a certain category first, and the system sends a request with a queue index to the unit, finds the corresponding fault data in the queue of the unit, and performs calling processing first.

[0141] Next, the types of indexes that can be established are introduced:

[0142] Timestamp index: data is sorted according to timestamp, data that enters the unit earlier is placed in front of the queue, and data that enters the unit later is placed behind the queue. In this way, when processing fault data, the data with an earlier timestamp can be processed first to ensure the timeliness of data processing.

[0143] Severity level index: data is sorted according to severity level, data with a higher severity level is placed in front of the queue, and data with a lower severity level is placed behind the queue. In this way, when processing fault data, the data with a higher severity level can be processed first to ensure the priority of fault processing.

[0144] Fault classification index: sort the data according to fault classification, and the data of the same classification is arranged together. In this way, when processing fault data, the data of the same classification can be processed first, thereby improving the processing efficiency.

[0145] Combined index: the above multiple indexes can be combined for use, such as sorting according to the severity level first, and then sorting according to the timestamp, so that the data with a higher severity level can be processed preferentially while ensuring the timeliness of data processing.

[0146] It should be understood that appropriate index methods can be selected according to specific scenarios to improve data processing efficiency.

[0147] In the embodiment of the application, by adding a queue index in the unit and calling the specified fault in the unit according to the queue index, the fault requiring emergency processing can be processed preferentially.

[0148] Based on any of the above embodiments, Figure 3 is a flowchart of a multi-active disaster recovery method under a cloud native architecture provided by the application, as Figure 3 shown, the method comprises the following steps:

[0149] Step 310: receiving a traffic request, converting the protocol of the traffic request into a standard protocol, and then parsing the traffic request to obtain a parsing result;

[0150] Step 320: determining a concurrent scenario to which the traffic request belongs, determining a corresponding shunting tool based on the concurrent scenario, and distributing traffic to each unit by applying the shunting tool and the parsing result;

[0151] Step 330: monitoring the traffic of each unit, and in the case that the traffic of any unit exceeds a threshold value, performing secondary shunting of the traffic of the any unit based on a preset routing rule.

[0152] It should be noted that the method provided by the embodiment of the application can be applied to a multi-active disaster recovery system under a cloud native architecture, and other embodiments or specific implementation modes of the multi-active disaster recovery method under the cloud native architecture provided by the application can refer to the above-mentioned system embodiments, which will not be described here.

[0153] The method provided by the embodiment of the application can realize effective utilization of resources by dynamically selecting a shunting tool according to a concurrent scene to which a traffic request belongs, avoid waste of resources in high concurrency and idle of resources in low concurrency, and make the system better adapt to the needs of different business scenes. Moreover, the system designs a unified interface, can convert other protocols into a standard protocol, thereby realizing processing of traffic requests of different protocols, and improving the universality of the system, so that the system can be applied to different scenes. In addition, by monitoring the traffic conditions of each unit in real time, the traffic data in the unit can be automatically shunted again according to routing rules when overload is found, effectively avoiding overload of a single unit and relieving the burden of the unit, thereby improving the processing efficiency of faults.

[0154] Figure 4 An example of a schematic diagram of the physical structure of an electronic device is shown in Figure 4 The electronic device can 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 can communicate with each other through the communication bus 440. The processor 410 can invoke a logical instruction in the memory 430 to execute a multi-active disaster recovery method under a cloud native architecture, which includes receiving a traffic request, converting a protocol of the traffic request into a standard protocol, and then analyzing the traffic request to obtain an analysis result; determining a concurrent scene to which the traffic request belongs, and determining a corresponding shunting tool based on the concurrent scene; applying the shunting tool and the analysis result to distribute traffic to each unit; and monitoring the traffic of each unit, and performing secondary shunting of the traffic of any unit based on a preset routing rule when the traffic of the any unit exceeds a threshold value.

[0155] In addition, the logical instruction in the memory 430 described above can be implemented in the form of a software functional unit and sold or used as an independent product, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the application essentially or the parts that make contributions to the related art or parts of the technical solutions can be embodied in the form of a software product, and the computer software product is stored in a storage medium, includes a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the method described in the embodiments of the application. The foregoing storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0156] In another aspect, the present application also provides a computer program product comprising a computer program, which can be stored on a non-transitory computer-readable storage medium, and the computer program, when executed by a processor, enables a computer to perform the cloud-native architecture multi-active disaster recovery method provided by the above methods, which comprises: receiving a traffic request, converting the protocol of the traffic request into a standard protocol, and then parsing the traffic request to obtain a parsing result; determining a concurrent scenario to which the traffic request belongs, and determining a corresponding shunting tool based on the concurrent scenario, and distributing traffic to each unit by applying the shunting tool and the parsing result; monitoring the traffic of each unit, and in the case that the traffic of any unit exceeds a threshold, performing secondary shunting of the traffic of the any unit based on a preset routing rule.

[0157] In another aspect, the present application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, and the computer program, when executed by a processor, implements the cloud-native architecture multi-active disaster recovery method provided by the above methods, which comprises: receiving a traffic request, converting the protocol of the traffic request into a standard protocol, and then parsing the traffic request to obtain a parsing result; determining a concurrent scenario to which the traffic request belongs, and determining a corresponding shunting tool based on the concurrent scenario, and distributing traffic to each unit by applying the shunting tool and the parsing result; monitoring the traffic of each unit, and in the case that the traffic of any unit exceeds a threshold, performing secondary shunting of the traffic of the any unit based on a preset routing rule.

[0158] The device embodiments described above are only schematic, wherein the units shown as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the present embodiment. Those skilled in the art can understand and implement without creative labor.

[0159] From the above description of the embodiments, those skilled in the art can clearly understand that the embodiments can be realized by means of software plus necessary general hardware systems, and of course can also be realized by hardware. Based on such understanding, the above technical solutions, essentially or in terms of related art, can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a ROM / RAM, a magnetic disk, or an optical disk, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to perform the methods described in each embodiment or some parts of the embodiments.

[0160] It should be pointed out finally that the above embodiments are only used to illustrate the technical solutions of the present application, but not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features therein can be replaced equivalently; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A multi-active disaster recovery system under a cloud-native architecture, characterized in that, The system comprises: a traffic receiving module configured to receive a traffic request, convert a protocol of the traffic request into a standard protocol, and parse the traffic request to obtain a parsing result; a traffic distribution module configured to determine a concurrent scenario to which the traffic request belongs, determine a corresponding shunting tool based on the concurrent scenario, and distribute traffic to units by using the shunting tool and the parsing result; a traffic monitoring module configured to monitor the traffic of the units, and perform secondary shunting of traffic of any unit based on a preset routing rule when it is monitored that the traffic of the unit exceeds a threshold value; the traffic distribution module comprises a tool determination unit configured to: obtain a request number of the traffic corresponding to the traffic request at the same time; determine that the concurrent scenario to which the traffic request belongs is a high-concurrency scenario and determine that the shunting tool corresponding to the high-concurrency scenario is a load balancer when the request number exceeds a preset threshold value; determine that the concurrent scenario to which the traffic request belongs is a low-concurrency scenario and determine that the shunting tool corresponding to the low-concurrency scenario is a DNS round robin when the request number does not exceed the preset threshold value.

2. The multi-active disaster recovery system under the cloud-native architecture according to claim 1, characterized in that, The traffic distribution module further comprises: a mode determination unit configured to determine a service scenario to which the traffic request belongs by using a traffic analysis tool, and determine a shunting mode based on the service scenario; a traffic distribution unit configured to distribute traffic to units according to the shunting mode and a shunting granularity based on the shunting tool and the parsing result.

3. The multi-active disaster recovery system under the cloud-native architecture according to claim 2, characterized in that, The shunting mode comprises any one of proportional shunting and service attribute shunting, and the shunting granularity comprises any one of domain name shunting and URI prefix shunting.

4. The multi-active disaster recovery system under the cloud-native architecture according to claim 1, characterized in that, Further comprising: a fault processing module configured to, when a fault processing request is received, find corresponding fault data in a queue of the units and perform call processing based on a fault index carried in the fault processing request, wherein a queue index is added to the queue of the units, the queue index is established based on fault data, and the queue index corresponds to the fault index.

5. The multi-active disaster recovery system under the cloud-native architecture according to claim 4, characterized in that, 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. 6.The multi-active disaster recovery system under the cloud native architecture according to any one of claims 1 to 5, characterized in that, The system is used for replication and synchronization of application programs between different data centers, a plurality of data centers are provided, and the system further comprises: a center monitoring module configured to monitor running conditions of the data centers, and call other data centers for processing when it is monitored that a running data center fails.

7. A multi-active disaster recovery method under a cloud-native architecture, characterized in that, The system comprises: receiving a traffic request, converting a protocol of the traffic request into a standard protocol, and parsing the traffic request to obtain a parsing result; determining a concurrent scenario to which the traffic request belongs, determining a corresponding shunting tool based on the concurrent scenario, and distributing traffic to units by using the shunting tool and the parsing result; monitoring the traffic of the units, and performing secondary shunting of traffic of any unit based on a preset routing rule when it is monitored that the traffic of the unit exceeds a threshold value; The determining the concurrent scenario to which the traffic request belongs and determining the corresponding shunting tool based on the concurrent scenario comprises: acquiring a request number of the traffic corresponding to the traffic request at the same time; in a case where the request number exceeds a preset threshold, judging that the concurrent scenario to which the traffic request belongs is a high-concurrency scenario, and determining that the shunting tool corresponding to the high-concurrency scenario is a load balancer; in a case where the request number does not exceed the preset threshold, judging that the concurrent scenario to which the traffic request belongs is a low-concurrency scenario, and determining that the shunting tool corresponding to the low-concurrency scenario is DNS polling.

8. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the cloud-native architecture multi-active disaster recovery method of claim 7 when executing the computer program. 9.A non-transitory computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the cloud-native architecture multi-active disaster recovery method of claim 7.

Images