Distributed system, distributed management method and device based on cooperative bus

Abstract

The invention provides a distributed system based on a cooperative bus and a distributed management method and device.The distributed system based on the cooperative bus comprises at least two distributed physical nodes arranged on the cooperative bus, and each distributed physical node comprises at least one bus service node and at least one bus management node, the execution module is used for executing a preset service function; and the bus management node is used for executing at least one of registration, logout and information change operations on the at least one bus service node on the cooperative bus. According to the method and the device, the dynamic expansion of the service functions of the distributed system can be realized, the dynamic expansion of the service scale of the system can be further realized, the system operation is high in reliability, the distributed collaboration is high in performance, the method and the device can be suitable for the construction of a lightweight autonomous high-security local area network distributed system, and the calling collaboration among the service functions can be supported.

Description

Technical Field

[0001] This application belongs to the field of distributed technology, and in particular relates to a distributed system, distributed management method and device based on a cooperative bus. Background Technology

[0002] For large-scale distributed systems with complex business operations and high real-time requirements, such as large-scale data acquisition platforms, monitoring systems, and monitoring and diagnostic systems, RPC (Remote Procedure Call) or message queue middleware are usually used during their construction to enable communication between different business services.

[0003] However, direct RPC calls can easily lead to complex dependencies between services, resulting in severe coupling and making it difficult to build flexible and reliable large-scale complex systems. In addition, using message middleware can lead to complex system architecture, low collaboration efficiency, severe third-party dependencies, and high hardware deployment costs, making it unsuitable for building lightweight, autonomous, and highly secure local area network distributed systems.

[0004] Currently, how to build a distributed system suitable for local area networks and capable of supporting collaborative calls between business functions is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of the above-mentioned technical problems, the embodiments of this application provide a distributed system, a distributed management method and apparatus based on a collaborative bus, which can realize the dynamic expansion of the business functions of the distributed system, and thus also realize the dynamic expansion of the business scale of the system. The system operates with high reliability and high performance in distributed collaboration.

[0006] In a first aspect, embodiments of this application provide a distributed system based on a cooperative bus, the system including at least two distributed physical nodes disposed on the cooperative bus, each of the distributed physical nodes including:

[0007] At least one bus service node is used to: execute pre-set service functions;

[0008] A bus management node is configured to: perform at least one of the following operations on the at least one bus service node: registration, deregistration, and information modification on the cooperative bus.

[0009] In this embodiment, the distributed system includes at least two distributed physical nodes set on a collaborative bus. Each physical node includes at least one bus service node for performing business functions and a bus management node. The bus management node is used to perform at least one of the following operations on the collaborative bus: registration, deregistration, and information modification. For example, according to actual needs, the bus management node can register a bus service node on the collaborative bus to connect the bus service node to the collaborative bus to support the execution of corresponding business functions. It can also deregister a connected bus service node on the collaborative bus to remove the service node from the collaborative bus. It can also modify the information about a bus service node on the collaborative bus. By supporting the execution of the above operations, the bus management node enables the bus service nodes to publish corresponding business function services to the collaborative bus in a hot-swappable manner, which facilitates subsequent mutual invocation of their respective services by business nodes for collaboration, thereby realizing the business functions of the entire distributed system. This application can realize the dynamic expansion of the business functions of the distributed system, and thus also the dynamic expansion of the system's business scale. The system operates with high reliability and high performance in distributed collaboration. It is suitable for the construction of lightweight, autonomous, and highly secure local area network distributed systems and can support the invocation and collaboration between business functions.

[0010] In some embodiments, the bus management node is specifically used for:

[0011] Send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes, wherein the first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node;

[0012] Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes;

[0013] The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

[0014] This application provides a specific implementation method for a bus management node to perform registration, deregistration, and information modification. Specifically, the bus management node synchronizes the first information of at least one bus service node within its own physical node to other bus management nodes in the distributed physical nodes. The first information includes at least one of registration information, deregistration information, and modification information related to at least one bus service node. For example, synchronizing registration information indicates that a bus service node has been registered on the collaborative bus, allowing other local service nodes or service nodes within other distributed physical nodes to call the registered bus service node for collaboration. Alternatively, after a bus service node exits, the bus management node can synchronize deregistration information to other service nodes, preventing further calls to the exited service node. Furthermore, after a bus service node's information is modified, such as its interface information, the bus management node can synchronize the corresponding modification information to other service nodes, allowing them to call and collaborate with the modified service node based on the updated interface information, ensuring the normal operation of the distributed system.

[0015] In some embodiments, the bus management node is further configured to:

[0016] Receive a query instruction sent by the at least one bus service node; wherein the query instruction is used to query the target bus service node that performs the target service function;

[0017] According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes;

[0018] If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function;

[0019] Send the call interface information to the bus service node that sent the query command.

[0020] This application provides a specific implementation method for a bus management node to query and obtain the calling interface information of a target bus service node. Specifically, after receiving a query instruction sent by a bus service node, the node can query all distributed physical nodes to see if a target bus service node that supports the execution of the target service function exists. If the target bus service node is found, the calling interface information of the service node is obtained and returned to the bus service node that sent the query instruction, so that the service node can call the target bus service node through the calling interface information.

[0021] In some embodiments, the bus management node is further configured to:

[0022] Add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node;

[0023] Receive heartbeat signals sent by each of the first guardian nodes at a pre-set first time interval;

[0024] If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period.

[0025] If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

[0026] In this embodiment, the bus management node can also be used to monitor and protect the bus service nodes within the distributed physical nodes. Specifically, these bus service nodes can be added to the first protection list of the bus management node as the first protection nodes of the bus management node. For these first protection nodes, the bus management node can receive the heartbeat signaling sent by these first protection nodes at the first time interval. If the bus management node has not received the heartbeat signaling sent by the first target node in the first protection node at the second time interval, it is considered that the first target node has exited from the cooperative bus. If it also does not receive the deregistration information sent by the first target node, it is considered that the first target node has not actively exited the cooperative bus, so it is determined that it has exited abnormally. At this time, the first target node is restarted to make it run again, which improves the reliability of the bus service nodes and the cooperative bus itself to a certain extent.

[0027] In some embodiments, each of the distributed physical nodes further includes a bus daemon node:

[0028] The bus guardian node is used for:

[0029] Add the bus management node to the second guardian list of the bus guardian node, as at least one second guardian node of the bus guardian node;

[0030] Receive heartbeat signals sent by each of the second guardian nodes at a pre-set third time interval;

[0031] If no heartbeat signal is received from the second target node among the at least one second guardian node within a pre-set fourth time period, it is determined that the second target node has abnormally exited and is restarted; wherein, the fourth time period is greater than or equal to the third time period;

[0032] The bus management node is also used to: add the bus guardian node to the first guardian list of the bus management node, so as to serve as the first guardian node of the bus management node.

[0033] In this embodiment, each distributed physical node may further include a bus guardian node for bidirectional monitoring and protection with the bus management node in the distributed physical node. Specifically, the bus guardian node adds the bus management node to the second guardian list as its second guardian node. The bus guardian node can receive heartbeat signals sent by these second guardian nodes every third time interval. If the bus guardian node has not received a heartbeat signal sent by the second target node in the second guardian node within the fourth time interval, it is considered that the second target node has abnormally exited, and at this time it is necessary to restart the second target node to make it run again. Similarly, the bus guardian node can also be added to the first guardian list of the bus management node, so that the bus management node can monitor and protect the bus guardian node, which improves the reliability of the bus management node, bus service nodes and the cooperative bus itself to a certain extent.

[0034] In some embodiments, the at least two distributed physical nodes are divided into a first distributed physical node that provides stateless services and a second distributed physical node that provides stateful services.

[0035] In this context, the stateless service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is unrelated to the data state inside the bus service node. The stateful service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is related to the data state inside the bus service node. At least two first distributed physical nodes are set as master nodes, one second distributed physical node is set as a master node, and at least one second distributed physical node is set as a backup node. The bus service node in the master node is used to execute the business function, and the backup node is used to synchronize the data state inside the master node and to replace the master node in executing the business function in the event of an anomaly in the master node.

[0036] In this embodiment, based on the service characteristics of the bus service nodes, i.e., whether the distributed physical nodes provide stateless or stateful services, the distributed physical nodes can be divided into first distributed physical nodes and second distributed physical nodes for separate deployment. Specifically, for the first distributed physical nodes providing stateless services, since the call result of the bus service node's business function is independent of the data state inside the bus service node, at least two first distributed physical nodes can be set as master nodes. The bus service nodes in these master nodes can all execute business functions, thus supporting dynamic load balancing. That is, multiple running first distributed physical nodes jointly provide services, and each first distributed physical node can provide equivalent services. When an external call occurs, the load balancing algorithm dynamically selects the first distributed physical node with the lighter load to provide services, thereby achieving dynamic load balancing. Furthermore, if multiple first distributed physical nodes are set as master nodes, this multi-master redundancy setting enables... The failure of any one of the first distributed physical nodes ensures that the other first distributed physical nodes can continue to provide services, thus improving the reliability of the cooperative bus itself. In addition, for the second distributed physical nodes that provide stateful services, since the result of calling the business function of the bus business node is related to the internal data state of the bus business node, and not just the input data or parameters passed by the caller, one of the second distributed physical nodes is set as the master node to execute the business function, and the rest are set as backup nodes. The backup nodes are always on standby. When the master node fails, the backup nodes can be promoted to the master node to continue to provide the expected services to the system, ensuring the continuity of services and the reliability of the system.

[0037] In some embodiments, each of the distributed physical nodes further includes a bus proxy module, and the at least one bus service node interacts with the bus management node and / or other bus service nodes among the at least two distributed physical nodes by calling the bus proxy module;

[0038] The bus proxy module is used for:

[0039] Receive a call instruction sent by at least one bus service node;

[0040] Based on the call type indicated by the call instruction, perform at least one of the following operations on the bus service node that sent the call instruction: a first operation related to node management; a second operation related to message multicast or broadcast; and a third operation related to remote procedure call (RPC) access.

[0041] In this embodiment, each distributed physical node may further include a bus proxy module. Bus service nodes can interact with the bus management node and other bus service nodes on the cooperative bus by calling the bus proxy module, thus realizing bidirectional proxy between service nodes and the bus. Specifically, the bus proxy module can receive a call instruction sent by at least one bus service node and, according to the call type indicated by the call instruction, execute a first operation related to node management, and / or a second operation related to message multicast or broadcast, and / or a third operation related to RPC access. By setting the bus proxy module, standardized management and scheduling of bus service nodes are realized, enabling different bus service nodes to interact normally with the cooperative bus through the bus proxy module.

[0042] Secondly, embodiments of this application also provide a distributed management method based on a cooperative bus. The method is based on the distributed system based on a cooperative bus described in any of the above embodiments and is applied to a bus management node. The method includes:

[0043] On the collaborative bus, perform at least one of the following operations: registration, deregistration, and information change on at least one bus service node;

[0044] At least one bus service node is used to execute pre-set service functions.

[0045] In some embodiments, performing at least one of registration, deregistration, and information modification on at least one bus service node on the cooperative bus includes:

[0046] Send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes, wherein the first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node;

[0047] Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes;

[0048] The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

[0049] In some embodiments, the method further includes:

[0050] Receive a query instruction sent by the at least one bus service node; wherein the query instruction is used to query the target bus service node that performs the target service function;

[0051] According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes;

[0052] If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function;

[0053] Send the call interface information to the bus service node that sent the query command.

[0054] In some embodiments, the method further includes:

[0055] Add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node;

[0056] Receive heartbeat signals sent by each of the first guardian nodes at pre-set first intervals;

[0057] If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period.

[0058] If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

[0059] Thirdly, embodiments of this application also provide a distributed management device based on a cooperative bus. The device is based on the distributed system based on a cooperative bus described in any of the above embodiments and is applied to a bus management node. The device includes:

[0060] An execution module is used to perform at least one of registration, deregistration, and information modification on at least one bus service node on the cooperative bus;

[0061] At least one bus service node is used to execute pre-set service functions.

[0062] Fourthly, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the distributed management method based on a cooperative bus as described in the second aspect.

[0063] Fifthly, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the distributed management method based on a cooperative bus as described in the second aspect.

[0064] In a sixth aspect, embodiments of this application also provide a computer program product, which includes a computer program that, when run on a computer, implements the distributed management method based on a cooperative bus as described in the second aspect. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 This is one of the schematic diagrams of a distributed system based on a cooperative bus proposed in the embodiments of this application;

[0067] Figure 2 This is a second schematic diagram of the structure of a distributed system based on a cooperative bus proposed in the embodiments of this application;

[0068] Figure 3 This is a schematic diagram illustrating the relationship between bus service nodes and bus proxy modules in a distributed system based on a collaborative bus, as proposed in an embodiment of this application.

[0069] Figure 4 This is a flowchart illustrating the operation of a bus proxy module in a distributed system based on a collaborative bus, as proposed in an embodiment of this application.

[0070] Figure 5 This is one of the flowcharts illustrating a distributed management method based on a collaborative bus proposed in an embodiment of this application;

[0071] Figure 6 This is a second flowchart illustrating a distributed management method based on a collaborative bus proposed in an embodiment of this application;

[0072] Figure 7 This is the third flowchart illustrating a distributed management method based on a collaborative bus proposed in this application embodiment;

[0073] Figure 8 This is the fourth flowchart illustrating a distributed management method based on a collaborative bus proposed in this application embodiment;

[0074] Figure 9 This is the third schematic diagram of the structure of a distributed system based on a cooperative bus proposed in the embodiments of this application;

[0075] Figure 10 This is a schematic diagram illustrating the workflow of each node in a distributed system based on a collaborative bus, as proposed in an embodiment of this application.

[0076] Figure 11 This is a flowchart illustrating the implementation steps of a distributed system based on a cooperative bus, as proposed in an embodiment of this application.

[0077] Figure 12 This is a schematic diagram of the architecture of a data acquisition system example based on a cooperative bus distributed system proposed in an embodiment of this application;

[0078] Figure 13 This is a schematic diagram of the structure of a distributed management device based on a cooperative bus proposed in an embodiment of this application. Detailed Implementation

[0079] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0080] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0081] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0082] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0083] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0084] Among related technologies, how to build a distributed system suitable for local area networks and support collaborative calls between business functions is a technical problem that urgently needs to be solved.

[0085] To address the aforementioned issues, this application provides a distributed system based on a collaborative bus. This system can assist in the construction of large-scale distributed systems with complex business processes and high real-time requirements, such as large-scale data acquisition platforms, monitoring systems, and diagnostic systems, by enabling distributed communication and collaboration between different services and applications via a soft bus. This application supports dynamic expansion of distributed system business functions and system business scale, ensuring high system reliability and high performance in distributed collaboration.

[0086] The following provides a detailed description of the distributed system, distributed management method, and apparatus based on the cooperative bus provided in the embodiments of this application.

[0087] First, the distributed system based on the cooperative bus provided in the embodiments of this application will be described. Figure 1 This is one of the schematic diagrams of a distributed system based on a cooperative bus proposed in the embodiments of this application, such as... Figure 1 As shown, the distributed system 10 based on the cooperative bus includes at least two distributed physical nodes 100 disposed on the cooperative bus, and each of the distributed physical nodes 100 includes;

[0088] At least one bus service node 101 is used to: execute pre-set service functions;

[0089] Bus management node 102 is configured to: perform at least one of the following operations on the at least one bus service node 101: registration, deregistration, and information change, on the cooperative bus.

[0090] It should be noted that for each distributed physical node 100, its bus management node 102 typically only performs related operations on at least one of its bus service nodes 101, and does not perform related operations on the bus service nodes included in other distributed physical nodes.

[0091] It should also be noted that the aforementioned collaborative bus can be implemented, for example, through a switch. The physical layer of the collaborative bus is based on a local area network, and multiple distributed physical nodes 100 can be connected to the bus. Different distributed physical nodes 100 can be interconnected based on TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Each distributed physical node 100 can be considered as an independent server or PC (Personal Computer) workstation.

[0092] The aforementioned bus service nodes are participants in the collaborative bus and the main body of business functions in building the distributed system. They encapsulate the implementation of specific business functions. Different bus service nodes can implement the same or different functions, and multiple bus service nodes collaborate to realize the business functions of the entire distributed system.

[0093] In some embodiments, collaboration between bus service nodes can be divided into two methods: message multicast and RPC calls. Message multicast is implemented based on UDP multicast and is mainly used for one-to-many event notifications or data synchronization, while RPC calls are based on direct TCP connections and are mainly used for point-to-point remote function calls. All collaborative content can be bypassed by the bus management node, thus ensuring high efficiency in collaboration.

[0094] The bus management node is the builder of the collaborative bus. It can manage the bus service nodes on its own machine (the distributed physical node where the bus management node is located), and supports the dynamic registration, deregistration, and information modification of bus service nodes on the collaborative bus. That is, it supports the access or removal of bus service nodes from the collaborative bus, and can also modify the relevant information of some bus service nodes that have been connected to the collaborative bus, such as changing the calling interface information of the bus service nodes.

[0095] It should also be noted that each of the above nodes, except for the distributed physical nodes, such as bus service nodes and bus management nodes, can be understood as an independent service process instance or application process instance.

[0096] Specifically, the distributed system of this application includes at least two distributed physical nodes set on a cooperative bus. Each physical node includes at least one bus service node for performing business functions and a bus management node for managing the bus service nodes. The bus management node is used to perform at least one of the following operations on the cooperative bus: registration, deregistration, and information modification.

[0097] For example, based on actual needs, a bus service node can be registered on the collaborative bus through the bus management node to connect the bus service node to the collaborative bus, so that the distributed system can support the execution of the corresponding business functions.

[0098] Alternatively, a bus service node that has been connected to the cooperative bus can be deregistered through the bus management node, so that the service node can be removed from the cooperative bus.

[0099] In addition, information about a specific bus service node on the cooperative bus can be changed through the bus management node.

[0100] By supporting the above operations, the bus management node enables bus service nodes to publish services with corresponding business functions to the collaborative bus in a hot-swappable manner. This facilitates subsequent mutual invocation of their respective services among service nodes for collaboration, thereby realizing the business functions of the entire distributed system.

[0101] In the embodiments of this application, the dynamic expansion of the business functions of the distributed system can be realized, and thus the dynamic expansion of the scale of the system business can also be realized. The system operates with high reliability and high performance in distributed collaboration. It can be applied to the construction of lightweight, autonomous, and highly secure local area network distributed systems and can support the call and collaboration between business functions.

[0102] In some embodiments, a specific implementation method is provided for the bus management node to perform registration, deregistration, and information modification. The bus management node 102 is specifically used for:

[0103] Send first information related to the at least one bus service node 101 to other bus management nodes, including other distributed physical nodes. The first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node 101.

[0104] Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information and change information related to at least one bus service node 101 included in the other distributed physical nodes;

[0105] The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes 100, and the local distributed physical node is the distributed physical node where the bus management node 102 is located.

[0106] Specifically, on the collaborative bus, the bus management node performs at least one of the following operations: registration, deregistration, and information modification on at least one bus service node. Specifically, it dynamically synchronizes the registration information, deregistration information, and modification information (considered as the first information) of at least one bus service node in the local distributed physical nodes to other bus management nodes included in the other distributed physical nodes on the collaborative bus. This enables all bus management nodes on the collaborative bus to obtain the dynamic changes of at least one bus service node on their local machine in a timely manner, facilitating other bus service nodes to choose whether to collaborate with certain bus service nodes based on this synchronized information.

[0107] Similarly, registration, deregistration, and information changes (considered as secondary information) of bus service nodes in other distributed physical nodes also need to be promptly synchronized to the bus management node of the local distributed physical node, so that at least one bus service node in the local distributed physical node can choose whether to collaborate with certain bus service nodes.

[0108] This application provides a specific implementation method for a bus management node to perform registration, deregistration, and information modification. Specifically, the bus management node synchronizes first information of at least one bus service node within its own physical node to other bus management nodes in the distributed physical nodes. This first information includes at least one of registration information, deregistration information, and modification information related to the at least one bus service node. For example, synchronizing registration information indicates that a bus service node has been registered on the collaborative bus, allowing other local service nodes or service nodes within other distributed physical nodes to call the registered bus service node for collaboration. Alternatively, after a bus service node exits, the bus management node can synchronize deregistration information to other service nodes, preventing further calls to the exited service node. Furthermore, after a bus service node's information is modified, such as its interface information, the bus management node can synchronize the corresponding modification information to other service nodes, allowing them to call and collaborate with the modified service node based on the updated interface information, thus ensuring the normal operation of the distributed system.

[0109] In some embodiments, a specific implementation method is provided for a bus management node to query and obtain the calling interface information of a target bus service node. The bus management node 102 is further configured to:

[0110] Receive a query instruction sent by the at least one bus service node 101; wherein the query instruction is used to query the target bus service node that performs the target service function;

[0111] According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes 100;

[0112] If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function;

[0113] Send the call interface information to the bus service node that sent the query command.

[0114] For example, suppose that bus management node A-1 in distributed physical node A receives a query instruction sent by bus service node A-2 in its local machine to query whether there is a target bus service node in the distributed system for performing the data acquisition service function. Then bus management node A-1 can first query whether there is a target bus service node in distributed physical node A.

[0115] If a target bus service node is found in distributed physical node A, the corresponding call interface information of the target bus service node can be obtained and returned to bus service node A-2 to facilitate call coordination by bus service node A-2.

[0116] If the query finds that there is no target bus service node in distributed physical node A, you can further query whether there is a target bus service node in other distributed physical nodes besides distributed physical node A.

[0117] If there is a target bus service node among other distributed physical nodes, the call interface information corresponding to the target bus service node can be obtained and returned to bus service node A-2 to facilitate call coordination by bus service node A-2;

[0118] If the target bus service node does not exist in other distributed physical nodes, a prompt message indicating that the target bus service node does not exist in the collaborative bus can be output. Subsequently, as needed, the target bus service node for executing the target service function can be added to the collaborative bus through bus registration, thereby realizing the dynamic expansion of the distributed system service function.

[0119] In some embodiments, if it is determined that a target bus service node is not needed in the cooperative bus for performing the target service function temporarily, the target bus service node can be dynamically removed from the cooperative bus by bus deregistration, thereby avoiding the target bus service node occupying process resources in the distributed physical nodes.

[0120] This application provides a specific implementation method for a bus management node to query and obtain the calling interface information of a target bus service node. Specifically, after receiving a query instruction sent by a bus service node, the node can query all distributed physical nodes to see if a target bus service node that supports the execution of the target service function exists. If the target bus service node is found, the calling interface information of the service node is obtained and returned to the bus service node that sent the query instruction, so that the service node can call the target bus service node through the calling interface information.

[0121] In some embodiments, a specific implementation method is provided for a bus management node to monitor and protect bus service nodes within a local distributed physical node. The bus management node 102 is further configured to:

[0122] Add the at least one bus service node 101 to the first guardian list of the bus management node, as at least one first guardian node of the bus management node 102;

[0123] Receive heartbeat signals sent by each of the first guardian nodes at a pre-set first time interval;

[0124] If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period.

[0125] If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

[0126] In some embodiments, all bus service nodes within the local distributed physical node can be added to the first protection list. Alternatively, depending on the actual situation, only some frequently invoked bus service nodes or specified bus service nodes can be added to the first protection list for monitoring and protection. This application does not impose any restrictions on this.

[0127] It should be noted that the first time for sending heartbeat signals can be set to be the same or different for each of the first guardian nodes in the first guardian list, and this application does not impose any restrictions on this.

[0128] It should also be noted that the specific size of the second time can be set according to the actual situation, as long as it is greater than or equal to the first time. For example, the second time can be set to be equal to the first time; or the second time can be set to a multiple of the first time to avoid the situation where a certain first guardian node fails to send a heartbeat signal in a certain cycle, but is considered to have left the cooperative bus because it has not left the cooperative bus. This application does not impose any restrictions on this.

[0129] In this embodiment, the bus management node can also be used to monitor and protect the bus service nodes within the distributed physical nodes. Specifically, these bus service nodes can be added to the first protection list of the bus management node as the first protection nodes of the bus management node. For these first protection nodes, the bus management node can receive the heartbeat signaling sent by these first protection nodes at the first time interval. If the bus management node has not received the heartbeat signaling sent by the first target node in the first protection node at the second time interval, it is considered that the first target node has exited from the cooperative bus. If it also does not receive the deregistration information sent by the first target node, it is considered that the first target node did not actively exit the cooperative bus, so it is determined that it has exited abnormally. At this time, the first target node is restarted to make it run again, which improves the reliability of the bus service nodes and the cooperative bus itself to a certain extent.

[0130] In some embodiments, Figure 2 This is a second schematic diagram of the structure of a distributed system based on a cooperative bus proposed in this application embodiment, as shown below. Figure 2 As shown, each of the distributed physical nodes 100 also includes a bus daemon node 103:

[0131] The bus guardian node 103 is used for:

[0132] The bus management node 102 is added to the second guardian list of the bus guardian node 103, serving as at least one second guardian node of the bus guardian node 103;

[0133] Receive heartbeat signals sent by each of the second guardian nodes at a pre-set third time interval;

[0134] If no heartbeat signal is received from the second target node among the at least one second guardian node within a pre-set fourth time period, it is determined that the second target node has abnormally exited and is restarted; wherein, the fourth time period is greater than or equal to the third time period;

[0135] The bus management node 102 is further configured to: add the bus guardian node 103 to the first guardian list of the bus management node 102, as the first guardian node of the bus management node 102.

[0136] In some embodiments, bus guardian nodes can be set in all distributed physical nodes so that the bus guardian nodes and bus management nodes can monitor and protect each other bidirectionally, thereby improving the reliability of the cooperative bus; alternatively, bus guardian nodes can be set only in some more important distributed physical nodes or designated distributed physical nodes as needed to improve the reliability of these distributed physical nodes. This application does not impose any restrictions on this.

[0137] It should be noted that the third time for sending heartbeat signaling for each of the second guardian nodes in the second guardian list can be set to be the same or different, and this application does not impose any restrictions on this.

[0138] It should also be noted that the specific size of the fourth time can be set according to the actual situation, as long as it is greater than or equal to the third time. For example, the fourth time can be set to be equal to the third time; or the fourth time can be set to a multiple of the third time to avoid the situation where a second guardian node fails to send a heartbeat signal in a certain cycle, but is considered to have exited the cooperative bus because it has not exited. This application does not impose any restrictions on this.

[0139] Specifically, the bus daemon node is responsible for monitoring and protecting the bus management node. If the bus management node process exits abnormally, it is restarted to achieve self-healing of the bus. Furthermore, the bus daemon node itself, as a special service node, is also monitored and protected by the bus management node. Through this bidirectional protection between the bus daemon node and the bus management node, the reliability of the bus itself can be effectively guaranteed.

[0140] In this embodiment, each distributed physical node may further include a bus guardian node for bidirectional monitoring and protection with the bus management node in the distributed physical node. Specifically, the bus guardian node adds the bus management node to the second guardian list as its second guardian node. The bus guardian node can receive heartbeat signals sent by these second guardian nodes every third time interval. If the bus guardian node has not received a heartbeat signal sent by the second target node in the second guardian node within the fourth time interval, it is considered that the second target node has abnormally exited, and at this time it is necessary to restart the second target node to make it run again. Similarly, the bus guardian node can also be added to the first guardian list of the bus management node, so that the bus management node can monitor and protect the bus guardian node, which improves the reliability of the bus management node, bus service node and the cooperative bus itself to a certain extent.

[0141] In some embodiments, the at least two distributed physical nodes 100 may be divided into a first distributed physical node that provides stateless services and a second distributed physical node that provides stateful services.

[0142] In this context, the stateless service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is unrelated to the data state inside the bus service node. The stateful service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is related to the data state inside the bus service node. At least two first distributed physical nodes are set as master nodes, one second distributed physical node is set as a master node, and at least one second distributed physical node is set as a backup node. The bus service node in the master node is used to execute the business function, and the backup node is used to synchronize the data state inside the master node and to replace the master node in executing the business function in the event of an anomaly in the master node.

[0143] It should be noted that this application defines the service characteristics of bus service nodes, that is, to segment different services and classify them as stateful or stateless services, so as to realize the dynamic and static load balancing and redundancy scheduling of the distributed system, thereby realizing the dynamic expansion and high performance of the distributed system's business scale.

[0144] For example, to adapt to large-scale business processing, bus service nodes adapted to the collaborative bus will segment a certain service they provide according to the scope of the service objects. For instance, for data collection from 1000 field devices, each segment can be divided into 100 devices. Simultaneously, to achieve load balancing and redundant scheduling, services will be divided into stateless services and stateful services, with different cluster scheduling strategies corresponding to the two types of nodes.

[0145] 1) Stateless service: This refers to a service whose result is independent of its internal data state when called externally, and depends only on the input data or parameters passed by the caller. Typically, this type of service only performs immediate business processing responses based on external calls, does not save business-related state data, and does not perform any business processing autonomously without external calls. Therefore, the load of this type of service is strongly correlated with external access and fluctuates randomly due to the influence of external access.

[0146] For the scheduling strategy of stateless service clusters (composed of multiple first distributed physical nodes): For stateless services, the cluster strategy adopts the method of "dynamic load balancing + multi-master redundancy".

[0147] Dynamic load balancing refers to the following: multiple running service instances (i.e., the first distributed physical nodes) jointly provide services for a certain service segment, and each instance can provide equal services; when an external call occurs, the load balancing algorithm dynamically selects the node instance with the lighter load to provide services, thereby achieving dynamic load balancing.

[0148] Multi-master redundancy means that since the service instances provided by the above service instances are completely identical in terms of the service type and the corresponding service segments, the failure of any one instance will not affect the service capabilities of other instances, thus having a built-in redundancy effect, and there is no distinction between primary and backup states between parallel service instances.

[0149] 2) Stateful Services: These are services where the result of an external call depends on the service's internal data state, not solely on the input data or parameters passed by the caller. Typically, the primary function of this type of service is to autonomously run and perform continuous business processing. Responding to external requests does not affect the operation of the main business. The workload mainly comes from predictable, continuous business operations, thus the load is relatively stable. Because it is a continuous business process, the system state data changes over time, and external accesses with the same parameters will yield different results depending on the system's internal state.

[0150] For the scheduling strategy of stateful service clusters (composed of multiple second distributed physical nodes): For stateful services, the cluster strategy adopts the method of "static load balancing + primary and backup redundancy".

[0151] Static load balancing refers to the static allocation of different service instances to provide service capabilities for different service segments based on the load calculation results before the service runs. The service scope of the service instances will not be dynamically adjusted after the system starts.

[0152] To ensure high service availability, each service segment is configured with one primary running node and several backup redundant nodes (i.e., primary-backup redundancy). Under normal circumstances, the primary node provides the expected service and synchronizes its running status with the backup nodes. The backup nodes are always on standby. When the primary node fails, the backup node will be promoted to the primary node to continue providing the expected service to the system, ensuring service continuity.

[0153] For example, Table 1 below represents the stateless service cluster strategy, and Table 2 represents the stateful service cluster strategy.

[0154] Table 1 Stateless Service Cluster Strategy

[0155]

[0156] Table 2 Stateful Service Cluster Strategy

[0157]

[0158] Where N is the number of service segments, and M is the number of distributed physical nodes set in each service segment.

[0159] In this embodiment, based on the service characteristics of the bus service nodes, i.e., whether the distributed physical nodes provide stateless or stateful services, the distributed physical nodes can be divided into first distributed physical nodes and second distributed physical nodes for separate deployment. Specifically, for the first distributed physical nodes providing stateless services, since the call result of the bus service node's business function is independent of the data state inside the bus service node, at least two first distributed physical nodes can be set as master nodes. The bus service nodes in these master nodes can all execute business functions, thus supporting dynamic load balancing. That is, multiple running first distributed physical nodes jointly provide services, and each first distributed physical node can provide equivalent services. When an external call occurs, the load balancing algorithm dynamically selects the first distributed physical node with the lighter load to provide services, thereby achieving dynamic load balancing. Furthermore, if multiple first distributed physical nodes are set as master nodes, this multi-master redundancy setting enables... The failure of any one of the first distributed physical nodes ensures that the other first distributed physical nodes can continue to provide services, thus improving the reliability of the cooperative bus itself. In addition, for the second distributed physical nodes that provide stateful services, since the result of calling the business function of the bus business node is related to the internal data state of the bus business node, and not just the input data or parameters passed by the caller, one of the second distributed physical nodes is set as the master node to execute the business function, and the rest are set as backup nodes. The backup nodes are always on standby. When the master node fails, the backup nodes can be promoted to the master node to continue to provide the expected services to the system, ensuring the continuity of services and the reliability of the system.

[0160] In some embodiments, each of the distributed physical nodes 100 may further include a bus proxy module, and the at least one bus service node 101 realizes interaction with the bus management node 102 and / or other bus service nodes among the at least two distributed physical nodes by calling the bus proxy module;

[0161] The bus proxy module is used for:

[0162] Receive a call instruction sent by at least one bus service node;

[0163] Based on the call type indicated by the call instruction, perform at least one of the following operations on the bus service node that sent the call instruction: a first operation related to node management; a second operation related to message multicast or broadcast; and a third operation related to RPC access.

[0164] Specifically, the bus proxy module can be understood as a software module that encapsulates all bus-related functions and is called by bus service nodes to achieve bus access. The bus proxy module implements bidirectional proxying between bus service nodes and the cooperative bus. On the one hand, from the perspective of the bus service node, it proxies all the functions of the bus, and the business logic inside the bus service node can access all the functions and services provided by the bus by calling this module. On the other hand, from the perspective of the bus, it proxies all the functions of the standard bus service nodes, and the bus management node can also achieve standardized management and scheduling of bus service nodes by interacting with this module.

[0165] In some embodiments, bus service nodes can invoke different functional interfaces of the bus proxy module to perform different operations. The three functional interfaces of the bus proxy module that can be invoked by bus service nodes are:

[0166] 1) Node Management Interface (used to perform the first operation related to node management). This interface encapsulates node management-related functions, the main contents of which include:

[0167] <1> Query all bus service nodes and their self-description information within the system;

[0168] <2> Query all bus service nodes within the local machine and their self-description information;

[0169] <3> Register / deregister this bus service node (including self-describing information) within the system;

[0170] <4> Respond to the heartbeat query of the service node on this bus;

[0171] <5> Respond to the running status query of the service node on this bus;

[0172] <6> Respond to the start / stop / state switching control of the service nodes on this bus;

[0173] <7> Respond to runtime parameter space queries from the service nodes of this bus;

[0174] <8> Respond to runtime parameter queries from the service nodes of this bus;

[0175] <9> Respond to the runtime parameter settings of the service nodes on this bus.

[0176] 2) Message multicast / broadcast interface (used to perform secondary operations related to message multicast or broadcast). This interface encapsulates message multicast / broadcast related functions, and its main contents include:

[0177] <1> Query all multicast groups and their descriptions within the system;

[0178] <2> Create or delete a multicast group;

[0179] <3> Join or leave a multicast group;

[0180] <4> Messages are sent to a specific group.

[0181] <5> Receive multicast messages and send callbacks to the service nodes on this bus;

[0182] <6> Broadcast messages to the bus;

[0183] <7> Receive broadcast messages and send them back to the service nodes on this bus.

[0184] 3) RPC access interface (used to perform third-party operations related to RPC access). This interface encapsulates RPC call-related functions and supports private or standard RPC protocols. Its main components include:

[0185] <1> Query the RPC interface of the specified bus service node;

[0186] <2> Query all bus service nodes that provide the specified RPC service;

[0187] <3> Publish the RPC interface of this bus service node (responding to queries from other bus service nodes);

[0188] <4> Call the RPC interface of the specified bus service node;

[0189] <5> Bind the RPC callback of the specified bus service node;

[0190] <6> Call the specified RPC service in a continuous delegation manner (suitable for static load balancing scenarios where the scope of the service is the same for multiple calls);

[0191] <7> Invoke a specified RPC service in a single delegation manner (suitable for dynamic load balancing, or static load balancing but the scope of the service called is different each time).

[0192] In this context, delegated RPC service invocation refers to the process where bus service nodes make RPC calls through the bus proxy module, specifying only the RPC service without specifying the specific bus service node providing the RPC service. The bus proxy module automatically selects the bus service node based on the optimal cluster strategy. For the bus service node, it only needs to be concerned with what service to call, without needing to be concerned with the specific cluster architecture providing the service.

[0193] In other embodiments, Figure 3 This is a schematic diagram illustrating the relationship between bus service nodes and bus proxy modules in a distributed system based on a collaborative bus, as proposed in an embodiment of this application. Figure 3 As shown, a bus service node contains an externally published RPC service. It can register with the cooperative bus by calling the node management interface of the bus agent module to provide distributed services to other bus service nodes. It can also notify other bus service nodes of its status or data or receive notification messages from other bus service nodes by calling the message multicast / broadcast interface of the bus agent module. It can also access the RPC services provided by other bus service nodes on the bus in a distributed manner by calling the RPC access interface of the bus agent module.

[0194] Figure 4 This is a flowchart illustrating the operation of a bus proxy module in a distributed system based on a cooperative bus, as proposed in an embodiment of this application. Figure 4 As shown, the main workflow of the bus proxy module includes the following steps:

[0195] S401, Begin.

[0196] S402, the bus service node calls the bus agent module through the interface.

[0197] S403, the bus agent module determines the call type. If it is a node management type, proceed to step S404-1; if it is an RPC call type, proceed to step S405-1; if it is a message multicast / broadcast type, proceed to step S406-1.

[0198] It should be noted that S404-1~S404-6, S405-1~S405-7 and S406-1~S406-5 are three parallel processes, which proceed to step S407 after completion.

[0199] S404-1, the bus agent module serializes function call requests into a byte stream.

[0200] S404-2, the bus proxy module sends the serialized byte stream to the local bus management node.

[0201] S404-3, the local bus management node receives the byte stream and parses it into a call request.

[0202] S404-4, the local bus management node executes the call request and serializes the execution result into a byte stream and returns it to the bus agent module.

[0203] S404-5, the bus agent module receives the response byte stream and parses it into a response result.

[0204] S404-6, the bus proxy module returns the response result to the bus service node that called the interface.

[0205] S405-1, the bus proxy module (i.e. the call-side bus proxy module) serializes the function call request into a byte stream.

[0206] S405-2, the bus proxy module sends the serialized byte stream to the bus service node that provides RPC services.

[0207] S405-3, the bus agent module corresponding to the bus service node providing RPC service receives the byte stream and parses it into a call request.

[0208] S405-4, the bus agent module corresponding to the bus service node that provides RPC service will call the request callback to the bus service node that provides RPC service.

[0209] S405-5, the bus service node providing RPC service responds to the request and returns the result to the bus agent module corresponding to the bus service node providing RPC service.

[0210] S405-6, the bus agent module corresponding to the bus service node providing RPC service serializes the result data and sends it to the calling side bus agent module.

[0211] S405-7: After the calling side bus agent module receives the serialized data and parses it into result data, it sends a callback to the calling bus service node.

[0212] S406-1, the bus proxy module serializes multicast messages into a byte stream.

[0213] S406-2, the bus proxy module sends the byte stream to all bus service nodes in the target multicast group via UDP broadcast.

[0214] S406-3, the bus proxy module (receiving side bus proxy module) corresponding to all bus service nodes (as receiving side bus service nodes) in the target multicast group receives the byte stream and parses it into a multicast message.

[0215] S406-4, the receiving-side bus proxy module will send the parsed multicast message back to the bus service node on the receiving side.

[0216] S406-5, the bus service node on the receiving side processes multicast messages.

[0217] S407, End.

[0218] In this embodiment, each distributed physical node may further include a bus proxy module. Bus service nodes can interact with the bus management node and other bus service nodes on the cooperative bus by calling the bus proxy module, thus realizing bidirectional proxy between service nodes and the bus. Specifically, the bus proxy module can receive a call instruction sent by at least one bus service node and, according to the call type indicated by the call instruction, execute a first operation related to node management, and / or a second operation related to message multicast or broadcast, and / or a third operation related to RPC access. By setting the bus proxy module, standardized management and scheduling of bus service nodes are realized, enabling different bus service nodes to interact normally with the cooperative bus through the bus proxy module.

[0219] This application also provides a distributed management method based on a cooperative bus. Figure 5 This is one of the flowcharts illustrating a distributed management method based on a cooperative bus proposed in this application. The method is based on the distributed system based on a cooperative bus described in any of the above embodiments and is applied to a bus management node, such as... Figure 5 As shown, the distributed management method based on the cooperative bus includes S501;

[0220] S501, on the cooperative bus, performs at least one of the following operations: registration, deregistration, and information change on at least one bus service node;

[0221] At least one bus service node is used to execute pre-set service functions.

[0222] Specifically, for a distributed system based on a cooperative bus, each distributed physical node includes a bus management node and at least one bus service node for performing business functions. The bus management node is used to perform at least one of the following operations on the cooperative bus: registration, deregistration, and information modification.

[0223] It should be noted that the technical implementation details and beneficial effects of the distributed management method based on the cooperative bus provided in the embodiments of this application can be referred to the relevant content of the distributed system based on the cooperative bus in the above embodiments, and will not be repeated here.

[0224] In some embodiments, Figure 6This is a second flowchart illustrating a distributed management method based on a cooperative bus proposed in this application. Figure 6 As shown, S501 specifically includes S5011-S5012;

[0225] S5011, send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes;

[0226] The first information includes at least one of the following: registration information, deregistration information, and change information related to the at least one bus service node.

[0227] S5012 receives second information sent by other distributed physical nodes, including other bus management nodes;

[0228] The second information is at least one of the following: registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes.

[0229] The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

[0230] It should be noted that the technical implementation details and beneficial effects of the distributed management method based on the cooperative bus provided in the embodiments of this application can be referred to the relevant content of the distributed system based on the cooperative bus in the above embodiments, and will not be repeated here.

[0231] In some embodiments, Figure 7 This is the third flowchart illustrating a distributed management method based on a cooperative bus proposed in this application. Figure 7 As shown, the distributed management method based on the cooperative bus also includes S701-S704;

[0232] S701, Receive a query command sent by the at least one bus service node;

[0233] The query instruction is used to query the target bus service node that performs the target service function.

[0234] S702, according to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes.

[0235] S703, if the target bus service node is found, obtain the call interface information corresponding to the target bus service node;

[0236] The interface call information is used to call the target bus service node to execute the corresponding service function.

[0237] S704, send the call interface information to the bus service node that sent the query command.

[0238] It should be noted that the technical implementation details and beneficial effects of the distributed management method based on the cooperative bus provided in the embodiments of this application can be referred to the relevant content of the distributed system based on the cooperative bus in the above embodiments, and will not be repeated here.

[0239] In some embodiments, Figure 8 This is the fourth flowchart illustrating a distributed management method based on a cooperative bus proposed in this application. Figure 8 As shown, the distributed management method based on the cooperative bus also includes S801-S804;

[0240] S801, add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node.

[0241] S802, receive the heartbeat signaling sent by each of the first guardian nodes at a preset first time interval.

[0242] S803, if no heartbeat signaling is received from the first target node among the at least one first guardian node within a preset second time period, the first target node is determined to have exited;

[0243] Wherein, the second time is greater than or equal to the first time.

[0244] S804, if it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally and the first target node is restarted.

[0245] It should be noted that the technical implementation details and beneficial effects of the distributed management method based on the cooperative bus provided in the embodiments of this application can be referred to the relevant content of the distributed system based on the cooperative bus in the above embodiments, and will not be repeated here.

[0246] The following example illustrates the distributed system and distributed management method based on the cooperative bus provided in this application. This system and method are applicable to the construction of local area network distributed systems, specifically involving the following points:

[0247] (i) The overall architecture of the collaborative bus is defined, including: the definitions of bus management nodes, bus guardian nodes, and bus service nodes; the main functions and mutual cooperation relationships of different types of nodes; and the collaborative mechanism and deployment method of the collaborative bus.

[0248] Figure 9 This is the third schematic diagram of a distributed system based on a cooperative bus proposed in this application embodiment, as shown below. Figure 9 As shown, the distributed system based on the cooperative bus implements the cooperative bus through a switch. Distributed physical nodes 1 to X are connected to the cooperative bus. The figure takes distributed physical node 2 as an example to show the specific nodes included in the distributed physical nodes, specifically including bus service nodes 1 to Y (a total of Y bus service nodes), a bus guardian node and a bus management node.

[0249] It should be noted that each bus service node can also be configured with a corresponding bus proxy module to realize bidirectional proxying between the bus service node and the cooperative bus. Figure 9 This is not shown in the Chinese text.

[0250] In one embodiment, each distributed physical node must be equipped with one bus management node, one bus daemon node, and several bus service nodes. Wherein:

[0251] <1> The bus management node is the builder of the collaborative bus. On one hand, it manages the bus service nodes on its own machine, supporting dynamic registration, service publishing, and service querying. On the other hand, it synchronizes distributed registration information among bus management nodes deployed on multiple distributed physical nodes, supporting distributed service publishing and querying among bus service nodes deployed on different distributed physical nodes. Finally, the bus management node is also responsible for process protection and operational monitoring of the bus service nodes on its own machine. When a bus service node process exits abnormally, it restarts the process, achieving system self-healing and ensuring system reliability.

[0252] <2> The bus daemon node is responsible for monitoring and protecting the bus management node. If the bus management node's process exits abnormally, it restarts the node, enabling self-healing of the bus. Furthermore, the bus daemon node itself, as a special service node, is also monitored and protected by the bus management node. This bidirectional protection between the bus daemon node and the bus management node ensures the reliability of the bus itself.

[0253] <3> Bus service nodes are participants in the collaborative bus and the main entities responsible for building the business functions of the distributed system. They encapsulate the implementation of specific business functions, with different bus service nodes implementing different functions. Multiple bus service nodes collaborate to realize the business functions of the entire distributed system. Collaboration between bus service nodes takes two forms: message multicast and RPC calls. Message multicast, based on UDP multicast, is mainly used for one-to-many event notifications or data synchronization. RPC, based on direct TCP connections, is mainly used for point-to-point remote function calls. All collaborative content is not relayed through the bus management node, thus ensuring high efficiency in collaboration.

[0254] In some embodiments, for the initialization and node management of the cooperative bus, Figure 10 This is a flowchart illustrating the operation of each node in a distributed system based on a cooperative bus, as proposed in an embodiment of this application. Figure 10 As shown, the main steps include:

[0255] S1, Begin.

[0256] S2, the bus management node starts up and establishes a connection with other bus management nodes on the cooperative bus.

[0257] S3, the bus guardian node starts up, registers itself with the local bus management node, and adds the bus management node to its guardian list.

[0258] S4, the bus service node starts up and registers itself with the local bus management node.

[0259] S5, the local bus management node accepts the registration of bus service nodes, adds new nodes (including bus guardian nodes and bus service nodes) to its guardian list, and synchronizes the information of the new nodes to other bus management nodes on the bus.

[0260] S6, each bus management node will notify other bus service nodes on the local machine of the addition of a new node.

[0261] S7: Each bus service node establishes an RPC connection with the new node according to its own needs.

[0262] In S8, each bus service node continuously loops through S8 according to its own needs and by calling new node functions via RPC, until the bus management node detects that a bus service node has exited, and then enters S9.

[0263] S9, the local bus management node detects that a bus service node has exited and synchronizes the exited node's information to other bus management nodes.

[0264] S10, each bus management node will notify other bus service nodes on the same machine of the exiting node information.

[0265] S11, each bus service node receives a notification of node exit and responds according to its own service needs.

[0266] S12, the local bus management node determines whether the exit of a certain bus service node is an abnormal exit. If yes, proceed to S13; otherwise, proceed to S14.

[0267] S13, after the local bus management node restarts the bus service node that exited abnormally, it returns to S4.

[0268] S14, End.

[0269] (ii) Defines the types of distributed services based on the collaborative bus and the corresponding cluster strategies to guide the implementation of distributed systems based on the collaborative bus.

[0270] To adapt to large-scale business processing, bus service nodes adapted to the collaborative bus will segment the services they provide according to the scope of the service objects. For example, data collection from 1000 field devices can be divided into service segments of 100 devices each. At the same time, to achieve load balancing and redundant scheduling, services will be divided into stateless services and stateful services, with different cluster scheduling strategies corresponding to the two types of nodes.

[0271] For stateless services, the cluster strategy employs a combination of dynamic load balancing and multi-master redundancy. For details on dynamic load balancing and multi-master redundancy, please refer to the above embodiments; they will not be repeated here.

[0272] For stateful services, the cluster strategy adopts a combination of static load balancing and primary / secondary redundancy. The details of static load balancing and primary / secondary redundancy are described in the above embodiments and will not be repeated here.

[0273] (iii) A bus proxy module for the collaborative bus is defined to realize bidirectional business proxy between bus service nodes and the bus, which simplifies the development of distributed systems based on the collaborative bus.

[0274] The specific implementation method and corresponding beneficial effects of the bus proxy module can be found in the above embodiments, and will not be repeated here.

[0275] (iv) The embodiments of this application also provide implementation steps for a distributed system based on a cooperative bus.

[0276] Figure 11 This is a flowchart illustrating the implementation steps of a distributed system based on a cooperative bus, as proposed in an embodiment of this application. Figure 11 As shown, it mainly includes the following parts:

[0277] 1) Define system functions. Based on actual business needs, define the business function boundaries of the distributed system. For example: implement data acquisition and storage for 1000 energy storage cabinets.

[0278] 2) Divide the service modules and determine the service types. For the above data acquisition system, the system is divided into two service modules: data acquisition service and data storage service. The former connects to the energy storage cabinet to collect real-time data using a predetermined communication protocol, and then calls the latter to store the collected real-time data into the database to realize historical data storage.

[0279] 3) Define the cluster strategy for each service module. The data acquisition service is a stateful service, employing a "static load balancing + master-slave redundancy" cluster strategy. The acquisition of data from 1000 devices is divided into 10 service segments, each responsible for the acquisition of data from 100 devices. There is one master and one backup, for a total of 20 data acquisition nodes, deployed on two servers (i.e., distributed physical nodes, specifically acquisition servers 1 and 2). Ten master nodes are deployed on the same server, and ten backup nodes are deployed on the other server. The data storage service is a stateless service, employing a "dynamic load balancing + master-master redundancy" cluster strategy. The data storage of 1000 devices is divided into two service segments, each responsible for the data storage of data from 500 devices. Each segment has four master nodes for mutual backup, for a total of eight data storage nodes, deployed on two servers (specifically storage servers 1 and 2). Each server deploys two nodes for each service segment. Figure 12 This is a schematic diagram of the architecture of a data acquisition system example based on a distributed system of a cooperative bus proposed in this application. It can be seen that a PC workstation and a database server can also be set up on the cooperative bus implemented by the switch. The PC workstation may include a client program, and the database server may include a historical database.

[0280] 4) Develop each service module as a type of bus service node. Treat the data acquisition service and data storage service as independent bus service nodes, encapsulating them as independent software processes. The former publishes data acquisition RPC services to the bus for client programs to access real-time data; the latter publishes data storage RPC services for the data acquisition service to store historical data.

[0281] 5) System debugging and deployment. Deploy the software process developed in step 4) above on the actual physical server according to the clustering strategy in step 3) above, and then debug and verify it until the design expectation is achieved.

[0282] In the embodiments of this application, at least the following beneficial effects exist:

[0283] <1> It supports hot-swapping of bus service nodes to publish services to the bus and call other services on the bus, thereby enabling dynamic expansion of distributed system business functions.

[0284] <2> The service characteristics of bus service nodes (service segmentation, stateful / stateless services) are defined, and it also supports accessing distributed services published on the bus in a proxy manner. This enables dynamic and static load balancing and redundancy scheduling of the distributed system, thereby achieving dynamic expansion of the distributed system's business scale and high performance.

[0285] <3> High reliability of the collaborative bus itself is achieved through distributed redundant deployment of bus management nodes among different distributed physical nodes, and mutual protection between bus guardian nodes and bus management nodes within the same distributed physical node.

[0286] <4> High reliability of bus service nodes is ensured by the distributed redundant deployment of bus service nodes within different distributed physical nodes and the protection of bus service nodes by bus management nodes within the same distributed physical node.

[0287] The above describes the distributed management method based on the cooperative bus proposed in the embodiments of this application. The related devices and electronic equipment are described below.

[0288] Figure 13 This is a schematic diagram of a distributed management device based on a cooperative bus according to an embodiment of this application. The device is based on the distributed system based on a cooperative bus described in any of the above embodiments and is applied to a bus management node, such as... Figure 13 As shown, the distributed management device 1300 based on the cooperative bus includes:

[0289] Execution module 1301 is used to perform at least one of registration, deregistration and information modification on at least one bus service node on the cooperative bus;

[0290] At least one bus service node is used to execute pre-set service functions.

[0291] In some embodiments, the execution module 1301 is specifically used for:

[0292] Send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes, wherein the first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node;

[0293] Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes;

[0294] The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

[0295] In some embodiments, the distributed management device 1300 based on a cooperative bus further includes a query module for:

[0296] Receive a query instruction sent by the at least one bus service node; wherein the query instruction is used to query the target bus service node that performs the target service function;

[0297] According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes;

[0298] If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function;

[0299] Send the call interface information to the bus service node that sent the query command.

[0300] In some embodiments, the distributed management device 1300 based on the cooperative bus further includes a guardian module for:

[0301] Add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node;

[0302] Receive heartbeat signals sent by each of the first guardian nodes at a pre-set first time interval;

[0303] If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period.

[0304] If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

[0305] It should be understood that the distributed management device 1300 based on the cooperative bus in this application embodiment can be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The aforementioned method can also be implemented in software; the distributed management device 1300 based on the cooperative bus and its various modules can also be software modules.

[0306] This application also provides an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned distributed management method based on a cooperative bus.

[0307] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive (SSD).

[0308] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the distributed management method based on the cooperative bus in the above embodiments.

[0309] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0310] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0311] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the following steps:

[0312] On the collaborative bus, at least one of the following operations is performed on at least one bus service node: registration, deregistration, and information change; wherein at least one bus service node is used to perform a pre-set service function.

[0313] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0314] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can 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.

[0315] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0316] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the aforementioned distributed management method based on a cooperative bus. Utilizing the bus management node, the distributed system's business functions can be dynamically expanded, thereby enabling dynamic expansion of the system's business scale. The system operates with high reliability and exhibits high performance in distributed collaboration. It is suitable for building lightweight, autonomous, and highly secure local area network distributed systems and supports collaborative calls between business functions. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the distributed management method based on a cooperative bus provided in the above embodiments, and will not be elaborated upon here.

[0317] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the distributed management method based on the cooperative bus described above.

[0318] The computer program product provided in this application can dynamically expand the business functions of a distributed system, and thus also dynamically expand the scale of the system's business operations. The system operates with high reliability and exhibits high performance in distributed collaboration. It is suitable for building lightweight, autonomous, and highly secure local area network distributed systems and supports collaborative calls between business functions. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the distributed management method based on a collaborative bus provided in the above embodiments, and will not be elaborated upon here.

[0319] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A distributed system based on a cooperative bus, characterized in that, The system includes at least two distributed physical nodes configured on a cooperative bus, each of the distributed physical nodes comprising: At least one bus service node is used to: execute pre-set service functions; A bus management node is configured to: perform at least one of the following operations on the at least one bus service node: registration, deregistration, and information modification on the cooperative bus.

2. The distributed system based on a cooperative bus according to claim 1, characterized in that, The bus management node is specifically used for: Send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes, wherein the first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node; Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes; The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

3. The distributed system based on a cooperative bus according to claim 2, characterized in that, The bus management node is also used for: Receive a query instruction sent by the at least one bus service node; wherein the query instruction is used to query the target bus service node that performs the target service function; According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes; If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function; Send the call interface information to the bus service node that sent the query command.

4. The distributed system based on a cooperative bus according to claim 1, characterized in that, The bus management node is also used for: Add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node; Receive heartbeat signals sent by each of the first guardian nodes at pre-set first intervals; If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period. If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

5. The distributed system based on a cooperative bus according to any one of claims 1 to 4, characterized in that, Each of the aforementioned distributed physical nodes also includes a bus daemon node: The bus guardian node is used for: Add the bus management node to the second guardian list of the bus guardian node, as at least one second guardian node of the bus guardian node; Receive heartbeat signals sent by each of the second guardian nodes at a pre-set third time interval; If no heartbeat signal is received from the second target node among the at least one second guardian node within a pre-set fourth time period, it is determined that the second target node has abnormally exited and is restarted; wherein, the fourth time period is greater than or equal to the third time period; The bus management node is also used to: add the bus guardian node to the first guardian list of the bus management node, so as to serve as the first guardian node of the bus management node.

6. The distributed system based on a cooperative bus according to any one of claims 1 to 4, characterized in that, The at least two distributed physical nodes are divided into a first distributed physical node that provides stateless services and a second distributed physical node that provides stateful services. In this context, the stateless service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is unrelated to the data state inside the bus service node. The stateful service represents the call result of invoking the business function of the bus service node in the distributed physical node, which is related to the data state inside the bus service node. At least two first distributed physical nodes are set as master nodes, one second distributed physical node is set as a master node, and at least one second distributed physical node is set as a backup node. The bus service node in the master node is used to execute the business function, and the backup node is used to synchronize the data state inside the master node and to replace the master node in executing the business function in the event of an anomaly in the master node.

7. The distributed system based on a cooperative bus according to any one of claims 1 to 4, characterized in that, Each of the distributed physical nodes further includes a bus proxy module, and the at least one bus service node realizes the interaction with the bus management node and / or other bus service nodes in the at least two distributed physical nodes by calling the bus proxy module; The bus proxy module is used for: Receive a call instruction sent by at least one bus service node; Based on the call type indicated by the call instruction, perform at least one of the following operations on the bus service node that sent the call instruction: a first operation related to node management; a second operation related to message multicast or broadcast; and a third operation related to remote procedure call (RPC) access.

8. A distributed management method based on a collaborative bus, characterized in that, The method is based on a distributed system based on a cooperative bus as described in any one of claims 1 to 7, and is applied to a bus management node. The method includes: On the collaborative bus, perform at least one of the following operations: registration, deregistration, and information change on at least one bus service node; At least one bus service node is used to execute pre-set service functions.

9. The distributed management method based on a collaborative bus according to claim 8, characterized in that, The step of performing at least one of registration, deregistration, and information modification on at least one bus service node on the cooperative bus includes: Send first information related to the at least one bus service node to other distributed physical nodes, including other bus management nodes, wherein the first information includes at least one of registration information, deregistration information, and change information related to the at least one bus service node; Receive second information sent by other bus management nodes, including other distributed physical nodes, wherein the second information is at least one of registration information, deregistration information, and change information related to at least one bus service node included in the other distributed physical nodes; The other distributed physical nodes are the distributed physical nodes other than the local distributed physical node among the at least two distributed physical nodes, and the local distributed physical node is the distributed physical node where the bus management node is located.

10. The distributed management method based on a collaborative bus according to claim 9, characterized in that, The method further includes: Receive a query instruction sent by the at least one bus service node; wherein the query instruction is used to query the target bus service node that performs the target service function; According to the query instruction, query whether the target bus service node exists in the at least two distributed physical nodes; If the target bus service node is found, the call interface information corresponding to the target bus service node is obtained; wherein, the call interface information is used to call the target bus service node to execute the corresponding business function; Send the call interface information to the bus service node that sent the query command.

11. The distributed management method based on a cooperative bus according to any one of claims 8 to 10, characterized in that, The method further includes: Add the at least one bus service node to the first guardian list of the bus management node, as at least one first guardian node of the bus management node; Receive heartbeat signals sent by each of the first guardian nodes at pre-set first intervals; If no heartbeat signal is received from the first target node among the at least one first guardian node within a pre-set second time period, the first target node is determined to have exited; wherein the second time period is greater than or equal to the first time period. If it is determined that the first target node has exited and no cancellation information has been received from the first target node, then it is determined that the first target node has exited abnormally, and the first target node is restarted.

12. A distributed management device based on a cooperative bus, characterized in that, The device is based on a distributed system based on a cooperative bus as described in any one of claims 1 to 7, and is applied to a bus management node. The device includes: An execution module is used to perform at least one of registration, deregistration, and information modification on at least one bus service node on the cooperative bus; At least one bus service node is used to execute pre-set service functions.

13. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the distributed management method based on a cooperative bus as described in any one of claims 8 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to perform the distributed management method based on a cooperative bus as described in any one of claims 8 to 11.

Images