Nacos-based block chain network service management method and system

Abstract

The invention relates to the technical field of block chains, and provides a Nacos-based block chain network service management method and system, and the Nacos-based block chain network service management method comprises a server construction and configuration process and a client construction and configuration process. The server construction and configuration process comprises the following steps: loading local configuration and creating a Nacos instance when a block chain server is started, starting an RPC and a P2P port, registering the RPC and the P2P port to the Nacos with a label, and constructing a P2P network; the client construction and configuration process comprises the following steps that when a block chain client is started, local configuration is read, a Nacos instance is created, an RPC port is provided, and a grouping instance list is created; rPC port balanced access is provided, sub-threads are created for real-time monitoring, and a grouping instance list is updated. According to the method and the device, the block chain network nodes and ports can be dynamically managed, real-time network joining of new nodes is supported, and automatic capacity expansion is realized; and the block chain network node list can be updated in real time through a health check function, so that the high availability of the network is ensured.

Description

Technical Field

[0001] This application relates to the field of blockchain, and specifically to a blockchain network service management method and system based on Nacos. Background Art

[0002] A blockchain network is a distributed, decentralized network infrastructure used to record and verify a series of transactions or data ledgers. It is a peer-to-peer communication network formed by nodes connected via a point-to-point protocol. Nodes are categorized as application nodes and consensus nodes. Consensus nodes participate in consensus voting on transaction data within the P2P network, ensuring the authenticity and validity of ledger data across all nodes in the network. Beyond the P2P network, blockchains also offer RPC services to clients, allowing them to access blockchain nodes and retrieve transaction data.

[0003] The node management mode in the existing technology has the following obvious shortcomings: The construction of blockchain P2P networks relies on local configuration. Adding or removing nodes requires manual updating of local configuration. As the network scales, the configuration maintenance cost will increase significantly.

[0004] The blockchain network does not have a real-time node health check function. The client cannot update the node list in time and may send requests to unhealthy service instances. It will not be able to request correct data, and the consistency of the ledger cannot be guaranteed.

[0005] Consensus nodes may present a single point of failure. Without consensus nodes, ledger consistency cannot be maintained. Relying on manual maintenance of consensus nodes will greatly reduce the availability of the blockchain network.

[0006] Blockchain network node resource management relies on local configuration and cannot monitor the entire network from a global perspective. Clients or other nodes cannot know all network port numbers. Summary of the Invention

[0007] In order to help solve the above technical problems, this application provides a blockchain network service management method and system based on Nacos.

[0008] In the first aspect, this application provides a blockchain network service management method based on Nacos, which adopts the following technical solutions: A Nacos-based blockchain network service management method, wherein the Nacos-based blockchain network service management method includes a server-side construction and configuration process and a client-side construction and configuration process, and the server-side construction and configuration process includes the following steps: When the blockchain server starts, it loads the local configuration and creates a Nacos instance, starts the RPC and P2P ports, registers with Nacos with tags, and builds a P2P network. Building a P2P network includes a main thread and child threads: Main thread: Sets Nacos request parameters and obtains a list of node groups from Nacos. The main thread creates persistent connections with the nodes in the list based on the obtained list of node groups, stores the persistent connections in the connection pool, and adds a mutex lock to the connection pool. Child thread: Set subscription service parameters, create a Nacos listener to continuously monitor Nacos, and when a node update is detected, release the original connection pool resources, rebuild the P2P network connection, and update the connection pool.

[0009] The client build and configuration process includes the following steps: When the blockchain client starts, it reads the local configuration to create a Nacos instance, provides the RPC port, and creates a group instance list; providing the RPC port and creating a group instance list includes the main thread and child threads: Multiple child threads: used to monitor the Nacos service registration center, respectively obtain the latest list of each group instance, set the subscription tag parameter in the Nacos subscription parameter to the application node tag, and update the group instance list of the main thread if the monitored service instance list changes, and continue to monitor; Main thread: Read different service instance lists according to the interface type, select an instance from the service instance list through the load balancing algorithm, call the corresponding method of the instance, initiate a request to the blockchain service, and obtain blockchain data.

[0010] Preferably, the blockchain server loads the local configuration and creates a Nacos instance at startup, starts the RPC and P2P ports, and registers with Nacos with a label. Building a P2P network includes: A1: Load the local configuration file, obtain the local IP address, and create a server-side Nacos instance; A2: Start the RPC port and P2P network port of the blockchain network; A3: Register the RPC port and P2P port to Nacos based on the label, and obtain multiple port groups with labels, including consensus node labels and application node labels; A4: Build a P2P network.

[0011] Preferably, when the blockchain client starts, it reads the local configuration to create a Nacos instance, provides the RPC port, and creates a group instance list including: B1: Read the local configuration file, obtain the Nacos address, and create a client Nacos instance; B2: Provide external access to the RPC port of the RPC service, create a group instance list corresponding to the RPC port, and store the instance information of the corresponding group obtained from Nacos.

[0012] Preferably, the Nacos-based blockchain network service management method further includes a service instance liveness detection and health management strategy, including: C1: Nacos regularly performs liveness detection on registered service instances, sending detection requests to service instances to check whether the instances can respond normally. C2: If the service instance does not respond to the detection request normally within the preset time, Nacos will mark the service instance as unhealthy; C2: Remove the service instances marked as unhealthy from the service instance list through Nacos, and send an alarm message to notify the operation and maintenance personnel through Nacos.

[0013] Preferably, the Nacos-based blockchain network service management method further includes consensus node health monitoring and remediation strategies, including: D1: Monitor the number of consensus nodes marked as healthy through Nacos. D2: If the actual number of healthy consensus nodes is detected to be 0, restart the consensus node; D3: If the original consensus node fails to restart, another node is selected as the consensus node through Nacos.

[0014] In a second aspect, the present application provides a Nacos-based blockchain network service management system according to any one of the aforementioned first aspects, wherein the Nacos-based blockchain network service management system includes: At least one consensus node, used to obtain a list of P2P service instances and interact with Nacos; At least one application node, used to provide and consume RPC services; Nacos instance cluster and client.

[0015] In summary, the service management method of the blockchain network based on Nacos in this application can dynamically manage blockchain network nodes and ports, support new nodes to join the network in real time, and realize automatic expansion; it can also update the blockchain network node list in real time through the health check function to ensure the high availability of the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A schematic block diagram of a related technology blockchain network; Figure 2This is a schematic block diagram of an embodiment of a Nacos-based blockchain network service management system of the present application; Figure 3 A flowchart of an embodiment of the server-side construction and configuration process of the present application; Figure 4 The following is a flowchart of an embodiment of the client construction and configuration process of the present application. DETAILED DESCRIPTION

[0017] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention will be very clear to those skilled in the art. It should be understood that the specific embodiments described herein are only intended to explain the present invention and are not intended to limit the present invention.

[0018] Figure 1 The figure is a schematic block diagram of a related technology blockchain network.

[0019] A blockchain network is a distributed, decentralized network infrastructure used to record and verify a series of transactions or data ledgers. It is a peer-to-peer communication network (P2P) formed by connecting nodes via a point-to-point protocol. Nodes are divided into application nodes and consensus nodes. Consensus nodes participate in consensus voting on transaction data within the P2P network, ensuring the authenticity and validity of ledger data across all nodes in the network. Beyond the P2P network, blockchains also offer RPC (Remote Procedure Call) services to clients, allowing them to access blockchain nodes and obtain ledger transaction data. Figure 1 This is a categorization of RPC permissions provided by the blockchain. There are three main types: admin, user, and monitor, with permissions decreasing in order. Accessing the RPC interface through different ports grants corresponding permissions, which are configured in the local configuration file. The admin role is generally accessible only to the local machine and can perform almost all operations. The user role requires token authentication when sending RPC requests. The monitor role has the least permissions and can only retrieve some monitoring information.

[0020] The blockchain network is dynamic. During system operation, new nodes may join and old nodes may exit. To ensure high network availability, we need to dynamically manage the nodes in the blockchain network. For example, to cope with high-traffic scenarios, new nodes need to be added to relieve the pressure on single nodes. If there are abnormal access nodes, they also need to be removed in time to ensure that the client can correctly access the ledger data. Traditional blockchain network service management uses manual maintenance. When the program on a node starts, it reads the local configuration, starts the listening port, and builds a P2P network. When the client requests ledger transaction data, it reads the local configuration, obtains and initializes the list of blockchain service instances. This node management model has the following obvious disadvantages: 1. Blockchain P2P network construction relies on local configuration. Adding or removing nodes requires manual updating of local configuration. As the network scales, configuration maintenance costs will increase significantly.

[0021] 2. The blockchain network does not have a real-time node health check function. The client cannot update the node list in a timely manner and may send requests to unhealthy service instances. It may not request correct data and the consistency of the ledger cannot be guaranteed.

[0022] 3. Consensus nodes may present a single point of failure. Without consensus nodes, ledger consistency cannot be maintained. Relying on manual maintenance of consensus nodes will significantly reduce the availability of the blockchain network.

[0023] 4. Blockchain network node resource management relies on local configuration, and it is impossible to monitor the entire network from a global perspective. Clients or other nodes cannot know all network port numbers.

[0024] Figure 2 This is a schematic block diagram of an embodiment of a blockchain network service management system based on Nacos in this application. Figure 3 This is a flow chart of an embodiment of the server-side construction and configuration process of this application. Figure 4 The following is a flowchart of an embodiment of the client construction and configuration process of the present application.

[0025] Combine Figure 2 、 Figure 3 and Figure 4As you can understand, blockchain network nodes are divided into consensus nodes and application nodes, and their interfaces are divided into external RPC services and P2P network services. External RPC services provide two external ports: user and monitor. P2P networks communicate with other nodes through peer ports (peer nodes). As shown in the figure below, assume a blockchain network has four nodes: one consensus node and three application nodes. To ensure high availability of Nacos, we deploy a Nacos instance cluster to manage the nodes in the blockchain network. Upon startup, the node program registers the corresponding node service group with Nacos and identifies the consensus node and application node with different labels. Clients request the Nacos service to obtain the latest grouped node list in real time and select a node to retrieve ledger data. When building a P2P network, they request and listen to the Nacos service to obtain the latest instance list, establish persistent connections with other nodes, and store them in the connection pool to complete the initial construction or reconstruction of the P2P network.

[0026] This application also proposes a blockchain network service management system based on Nacos, which includes: At least one consensus node, used to obtain a list of P2P service instances and interact with Nacos; At least one application node, used to provide and consume RPC services; Nacos instance cluster and client.

[0027] Services are registered with Nacos in three groups: rpc-user, rpc-monitor, and peer. These groups correspond to the user and monitor ports of RPC services, and the peer port of P2P services, respectively. Consensus nodes and application nodes are distinguished by the labels consensus and app. The following table illustrates a blockchain network service resource list, using groups and labels to distinguish services. See Table 1 for details.

[0028] From a call-based perspective, a blockchain network is divided into a server and a client. The nodes on the server constitute the blockchain network, representing the list of node services that Nacos manages. The client, the business side, initiates network requests and retrieves server-side ledger data through RPC calls. Typically, an SDK is packaged to access the blockchain RPC service. The following describes the operational flow of the design approach from the perspectives of the server, client, and dynamic management.

[0029] The Nacos-based blockchain network service management method of this application includes a server-side construction and configuration process and a client-side construction and configuration process. The server-side construction and configuration process includes the following steps: A1: Load the local configuration file, obtain the local IP address, and create a server-side Nacos instance. In step A1, the blockchain server first loads the local configuration file during startup. This configuration file contains key information, such as the Nacos service address, which is used for subsequent interaction with the Nacos service; the port number to listen on, which corresponds to different service functions; and a consensus node flag, which distinguishes a node's role in the blockchain network. The server obtains the local IP address because, in network communication, IP addresses are the basis for node identification and communication. Based on the loaded configuration information and the obtained local IP address, the server creates a Nacos instance, enabling subsequent use of the service registration and discovery features provided by Nacos.

[0030] A2: Start the blockchain network's RPC and P2P network ports. In step A2, the server starts multiple listening ports in a specific order. The admin port provides external management functions within the RPC (Remote Procedure Call) service. Typically, this port is used for local management operations and is not open to the public to ensure security. The user port is also an external RPC service port, specifically used to handle user-related requests, such as user-initiated transactions and queries. The monitor port is used for monitoring services. Through this port, information such as the server's operating status and performance metrics can be obtained, facilitating system monitoring and management by operations and maintenance personnel. The peer network port is a P2P network listening port used for direct communication between blockchain nodes, enabling functions such as ledger synchronization and consensus algorithm execution.

[0031] A3: Register the RPC and P2P ports with Nacos based on the tags, resulting in multiple labeled port groups. These tags include consensus node tags and application node tags. In step A3, the admin port does not need to be registered with Nacos because it is only used for local management and not publicly accessible. However, the user port, monitor port, and peer network port must be registered with Nacos so that other services or nodes can discover and access them. In Nacos, different service port instances are grouped and named. User port instances are grouped as rpc-user, monitor port instances are grouped as rpc-monitor, and peer network port instances are grouped as peer. Each instance registered with Nacos is assigned a tag to distinguish the node type. Tags are divided into consensus node tags and app node tags. Tags clarify the role and responsibilities of a node in the blockchain network. The English words here are simply names and have no actual meaning.

[0032] A4: Build a P2P network, including the main thread and sub-threads: Main thread: Sets Nacos request parameters and retrieves a list of node groups from Nacos. Based on this list, the main thread creates persistent connections with the nodes in the list and stores them in the connection pool, securing access to the connection pool with a mutex lock. In the main thread, obtains the peer group list: After service registration is complete, the main thread sets Nacos request parameters and retrieves a list of peer groups from Nacos. This list contains information about all connectable nodes in the current blockchain network. Based on the obtained peer group list, the main thread establishes persistent connections with other nodes in the list. These persistent connections are used for real-time communication between nodes, ensuring smooth operations such as ledger synchronization and consensus algorithm execution. The created persistent connections are stored in the connection pool for easy subsequent management and use. Because the connection pool may be accessed simultaneously by multiple threads, such as the Nacos monitoring subprocess, a mutex lock is required to ensure data consistency and thread safety.

[0033] Child thread: Set subscription service parameters, create a Nacos listener to continuously monitor Nacos, and upon detecting a node update, release existing connection pool resources, rebuild the P2P network connection, and update the connection pool. Within the child thread, the server creates a child thread that monitors the Nacos service. The child thread sets subscription service parameters and creates a Nacos listener to obtain the latest peer group node list in real time. The child thread continuously monitors Nacos. Upon detecting a service node update (e.g., a new node joining or an existing node leaving), the child thread releases existing connection pool resources, rebuilds the P2P network connection, and updates the connection pool. This ensures that the blockchain network's P2P connections are always up to date, guaranteeing the reliability and effectiveness of network communications.

[0034] The C++ pseudo code for building a P2P network is as follows: / / Create a NacosService instance NacosService* nacosService = NacosServiceFactory::CreateNacosService(param); / / Define parameters for getting instance list GetAllInstancesParam getAllInstancesParam; getAllInstancesParam.serviceName = "Blockchain"; / / Get the service name of the instance getAllInstancesParam.clusterName = ""; getAllInstancesParam.groupName = "peer"; getAllInstancesParam.healthyOnly = true; / / Get a list of service instances std::list <instance>instances = nacosService->getAllInstances(getAllInstancesParam); std::list <connection>pool; / / mutex lock std::mutex mtx; { std::lock_guard <std::mutex>lock(mtx); createConnectionPool(instances, pool); } / / Custom service information listener class MyServiceInfoListener : public ServiceInfoListener { public: std::mutex _mtx; void receiveNamingInfo(const ServiceInfo&serviceInfo) override { { std::lock_guard <std::mutex>lock(_mtx); for (const auto&instance : serviceInfo.hosts) { reBuildConnectionPool(instance); / / Reconstruct network } } } }; / / Child thread function, used to monitor changes in Nacos service instances void listenToNacos(NacosService* nacosService, MyServiceInfoListener&listener, std::atomic <bool>&running) { / / Define the parameters of the subscription service SubscribeServiceParam subscribeParam; subscribeParam.serviceName = "Blockchain"; subscribeParam.clusterName = ""; subscribeParam.groupName = "peer"; / / Subscription service NacosError error = nacosService->subscribeService(subscribeParam,&listener); / / Continue listening until the main thread notifies you to stop while (running) { std::this_thread::sleep_for(std::chrono::seconds(1)); } / / Unsubscribe nacosService->unsubscribeService(subscribeParam,&listener); } / / Used to control the running status of the child thread std::atomic <bool>running(true); / / Create a listener instance MyServiceInfoListener* listener = new MyServiceInfoListener(mtx); / / Create a child thread to monitor and reconstruct the P2P network std::thread listenerThread(listenToNacos, nacosService, std::ref(listener),std::ref(running)); ... / / P2P network construction is complete, the main thread continues to execute / / Wait for the monitoring child thread to end listenerThread.join(); Next, we will introduce the client construction and configuration process, which includes the following steps: B1: Read the local configuration file, obtain the Nacos address, and create a client-side Nacos instance. In step B1, when the blockchain client SDK starts, it first reads relevant information from the local configuration file. The local configuration file typically contains various parameters required for operation, such as the Nacos address. The address of the Nacos service registry is parsed from the local configuration file. Nacos is a dynamic service discovery, configuration management, and service management platform that the SDK uses to interact with blockchain service instances. Based on the obtained Nacos address, the SDK creates an instance that interacts with the Nacos service registry. This instance will be used for subsequent service discovery, subscription, and other operations.

[0035] B2: Provides external access to the RPC port of the RPC service, creates a group instance list corresponding to the RPC port, and stores the instance information of the corresponding group obtained from Nacos, including: Multiple child threads: used to monitor the Nacos service registration center, used to obtain the latest list of each group instance, set the subscription tag parameter in the Nacos subscription parameter to the application node tag, and update the group instance list of the main thread if the service instance list is monitored to change, and continue monitoring.

[0036] Main thread: Read different service instance lists according to the interface type, select an instance from the service instance list through the load balancing algorithm, call the corresponding method of the instance, initiate a request to the blockchain service, and obtain blockchain data.

[0037] Specifically, the SDK provides two ports for external access: the user port and the monitor port. RPC (remote procedure call) allows external applications to communicate with the SDK and invoke various SDK functions through these two ports. Two group instance lists are created: the rpc-user group list and the rpc-monitor group list. These lists store instance information for corresponding service groups obtained from Nacos. To ensure secure access to these lists in a multi-threaded environment, thread-safe containers are used to create these lists. In Java, the Vector type is a thread-safe dynamic array implementation, so the Vector type is chosen here to create the lists.

[0038] Create child threads: Create two child threads, each responsible for monitoring the Nacos service registry. Get the latest service instance list: Each child thread is responsible for obtaining two latest service instance lists, namely the instance lists of the rpc-user service group and the rpc-monitor service group. Set subscription parameters: Since the SDK only provides access to application nodes, set tag = app in the Nacos subscription parameters. This means that the child threads will only monitor service instances tagged with app, filtering out other irrelevant instance information.

[0039] The child thread continuously monitors the Nacos service registry. When the service instance list changes (for example, a new instance goes online, an existing instance goes offline, or instance information is updated), the child thread is able to promptly perceive these changes. Once the child thread monitors the service instance list for changes, it updates the two group instance lists in the main thread (the rpc-user group list and the rpc-monitor group list) to ensure that the instance information obtained by the main thread is the latest. After completing an update, the child thread does not stop, but continues to monitor the Nacos service registry to respond promptly to subsequent service instance changes.

[0040] Based on the interface type (user or monitor), the main thread reads service instance information from the corresponding grouped instance list. The main thread then selects an instance using an appropriate load balancing algorithm. Common load balancing algorithms include RR (Random Round Robin) and WRR (Weighted Random Round Robin). The RR algorithm selects each instance in turn, ensuring that each instance has a chance to be selected. The WRR algorithm distributes requests based on instance weight, with instances with higher weights having a higher probability of being selected. After selecting an instance, the main thread calls the corresponding method on that instance to initiate a request to the blockchain service to obtain the required blockchain data.

[0041] In addition, the Nacos-based blockchain network service management method also includes service instance liveness detection and health management strategies, including: C1: Nacos regularly performs liveness detection on registered service instances, and sends detection requests to service instances to check whether the instances can respond normally.

[0042] C2: If the service instance does not respond to the detection request normally within the preset time, Nacos will mark the service instance as unhealthy.

[0043] C2: Remove the service instances marked as unhealthy from the service instance list through Nacos, and send an alarm message to notify the operation and maintenance personnel through Nacos.

[0044] Specifically, Nacos regularly performs liveness checks on registered service instances. It does this by sending specific probe requests (such as heartbeats) to service instances to check whether they are responding normally. For example, for a blockchain server registered with Nacos, Nacos will send probe requests to the instance's user port at a set interval. If a service instance fails to respond to the probe request within the specified time, Nacos marks it as unhealthy. Once a service instance is marked unhealthy, Nacos promptly removes it from the service instance list. This prevents other services or nodes from calling the unavailable service instance. Nacos also issues an alert to notify operations and maintenance personnel or related systems of the service instance anomaly. Alerts can be sent via email, SMS, or system logs.

[0045] When a new node joins the blockchain network, the new service instance is automatically registered with Nacos after the program on the new node is started. For example, the newly joined blockchain server will register its service instance information, such as its user port, monitor port, and peer network port, with Nacos according to the local configuration loaded at startup. After receiving the new service instance registration request, Nacos will update the corresponding service instance list. This allows other services or nodes to obtain the latest instance list when querying service instance information, enabling real-time dynamic management of services.

[0046] The Nacos-based blockchain network service management method also includes consensus node health monitoring and remediation strategies, including: D1: The number of consensus node instances marked as healthy by Nacos monitoring.

[0047] D2: If the actual number of healthy consensus nodes is detected to be 0, restart the consensus node. In this embodiment, the restart can be performed manually by operation and maintenance personnel or by a program script.

[0048] D3: If the original consensus node fails to restart, another node is selected as the consensus node through Nacos.

[0049] Nacos focuses on monitoring the number of healthy consensus node instances, specifically the size of the instance list with group = peer and tag = consensus. Consensus nodes play a key role in the blockchain network, responsible for maintaining the consistency and security of the blockchain. Nacos continuously checks the health of consensus node instances and ensures their normal operation through methods such as liveness detection.

[0050] The remedies are as follows: Measure 1: Restart the consensus node If the actual number of healthy consensus nodes is detected to be 0, first try restarting the consensus node. For example, use an automated operation and maintenance script to send a restart command to the server where the consensus node is located. Restarting the consensus node can resolve some issues caused by temporary failures, such as memory leaks and process anomalies.

[0051] Measure 2: Select a new consensus node If the original consensus node fails to restart, Nacos will select another node as the consensus node. Generally, a suitable node will be selected from the application nodes (tag = app).

[0052] When selecting a new consensus node, factors such as node performance and stability will be considered. After the selection is completed, the node's configuration will be modified to enable it to start serving as a consensus node.

[0053] In addition, to automatically start and stop services, you can use automated operation and maintenance tools such as Ansible and Puppet. These tools can implement remote operations on servers by writing scripts, such as starting and stopping service processes and modifying configuration files. When Nacos detects that a consensus node needs to be restarted, the automated operation and maintenance tool can automatically connect to the server where the consensus node is located according to the preset script and perform the restart operation.< / bool> < / bool> < / std::mutex> < / std::mutex> < / connection> < / instance>

Claims

1. A blockchain network service management method based on Nacos, characterized in that: The Nacos-based blockchain network service management method includes a server-side construction and configuration process and a client-side construction and configuration process. The server-side construction and configuration process includes the following steps: When the blockchain server starts, it loads the local configuration and creates a Nacos instance, starts the RPC and P2P ports, registers with Nacos with tags, and builds a P2P network. Building a P2P network includes a main thread and child threads: Main thread: Sets Nacos request parameters and obtains a list of node groups from Nacos. The main thread creates persistent connections with the nodes in the list based on the obtained list of node groups, stores the persistent connections in the connection pool, and adds a mutex lock to the connection pool. Child thread: Set subscription service parameters, create a Nacos listener to continuously monitor Nacos, and when a node update is detected, release the original connection pool resources, rebuild the P2P network connection, and update the connection pool; The client build and configuration process includes the following steps: When the blockchain client starts, it reads the local configuration to create a Nacos instance, provides the RPC port, and creates a group instance list; providing the RPC port and creating a group instance list includes the main thread and child threads: Multiple child threads: used to monitor the Nacos service registration center, respectively obtain the latest list of each group instance, set the subscription tag parameter in the Nacos subscription parameter to the application node tag, and update the group instance list of the main thread if the monitored service instance list changes, and continue to monitor; Main thread: Read different service instance lists according to the interface type, select an instance from the service instance list through the load balancing algorithm, call the corresponding method of the instance, initiate a request to the blockchain service, and obtain blockchain data.

2. The Nacos-based blockchain network service management method according to claim 1, characterized in that: The blockchain server loads the local configuration and creates a Nacos instance at startup, starts the RPC and P2P ports, and registers with Nacos with tags. Building a P2P network includes: A1: Load the local configuration file, obtain the local IP address, and create a server-side Nacos instance; A2: Start the RPC port and P2P network port of the blockchain network; A3: Register the RPC port and P2P port to Nacos based on the label, and obtain multiple port groups with labels, including consensus node labels and application node labels; A4: Build a P2P network.

3. The Nacos-based blockchain network service management method according to claim 1, characterized in that: When the blockchain client starts, it reads the local configuration to create a Nacos instance, provides the RPC port, and creates a group instance list including: B1: Read the local configuration file, obtain the Nacos address, and create a client Nacos instance; B2: Provide external access to the RPC port of the RPC service, create a group instance list corresponding to the RPC port, and store the instance information of the corresponding group obtained from Nacos.

4. The Nacos-based blockchain network service management method according to claim 2 or 3, characterized in that: The Nacos-based blockchain network service management method also includes service instance liveness detection and health management strategies, including: C1: Nacos regularly performs liveness detection on registered service instances, sending detection requests to service instances to check whether the instances can respond normally. C2: If the service instance does not respond to the detection request normally within the preset time, Nacos will mark the service instance as unhealthy; C2: Remove the service instances marked as unhealthy from the service instance list through Nacos, and send an alarm message to notify the operation and maintenance personnel through Nacos.

5. The Nacos-based blockchain network service management method according to claim 2 or 3, characterized in that: The Nacos-based blockchain network service management method also includes consensus node health monitoring and remediation strategies, including: D1: The number of consensus node instances marked as healthy monitored by Nacos; D2: If the actual number of healthy consensus nodes is detected to be 0, restart the consensus node; D3: If the original consensus node fails to restart, another node is selected as the consensus node through Nacos.

6. A Nacos-based blockchain network service management system according to any one of claims 1 to 5, characterized in that: The Nacos-based blockchain network service management system includes: At least one consensus node, used to obtain a list of P2P service instances and interact with Nacos; At least one application node, used to provide and consume RPC services; Nacos instance cluster and client.

Images