Concurrent scene-oriented extensible block chain client optimization method

Abstract

The invention discloses a concurrent scene-oriented extensible block chain client optimization method, which comprises the following steps of: decoupling a client into an interface service layer, a message service layer and a data service layer based on an asynchronous message bus, and realizing node dynamic registration and routing table maintenance through a heartbeat protocol; the interface service layer calculates a dynamic weight according to the state information of the data service nodes to construct a dynamic weight table so as to distribute an external request to the surviving data service nodes; a distributed cache layer is introduced, a cache layer cluster is preferentially queried in a read operation path, chain code query is triggered when the cache layer is not hit, and a result is written into a cache; and a write operation path adopts two-stage cache failure guarantee to eliminate dirty reading. Industrial environment parameters of all the data service nodes are collected in real time and scored, and part or all of the flow is intelligently migrated according to the score. According to the method, the client throughput, the response efficiency and the industrial environment adaptability are remarkably improved, and large-scale deployment of intelligent manufacturing high-concurrency scenes is supported.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of blockchains, and particularly relates to a scalable blockchain client optimization method for concurrent scenarios. BACKGROUND

[0002] The rapid development of the industrial internet promotes the intelligent transformation of manufacturing, and cross-enterprise collaboration, massive device access and real-time data sharing become core requirements. Traditional centralized systems have significant defects in data credibility, privacy protection and multi-party collaboration, and are difficult to meet the concurrent and low-latency requirements of intelligent factory, supply chain finance and other scenarios. The blockchain technology provides a new paradigm for building a trusted industrial collaboration network with its distributed ledger and smart contract features, but the existing architecture has serious performance bottlenecks in client design, which restricts its large-scale application.

[0003] Although the current mainstream blockchain framework such as Hyperledger Fabric adapts to industrial scenarios through multi-channel isolation and modular design, its client architecture still has the following problems: first, the static binding mechanism based on SDK leads to strong coupling between the application program and the blockchain network, resulting in single-point dependency and poor scalability; second, the service discovery mechanism lacks dynamic sensing capability, and in the production line environment where devices are frequently connected / disconnected, the node load imbalance degree causes coexistence of resource idling and overload; third, the design of non-separated read-write path leads to resource contention between high-frequency queries and transaction processing, resulting in poor read-write performance of the system.

[0004] Existing optimization solutions focus on consensus algorithm improvement, and still have significant limitations in dealing with the complexity of industrial scenarios. Although some dynamic evaluation mechanisms can improve node reliability, they lack deep integration with load balancing strategies, resulting in additional consumption of computing resources in the presence of thousands of nodes, leading to low overall system efficiency.

[0005] In summary, the existing technology cannot balance the concurrent processing, dynamic expansion and data consistency requirements in the industrial internet scenario. It is urgent to build a new type of client architecture to realize efficient response and high availability in concurrent scenarios through service decoupling, environment-aware load balancing and industrial protocol adaptive mechanism. SUMMARY

[0006] The purpose of the present application is to provide a scalable blockchain client optimization method for concurrent scenarios, which improves the throughput and response efficiency of the blockchain system in the intelligent manufacturing scenario through service decoupling, dynamic load balancing and read-write separation mechanism.

[0007] The technical solution adopted by the present application is:

[0008] A scalable blockchain client optimization method for concurrent scenarios, comprising the following steps:

[0009] S1, client asynchronous decomposition: a three-layer service decoupling architecture based on an asynchronous message bus decouples the interaction of the client with the blockchain network into an interface service layer, a message service layer, and a data service layer; the interface service layer includes at least one service interface, and the service interface is used to receive an external request of an object to be stored; the message service layer is configured with an interface server exchange center and a data server exchange center; the data service layer includes at least one data service node, and the data service node interacts with the interface server exchange center and the data server exchange center respectively to register information and state information through a heartbeat packet; the interface service layer listens to and acquires the registration information and state information of the data service node through the message service layer, constructs and maintains a routing table of the live data service node, and realizes the matching of the external request and the corresponding Fabric channel by using the routing table;

[0010] S2, dynamic load balancing strategy: the interface service layer calculates the dynamic weight of each data service node according to the real-time collected state information of the data service node to construct a dynamic weight table, and distributes the external request to the live data service node according to the dynamic weight table;

[0011] S3, read-write path separation mechanism: a distributed cache layer is introduced between the interface service layer and the zone as the blockchain network; in the read operation path, the cache layer cluster is preferentially queried, and when the cache layer is not hit, the chain code is triggered to query and the result is written into the cache layer; the write operation path adopts a two-stage cache invalidation guarantee, and when the state update request is processed, the cache record corresponding to the request is first cleared, and after the transaction is successfully written into the blockchain account book, the cache cleaning operation is executed again through the background asynchronous task after a fixed time delay; (eliminate the dirty read problem caused by industrial multi-node concurrent writing.)

[0012] S4, environment-aware traffic migration mechanism: real-time collection of industrial environment parameters of each data service node and evaluation of the comprehensive availability score of each data service node based on the industrial environment parameters through a sliding window algorithm, and intelligent migration of part or all traffic to other data service nodes with better industrial environment parameters according to the score.

[0013] Further, in S1, the data service node sends a heartbeat packet of Fabric channel binding information to the interface server exchange center, and simultaneously publishes association information of the service address and the Fabric channel to the data server exchange center; the interface service layer listens to and acquires the registration information and state information of each data service node in the data service layer, constructs and maintains a routing table of the live data service node, and realizes the matching of the external request and the corresponding Fabric channel by using the routing table.

[0014] Further, the data service node in S1 periodically sends heartbeat information to the interface service layer in a UDP broadcast manner; the heartbeat message sent by the data service node is encapsulated by using a Protocol Buffers protocol, the heartbeat message includes a node IP address, a port number, a current CPU utilization rate, and a bound Fabric channel hash value, a heartbeat interval t is set to 5 seconds, and a message validity period is updated synchronously with a sliding window maintenance period.

[0015] Further, the routing table in S1 includes routing addresses and channel association information of each data service node; the interface service layer uses a hash mapping algorithm to realize matching of an external request and a corresponding Fabric channel by using the routing table, and a calculation formula is as follows:

[0016] H(channelID)=CRC32(channelID)mod N;

[0017] wherein channelID represents a unique identifier of a blockchain channel, and N represents a total number of live data service layer nodes in the current network.

[0018] Further, in S2, a distributed service discovery module is deployed in the interface service layer to collect state information of the data service node in real time, and the state information of the data service node includes a CPU utilization rate C i , a memory occupancy rate M i , and a network delay L i .

[0019] Further, a dynamic weight calculation expression is as follows:

[0020]

[0021] wherein 0.4, 0.3, and 0.3 are preset weight adjustment coefficients, W i is a dynamic weight corresponding to the data service node i, L max is a preset maximum acceptable network delay reference value, and the value is 150 milliseconds; L i is a network delay of the data service node i.

[0022] Further, in S2, when the dynamic weight of the data service node is lower than a safety threshold value (for example, 0.30), the data service node is automatically marked as an unusable state; and when a new node is accessed, a routing table of the interface service layer is triggered to be dynamically updated.

[0023] Further, in the read operation path of S3, differentiated cache expiration policies are used for different types of data in the cache layer cluster; for device configuration information, a predetermined time of 15 minutes is used as an expiration policy, and the device configuration information includes a firmware version, a software version, and a function list; and for real-time production data, a data LRU algorithm is used, and a corresponding elimination priority Pi The calculation formula is:

[0024]

[0025] Among them, t current t represents the current system time. lastaccess,i This indicates the time when data item i was last accessed.

[0026] Furthermore, the industrial environmental parameters in S4 include real-time ambient temperature fluctuations, power supply stability indicators, equipment physical vibration frequencies, and network communication protocol parsing success rates.

[0027] Furthermore, the scoring in S4 uses a comprehensive weighted function:

[0028]

[0029] Where w i The weights for each environmental factor are floating-point numbers, f. i (x i ) is the normalization function for each parameter;

[0030] Furthermore, f i (x i The resource utilization rate normalization function is adopted, and its specific expression is as follows:

[0031] f r (r)=1-r / r wax

[0032] Where r is the current resource utilization rate, r wax The maximum threshold is 1.

[0033] This invention adopts the above technical solution and has the following technical advantages compared with the prior art: 1) Improved high concurrency throughput: The three-layer asynchronous decoupled architecture (interface layer / message layer / data layer) breaks the strong coupling of the traditional SDK, improves horizontal scalability, and supports dynamic node access. 2) Optimized read and write performance: The combination of read and write path separation and distributed caching layer (Redis cluster) reduces query response latency; moreover, the two-stage cache invalidation mechanism for write operations (instant clearing + asynchronous secondary cleanup) completely eliminates the dirty read problem of concurrent writes by multiple nodes in industrial applications. 3) Enhanced adaptability to industrial environments: The environment-aware traffic migration mechanism (temperature / power / vibration / network protocol parsing success rate monitoring) improves the reliability of the system in harsh industrial scenarios and shortens the automatic switching time for node failures. Sliding window heartbeat detection (5-second cycle + 10-second window) achieves second-level node status awareness, and the accuracy of removing failed nodes is high. 4) Source efficiency and scalability: The dynamic routing table (CRC32 (channelID) mod N algorithm) supports seamless access of new nodes, and business is uninterrupted when expanding services.

[0034] The application significantly improves the throughput, response efficiency and overall system stability of the blockchain client in the industrial internet high concurrency, dynamic change complex scene, and provides a safe, efficient and scalable client optimization solution for the deep application and large-scale deployment of blockchain technology in the field of intelligent manufacturing and other industries. BRIEF DESCRIPTION OF DRAWINGS

[0035] The application will be further described in detail below in combination with the drawings and specific embodiments;

[0036] Fig. 1 It is a schematic diagram of a client architecture based on asynchronous messages;

[0037] Fig. 2 It is a schematic diagram of the read path flow of the application;

[0038] Fig. 3 It is a schematic diagram of the write path flow of the application;

[0039] Fig. 4 It is a schematic diagram of the traditional client architecture;

[0040] Fig. 5 It is a schematic diagram of the client architecture of the application. DETAILED DESCRIPTION

[0041] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application.

[0042] As shown in one of the drawings, Figs. 1 to 5 The application discloses an extensible blockchain client optimization method for concurrent scenarios, specifically:

[0043] Client asynchronous decomposition: a three-layer service decoupling architecture based on an asynchronous message bus decouples the interaction of the client and the blockchain network into an interface service layer, a message service layer and a data service layer; the interface service layer includes at least one service interface, and the service interface is used to receive an external request of an object to be stored; the message service layer is configured with an interface server exchange center and a data server exchange center; the data service layer includes at least one data service node, and the data service node interacts with the interface server exchange center and the data server exchange center respectively through a heartbeat packet to register information and state information; the interface service layer listens to and acquires the registration information and state information of the data service node through the message service layer, constructs and maintains a routing table of the live data service node, and realizes the matching of the external request and the corresponding Fabric channel by using the routing table;

[0044] The interface server exchange center configured in the message service layer is a logical component and an information exchange node in the message service layer. It can be understood as a switch in the message queue. The main function of the interface server exchange center is to receive and process information related to node status and routing. Specifically, the nodes in the data service layer send heartbeat packets containing Fabric channel binding information to the exchange center. The interface service layer can dynamically obtain the survival status and registration information of the data service nodes by listening to the exchange center, thereby constructing and maintaining a real-time routing table for correctly distributing external requests to the corresponding data service nodes.

[0045] Similarly, the data server exchange center configured in the message service layer is another logical information exchange node in the message service layer, similar to the interface server exchange center. The main function of the data server exchange center is to receive and publish the association information between service addresses and Fabric channels. When starting, the data service nodes publish their service addresses (such as IP and port) and the Fabric channel information they can handle to the exchange center. This forms a "double-channel registration mechanism" with the heartbeat packets sent to the interface server exchange center, providing the interface service layer with the data needed to build a complete and accurate routing table. This allows the interface service layer to not only know which nodes are alive, but also know which Fabric channel each node can serve.

[0046] Specifically, the data service layer nodes encapsulate the blockchain SDK and establish a dynamic service discovery mechanism. Each node sends a heartbeat message to the interface server exchange center of the message queue when starting, carrying its routing address and bound blockchain channel information. The data service nodes send heartbeat packets containing Fabric channel binding information to the interface server exchange center and publish the association information between service addresses and Fabric channels to the data server exchange center. The interface service layer listens to and obtains the registration information and status information of each data service node in the data service layer, constructs and maintains a routing table of the surviving data service nodes, and uses the routing table to realize the matching of external requests and corresponding Fabric channels.

[0047] The interface layer node dynamically maintains a routing mapping table of live data service nodes by listening to the interface server exchange center. When forwarding a client request, the interface layer node randomly selects a live data service node from the currently maintained routing mapping table, distributes the request to the node, and eliminates the single-point dependency of the traditional client architecture in which the SDK is statically bound with the application program. The architecture realizes non-blocking interaction between service layers through the asynchronous communication characteristics of the message queue. When starting, the data service layer node sends a heartbeat to the interface server exchange center with a period of t, and the heartbeat period of the data service node is set to 5 seconds. The heartbeat message is encapsulated using the Protocol Buffers protocol and includes the node IP address, port number, current CPU utilization, and bound Fabric channel hash value. The interface layer node maintains a list of live nodes using a sliding window mechanism and automatically removes invalid nodes that have not sent a heartbeat for more than 2t, ensuring that the scale of industrial equipment access can be horizontally expanded. At the same time, the data service node publishes service address and channel association information to the data server exchange center, forming a dual-channel registration mechanism.

[0048] In the deployment of the data service layer node, the dynamic service discovery mechanism realizes node state synchronization through dual-channel registration: each data service node sends a heartbeat packet containing Fabric channel binding information to the interface server exchange center when starting, and publishes service address and channel association information to the data server exchange center. The interface layer node constructs a three-dimensional routing table containing node routing address, load state, and channel affiliation by parallelly listening to the two exchange centers, and realizes fast matching of requests and channels using a hash mapping algorithm. The calculation formula is:

[0049] H(channelID) = CRC32(channelID) mod N

[0050] where channelID represents the unique identifier of the blockchain channel, and N represents the total number of live data service layer nodes in the current network. When a new data service node is added, its heartbeat message triggers dynamic updating of the routing table of the interface layer, realizing elastic expansion of the service node pool. Specifically, the service discovery module maintains node activity state using a sliding window mechanism, and the window time span is 2t. When a data service node does not send a heartbeat message for two consecutive heartbeat periods, the system automatically removes the node information from the routing table. When a new node is added, it triggers incremental updating of the routing table, and the updating process does not affect the transaction requests being processed.

[0051] The dynamic load balancing strategy deploys a distributed service discovery module in the interface layer, monitors the CPU utilization, memory occupancy, and network delay indicators of the data service nodes in real time, constructs a dynamic weight table, and realizes request distribution using an improved weighted random algorithm. The weight calculation model is:

[0052]

[0053] wherein 0.4, 0.3, 0.3 are preset weight adjustment coefficients, W i is the dynamic weight corresponding to the node, L max is a preset maximum acceptable network delay reference value, the value of which is 150 milliseconds; when the node weight is lower than the safety threshold 0.30, it is automatically marked as an unusable state; when a new node is accessed, the routing table of the interface layer is triggered to update dynamically.

[0054] Specifically, when the node weight is continuously detected to be lower than the threshold value for 3 times, it is automatically marked as an unusable state.

[0055] The industrial internet data chaining service module adopts an intelligent load balancing algorithm, and collects industrial environment data in real time, including but not limited to environmental temperature fluctuation, power stability index, equipment vibration frequency, gas concentration parameter, and communication protocol (such as Modbus, OPC UA, MQTT, etc.) message parsing success rate. The interface service layer continuously evaluates the comprehensive availability score of each data service node in the module through a sliding window algorithm, dynamically identifies the best node. When any environmental parameter is detected to exceed the safety threshold (for example, the temperature is too high, the power fluctuation is abnormal, or the communication error rate rises), the system automatically adjusts the node weight distribution, triggers the intelligent traffic migration mechanism, and ensures that the industrial data is routed to the most stable service node in the current environment for processing. The node scoring model adopts a comprehensive weighted function:

[0056]

[0057] wherein w i is the weight of each environmental factor, f i (x i ) is the normalization function of each parameter. Taking resource utilization as an example:

[0058] f r (r) = 1 - r / r max

[0059] wherein r is the current resource occupancy rate, r max is the maximum threshold value. Improve the flexibility and reliability of the overall system in the complex and changeable industrial environment.

[0060] The read-write path separation mechanism introduces a distributed cache layer between the interface layer and the blockchain network, and designs a cache hit optimization strategy for high-frequency query requests of industrial equipment. In the read operation path, the interface layer queries the cache cluster first, triggers chain code query when the cache is not hit, and writes the result into the cache. The cache expiration time is dynamically set according to the data type: the device configuration information data adopts a timing expiration strategy, and the real-time production data adopts a mechanism based on the latest access time to dynamically maintain the cache space. The cache cleaning priority is inversely proportional to the last access time of the data. When the cache capacity reaches the threshold, the longest unused data entry is removed according to the LRU algorithm, and the priority calculation formula is:

[0061]

[0062] where t current represents the current system time, t lastaccess,i represents the last time the data item i was accessed; a short-term cache strategy is also implemented.

[0063] The write operation path adopts a two-stage cache invalidation guarantee mechanism: the first stage immediately clears the related cache records when the state update request is processed; the second stage starts an asynchronous cleaning task after the transaction is written into the blockchain ledger. The asynchronous task delays a fixed time to perform a second cleaning operation, eliminating the dirty read problem caused by industrial multi-node concurrent writing.

[0064] It should be noted that the blockchain network is the underlying, distributed ledger system (such as Hyperledger Fabric in this paper), which is the final storage and consensus place for all data. The data service layer is a logical layer designed to optimize interaction with the blockchain network. It is not part of the blockchain network itself, but exists as part of the client architecture. The data service node is the actual running work unit or process in the data service layer. A data service layer consists of one or more data service nodes. In summary, the blockchain network is the provider of the service (like a database system), while the data service layer / node is an optimized, scalable, and specialized "client cluster" that represents the application to access the blockchain network, acting as a proxy, load balancing, and improving the overall performance of the system.

[0065] Compared with the prior art, the application has the following technical advantages: 1) high concurrent throughput is improved: the three-layer asynchronous decoupling architecture (interface layer / message layer / data layer) breaks the traditional SDK strong coupling, improves the horizontal expansion capability, and supports dynamic node access. 2) read-write performance optimization: the read-write path separation and distributed cache layer (Redis cluster) combination technology is adopted to reduce the query response delay; moreover, the two-stage cache invalidation mechanism (instantaneous clearing + asynchronous secondary cleaning) of the write operation completely eliminates the dirty read problem of industrial multi-node concurrent writing. 3) industrial environment adaptability is enhanced: the environment-aware traffic migration mechanism (temperature / power / vibration / network protocol parsing success rate monitoring) improves the reliability of the system in harsh industrial scenarios and shortens the automatic switching time of node failure. The sliding window heartbeat detection (5-second period + 10-second window) realizes the second-level node state awareness, and the invalid node elimination accuracy is high. 4) source efficiency and expansibility: the dynamic routing table (CRC32 (channelID) mod N algorithm) supports seamless access of new nodes, and the service expansion has zero business interruption.

[0066] In the complex scene of industrial internet high concurrency and dynamic change, the application significantly improves the throughput, response efficiency and overall system stability of the blockchain client, and provides a safe, efficient and scalable client optimization solution for the deep application and large-scale deployment of blockchain technology in the field of intelligent manufacturing and other industries.

[0067] Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. The embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The components of the embodiments of the present application described and shown in the drawings can be arranged and designed in various different configurations. Therefore, the detailed description of the embodiments of the present application is not intended to limit the scope of the claimed application, but only represents selected embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

Claims

1. A method for scalable blockchain client optimization for concurrent scenarios, the method comprising: It comprises the following steps: S1, client asynchronous decomposition: based on the three-layer service decoupling architecture of the asynchronous message bus, the interaction between the client and the blockchain network is decoupled into an interface service layer, a message service layer and a data service layer; the interface service layer includes at least one service interface, and the service interface is used to receive an external request of an object to be stored; the message service layer is configured with an interface server exchange center and a data server exchange center; the data service layer includes at least one data service node, and the data service node interacts with the interface server exchange center and the data server exchange center respectively to register information and state information through a heartbeat packet; the interface service layer listens to and obtains the registration information and state information of the data service node through the message service layer, constructs and maintains a routing table of the live data service node, and realizes the matching of the external request and the corresponding Fabric channel by using the routing table; S2, dynamic load balancing strategy: the interface service layer calculates the dynamic weight of each data service node according to the real-time collected state information of the data service node to construct a dynamic weight table, and distributes the external request to the live data service node according to the dynamic weight table; S3, read-write path separation mechanism: a distributed cache layer is introduced between the interface service layer and the blockchain network; in the read operation path, the cache layer cluster is preferentially queried, and when the cache layer is not hit, the chain code is triggered to query and the result is written into the cache layer; the write operation path adopts a two-stage cache invalidation guarantee, and when a state update request is processed, the cache record corresponding to the request is first cleared, and after the transaction is successfully written into the blockchain account book, the cache cleaning operation is executed again through a background asynchronous task after a fixed time delay; S4, environment-aware traffic migration mechanism: real-time collection of industrial environment parameters of each data service node and evaluation of the comprehensive availability score of each data service node based on the industrial environment parameters through a sliding window algorithm, and intelligent migration of part or all traffic to other data service nodes with better industrial environment parameters according to the score. 2.The method for optimizing a blockchain client for concurrent scenarios according to claim 1, characterized in that: In S1, the data service node sends a Fabric channel binding information heartbeat packet to the interface server exchange center, and publishes the association information of the service address and the Fabric channel to the data server exchange center; the interface service layer listens to and obtains the registration information and state information of each data service node in the data service layer, constructs and maintains a routing table of the live data service node, and realizes the matching of the external request and the corresponding Fabric channel by using the routing table. 3.The method for optimizing a blockchain client for concurrent scenarios according to claim 1, characterized in that: In S1, the data service node periodically sends heartbeat information to the interface service layer in UDP broadcast mode; The heartbeat message sent by the data service node is encapsulated by the Protocol Buffers protocol, and the heartbeat message includes the node IP address, the port number, the current CPU utilization and the bound Fabric channel hash value, the heartbeat interval t is set to 5 seconds, and the message validity period and the sliding window maintenance period are updated synchronously. 4.The method for optimizing a blockchain client for concurrent scenarios according to claim 1, characterized in that: In S1, the routing table includes the routing address and channel association information of each data service node; the interface service layer uses a hash mapping algorithm to realize the matching of the external request and the corresponding Fabric channel by using the routing table, and the calculation formula is: H(channelID) = CRC32(channelID) mod N; Wherein, channelID represents the unique identification of the blockchain channel, N represents the total number of data service layer nodes alive in the current network.

5. The method of claim 1, wherein: In S2, a distributed service discovery module is deployed at the interface service layer to collect real-time status information of data service nodes. This status information includes CPU utilization (C). i Memory usage M i and network latency L i The dynamic weight calculation expression is: Wherein, 0.4, 0.3, 0.3 are preset weight adjustment coefficients, W i is a dynamic weight corresponding to the data service node i, L max is a preset maximum acceptable network delay reference value; L i is a network delay of the data service node i.

6. The method of claim 1 or 5, wherein: S2 in the data service layer is automatically marked as unavailable when the dynamic weight is lower than the security threshold; when the new node is accessed, the routing table of the interface service layer is dynamically updated.

7. The method of claim 1, wherein: In the read operation path of S3, differentiated cache expiration policies are adopted for different types of data in the cache layer cluster; for device configuration information, a predetermined expiration policy of 15 minutes is adopted, and the device configuration information includes firmware version, software version, and function list; for real-time production data, a data LRU algorithm is adopted, and the corresponding eviction priority P i The calculation formula is: where t current represents the current system time, t lastaccess,i represents the time when the data item i was last accessed. 8.The method for optimizing a blockchain client for concurrent scenarios according to claim 1, characterized in that: S4 in the industrial environment parameters includes real-time environmental temperature fluctuation, power supply stability index, equipment physical vibration frequency and network communication protocol parsing success rate. 9.The method for optimizing a blockchain client for concurrent scenarios according to claim 1, characterized in that: S4 in the score adopts a comprehensive weighted function: where w i is the weight of each environmental factor, which is a floating point number, f i (x i ) is the normalization function of each parameter.

10. The method of claim 9, wherein: f i (x i ) is the resource utilization normalization function, and the specific expression is: f r (r)＝1-r / r max wherein r is the current resource occupancy, r max is a maximum threshold value 1.

Images