Node control method and device, equipment, medium and program product

Abstract

The invention provides a node control method which can be applied to the fields of big data and distribution. The node control method comprises the following steps: acquiring state data uploaded by a first actuator and at least one second actuator respectively, the state data being generated by independently monitoring front nodes in one-to-one correspondence based on each actuator, the front nodes corresponding to the first actuator and the second actuator and the target system are in a connection activated state and a connection disabled state respectively; when it is detected that the state data uploaded by the first actuator is abnormal, a third actuator is determined from the second actuators with normal state data based on a preset performance evaluation rule or an operation instruction of a user; and controlling the first actuator to set the connection between the corresponding front node and the target system to be in a forbidden state, and controlling the third actuator to set the connection between the corresponding front node and the target system to be in an activated state. The invention further provides a node control method and device, equipment, a medium and a program product.

Description

Technical Field

[0001] This application relates to the fields of big data and distributed systems, specifically to a node control method, apparatus, device, medium, and program product. Background Technology

[0002] In the financial industry, internal trading systems need to connect with multiple external counterparty systems. These external systems typically use some industry-standard protocols to communicate and assign a unique connection account to each access institution. This account is only allowed to establish a single long connection at a time, meaning that multiple concurrent logins are prohibited.

[0003] In existing technical solutions, a single logical node is commonly used as the external interface front-end node. This front-end node exclusively uses the access institution's unique account to establish a long-term connection with the external transaction system, and independently undertakes the tasks of receiving, parsing, and forwarding transaction messages. The core transaction system within the financial institution needs to call this single front-end node through the internal network to indirectly complete the interaction with the external transaction system. If the front-end node stops operating due to hardware failure, system crash, process abnormality, or network interruption, the entire external transaction channel will be interrupted. Since financial transactions have extremely high timeliness requirements, channel interruption can easily cause significant economic losses. Summary of the Invention

[0004] In view of the above problems, this application provides a node control method, device, equipment, medium and program product for realizing automatic detection, intelligent decision-making and rapid switching of front-end node faults.

[0005] According to a first aspect of this application, a node control method is provided, comprising: acquiring status data uploaded by a first actuator and at least one second actuator, wherein the status data is generated based on independent monitoring of a corresponding front-end node by each actuator, the front-end node corresponding to the first actuator being in an active connection state with the target system, and the front-end node corresponding to the second actuator being in a disabled connection state with the target system; when an abnormality is detected in the status data uploaded by the first actuator, determining a third actuator from the second actuators with normal status data based on preset performance evaluation rules or user operation instructions; issuing a first instruction to the first actuator to control the first actuator to set the connection between the corresponding front-end node and the target system to a disabled state, and issuing a second instruction to the third actuator to control the third actuator to set the connection between the corresponding front-end node and the target system to an active state.

[0006] According to the embodiments of this application, each actuator independently monitors its corresponding front-end node, including: defining monitoring indicator types, collection frequency and local caching strategies through configuration files to generate monitoring rules; and controlling each actuator to perform status monitoring and data collection on its corresponding front-end node based on the monitoring rules, thereby obtaining the status data of each front-end node, with the monitoring and collection processes of each actuator not interfering with each other.

[0007] According to the embodiments of this application, controlling each actuator to perform status monitoring and data collection on a corresponding front node, and obtaining the status data of each front node includes: collecting data from the monitored corresponding front node from multiple dimensions through each actuator to obtain multi-dimensional data; and encapsulating the multi-dimensional data in a unified format to obtain status data.

[0008] According to an embodiment of this application, the target system includes a transaction system; data collection from multiple dimensions of the monitored front-end nodes by each executor includes: collecting at least one type of data, such as heartbeat data, resource usage data, and transaction flow data between each front-end node and the transaction system, wherein the resource usage data includes at least one type of computing resource usage data, memory resource usage data, and network resource usage data, and the transaction flow data includes at least one type of transaction message response time, abnormal message ratio, and number of consecutive failed transactions.

[0009] According to an embodiment of this application, detecting an anomaly in the status data uploaded by the first executor includes: comparing the heartbeat data, resource usage data, and transaction flow data of each front-end node with their respective preset thresholds, and determining that the status data uploaded by the first executor is abnormal if any one of them exceeds the corresponding preset threshold.

[0010] According to an embodiment of this application, determining a third executor from second executors with normal state data based on preset performance evaluation rules includes: extracting computing resource usage data and network latency data from each normal state data; performing a weighted summation on the normalized computing resource usage data and network latency data to determine the performance score of each second executor with normal state data; and determining the second executor with the highest performance score as the third executor.

[0011] According to an embodiment of this application, determining a third actuator from a second actuator with normal status data based on a user's operation command includes: displaying information about a first actuator with abnormal status data and a second actuator with normal status data on a visual interface, and issuing an alarm message to the user; in response to the user specifying one of the second actuators with normal status data on the visual interface, determining the second actuator specified by the user as the third actuator.

[0012] According to an embodiment of this application, displaying the information of the second actuator with normal status data on the visualization interface includes: displaying the second actuators with normal status data in descending order of their respective performance scores and their respective performance scores on the visualization interface.

[0013] A second aspect of this application provides a node control device, comprising: an acquisition module, configured to acquire status data uploaded by a first actuator and at least one second actuator, wherein the status data is generated based on independent monitoring of a corresponding front-end node by each actuator, the front-end node corresponding to the first actuator being in an active connection state with the target system, and the front-end node corresponding to the second actuator being in a disabled connection state with the target system; a determination module, configured to, upon detecting an anomaly in the status data uploaded by the first actuator, determine a third actuator from the second actuators with normal status data based on preset performance evaluation rules or user operation instructions; and a control module, configured to issue a first instruction to the first actuator to control the first actuator to set the connection between the corresponding front-end node and the target system to a disabled state, and to issue a second instruction to the third actuator to control the third actuator to set the connection between the corresponding front-end node and the target system to an active state.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0017] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0018] Figure 1 The illustrations depict application scenarios of node control methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0019] Figure 2 A flowchart illustrating a node control method according to an embodiment of this application is shown schematically.

[0020] Figure 3The diagram schematically illustrates the architecture of the front-end node control system of a bank transaction system according to an embodiment of this application;

[0021] Figure 4 A schematic plan view of a visual interface according to an embodiment of this application is shown;

[0022] Figure 5 A schematic diagram illustrating the structure of a node control device according to an embodiment of this application is shown.

[0023] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a node control method according to an embodiment of this application. Detailed Implementation

[0024] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0027] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0028] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0029] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer users corresponding entry points for choosing to agree to or reject the automated decision-making results. If the user chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0030] Figure 1 The illustration shows an application scenario diagram of the node control method, apparatus, device, medium, and program product according to embodiments of this application.

[0031] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0032] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send instructions, status information, etc., related to the connection with the financial trading system. The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be equipped with applications for the operation and maintenance management of the financial trading system, such as a trading system monitoring platform, a node management client, and visual operation and maintenance tools (for example only).

[0033] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays that support the operation and monitoring of financial transaction systems, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0034] Server 105 can be a server that provides node control services for the connection between the financial trading system and external trading systems, such as a backend server responsible for managing the front-end nodes of financial trading (for example only). This backend server can collect and analyze the status data of the front-end nodes of financial trading. When an anomaly of the front-end node is detected, it determines the target front-end node to be switched based on preset rules or by receiving user instructions from the terminal device, and sends a connection status switching instruction to the relevant executor. At the same time, it feeds back the node status and other information to the terminal device.

[0035] It should be noted that the node control method provided in this application embodiment can generally be executed by server 105. Correspondingly, the node control device provided in this application embodiment can generally be located in server 105. The node control method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the node control device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0036] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0037] It should be noted that the node control method and apparatus of this application are deeply adaptable to the needs of the fintech field, and are particularly suitable for scenarios where trading systems of financial institutions such as banks, securities firms, funds, and insurance companies interface with external counterparty systems, covering core business areas such as foreign exchange trading, gold trading, bond trading, and derivatives trading. In the fintech field, the interface between trading systems and external systems must strictly adhere to the account management rules of "single account, single sign-on," and have extremely high requirements for transaction continuity, while also meeting regulatory requirements for business continuity and fault traceability. This method, through its core design of independent monitoring of multiple actuators and intelligent switching of the adjudication system, can effectively solve problems such as single point of failure, inefficient switching, and resource waste in financial trading interface scenarios, ensuring high availability of trading channels.

[0038] For example, in a scenario where a bank's foreign exchange trading system connects to an external foreign exchange trading platform, the external platform assigns only a unique Financial Information Exchange Protocol (FIX) connection account to the bank and prohibits multiple concurrent logins. The bank deploys several process control executors (corresponding to primary and backup front-end nodes). The primary executor monitors the heartbeat, computing resource usage, and foreign exchange transaction message response status of the primary front-end node in real time. When the primary front-end node experiences continuous transaction message timeouts due to network fluctuations, the adjudication system can detect the anomaly within a very short time, automatically extract the performance data of the backup executor, determine it as the optimal switch node, and then send a "disconnect" command to the primary executor and a "connection activation" command to the backup executor. The backup front-end node quickly establishes a long-lived FIX connection using the unique account and takes over the forwarding of foreign exchange transaction instructions. The entire process is automated, avoiding losses due to exchange rate fluctuations caused by foreign exchange trading interruptions.

[0039] It should be noted that the node control method and device of this application can be used for the docking of transaction systems in the financial technology field, and can also be used in any scenario other than the financial field where a single account / resource is exclusive and has high availability requirements, such as docking of e-government systems with higher-level regulatory platforms in the government sector, docking of power trading systems with power grid dispatching platforms in the energy sector, and docking of rail transit dispatching systems with regional control centers in the transportation sector. The application fields of the node control method and device of this application are not limited.

[0040] The following will be based on Figure 1 The described scene, through Figures 2-4 The node control method according to the embodiments of this application will be described in detail.

[0041] Figure 2 A flowchart illustrating a node control method according to an embodiment of this application is shown schematically.

[0042] like Figure 2 As shown, the node control method of this embodiment includes operations S210 to S230, and the node control method can be executed by the server 105.

[0043] In operation S210, the status data uploaded by the first actuator and at least one second actuator are obtained. The status data is generated based on the independent monitoring of the corresponding front-end node by each actuator. The front-end node corresponding to the first actuator is in an active connection state with the target system, while the front-end node corresponding to the second actuator is in a disabled connection state with the target system.

[0044] In operation S220, if an abnormality is detected in the status data uploaded by the first actuator, a third actuator is determined from the second actuator with normal status data based on preset performance evaluation rules or user operation instructions.

[0045] In operation S230, a first instruction is issued to the first actuator to control the first actuator to set the connection between the corresponding front node and the target system to a disabled state, and a second instruction is issued to the third actuator to control the third actuator to set the connection between the corresponding front node and the target system to an active state.

[0046] In this embodiment, each executor has the same number of front-end nodes and a one-to-one binding relationship. These executors independently monitor the operational status of their respective front-end nodes. That is, monitoring by each executor does not affect the normal function of the front-end node, and the executors do not interfere with each other. The business processes of the executors and front-end nodes are isolated, preventing monitoring component failures from affecting transactions. The number of second executors can be one, two, or more. Setting only one second executor means there is only one backup front-end node. When the front-end node corresponding to the first executor malfunctions, the only second executor, if its status data is normal, can be designated as the third executor. Having two or more second executors means there are also two or more backup front-end nodes. When the front-end node corresponding to the first executor malfunctions, a second executor meeting the criteria can be selected from the second executors with normal status data to be designated as the third executor. The selection process can be automated, for example, based on preset performance evaluation rules, selecting the second executor corresponding to a front-end node with better performance as the third executor. The selection process can also be done manually. For example, based on user commands, the user can specify a second executor corresponding to a front-end node with normal status data as the third executor. The structures and models of the various executors can be the same or different, as long as they can achieve status monitoring and control of the front-end node.

[0047] This embodiment employs a multi-executor, multi-front-end node architecture. When the front-end node corresponding to the first executor malfunctions (e.g., server hardware failure, operating system crash, abnormal process exit, network interruption), it can quickly switch to a front-end node corresponding to a healthy second executor. This prevents the entire target system from being interrupted due to a single node failure, ensuring business continuity and reducing potential significant economic losses caused by business interruption. Secondly, node switching can be automatically completed based on preset rules or user commands, with recovery time far lower than manual operation time. This meets business continuity requirements, greatly improves emergency response efficiency, and supports automatic / manual dual-mode switching to meet the needs of different fault scenarios. Furthermore, backup nodes are no longer idle indefinitely; they can be activated and used promptly when the primary node fails, improving resource utilization and fully leveraging the value of computing resources. Finally, it reduces operational complexity, minimizing the need for coordination among multiple teams during manual switching, avoiding operational errors, and making system operation and maintenance more efficient and stable.

[0048] In some embodiments, the target system may be a bank transaction system. Accordingly, the front-end node is a service process deployed at the boundary of the financial institution's internal network, specifically responsible for protocol conversion and message forwarding with the external transaction system. Figure 3 The diagram illustrates the architecture of a front-end node control system for a bank transaction system according to an embodiment of this application.

[0049] like Figure 3 As shown, the bank transaction system front-end node control system of this embodiment may include an external transaction system 350, an external interface front-end 310, a service adjudication management central control 330, and an internal business transaction system 340. The node control methods of the above operations S210 to S230 can be executed by the service adjudication management central control 330.

[0050] The internal business transaction system 340 is the core system for financial institutions to conduct transaction business. It is responsible for generating transaction instructions and sending them to the external transaction system 350 through interaction with the front-end nodes activated in the external interface front-end 310. The internal business transaction system 340 also receives the transaction results returned by the external transaction system 350 and performs subsequent business processing. The external transaction system 350 is the financial institution's counterparty system. It establishes a connection with the front-end nodes in the external interface front-end 310, receives and executes transaction instructions from the internal business transaction system 340, and then sends the transaction results back.

[0051] The external interface front-end 310 comprises multiple front-end nodes 311, 312, and 313, each equipped with a dedicated executor 321, 322, or 323. Front-end node 311 is in an active connection state, establishing a long-term connection with the external transaction system 350 through the organization's unique dedicated protocol interface account. It is responsible for receiving transaction instructions from the internal business transaction system 340 and forwarding them to the external transaction system 350, while also receiving transaction receipts from the external transaction system 350 and sending them back to the internal system. Front-end nodes 312 and 313 are in a disabled connection state, maintaining only basic operations and not occupying the interface account for the external transaction system, but are always ready to take over business in the event of a failure in front-end node 311. Taking executor 321 as an example, it independently monitors the status data of front-end node 311 and reports the collected status data to the service adjudication management control center 330 at a preset frequency.

[0052] The Service Decision Management Control Unit 330 is the core decision-making unit of the entire architecture, comprising the Decision Management Node 331 and the Visual Interface 332. The Visual Interface 332 can also be referred to as the Visual Console. The Decision Management Node 331 receives status data reported by each executor 321, 322, and 323 in real time. When an anomaly is detected in the status data uploaded by executor 321, the switching logic is immediately initiated. If a new node is selected based on preset performance evaluation rules, the Decision Management Node 331 extracts the normal status data uploaded by executors 322 and 323, calculates the performance score of each executor, and determines the executor with the highest performance score (e.g., executor 322) as the third executor. If a new node is selected based on user operation commands, the Decision Management Node 331 can display information about executor 321 (with abnormal status data) and executors 322 and 323 (with normal status data) on the Visual Interface 332. After viewing the status of each node on the Visual Interface 332, the user can designate one of the normal executors (e.g., executor 323) as the third executor. After determining the third executor, the adjudication management node 331 issues a first instruction to executor 321. Executor 321 controls the connection between the front-end node 311 and the external transaction system 350 to a disabled state, releasing the connected account. The first instruction may include "graceful stop" logic to prevent transaction data loss. For example, it may first complete the forwarding of unprocessed messages and then disconnect. Simultaneously, a second instruction is issued to the third executor (such as executor 322). Executor 322 controls the connection between the front-end node 312 and the external transaction system 350 to an active state, establishing a long-lived connection using a unique account. Subsequent transaction instructions from the internal business transaction system 340 interact with the external transaction system 350 through the activated front-end node 312, ensuring continuous transaction operations. Through this architecture, financial institutions can effectively avoid transaction channel interruptions caused by the failure of a single front-end node, improve the high availability of the transaction system, and meet the stringent requirements of financial business for timeliness and continuity.

[0053] In some embodiments, each executor can define monitoring metric types, collection frequencies, and local caching strategies through a configuration file to generate monitoring rules. Then, based on the monitoring rules, each executor is controlled to perform status monitoring and data collection on its corresponding front-end nodes, obtaining the status data of each front-end node. The monitoring and data collection processes of each executor do not interfere with each other.

[0054] For example, such as Figure 3 As shown, users (such as operations and maintenance personnel) can define monitoring metric types, data collection frequencies, and local caching strategies through the visual interface 332 of the service adjudication management control 330, or by directly editing the executor's local configuration file. The configuration file supports dynamic loading, allowing rules to be updated without restarting the executor. Monitoring metric types include, but are not limited to, heartbeats, resources, and transaction flows. For example, data can be collected at a frequency of 1 second / time or 5 seconds / time; monitoring can be performed only during transaction periods, and not during holidays. Cached data can use a circular overwrite mechanism, retaining only the most recent data within a preset time frame, satisfying anomaly backtracking requirements while avoiding excessive disk space consumption. After each executor loads its own configuration file, it starts an independent monitoring thread to collect status data from the corresponding front-end nodes according to the rules. The monitoring thread is isolated from the front-end node's business thread. In other words, the executor can adopt a parallel architecture of a main process and monitoring sub-threads. The resource consumption of the monitoring sub-threads is limited, preventing excessive resource consumption by monitoring logic from affecting the transaction processing performance of the front-end nodes. The monitoring processes of different executors are independent of each other; even if one executor experiences a monitoring anomaly, it will not affect the monitoring work of other executors, ensuring the independence and reliability of monitoring data. This embodiment achieves independent and interference-free monitoring of the executor by pre-setting monitoring rules, which can ensure the standardization and reliability of status data collection, while reducing the impact of monitoring logic on the transaction process.

[0055] In some embodiments, the service adjudication management control unit 330 can collect data from the monitored front-end nodes from multiple dimensions through various actuators to obtain multi-dimensional data. Then, the multi-dimensional data is encapsulated in a unified format to obtain status data.

[0056] For example, each executor can collect data from its corresponding front-end node according to the monitoring indicator types defined in the monitoring rules, focusing on three dimensions: hardware resources, system operation, and business interaction. The hardware resource dimension focuses on the usage of basic resources such as computing, memory, and network; the system operation dimension focuses on basic states such as process survival and heartbeat response; and the business interaction dimension focuses on business-related data such as message transmission and transaction processing with the target system. The collection process combines real-time sampling and periodic statistics, such as real-time sampling of heartbeat status and calculating the average resource usage every 3 seconds. During the status data encapsulation stage, the executor can encapsulate the collected multi-dimensional raw data according to a unified data format preset by the service adjudication management control, ensuring consistency in the data structure reported by different executors. After encapsulation, the data can be verified to prevent data tampering or loss during transmission, and then reported to the adjudication system at a preset frequency. For example, Cyclic Redundancy Check (CRC) verification can be used to reduce computational overhead while ensuring data integrity, meeting the low-latency requirements of financial transaction scenarios. If the verification fails, the adjudication system can send a data retransmission instruction to the executor, which then retrieves the original data with the corresponding timestamp from its local cache, repackages it, and reports it. This embodiment, through multi-dimensional data collection and unified format packaging, can ensure the comprehensiveness and consistency of status data, providing high-quality input for subsequent anomaly detection.

[0057] In some embodiments, the service adjudication management control 330 can collect at least one type of data, including heartbeat data, resource usage data, and transaction flow data between each front-end node and the transaction system. The resource usage data includes at least one type of computing resource usage data, memory resource usage data, and network resource usage data. The transaction flow data includes at least one type of transaction message response time, percentage of abnormal messages, and number of consecutive failed transactions.

[0058] As an example, in heartbeat data collection, the actuator can collect heartbeat data through active probing or passive response. It can actively send heartbeat packets to the front-end node and record the response time. If no response is received multiple times consecutively or the response time exceeds a threshold, the heartbeat is marked as abnormal. For target systems with different protocols, the heartbeat packets can adopt the standard format of the corresponding protocol to ensure that the front-end node can correctly identify and respond, avoiding misjudgments due to format incompatibility. In resource usage data collection, considering the high resource requirements of financial trading systems, computing resources, memory resources, and network resources can be collected. For example, data can be collected every few seconds, and the average value is used as the reported data. Computing resources can include Central Processing Unit (CPU) utilization, with a normal threshold such as ≤90%; memory resources can include memory utilization, with a normal threshold such as ≤85%; network resources can include network bandwidth utilization and network latency, with normal thresholds such as bandwidth utilization ≤80% and latency ≤50ms. In transaction flow data collection, key indicators can be collected across the entire transaction business chain, including transaction message response time, abnormal message ratio, and number of consecutive failed transactions, such as counting every few seconds to ensure timely detection of business-level anomalies. Transaction message response time is the time from receiving a message from the core transaction system at the front-end node to sending it to the target system, with a normal threshold of ≤200ms; abnormal message ratio is the ratio of the number of abnormal messages to the total number of messages, with a normal threshold of ≤1%; and the number of consecutive failed transactions is the number of transaction failures caused by front-end node failures, with a normal threshold of ≤2 times. It is important to emphasize that these normal threshold values ​​are for reference only and do not constitute further limitations on this application. These values ​​can be reasonably adjusted according to different scenarios. For example, resource thresholds can be dynamically adjusted based on the trading period; for instance, the CPU threshold can be relaxed to 95% during peak stock market opening hours and restored to 90% during off-peak hours to adapt to the time-varying resource demand fluctuations in financial transactions. This embodiment, by collecting data from core monitoring dimensions such as heartbeat, resources, and transaction flow, covers node survival, performance, and business continuity, which can improve the accuracy of anomaly detection.

[0059] In some embodiments, the service adjudication management control 330 can compare the heartbeat data, resource usage data, and transaction flow data of each front-end node with their respective preset thresholds. If any one of them exceeds the corresponding preset threshold, it is determined that the status data uploaded by the first executor is abnormal.

[0060] For example, the service adjudication management control unit 330 can set independent preset thresholds for each type of data through the visual interface 332, and compare each indicator data uploaded by the first executor with the corresponding threshold. For example, if the heartbeat data shows "a consecutive times without response" or "response time exceeds b", the heartbeat is determined to be abnormal; if any one of the resource usage data shows "CPU greater than c", "memory greater than d", or "network latency greater than e", the resource is determined to be abnormal; if any one of the transaction flow data shows "response time greater than f", "abnormal percentage greater than g", or "number of consecutive failures greater than h", the transaction flow is determined to be abnormal. As long as any indicator in the status data uploaded by the first executor exceeds the preset threshold, the status data is immediately determined to be abnormal without waiting for other indicators to be verified, triggering the subsequent switching logic. At the same time, the specific value and occurrence timestamp of the abnormal indicator are recorded for subsequent fault backtracking analysis. The specific values ​​of these judgment thresholds can be reasonably set and adjusted according to different scenarios. This embodiment quantifies the abnormal judgment standard by preset thresholds, avoiding subjective ambiguity and ensuring the objectivity and operability of abnormal identification.

[0061] In some embodiments, the service adjudication management control 330 can extract computational resource usage data and network latency data from the normal state data. Then, it performs a weighted sum of the normalized computational resource usage data and network latency data to determine the performance score of each second executor with normal state data. The second executor with the highest performance score is then determined as the third executor.

[0062] As an example, when a switchover is triggered due to an abnormal state of the first executor, the service adjudication management control 330 can extract computing resource usage data (such as CPU utilization and memory usage) and network latency data (such as communication latency with the target system) from the status data reported by the second executors that are in normal state. Then, the extracted computing resource usage data and network latency data are normalized, mapping indicators of different dimensions to the same numerical range, such as 0-1. Subsequently, the normalized data is weighted and summed according to preset weights to obtain the performance score of each second executor. For example, computing resource usage percentage x%, network latency percentage y%, and the weights can be configured through the visual interface 332. In some embodiments, dynamic adjustment of weights can be supported, allowing financial institutions to flexibly configure them according to business scenarios to meet different business priority requirements. For example, during peak transaction periods, network latency is of greater concern, and the network latency weight can be increased. The service adjudication management control can cache the historical performance scores of each executor for subsequent fault backtracking analysis, while also providing data support for weight optimization. Then, the performance scores of each second executor are compared, and the second executor with the highest score is determined as the third executor, ensuring that the front-end node can handle transaction business with optimal performance after the switchover. This embodiment selects the optimal backup node based on performance scoring, which can ensure the efficiency and stability of transaction processing after the switchover.

[0063] In some embodiments, the service adjudication management control 330 can display information about a first actuator with abnormal status data and a second actuator with normal status data on a visualization interface 332, and issue an alarm message to the user. In response to the user specifying one of the second actuators with normal status data on the visualization interface 332, the second actuator specified by the user is identified as the third actuator.

[0064] Figure 4 A schematic plan view of a visual interface 332 according to an embodiment of this application is shown. Figure 4 As shown, when the current primary node encounters a problem, users can view information about each preceding node through the visualization interface 332, including the preceding node name, node number, and node information. The visualization interface 332 also provides the option to "switch to primary node." This corresponds to the user's operation of specifying a node on the visualization interface after an alarm message is sent to the user (operations personnel) via email, SMS, etc. After viewing the information of each executor on the visualization interface 332, operations personnel can manually designate one of the normally functioning second executors according to business needs. The service adjudication management control 330 responds to the operation and designates that executor as the third executor. This embodiment supports users manually specifying backup nodes through the visualization interface, compensating for the limitations of automatic switching, adapting to scenarios requiring proactive operations intervention, and improving system flexibility.

[0065] In some embodiments, the service adjudication management control 330 can display the second actuators with normal status data on a visualization interface in descending order of their performance scores.

[0066] For example, the service adjudication management control center 330, on the visualization interface 332, sorts the second executors in normal status according to their performance scores from high to low, and displays the specific performance score of each executor. Users can also click to view the detailed composition of the score, such as computing resource score and network latency score, helping them quickly identify the optimal or most suitable executor. The performance scores support real-time calculation and dynamic updates. If the status data of the second executor changes, the visualization interface 332 can automatically refresh the sorting to ensure the timeliness of the displayed information. In some embodiments, the visualization interface 332 supports hovering to view or clicking to expand to view score details. The details page can use a combination of charts and text to intuitively present the contribution of each indicator to the score. This embodiment uses a visualization interface to display backup nodes by performance score, providing a decision-making basis for users' manual selection, which can improve operational efficiency and accuracy.

[0067] Based on the above-described node control method, this application also provides a node control device. The following will be combined with... Figure 5 The device is described in detail.

[0068] Figure 5 A schematic block diagram of a node control device according to an embodiment of this application is shown.

[0069] like Figure 5 As shown, the node control device 500 in this embodiment includes an acquisition module 510, a determination module 520, and a control module 530.

[0070] The acquisition module 510 is used to acquire the status data uploaded by the first executor and at least one second executor. The status data is generated based on the independent monitoring of the corresponding front-end node by each executor. The front-end node corresponding to the first executor is in an active connection state with the target system, while the front-end node corresponding to the second executor is in a disabled connection state with the target system. In one embodiment, the acquisition module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0071] The determining module 520 is used to determine a third executor from the second executors whose status data is normal, based on preset performance evaluation rules or user operation instructions, when an anomaly is detected in the status data uploaded by the first executor. In one embodiment, the determining module 520 can be used to perform the operation S220 described above, which will not be repeated here.

[0072] The control module 530 is used to issue a first instruction to the first actuator to disable the connection between the corresponding front-end node and the target system, and to issue a second instruction to the third actuator to enable the connection between the corresponding front-end node and the target system. In one embodiment, the control module 530 can be used to execute the operation S230 described above, which will not be repeated here.

[0073] According to the embodiments of this application, the acquisition module 510 is also used to define the monitoring indicator type, collection frequency and local caching strategy through the configuration file to generate monitoring rules; based on the monitoring rules, control each actuator to perform status monitoring and data collection on the corresponding front-end nodes to obtain the status data of each front-end node, and the monitoring and collection processes of each actuator do not interfere with each other.

[0074] According to the embodiments of this application, the acquisition module 510 is also used to collect data from the corresponding front-end node being monitored from multiple dimensions through each actuator to obtain multi-dimensional data; and to encapsulate the multi-dimensional data in a unified format to obtain status data.

[0075] According to an embodiment of this application, the target system includes a transaction system; the acquisition module 510 is further used to collect at least one type of data, including heartbeat data, resource usage data, and transaction flow data between each front-end node and the transaction system, wherein the resource usage data includes at least one type of computing resource usage data, memory resource usage data, and network resource usage data, and the transaction flow data includes at least one type of transaction message response time, abnormal message ratio, and number of consecutive failed transactions.

[0076] According to the embodiments of this application, the determining module 520 is further configured to compare the heartbeat data, resource usage data and transaction flow data of each front-end node with their respective preset thresholds, and determine that the status data uploaded by the first executor is abnormal if any one of them exceeds the corresponding preset threshold.

[0077] According to the embodiments of this application, the determining module 520 is further used to extract the computing resource usage data and network latency data from the normal state data; perform a weighted summation on the normalized computing resource usage data and network latency data to determine the performance score of each second executor with normal state data; and determine the second executor with the highest performance score as the third executor.

[0078] According to an embodiment of this application, the determining module 520 is further configured to display information about a first actuator with abnormal status data and a second actuator with normal status data on a visual interface, and issue an alarm message to the user; in response to the user specifying one of the second actuators with normal status data on the visual interface, the second actuator specified by the user is determined as the third actuator.

[0079] According to an embodiment of this application, the determining module 520 is further configured to display the second actuators with normal status data in order of their respective performance scores on a visualization interface.

[0080] According to embodiments of this application, any plurality of the above modules can be combined into one module, or any one of the modules can be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules can be combined with at least a portion of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the above modules can be at least partially implemented as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a System-on-Chip, a System-on-Substrate, a System-on-Package, an Application-Specific Integrated Circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these. Alternatively, at least one of the above modules can be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

[0081] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a node control method according to an embodiment of this application.

[0082] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0083] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0084] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0085] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0086] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0087] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the node control method provided in the embodiments of this application.

[0088] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0089] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0090] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0091] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A node control method characterized by comprising: The method comprises: acquiring state data uploaded by each of a first executor and at least one second executor, the state data being generated based on independent monitoring of a one-to-one corresponding pre-node by each executor, the pre-node corresponding to the first executor being in a connection active state with a target system, and the pre-node corresponding to the second executor being in a connection disabled state with the target system; in a case where it is detected that the state data uploaded by the first executor is abnormal, determining a third executor from the second executor with normal state data based on a preset performance evaluation rule or an operation instruction of a user; issuing a first instruction to the first executor to control the first executor to set the connection of the corresponding pre-node with the target system to a disabled state, and issuing a second instruction to the third executor to control the third executor to set the connection of the corresponding pre-node with the target system to an active state.

2. The node control method according to claim 1, characterized by, The independent monitoring of the one-to-one corresponding pre-node by each executor comprises: defining a monitoring index type, a collection frequency and a local caching strategy through a configuration file to generate a monitoring rule; controlling each executor to perform state monitoring and data collection on the one-to-one corresponding pre-node based on the monitoring rule to obtain the state data of each pre-node, and the monitoring and collection processes of each executor do not interfere with each other.

3. The node control method according to claim 2, characterized by, The control of each executor to perform state monitoring and data collection on the one-to-one corresponding pre-node to obtain the state data of each pre-node comprises: collecting multi-dimensional data of the monitored corresponding pre-node by each executor from multiple dimensions; encapsulating the multi-dimensional data in a unified format to obtain the state data.

4. The node control method according to claim 3, characterized by, The target system comprises a transaction system; and the data collection from multiple dimensions by each executor on the monitored corresponding pre-node comprises: collecting at least one of heartbeat data, resource occupation data of each pre-node and transaction flow data between each pre-node and the transaction system, wherein the resource occupation data comprises at least one of computing resource occupation data, memory resource occupation data and network resource occupation data, and the transaction flow data comprises at least one of transaction message response time, abnormal message proportion and number of consecutive failed transactions.

5. The node control method according to claim 4, characterized by, The detection of the abnormal state data uploaded by the first executor comprises: comparing the heartbeat data, resource occupation data and transaction flow data of each pre-node with a corresponding preset threshold value, and determining that the state data uploaded by the first executor is abnormal in a case where any one exceeds the corresponding preset threshold value.

6. The node control method according to claim 1, characterized by, The determination of the third executor from the second executor with normal state data based on a preset performance evaluation rule comprises: extracting computing resource occupation data and network delay data from each normal state data; performing weighted summation on the normalized computing resource occupation data and network delay data to determine a performance score of each second executor with normal state data; determining the second executor with the highest performance score as the third executor.

7. The node control method of claim 1, wherein, determining, based on an operation instruction of the user, a third actuator from the second actuators with normal state data comprises: displaying information of the first actuators with abnormal state data and the second actuators with normal state data on a visual interface, and sending an alarm information to the user; in response to the user specifying one of the second actuators with normal state data on the visual interface, determining the second actuator specified by the user as the third actuator.

8. The node control method according to claim 7, characterized by, displaying information of the second actuators with normal state data on a visual interface comprises: displaying the second actuators with normal state data on the visual interface in a descending order of respective performance scores and the performance scores.

9. A node control device, characterized by comprising: The apparatus comprises: an acquisition module configured to acquire state data uploaded by a first actuator and at least one second actuator respectively, the state data being generated based on independent monitoring of a corresponding front node by each actuator, the front node corresponding to the first actuator being in a connection active state with a target system, and the front node corresponding to the second actuator being in a connection disabled state with the target system; a determination module configured to, in a case where it is detected that the state data uploaded by the first actuator is abnormal, determine a third actuator from the second actuators with normal state data based on a preset performance evaluation rule or an operation instruction of the user; a control module configured to send a first instruction to the first actuator to control the first actuator to set the connection between the corresponding front node and the target system to a disabled state, and send a second instruction to the third actuator to control the third actuator to set the connection between the corresponding front node and the target system to an active state.

10. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1-8.

11. A computer readable storage medium having stored thereon a computer program or instructions, characterized in that, The computer program or instructions, when executed by a processor, implement the steps of the method according to any one of claims 1-8.

12. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instructions, when executed by a processor, implement the steps of the method according to any one of claims 1-8. The computer program or instructions, when executed by a processor, implement the steps of the method according to any one of claims 1-8.

Images