System management method and device, storage medium and electronic equipment

Abstract

The invention discloses a system management method and device, a storage medium and electronic equipment. The method comprises the following steps: under the condition that an operation state of a business system indicates that a channel integration layer of the business system needs to be subjected to disaster recovery backup switching, using a first channel integration layer subsystem to replace a second channel integration layer subsystem to receive a target business request; under the condition that the running state indicates that a product service layer of the business system needs to be subjected to disaster recovery backup switching, a first product service layer subsystem is used for replacing a second product service layer subsystem to process a target business request; and under the condition that the running state indicates that the external connection integration layer of the service system needs to be subjected to disaster recovery backup switching, the first external connection integration layer subsystem is used for replacing the second external connection integration layer subsystem to obtain target interaction data related to the target service request. The technical problem that the management efficiency of the system is low is solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a system management method and device, a storage medium, and an electronic device. Background Art

[0002] At present, in the relevant technologies, disaster recovery switching solutions often focus on the redundant backup and switching of the overall system. That is, under normal operating conditions, the resources of the disaster recovery center are in a low utilization or even idle state, resulting in a waste of resources; further, the overall system switching strategy requires a lot of coordination work when implemented, which not only increases the complexity and time-consuming nature of disaster recovery switching, but also fails to guarantee business continuity, which is not conducive to system management. In summary, there is a technical problem of low system management efficiency in the relevant technologies.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a system management method and device, a storage medium, and an electronic device to at least solve the technical problem of low system management efficiency.

[0005] According to one aspect of an embodiment of the present application, a system management method is provided, including: obtaining the operating status of a business system; when the operating status indicates that a channel integration layer of the business system needs to perform a disaster recovery switch, using a first channel integration layer subsystem to receive a target business request, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are respectively responsible for receiving business requests initiated by different businesses at the same time, and before the second channel integration layer subsystem fails, is used to receive the target business request; when the operating status indicates that a product service layer of the business system needs to perform a disaster recovery switch, using the first product service layer subsystem to process the target business request, wherein the product service The service layer includes a second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is used to process the target business request, and the first product service layer subsystem is used to process the target business request when the second product service layer subsystem fails; when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, the first external integration layer subsystem is used to obtain target interaction data related to the target business request, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to respectively receive interaction data related to different businesses at the same time, and before the second external integration layer subsystem fails, it is used to receive the target interaction data.

[0006] According to another aspect of an embodiment of the present application, a system management device is also provided, including: an acquisition module, used to acquire the operating status of a business system; an integration module, used to use a first channel integration layer subsystem to receive a target business request when the operating status indicates that a channel integration layer of the business system needs to perform a disaster recovery switch, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are used to respectively receive business requests initiated by different businesses at the same time, and the second channel integration layer subsystem is used to receive the target business request before a failure occurs; a service module, used to use the first product service layer subsystem to process the target business request when the operating status indicates that a product service layer of the business system needs to perform a disaster recovery switch, Among them, the product service layer includes a second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is used to process the target business request, and the first product service layer subsystem is used to process the target business request when the second product service layer subsystem fails; the integration module is used to use the first external integration layer subsystem to obtain target interaction data related to the target business request when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to be responsible for receiving interaction data related to different businesses at the same time, and before the second external integration layer subsystem fails, it is used to receive the target interaction data.

[0007] Optionally, the device is also used to: before obtaining the operating status of the business system, control the second channel integration layer subsystem and the first channel integration layer subsystem to register with the target service bus in an active state, wherein the target service bus is used to control the mutual calls between the subsystems in the business system, and the subsystem whose registration status is the active state represents the subsystem that executes the business after completing the registration; control the second product service layer subsystem to register with the target service bus in the active state, and control the first product service layer subsystem to register with the target service bus in a standby state, wherein the subsystem whose registration status is the standby state represents the subsystem that does not execute the business after completing the registration; control the second external integration layer subsystem and the first external integration layer subsystem to register with the target service bus in the active state.

[0008] Optionally, the device is also used to: when the business system requires disaster recovery switching and the target business layer is the product service layer, switch the registration status of the second product service layer from the active state to the standby state, and change the registration status of the first product service layer from the standby state to the active state.

[0009] Optionally, the device is also used to: when the business system needs disaster recovery switching and the target business layer is the channel integration layer, send a first prompt message to the channel integration layer, wherein the first prompt message is used to instruct the first channel integration layer subsystem to receive the target business request originally received by the second channel integration layer subsystem, and the second channel integration layer subsystem stops receiving the target business request; when the business system needs disaster recovery switching and the target business layer is the external integration layer, send a second prompt message to the external integration layer, wherein the second prompt message is used to instruct the first external integration subsystem to receive the target interaction data originally received by the second external integration layer subsystem, and the second channel integration layer subsystem stops receiving the target interaction data.

[0010] Optionally, the device is also used to: obtain a first address set and a second address set, wherein the first address set includes a preset initiation address of the target business request allowed to be obtained by the first channel integration layer subsystem, and the second address set includes a preset initiation address of the target business request allowed to be obtained by the second channel integration layer subsystem; in the case where the first business request and the second business request need to be received at the same time at the target moment, determine the first initiation address of the first business request and the second initiation address of the second business request respectively; in the case where the first initiation address is an address in the first address set, the first channel integration layer subsystem receives the first business request; in the case where the second initiation address is an address in the second address set, the second business request is received by the second channel integration layer subsystem.

[0011] Optionally, the device is also used to: obtain a first preset weight value and a second preset weight value, wherein the first preset weight value is used to indicate the amount of interaction data allowed to be obtained by the second external integration layer subsystem within a target time period, and the second preset weight value is used to indicate the amount of interaction data allowed to be obtained by the first external integration layer subsystem within the target time period; and control the second external integration layer subsystem and the first external integration layer subsystem to obtain the target interaction data within the target time period according to the first preset weight value and the second preset weight value respectively.

[0012] Optionally, the device is also used to: deploy the second channel integration layer subsystem, the second product service layer subsystem and the second external integration layer subsystem in the production environment of the business system before obtaining the operating status of the business system; and deploy the first channel integration layer subsystem, the first product service layer subsystem and the first external integration layer subsystem in the disaster recovery environment of the business system.

[0013] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the management method of the above system when running.

[0014] According to another aspect of the embodiment of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the management method of the above system.

[0015] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the system management method through the computer program.

[0016] In an embodiment of the present application, the operation status of the business system is obtained. When the operation status indicates that the channel integration layer of the business system needs to perform disaster recovery switching, the first channel integration layer subsystem is used to receive the target business request, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, and the first channel integration layer subsystem and the second channel integration layer subsystem are respectively responsible for receiving business requests initiated by different businesses at the same time, and the second channel integration layer subsystem is used to receive the target business request before a failure occurs; when the operation status indicates that the product service layer of the business system needs to perform disaster recovery switching, the first product service layer subsystem is used to process the target business request, wherein the product service layer includes the second product service layer subsystem and the first product service layer subsystem, and the second product service layer subsystem The service layer subsystem is used to process target business requests, and the first product service layer subsystem is used to process target business requests when the second product service layer subsystem fails; when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, the first external integration layer subsystem is used to obtain target interaction data related to the target business request, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, and the first external integration layer subsystem and the second external integration layer subsystem are respectively responsible for receiving interaction data related to different businesses at the same time. Before the second external integration layer subsystem fails, the method for receiving target interaction data can quickly respond to failures of subsystems at each layer and automatically realize disaster recovery switching, which significantly improves the system management efficiency and business continuity.

[0017] Furthermore, it is especially possible to implement differentiated disaster recovery strategies according to the characteristics of different layers, thereby avoiding waste of resources, enhancing the robustness of the system and its ability to respond to emergencies, thereby solving the problems of low system management efficiency, great difficulty in disaster recovery switching, and low resource utilization existing in existing disaster recovery solutions. In summary, the present application solves the technical problem of low system management efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional system management method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of an optional system management method according to an embodiment of the present application;

[0021] Figure 3is a schematic diagram of an optional system management method according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional system management method according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional system management method according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of the structure of an optional system management device according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of a structure of an optional system management product according to an embodiment of the present application;

[0026] Figure 8 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0029] First, the terms in this application are explained:

[0030] Channel integration layer: The channel integration layer integrates channel access, receives business requests from different channels, calls background services and returns results;

[0031] External integration layer: The external integration layer is responsible for the interaction between third-party systems and business systems, shielding the technical complexity of business systems;

[0032] Product service layer: The product service layer provides channel-independent product service processing and realizes business capabilities shared by business systems.

[0033] The present application is described below in conjunction with embodiments:

[0034] According to one aspect of an embodiment of the present application, a system management method is provided. Optionally, in this embodiment, the system management method can be applied to: Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1 As shown, the server 101 is connected to the terminal 103 via a network, and can be used to provide services for the terminal device or an application 107 installed on the terminal device. The application can be a video application, an instant messaging application, a browser application, an educational application, a game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include, but is not limited to, a wired network and a wireless network, wherein the wired network includes, for example, a local area network, a metropolitan area network, and a wide area network; the wireless network includes, for example, Bluetooth, WIFI, and other networks that implement wireless communication; the terminal device 103 may be a terminal configured with an application program, and may include, but is not limited to, at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal, and other computer devices; the above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0035] Combination Figure 1 As shown, the management method of the above system can be executed by an electronic device, which can be a terminal device or a server. The management method of the above system can be implemented by the terminal device or the server respectively, or by the terminal device and the server together.

[0036] The above is only an example and is not specifically limited in this embodiment.

[0037] Optionally, as an optional implementation, as Figure 2 As shown, the management method of the above system includes:

[0038] S202, obtaining the operating status of the business system;

[0039] Optionally, in an embodiment of the present application, the above-mentioned business systems include but are not limited to transaction business systems, electronic banking business systems, mobile payment business systems and other systems. The operating status of the above-mentioned business systems refers to the health status and operation mode of the business systems, including but not limited to whether the system is running, the number of running nodes, the utilization rate of node resources, network connection status, application response time, and system error logs and other information.

[0040] For example, when an abnormality occurs in the database of a node in the product service layer of a business system, the abnormal operating status of the node can be automatically detected, such as database response time timeout or excessive node resource utilization. This will trigger the disaster recovery switching process, stop the node service and be taken over by the corresponding components of the backup center to ensure business continuity.

[0041] It should be noted that in actual applications, the operating status of the business system may be affected by many factors, such as hardware failure, software bug, network delay, security attack, etc.

[0042] S204, when the operation status indicates that the channel integration layer of the business system needs to perform disaster recovery switching, using the first channel integration layer subsystem to receive the target business request, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are respectively responsible for receiving business requests initiated by different businesses at the same time, and the second channel integration layer subsystem is used to receive the target business request before a failure occurs;

[0043] Optionally, in an embodiment of the present application, the above-mentioned disaster recovery switching refers to switching the business system or the services provided by the business system from one location or device to another location or device to ensure the continuity and reliability of the business when the above-mentioned business system faces a catastrophic event or emergency. The above-mentioned first channel integration layer subsystem and the second channel integration layer subsystem refer to the front-end processing module of the business system, including but not limited to online banking access portals, mobile banking applications, self-service terminal service interfaces, etc. for various types of businesses. These subsystems can independently process user requests from different channels and forward the requests to the back-end product service layer and external integration layer through the internal network.

[0044] For example, in the application scenario of the online banking access portal for transaction-related services, the second channel integration layer subsystem (assuming it is the online banking access portal) suddenly reports a failure. The system monitoring platform immediately recognizes this state change and automatically reroutes all online banking business requests to the first channel integration layer subsystem (also the online banking access portal) to ensure that users can continue to process transaction-related services without being affected by the failure of a single portal.

[0045] It should be noted that the subsystems of the channel integration layer may face various types and degrees of failure when disaster recovery switching occurs, such as network interruption, server downtime, application crash or data processing abnormality.

[0046] In an exemplary embodiment, the business system is a transaction-type business system. When the second channel integration layer subsystem (online banking access portal) stops providing external services due to exhaustion of server resources, the first channel integration layer subsystem (also the online banking access portal) receives the business request that should have been processed by the online bank in the second channel integration layer subsystem. This process is completed through the intelligent routing of the service bus (the above-mentioned target bus) of the business system. After detecting that the operating status of the second channel integration layer subsystem is abnormal, the service bus automatically directs all subsequent target business requests to the first channel integration layer subsystem, which can seamlessly take over and process these requests to ensure that business continuity is not affected.

[0047] S206, when the operation status indicates that the product service layer of the business system needs to be switched to a disaster recovery state, the first product service layer subsystem is used to process the target business request, wherein the product service layer includes the second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is used to process the target business request, and the first product service layer subsystem is used to process the target business request when the second product service layer subsystem fails;

[0048] Optionally, in an embodiment of the present application, the above-mentioned first product service layer subsystem and the second product service layer subsystem refer to the core processing modules of the business system, taking the transaction business system as an example, including but not limited to fund transfer processing, transaction review logic, account information management, loan approval process, payment and clearing services, etc. in the transaction business. Under normal circumstances, the first product service layer subsystem and the second product service layer subsystem cooperate according to preset strategies to divert and process business requests from the above-mentioned channel integration layer.

[0049] For example, in the application scenario of fund transfer processing of transaction business, the second product service layer subsystem (fund transfer processing center A) suddenly encounters an unrecoverable database failure, which makes it unable to process any business requests. At this time, all related business requests are automatically reallocated to the first product service layer subsystem (fund transfer processing center B). The first product service layer subsystem has pre-synchronized all necessary data and configurations and can quickly take over and process these requests to ensure business continuity.

[0050] In an exemplary embodiment, the business system is a transaction business system. When the database of the second product service layer subsystem (fund transfer processing center A) fails, the first product service layer subsystem (fund transfer processing center B) is automatically marked as active by the service bus and starts to process all target business requests. This process includes fast data synchronization confirmation, registration status update of the first product service layer subsystem and the second product service layer subsystem of the product service layer, and routing rule adjustment of the service bus, ensuring that business requests can be seamlessly switched from the failed subsystem to the first product service layer subsystem.

[0051] S208, when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, the first external integration layer subsystem is used to obtain target interaction data related to the target business request, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to receive interaction data related to different businesses at the same time, and the second external integration layer subsystem is used to receive target interaction data before a failure occurs.

[0052] Optionally, in an embodiment of the present application, the above-mentioned first external integration layer subsystem and the second external integration layer subsystem refer to modules in the business system responsible for data interaction with external organizations, including but not limited to communication interfaces with other third-party systems, etc., for message conversion, security protocol processing, data encryption and decryption and other operations.

[0053] For example, taking the business system in a bank as an example, the business system in the bank can interact with the payment and clearing system through the above-mentioned first external integration layer subsystem and second external integration layer subsystem to ensure the safe transmission and correct processing of business data between the bank's internal system and the payment and clearing system.

[0054] Exemplarily, in the application scenario of interface interaction between transaction business and payment clearing system, when the second external integration layer subsystem (the interface with the payment clearing system) has a network failure and is unable to receive or send data, the first external integration layer subsystem (the interface connected to the backup center data center) automatically takes over all business requests, business data, etc. related to the payment clearing system, and converts and processes data messages to ensure that business data can be correctly transmitted and processed, thereby maintaining business continuity and data accuracy.

[0055] In an exemplary embodiment, the business system is a transaction business system. When the second external integration layer subsystem (interface A with the payment and clearing system) encounters a network interruption and cannot receive or send target interaction data, the first external integration layer subsystem (interface B with the payment and clearing system) automatically adjusts to an active state according to the disaster recovery strategy and starts processing all related business requests. This process involves updating the routing rules of the service bus and real-time communication confirmation with the payment and clearing system to ensure that interface B can seamlessly replace interface A, receive and process all target interaction data, and maintain the normal operation of the business.

[0056] In another exemplary embodiment, in the disaster recovery construction application scenario of the business system, the disaster recovery technology at the application level is based on multi-center deployment (by deploying the same business system in multiple centers, these centers can provide services to the outside world at the same time, thereby achieving business continuity and capacity expansion), with multi-channel active, product component master-slave, and daily data synchronization of the master-slave database as the overall deployment strategy. When a disaster occurs, only the affected part needs to be switched for disaster recovery. For example, if a single center of the channel layer (the data center in the above-mentioned second channel integration layer system) fails, then it is only necessary to divert the traffic to the non-faulty node (the above-mentioned first channel integration layer system) through the network. The product service layer and the external integration layer do not need to be switched. The business system is disassembled into three major parts, namely the channel integration layer, the product service layer, and the external integration layer. The three business layers are all registered with the enterprise service bus (the above-mentioned target service bus) for mutual access and call between subsystems in each business layer. Each layer has several nodes and is deployed independently. When disaster recovery is constructed (using scientific technical means and methods to establish systematic application and data emergency methods in advance to improve the ability to resist disasters and ensure business continuity), each layer is deployed according to different disaster recovery strategies.

[0057] Through the embodiment of the present application, the operation status of the business system is obtained. When the operation status indicates that the channel integration layer of the business system needs to perform disaster recovery switching, the first channel integration layer subsystem is used to receive the target business request, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, and the first channel integration layer subsystem and the second channel integration layer subsystem are respectively responsible for receiving business requests initiated by different businesses at the same time, and the second channel integration layer subsystem is used to receive the target business request before a failure occurs; when the operation status indicates that the product service layer of the business system needs to perform disaster recovery switching, the first product service layer subsystem is used to process the target business request, wherein the product service layer includes the second product service layer subsystem and the first product service layer subsystem, and the second product service layer subsystem The service layer subsystem is used to process target business requests, and the first product service layer subsystem is used to process target business requests when the second product service layer subsystem fails; when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, the first external integration layer subsystem is used to obtain target interaction data related to the target business request, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, and the first external integration layer subsystem and the second external integration layer subsystem are respectively responsible for receiving interaction data related to different businesses at the same time. Before the second external integration layer subsystem fails, the method for receiving target interaction data can quickly respond to failures of subsystems at each layer and automatically realize disaster recovery switching, which significantly improves the system management efficiency and business continuity.

[0058] Furthermore, it is especially possible to implement differentiated disaster recovery strategies according to the characteristics of different layers, thereby avoiding waste of resources, enhancing the robustness of the system and its ability to respond to emergencies, thereby solving the problems of low system management efficiency, great difficulty in disaster recovery switching, and low resource utilization existing in existing disaster recovery solutions. In summary, the present application solves the technical problem of low system management efficiency.

[0059] As an optional solution, before obtaining the operating status of the business system, the method further includes: controlling the second channel integration layer subsystem and the first channel integration layer subsystem to register with the target service bus in an active state, wherein the target service bus is used to control the mutual calls between the subsystems in the business system, and the subsystem whose registration status is the active state indicates the subsystem that executes the business after completing the registration; controlling the second product service layer subsystem to register with the target service bus in the active state, and controlling the first product service layer subsystem to register with the target service bus in a standby state, wherein the subsystem whose registration status is the standby state indicates the subsystem that does not execute the business after completing the registration; controlling the second external integration layer subsystem and the first external integration layer subsystem to register with the target service bus in the active state.

[0060] As an optional solution, the above method also includes: when the above business system requires disaster recovery switching and the above target business layer is the above product service layer, the above registration status of the above second product service layer is switched from the above active state to the above standby state, and the above registration status of the above first product service layer is changed from the above standby state to the above active state.

[0061] Optionally, in an embodiment of the present application, the above-mentioned target service bus refers to an enterprise service bus (ESB), which can serve as the hub for data exchange and communication within the business system and between third-party systems, and is responsible for message transmission and data synchronization between various subsystems, including but not limited to fund transfers, account inquiries, payment settlements, data message conversion, security protocol processing, etc. in transaction services. The target service bus ensures that business requests can be correctly passed to each subsystem in the execution state by managing the status of registered subsystems and routing requests.

[0062] For example, taking the transaction business as an example, in the application scenario where the business system faces an external network attack, resulting in the interruption of the service of the second channel integration layer subsystem (online banking portal), the business system monitoring platform detects that the operating status of the subsystem is abnormal and automatically triggers the disaster recovery switching process, specifically:

[0063] The above-mentioned first channel integration layer subsystem (also the online banking entrance) has been pre-registered with the target service bus in an active state, and can immediately receive all business requests transferred from the online banking in the second channel integration layer subsystem; at the same time, the target service bus updates its routing rules to ensure that all channel requests are redirected to the first channel integration layer subsystem, so as to continue business processing seamlessly, ensuring business continuity and user experience.

[0064] It should be noted that in the actual disaster recovery switching process, there are many situations that need to be handled flexibly. For example, when a subsystem switches from an active state to a standby state, the target service bus needs to be able to dynamically adjust the routing logic to ensure that requests are not mistakenly forwarded to the faulty subsystem.

[0065] It should also be noted that in the daily operation of the product service layer subsystem, the second product service layer subsystem is registered in the active state, while the first product service layer subsystem is registered in the standby state. Only when the second product service layer subsystem fails, it is necessary to quickly adjust its registration state to active through the target service bus to achieve business takeover.

[0066] In an exemplary embodiment, taking the business system as a transaction business system as an example, it is assumed that the second product service layer subsystem (transaction processing center A) of the product service layer needs to perform disaster recovery switching due to abnormal data processing. At this time, although the first product service layer subsystem (transaction processing center B) has been registered with the target service bus, its registration status is standby and does not participate in business processing; during the disaster recovery switching process, the business system identifies the failure of transaction processing center A, and adjusts the registration status of transaction processing center B to active through the target service bus. Transaction processing center B begins to receive and process all transaction business requests, ensuring the accurate processing of business data and business continuity.

[0067] In yet another exemplary embodiment, Figure 3 is a schematic diagram of an optional system management method according to an embodiment of the present application, wherein the product service layer disaster recovery switching is as follows Figure 3 As shown, specifically:

[0068] Figure 3 The solid line in the figure is the transaction flow under normal circumstances, and the dotted line indicates that when a disaster occurs in center A, the enterprise service bus interacts with the business backend logic implementation system and switches to center B. The product service layer is mainly the implementation of business logic, and data and file processing are all in this layer. Therefore, in order to avoid data inconsistency between the two centers, this layer is used for disaster recovery processing; the business backend logic implementation system on center A (the second product service layer subsystem mentioned above) and the business backend logic implementation system on center B (the first product service layer subsystem mentioned above) are both registered with the target service bus; the registration status of the business backend logic implementation system on center A is active, and the registration status of the business backend logic implementation system on center B is standby. When the business system is operating normally, only the business backend logic implementation system of center A provides services to the outside world, and center A synchronizes database data to center B in real time; when a disaster occurs, the system of center A stops and is taken over by the system of center B. The registration status of the system of center A is changed to standby, and the registration status of the system of center B is changed to active, thereby realizing disaster recovery switching of the two centers.

[0069] Through the embodiments of the present application, by adopting target service bus state management and dynamic routing, disaster recovery switching can be quickly performed when failures occur in subsystems at various levels of the business system, and the business load can be seamlessly transferred to a safe subsystem without user perception or additional manual intervention, thereby achieving the purpose of improving the disaster recovery switching efficiency and business continuity of the business system.

[0070] As an optional solution, the method further includes: when the business system requires disaster recovery switching and the target business layer is the channel integration layer, sending a first prompt message to the channel integration layer, wherein the first prompt message is used to instruct the first channel integration layer subsystem to receive the target business request originally received by the second channel integration layer subsystem, and the second channel integration layer subsystem stops receiving the target business request; when the business system requires disaster recovery switching and the target business layer is the external integration layer, sending a second prompt message to the external integration layer, wherein the second prompt message is used to instruct the first external integration subsystem to receive the target interaction data originally received by the second external integration layer subsystem, and the second channel integration layer subsystem stops receiving the target interaction data.

[0071] Optionally, in an embodiment of the present application, the above-mentioned first prompt message and second prompt message refer to control instructions sent by the system monitoring and disaster recovery switching mechanism through the target service bus (such as the enterprise service bus ESB) when a subsystem failure of a certain layer of the system (such as the channel integration layer or the external integration layer) is detected, including but not limited to disaster recovery switching instructions, subsystem status update instructions, request forwarding rule updates, etc., which are used to instruct the subsystem in the standby state to switch to the active state, and to stop the request receiving function of the faulty subsystem to ensure that the business request can be processed correctly.

[0072] Exemplarily, in a transaction business system, when the second channel integration layer subsystem (such as an online banking portal) is unable to process business requests normally due to exhaustion of server resources, the business system immediately generates and sends a first prompt message to the channel integration layer. The first prompt message is received by the first channel integration layer subsystem (also the online banking portal), instructing it to increase resource allocation to receive and process business requests that were originally the responsibility of the second channel integration layer subsystem. At the same time, the online banking portal can also automatically stop receiving new business requests based on the first prompt message to prevent further resource pressure and data inconsistency problems.

[0073] It should be noted that during the disaster recovery switching process, the sending and receiving of the first prompt message and the second prompt message may involve coordination at multiple levels. For example, in the disaster recovery switching of the external integration layer, the second prompt message, in addition to instructing the first external integration subsystem to receive additional interaction data, may also include instructions for adjusting data synchronization strategies and re-establishing connections with third-party systems to ensure data consistency and communication stability.

[0074] In an exemplary embodiment, when the second external integration layer subsystem (interface A with a third-party system other than the business system) encounters a network interruption, the business system generates a second prompt message and sends the message to the external integration layer through the target service bus. After receiving the second prompt message, the first external integration layer subsystem (interface B with a third-party system other than the business system) immediately adjusts its status to active and begins to receive all interactive data originally responsible for by interface A. At the same time, it re-establishes a secure and stable communication connection with the third-party system to ensure the correct conversion and transmission of data messages.

[0075] In another exemplary embodiment, the channel integration layer can be deployed in multiple active-active mode. The channel integration layer is mainly composed of front-end page components and does not involve file and data synchronization. All scenarios that rely on files and data are moved down to the product service layer for implementation. The channel integration layer only performs page display and request calls as much as possible. Figure 4 is a schematic diagram of another optional system management method according to an embodiment of the present application, wherein the channel integration layer disaster recovery switching is as follows: Figure 4 As shown:

[0076] The solid line represents the normal operation of the business system, and transactions are diverted to Center A and Center B. The dotted line represents the failure of Center A, and transactions are diverted to Center B. The above-mentioned first channel integration layer subsystem includes systems such as the business front-end page in Center B, and the above-mentioned second channel integration layer subsystem includes systems such as the business front-end page in Center A. Specifically, the channel integration layer system is deployed in both the production environment (Center A) and the disaster recovery environment (Center B), and provides services to the outside world at the same time. On the basis of the original single center cluster of the business system, high availability is increased. In the normal operation of the business system, the dual-center transaction diversion is resolved to the corresponding center according to specific strategies (according to business type, business initiation address, etc.). When the disaster recovery is switched, the channel integration layer does not perform any operation, but diverts the traffic to the non-faulty node (the first channel integration layer subsystem) through network switching.

[0077] In yet another exemplary embodiment, Figure 5 is a schematic diagram of another optional system management method according to an embodiment of the present application, wherein the external integration layer disaster recovery switching is as follows Figure 5 As shown:

[0078] The solid line indicates the transaction diversion under normal circumstances, and the dotted line indicates that all transactions are forwarded to the B center for processing after the disaster recovery switch. The external integration layer can be deployed in multiple active-active modes. The external integration layer does not involve the continuity processing of data and files, and only performs transaction message conversion, security protocol and other operations with external third-party systems. The above-mentioned first external integration layer subsystem includes the external integration application in the B center, and the above-mentioned second external integration layer subsystem includes the external integration application in the A center. The external integration layer is deployed in the production environment (A center) and the disaster recovery environment (B center) at the same time, and is registered in the target service bus in an active state. Both centers provide services to the outside world. Under normal circumstances, the transaction diversion of the two centers is processed according to a specific strategy (for example, 50% of the transaction data messages are sent to the first external integration layer subsystem for processing, and the remaining 50% of the transaction data messages are sent to the second external integration layer subsystem for processing). When the disaster recovery switch is performed, the A center system stops, and the transaction will be automatically forwarded to the B center system without additional operation.

[0079] Through the embodiments of the present application, intelligent prompt messages and an automated subsystem status switching mechanism are used to achieve rapid and accurate disaster recovery switching when local failures occur in the channel integration layer or the external integration layer of the business system, and to seamlessly transfer the processing load of business requests or interactive data to healthy subsystems without the need for manual intervention or significant business interruption time, thereby ensuring business continuity.

[0080] As an optional scheme, the above method also includes: obtaining a first address set and a second address set, wherein the above first address set includes a pre-set initiation address of the above target business request allowed to be obtained by the above first channel integration layer subsystem, and the above second address set includes a pre-set initiation address of the above target business request allowed to be obtained by the above second channel integration layer subsystem; in the case where the first business request and the second business request need to be received at the same time at the target time, the first initiation address of the above first business request and the second initiation address of the second business request are determined respectively; in the case where the above first initiation address is an address in the above first address set, the above first channel integration layer subsystem receives the above first business request; in the case where the above second initiation address is an address in the above second address set, the above second channel integration layer subsystem receives the above second business request.

[0081] Optionally, in an embodiment of the present application, the above-mentioned first address set and second address set refer to a pre-set address list in the channel integration layer subsystem that allows a specific subsystem to receive business requests in order to achieve request distribution and load balancing during disaster recovery switching, including but not limited to IP addresses, domain names or port numbers of different channels such as online banking portals, mobile banking applications, telephone banking systems, ATM machines, etc.

[0082] For example, when the second channel integration layer subsystem fails in the business system, while the first channel integration layer subsystem is still operating normally, the business system will adjust the request distribution rules according to the pre-set address set. Assume that the first address set includes all business request addresses from City A, and the second address set includes business request addresses from City B. Then, at the target time, when the system simultaneously receives the first business request initiated by the website in City A and the second business request initiated by the website in City B, it will automatically direct the first business request to the first channel integration layer subsystem for processing according to the rules of the address set, and the second business request to the second channel integration layer subsystem for processing, until the failure is eliminated or disaster recovery switching is performed.

[0083] It should be noted that in the actual disaster recovery switching and request distribution process, the setting and use of address sets may be more complex and flexible. For example, the address set may be dynamically adjusted according to multiple conditions such as time, client type, and business type to adapt to different business peaks and disaster recovery requirements. In addition, in order to cope with emergencies, the update and switching strategy of the address set needs to be able to respond in real time to ensure the continuity and efficiency of business processing.

[0084] Through the embodiments of the present application, intelligent address set management and dynamic business request distribution strategies are adopted to achieve the goal of intelligently directing business requests to a safe subsystem for processing when the business system faces high concurrent requests or local subsystem failures, without the need for overall disaster recovery switching or manual intervention, thereby achieving efficient distribution and processing of business requests and improving the disaster recovery flexibility and business continuity of the proxy business system.

[0085] As an optional scheme, the above method also includes: obtaining a first preset weight value and a second preset weight value, wherein the above first preset weight value is used to indicate the amount of interaction data allowed to be obtained by the above second external integration layer subsystem within the target time period, and the above second preset weight value is used to indicate the amount of interaction data allowed to be obtained by the above first external integration layer subsystem within the target time period; and controlling the above second external integration layer subsystem and the above first external integration layer subsystem to obtain the above target interaction data within the above target time period according to the above first preset weight value and the above second preset weight value.

[0086] Optionally, in an embodiment of the present application, the above-mentioned first preset weight value and the second preset weight value refer to the priority and distribution ratio of the first external integration layer subsystem and the second external integration layer subsystem in receiving the target interaction data, including but not limited to the data reception amount expressed in numbers, the request distribution ratio expressed in percentage, and the priority determination rules of logical expressions, etc.

[0087] Furthermore, through these preset weight values, the business system can dynamically adjust the amount of interactive data received between the external integration layer subsystems within different target time periods according to business needs, system status and disaster recovery strategies, so as to achieve optimal resource allocation and rapid response to disaster recovery.

[0088] It should be noted that in the embodiment of the present application, the setting and adjustment mechanism of the preset weight value is highly flexible and intelligent. For example, during non-business peak periods, the setting of the weight value may be biased towards the second external integration layer subsystem to fully utilize its processing capacity; and during business peak periods or disaster recovery switching, the adjustment of the weight value may be more inclined to the first external integration layer subsystem to ensure business continuity and data processing stability. In addition, the update and application of the weight value should be able to respond to changes in the system status in real time to ensure the reasonable allocation of data processing and the high availability of the system.

[0089] In an exemplary embodiment, during a business peak period, that is, during a target period, a business system receives a large number of interactive data requests for docking with a third-party system. According to a preset disaster recovery strategy, the business system dynamically adjusts the data reception ratio using a first preset weight value and a second preset weight value. Specifically:

[0090] Assuming that the first preset weight value is 60% and the second preset weight value is 40%, it means that during the target period, the first external integration layer subsystem will be responsible for receiving 60% of the interaction data, while the second external integration layer subsystem will be responsible for the remaining 40%; when the second external integration layer subsystem fails, the system immediately adjusts the second preset weight value to the first external integration layer subsystem, for example, increasing the first preset weight value to 100%, to ensure that all interaction data requests can be received and processed by the first external integration layer subsystem, thereby maintaining business continuity.

[0091] Through the embodiments of the present application, dynamic weight management and intelligent request allocation strategies are adopted to automatically adjust the reception ratio of interactive data between the first external integration layer subsystem and the second external integration layer subsystem of the external integration layer according to business needs and system status, thereby achieving the purpose of optimizing resource allocation, improving data processing efficiency and enhancing system disaster recovery capabilities.

[0092] As an optional solution, before obtaining the operating status of the business system, the method further includes: deploying the second channel integration layer subsystem, the second product service layer subsystem and the second external integration layer subsystem in the production environment of the business system; deploying the first channel integration layer subsystem, the first product service layer subsystem and the first external integration layer subsystem in the disaster recovery environment of the business system.

[0093] Optionally, in an embodiment of the present application, the above-mentioned production environment refers to an environment in which the business system operates normally, which is used to process daily business requests and data interactions, taking the banking business system as an example, including but not limited to the bank's real-time transaction processing, account management, payment clearing and other services; and the above-mentioned "disaster recovery environment" is a pre-deployed backup environment to respond to possible disaster events, such as data center failures, network interruptions, software crashes, etc., to ensure that when an abnormality occurs in the main production environment, the business can be taken over quickly and services can be continuously provided, including but not limited to hot standby data centers, redundant server clusters, disaster recovery network infrastructure, etc.

[0094] Through the embodiments of the present application, a hierarchical deployment strategy and an intelligent switching mechanism for the production environment and the disaster recovery environment are adopted, so that when the business system faces a partial or overall failure, business requests and data processing can be quickly and seamlessly transferred to a preset disaster recovery environment, thereby achieving the technical effect of improving business continuity and system stability, reducing the risk of business interruption due to disaster events, and optimizing the complexity and time consumption of disaster recovery switching operations.

[0095] It should be noted that the embodiment of the present application realizes layered disaster recovery switching, rather than system-wide switching. Data-level disaster recovery can also be considered, where only important data and files are backed up, and the system is not backed up. In short, most business systems can be implemented in a layered design according to the channel integration layer, product service layer, and external integration layer, and each layer can be deployed separately. The switching of each layer system does not affect the operation of other layers of the system. Disaster recovery switching takes a short time and is simple to operate; specifically:

[0096] S1: If only some components are affected during a disaster, you can just switch those components, even without manual switching, which is easy and time-saving. For example, if the main center of the external integration layer fails, transactions will be automatically sent to the backup center, without any impact on customers.

[0097] S2, rational use of disaster recovery resources: The channel integration layer and external integration layer of multi-active deployment provide external services under normal conditions of the disaster recovery environment system, avoiding idle and wasted resources.

[0098] S3, the multi-active deployment mode further enhances the high availability of the business system. It is equivalent to horizontally expanding the cluster based on the original single center cluster. The system is more robust and can better respond to emergencies.

[0099] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0100] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0101] According to another aspect of the embodiment of the present application, a system management device for implementing the above system management method is also provided. Figure 6 As shown, the device comprises:

[0102] The acquisition module 602 is used to acquire the operation status of the business system;

[0103] The integration module 604 is used to use the first channel integration layer subsystem to receive the target service request when the operation status indicates that the channel integration layer of the business system needs to perform disaster recovery switching, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are used to respectively receive service requests initiated by different services at the same time, and the second channel integration layer subsystem is used to receive the target service request before a failure occurs;

[0104] The service module 606 is used to use the first product service layer subsystem to process the target business request when the operation status indicates that the product service layer of the business system needs to be switched to a disaster recovery state, wherein the product service layer includes the second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is used to process the target business request, and the first product service layer subsystem is used to process the target business request when the second product service layer subsystem fails;

[0105] Integration module 608 is used to use the first external integration layer subsystem to obtain target interaction data related to the target business request when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to respectively receive interaction data related to different businesses at the same time, and the second external integration layer subsystem is used to receive target interaction data before a failure occurs.

[0106] As an optional solution, the above-mentioned device is also used to: before obtaining the operating status of the business system, control the second channel integration layer subsystem and the first channel integration layer subsystem to register with the target service bus in an active state, wherein the target service bus is used to control the mutual calls between the subsystems in the business system, and the subsystem with an active registration state represents the subsystem that executes the business after completing the registration; control the second product service layer subsystem to register with the target service bus in an active state, and control the first product service layer subsystem to register with the target service bus in a standby state, wherein the subsystem with a standby registration state represents the subsystem that does not execute the business after completing the registration; control the second external integration layer subsystem and the first external integration layer subsystem to register with the target service bus in an active state.

[0107] As an optional solution, the above-mentioned device is also used to: when the business system requires disaster recovery switching and the target business layer is the product service layer, switch the registration status of the second product service layer from active status to standby status, and change the registration status of the first product service layer from standby status to active status.

[0108] As an optional solution, the above-mentioned device is also used to: when the business system needs disaster recovery switching and the target business layer is the channel integration layer, send a first prompt message to the channel integration layer, wherein the first prompt message is used to instruct the first channel integration layer subsystem to receive the target business request originally received by the second channel integration layer subsystem, and the second channel integration layer subsystem stops receiving the target business request; when the business system needs disaster recovery switching and the target business layer is the external integration layer, send a second prompt message to the external integration layer, wherein the second prompt message is used to instruct the first external integration subsystem to receive the target interaction data originally received by the second external integration layer subsystem, and the second channel integration layer subsystem stops receiving the target interaction data.

[0109] As an optional solution, the above-mentioned device is also used to: obtain a first address set and a second address set, wherein the first address set includes a preset initiation address of the target business request allowed to be obtained by the second channel integration layer subsystem, and the second address set includes a preset initiation address of the target business request allowed to be obtained by the first channel integration layer subsystem; when it is necessary to receive the first business request and the second business request at the target time, determine the first initiation address of the first business request and the second initiation address of the second business request respectively; when the first initiation address is an address in the first address set, the first business request is received by the second channel integration layer subsystem; when the second initiation address is an address in the second address set, the second business request is received by the first channel integration layer subsystem.

[0110] As an optional scheme, the above-mentioned device is also used to: obtain a first preset weight value and a second preset weight value, wherein the first preset weight value is used to indicate the amount of interaction data allowed to be obtained by the second external integration layer subsystem within the target time period, and the second preset weight value is used to indicate the amount of interaction data allowed to be obtained by the first external integration layer subsystem within the target time period; and control the second external integration layer subsystem and the first external integration layer subsystem to obtain target interaction data during the target time period according to the first preset weight value and the second preset weight value.

[0111] As an optional solution, the above-mentioned device is also used to: deploy a second channel integration layer subsystem, a second product service layer subsystem and a second external integration layer subsystem in the production environment of the business system before obtaining the operating status of the business system; and deploy a first channel integration layer subsystem, a first product service layer subsystem and a first external integration layer subsystem in the disaster recovery environment of the business system.

[0112] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0113] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0114] According to one aspect of the present application, a computer program product is provided. The computer program product includes a computer program.

[0115] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0116] Figure 7 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0117] It should be noted that Figure 7 The computer system 700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0118] like Figure 7As shown, the computer system 700 includes a central processing unit 701 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 702 (ROM) or the program loaded from the storage part 708 to the random access memory 703 (RAM). Various programs and data required for system operation are also stored in the random access memory 703. The central processing unit 701, the read-only memory 702 and the random access memory 703 are connected to each other through a bus 704. An input / output interface 705 (Input / Output interface, i.e., I / O interface) is also connected to the bus 704.

[0119] The following components are connected to the input / output interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 705 as needed. A removable medium 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 710 as needed so that a computer program read therefrom is installed into the storage section 708 as needed.

[0120] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processor 701, various functions defined in the system of the present application are executed.

[0121] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 709, and / or installed from the removable medium 711. When the computer program is executed by the central processor 701, various functions provided by the embodiment of the present application are performed.

[0122] According to another aspect of the embodiment of the present application, an electronic device for implementing the management method of the above system is also provided. The electronic device may be Figure 1 The terminal device or server shown in the figure. This embodiment is described by taking the electronic device as a terminal device as an example. Figure 8 As shown, the electronic device includes a memory 802 and a processor 804. The memory 802 stores a computer program, and the processor 804 is configured to execute the steps in any of the above method embodiments through the computer program.

[0123] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0124] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0125] Alternatively, a person skilled in the art may understand that: Figure 8 The structure shown is for illustration only. Figure 8 The structure of the electronic device is not limited. Figure 8 More or fewer components (such as network interfaces, etc.) as shown in, or with Figure 8 Different configurations are shown.

[0126] Among them, the memory 802 can be used to store software programs and modules, such as the program instructions / modules corresponding to the system management method and device in the embodiment of the present application. The processor 804 executes various functional applications and data processing by running the software programs and modules stored in the memory 802, that is, realizing the above-mentioned system management method. The memory 802 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 802 may further include a memory remotely located relative to the processor 804, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 802 can be specifically, but not limited to, used to store information such as business data of the above-mentioned target business. As an example, such as Figure 8 As shown, the memory 802 may include but is not limited to the acquisition module 602, integration module 604, service module 606 and integration module 608 in the management device of the system. In addition, it may also include but is not limited to other module units in the management device of the system, which will not be repeated in this example.

[0127] Optionally, the transmission device 806 is used to receive or send data via a network. Specific examples of the network may include wired networks and wireless networks. In one example, the transmission device 806 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 806 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0128] In addition, the electronic device further includes: a display 808 for displaying the service data of the target service; and a connection bus 810 for connecting various module components in the electronic device.

[0129] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. The nodes may form a peer-to-peer network, and any form of computing device, such as a server, terminal or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0130] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the system management method provided in various optional implementations of the management aspects of the above-mentioned system.

[0131] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0132] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0133] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0134] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for one or more electronic devices to execute all or part of the steps of the methods described in each embodiment of the present application.

[0135] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0136] In the several embodiments provided in the present application, it should be understood that the disclosed application can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0138] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0139] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A system management method, characterized in that: include: Get the operating status of the business system; In the case where the operation status indicates that the channel integration layer of the business system needs to perform disaster recovery switching, the first channel integration layer subsystem is used to receive the target business request, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are used to respectively receive business requests initiated by different businesses at the same time, and the second channel integration layer subsystem is used to receive the target business request before a failure occurs; When the operation status indicates that the product service layer of the business system needs to perform disaster recovery switching, the first product service layer subsystem is used to process the target business request, wherein the product service layer includes a second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is used to process the target business request, and the first product service layer subsystem is used to process the target business request when the second product service layer subsystem fails; When the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, the first external integration layer subsystem is used to obtain target interaction data related to the target business request, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to receive interaction data related to different businesses at the same time, and the second external integration layer subsystem is used to receive the target interaction data before a failure occurs.

2. The method according to claim 1, characterized in that Before obtaining the operating status of the business system, the method further includes: Control the second channel integration layer subsystem and the first channel integration layer subsystem to register with the target service bus in an active state, wherein the target service bus is used to control the mutual calls between the subsystems in the business system, and the subsystem whose registration state is the active state represents the subsystem that executes the business after completing the registration; Control the second product service layer subsystem to register with the target service bus in the active state, and control the first product service layer subsystem to register with the target service bus in the standby state, wherein the subsystem in the registration state is the subsystem in the standby state that does not execute business after completing registration; The second external integration layer subsystem and the first external integration layer subsystem are controlled to register with the target service bus in the active state.

3. The method according to claim 2, characterized in that The method further comprises: When the business system requires disaster recovery switching and the target business layer is the product service layer, the registration status of the second product service layer is switched from the active status to the standby status, and the registration status of the first product service layer is changed from the standby status to the active status.

4. The method according to claim 1, characterized in that The method further comprises: When the business system needs disaster recovery switching and the target business layer is the channel integration layer, a first prompt message is sent to the channel integration layer, wherein the first prompt message is used to instruct the first channel integration layer subsystem to receive the target business request originally received by the second channel integration layer subsystem, and the second channel integration layer subsystem stops receiving the target business request; When the business system requires disaster recovery switching and the target business layer is the external integration layer, a second prompt message is sent to the external integration layer, wherein the second prompt message is used to instruct the first external integration subsystem to receive the target interaction data originally received by the second external integration layer subsystem, and the second channel integration layer subsystem stops receiving the target interaction data.

5. The method according to claim 1, characterized in that: The method further comprises: Acquire a first address set and a second address set, wherein the first address set includes a preset initiation address of the target service request that is allowed to be acquired by the first channel integration layer subsystem, and the second address set includes a preset initiation address of the target service request that is allowed to be acquired by the second channel integration layer subsystem; In the case where a first service request and a second service request need to be received simultaneously at a target time, respectively determining a first initiation address of the first service request and a second initiation address of the second service request; In a case where the first initiating address is an address in the first address set, the first channel integration layer subsystem receives the first service request; When the second initiating address is an address in the second address set, the second service request is received by the second channel integration layer subsystem.

6. The method according to claim 1, characterized in that The method further comprises: Obtaining a first preset weight value and a second preset weight value, wherein the first preset weight value is used to indicate the amount of interaction data that the second external integration layer subsystem is allowed to obtain within a target period, and the second preset weight value is used to indicate the amount of interaction data that the first external integration layer subsystem is allowed to obtain within the target period; According to the first preset weight value and the second preset weight value, the second external integration layer subsystem and the first external integration layer subsystem are respectively controlled to obtain the target interaction data in the target time period.

7. The method according to claim 1, characterized in that Before obtaining the operating status of the business system, the method further includes: Deploy the second channel integration layer subsystem, the second product service layer subsystem and the second external connection integration layer subsystem in the production environment of the business system; The first channel integration layer subsystem, the first product service layer subsystem and the first external connection integration layer subsystem are deployed in the disaster recovery environment of the business system.

8. A system management device, characterized in that: include: The acquisition module is used to obtain the operating status of the business system; an integration module, configured to use a first channel integration layer subsystem to receive a target service request when the operation status indicates that the channel integration layer of the service system needs to perform disaster recovery switching, wherein the channel integration layer includes the first channel integration layer subsystem and the second channel integration layer subsystem, the first channel integration layer subsystem and the second channel integration layer subsystem are respectively responsible for receiving service requests initiated by different services at the same time, and the second channel integration layer subsystem is used to receive the target service request before a failure occurs; A service module, configured to use a first product service layer subsystem to process the target service request when the operation status indicates that the product service layer of the business system needs to perform disaster recovery switching, wherein the product service layer includes a second product service layer subsystem and the first product service layer subsystem, the second product service layer subsystem is configured to process the target service request, and the first product service layer subsystem is configured to process the target service request when a failure occurs in the second product service layer subsystem; An integration module is used to use the first external integration layer subsystem to obtain target interaction data related to the target business request when the operating status indicates that the external integration layer of the business system needs to perform disaster recovery switching, wherein the product service layer includes the first external integration layer subsystem and the second external integration layer subsystem, the first external integration layer subsystem and the second external integration layer subsystem are used to respectively receive interaction data related to different businesses at the same time, and the second external integration layer subsystem is used to receive the target interaction data before a failure occurs.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein the computer program can be executed by an electronic device to perform the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

11. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images