Adaptive scaling method for containerized blockchain systems

Abstract

This invention discloses an adaptive scaling method for a containerized blockchain system, relating to the field of blockchain technology. It proposes a consensus node scaling method based on cybernetics, a step-by-step communication node scaling method, and a scaling method based on hot and cold data separation storage. The consensus node scaling method based on cybernetics ensures that the response time of the blockchain system does not exceed a set threshold while effectively allocating resources. The communication node scaling method based on step-by-step communication node effectively allocates server resources, preventing a single service from consuming excessive network bandwidth and flexibly addressing demand fluctuations. The scaling method based on hot and cold data separation storage enables storage expansion, reduces storage costs, and improves the system's service quality.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to an adaptive scaling method for blockchain systems based on containerized deployment. Background Technology

[0002] To address the performance demands of blockchain systems in high-concurrency, complex transaction scenarios, blockchain platforms often employ containerized deployment to enhance system flexibility and scalability. However, in actual operation, blockchain systems exhibit highly dynamic resource requests and loads, with resource requirements constantly changing based on factors such as transaction volume, node participation, and network status. This highly dynamic load variation places higher demands on container resource scheduling. How to intelligently and dynamically allocate container resources according to changes in system load has become a key issue in improving blockchain system performance.

[0003] Existing research on container resource management mainly includes Kubernetes default scheduling strategies, threshold-based scheduling strategies, and multi-objective optimization scheduling strategies based on metaheuristic algorithms. The Kubernetes default scheduling strategy is one of the most commonly used container orchestration and scheduling methods. The Kubernetes scheduler listens for newly created Pods in the cluster that have not yet been assigned nodes and schedules them to the most suitable nodes based on preset filtering and scoring mechanisms. This strategy prioritizes factors such as node resource utilization, affinity, and taint tolerance to achieve basic resource balance and high availability. However, in scenarios with multiple services coexisting and frequent fluctuations in business load, this strategy fails to effectively perceive the resource sensitivity and real-time requirements of the blockchain system, making it difficult to dynamically adapt to the current business state, resulting in a disconnect between scheduling decisions and the actual system load.

[0004] Threshold-based scheduling strategies primarily trigger resource scaling operations by manually setting upper and lower limits for resources such as CPU and memory. This strategy is simple to implement and easy to deploy, and has some practicality in environments with relatively stable resource utilization. However, this method relies too heavily on static parameter settings and lacks adaptability to load fluctuations, especially when dealing with sudden surges in blockchain transactions, which can lead to increased system latency or uneven resource allocation. Furthermore, as the cluster size increases and the number of service types grows, the complexity of threshold settings and maintenance costs also increase accordingly.

[0005] Multi-objective optimization scheduling strategies based on metaheuristic algorithms introduce intelligent optimization algorithms (such as genetic algorithms, particle swarm optimization, and ant colony optimization) to consider multiple optimization objectives simultaneously during the scheduling process, including resource utilization, task response time, and system energy consumption. This type of strategy can more comprehensively balance resource allocation and performance requirements, and is suitable for environments with heterogeneous node resources and high task complexity. However, because metaheuristic algorithms often employ iterative optimization methods, they suffer from high computational overhead, slow convergence speed, and a tendency to get trapped in local optima. This leads to scheduling instability and drastic load fluctuations in highly dynamic transaction scenarios, impacting overall system performance and user experience.

[0006] In summary, the existing technical solutions mainly have the following drawbacks:

[0007] (1) The load of blockchain systems fluctuates frequently and is unpredictable, while existing resource scheduling methods often rely on static rules or preset thresholds, which cannot respond to sudden load changes in a timely manner. This leads to resource allocation failing to match actual needs when the system faces rapid fluctuations or extreme loads, resulting in resource contention or resource shortages.

[0008] (2) Many existing scheduling methods, especially those based on optimization algorithms, typically require a significant amount of computation time for iterative solutions. While these methods have certain advantages in long-term optimization, their excessive computation time or slow convergence speed in scenarios with high dynamic loads fails to meet the real-time and low-latency requirements of blockchain systems, thus affecting the overall performance of the system.

[0009] (3) When scheduling resources, blockchain systems not only involve the allocation of computing resources, but also need to consider multiple dimensions such as network bandwidth, storage resources and service quality. Although existing methods can optimize a single objective to a certain extent, they lack sufficient flexibility and real-time performance in the trade-off between multiple objectives and resource scheduling decisions, making it difficult to adapt to high-concurrency and high-fluctuation actual workloads, and easily leading to uneven resource allocation or performance degradation. Summary of the Invention

[0010] To address the shortcomings of existing technologies, this invention provides an adaptive scaling method for blockchain systems based on containerized deployment to schedule resources. It proposes a consensus node scaling method based on cybernetics, a step-by-step communication node scaling method, and a scaling method based on hot and cold data separation storage. The consensus node scaling method based on cybernetics ensures that the response time of the blockchain system does not exceed a set threshold while effectively allocating resources. The step-by-step communication node scaling method effectively allocates server resources, preventing a single service from consuming excessive network bandwidth and flexibly addressing demand fluctuations. The scaling method based on hot and cold data separation storage enables storage expansion, reduces storage costs, and improves the system's service quality.

[0011] The technical solution of this invention is as follows:

[0012] The first aspect of this invention provides an adaptive scaling method for a containerized blockchain system, comprising the following steps:

[0013] The blockchain system is modularized into communication components, consensus components, and storage components; the storage components include on-chain storage components and off-chain Ceph storage components.

[0014] The modularized blockchain system is deployed in a distributed manner using containerization technology. Nodes are used as running instances of the blockchain system. Different types of nodes run different components of the blockchain system. The nodes include consensus nodes, communication nodes, and storage nodes, which correspond to the consensus component, communication component, and storage component of the blockchain system, respectively. Each node corresponds to a container.

[0015] The operation status of the blockchain system is monitored in real time, and the operation status of the blockchain system is represented by three monitoring indicators, including CPU utilization, storage capacity and network traffic.

[0016] Based on the monitoring indicators of the blockchain system, an autoscaling method is used to achieve elastic allocation of resources in the blockchain system; the autoscaling method includes a consensus node scaling method based on cybernetics, a communication node scaling method based on step-by-step scaling, and a scaling method for separating and storing hot and cold data.

[0017] Furthermore, for consensus nodes, a cybernetics-based consensus node scaling method is used for CPU resource allocation; for communication nodes, a step-based communication node scaling method is used for network resource allocation; and for storage nodes, a cold and hot data separation storage scaling method is used for storage resource allocation.

[0018] Furthermore, the consensus node scaling method based on cybernetics specifically involves: each consensus node's corresponding container being managed by an independent controller; each controller monitoring the response time of its corresponding container in real time; and calculating the difference ε between the current container's response time and the target response time at each control step; and calculating the CPU resource allocation μ for the current container based on the difference ε. c Then, a regulator is used to allocate the CPU resources obtained by all controllers to μ c Aggregate into a vector μ M If the total amount of CPU resources to be allocated exceeds the capacity of machine M used to run the blockchain system, then the CPU resource allocation for each container is scaled according to a set strategy to obtain an adjusted CPU resource allocation u. ' cIf the total amount of CPU resources to be allocated is less than the capacity of machine M used to run the blockchain system, then the CPU resource allocation μ will be increased. c The adjusted CPU resource allocation is obtained. ' c Finally, the adjusted CPU resource allocation is executed. ' c Or directly perform CPU resource allocation μ c .

[0019] Furthermore, the step-by-step communication node scaling method specifically involves: each communication node's corresponding container being managed by an independent controller, which obtains the container's network resource utilization rate UC. Each controller, based on the current container's network resource utilization rate UC, determines the network bandwidth allocation A according to a preset strategy table. c Each controller will allocate the calculated network bandwidth A c Submitted to the regulator, the regulator allocates all network bandwidth to A c If the total network bandwidth to be allocated exceeds the network bandwidth capacity of machine M running the blockchain system, then the network bandwidth allocation for each container is scaled according to a set strategy to obtain an adjusted network bandwidth allocation A'. c If the total network bandwidth to be allocated does not exceed the network bandwidth capacity of machine M used to run the blockchain system, no scaling will be performed; the regulator will allocate the adjusted network bandwidth to A'. c Or the network bandwidth allocation A calculated by the controller c The data is transmitted to the container network management tool, which allocates A' based on the adjusted network bandwidth. c Or the network bandwidth allocation A calculated by the controller c Adjust the network bandwidth limit for each container.

[0020] Furthermore, the strategy table uses different network resource utilization thresholds to divide network resource utilization into different intervals, and sets different network bandwidth adjustment values ​​for each interval. Based on the current network resource utilization of the container, the interval and the corresponding network bandwidth adjustment value are determined, thereby obtaining network bandwidth allocation A. c .

[0021] Furthermore, the scaling method for separating hot and cold data storage specifically involves: storing hot data in a high-performance cluster with performance exceeding a set threshold, copying cold data to another low-cost cluster with performance below a set threshold through a multi-source configuration, and then clearing the data in the original cluster.

[0022] A second aspect of the present invention provides an electronic device, comprising: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the adaptive scaling method for a containerized blockchain system are performed.

[0023] A third aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the adaptive scaling method for a containerized blockchain system as described above.

[0024] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0025] (1) The consensus node scaling and step-by-step communication node scaling method based on cybernetics of the present invention can respond to changes in resource demand in a timely manner, avoiding the problems of oversupply or insufficient resources. The real-time feedback of cybernetics and the step-by-step hierarchical adjustment together improve the dynamic adaptability of the system.

[0026] (2) This invention reduces the cost of storage expansion by separating hot and cold data storage for scalability, while improving the service quality of the system under large-scale deployment. The tiered storage strategy achieves a balance between performance and cost, enhancing the long-term operating capability of the system.

[0027] In summary, the adaptive scaling method for blockchain systems based on containerized deployment proposed in this invention can improve the overall performance of blockchain systems, effectively address performance challenges in high-concurrency scenarios, solve the resource management problem of blockchain systems under high dynamic loads, and provide a methodology and practical tool for performance breakthroughs in decentralized applications. Attached Figure Description

[0028] Figure 1 This is a diagram illustrating the overall architecture of the adaptive scaling method for a blockchain system based on containerized deployment, as described in this invention.

[0029] Figure 2 This is an example diagram of a consensus node scaling method based on cybernetics in an embodiment of the present invention;

[0030] Figure 3 This is an example diagram of a step-based communication node scaling method in an embodiment of the present invention;

[0031] Figure 4 This is an example diagram of a scaling method based on separate storage of hot and cold data in an embodiment of the present invention;

[0032] Figure 5This is a graph showing the CPU utilization of consensus nodes at different times in an embodiment of the present invention.

[0033] Figure 6 This is a diagram showing the response time of consensus nodes at different times in this embodiment of the invention;

[0034] Figure 7 This is a network utilization diagram of communication nodes under a fixed resource allocation strategy in an embodiment of the present invention.

[0035] Figure 8 This is a network utilization graph of communication nodes under a step-by-step strategy in an embodiment of the present invention.

[0036] Figure 9 This is a graph showing the throughput performance test results under different concurrent thread request volumes in an embodiment of the present invention;

[0037] Figure 10 The graph shows the response time performance test results under different concurrent thread request volumes in this embodiment of the invention. Detailed Implementation

[0038] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0039] Adaptive scaling methods for containerized blockchain systems, such as Figure 1 As shown, it includes the following steps:

[0040] Step 1: First, the blockchain system is modularized into communication components, consensus components, and storage components, thereby improving the modular management and scalability of the blockchain system; the storage components include on-chain storage components and off-chain Ceph storage components.

[0041] The storage component mainly implements multimodal data storage services, the consensus component mainly implements query and transaction processing services, and the communication component is responsible for information exchange and coordination between components to ensure the collaborative operation of each component.

[0042] Step 2: In order to fully utilize the flexibility and elasticity of the cloud environment, containerization technology is used to deploy the componentized blockchain system in a distributed manner to achieve efficient deployment and dynamic scheduling. Nodes are used as running instances of the blockchain system, with different types of nodes running different components of the blockchain system.

[0043] Specifically: Nodes include consensus nodes, communication nodes, and storage nodes, which correspond to the consensus component, communication component, and storage component in the blockchain system, respectively. Each node corresponds to a container.

[0044] Step 3: To ensure the stable operation of the containerized deployment system, a resource monitoring mechanism is further implemented. Resource monitoring tools are used to monitor the operating status of the blockchain system in real time. The operating status of the blockchain system is represented by three monitoring indicators, including CPU utilization, storage capacity and network traffic.

[0045] In this embodiment, these monitoring metrics are provided by the Prometheus Client Component and collected and aggregated through periodic pull operations initiated by the Prometheus Server, providing data support for subsequent blockchain system optimization. Container resource monitoring mainly relies on the native API interfaces provided by container engines (such as Docker) to collect resource usage at the container level in real time. Through the Docker Engine API, detailed resource usage data for each container can be obtained, including CPU usage time, storage capacity, and network traffic. This approach has the advantages of strong real-time performance and low system overhead, making it suitable for dynamically changing blockchain operating environments. To improve the modularity and maintainability of the blockchain system, resource monitoring is designed as an independent component, deployed and run separately. Various monitoring metrics are exposed through interfaces of the Prometheus Client Component, and collected and aggregated by periodic pull operations initiated by the Prometheus Server. This approach supports unified collection of multiple targets, facilitating subsequent expansion and centralized management.

[0046] Step 4: Based on the monitoring indicators of the blockchain system, use autoscaling methods to achieve elastic allocation of resources in the blockchain system; the autoscaling methods include consensus node scaling methods based on cybernetics, communication node scaling methods based on step-by-step scaling, and scaling methods for separating and storing hot and cold data.

[0047] To achieve elastic resource allocation, this invention employs an automatic scaling method and containerized deployment to schedule these resources. Specifically, for consensus nodes, a cybernetics-based consensus node scaling method is used for CPU resource allocation; for communication nodes, a step-based communication node scaling method is used for network resource allocation; and for storage nodes, a cold / hot data separation storage scaling method is used for storage resource allocation.

[0048] The consensus node scaling method based on cybernetics, such as Figure 2 As shown, specifically: each consensus node's corresponding container is managed by an independent controller. The controller's goal is to ensure that the consensus node's response time does not exceed a set threshold. Each controller monitors the response time of its corresponding container in real time and calculates the difference ε between the current container's response time and the target response time at each control step (1 second). Based on the difference ε, the CPU resource allocation μ of the current container is calculated.c Then, a regulator is used to allocate the CPU resources obtained by all controllers to μ c Aggregate into a vector μ M If the total amount of CPU resources to be allocated exceeds the capacity of machine M used to run the blockchain system, then the CPU resource allocation for each container is scaled according to a set strategy to obtain an adjusted CPU resource allocation u. ' c Optionally, if the total amount of CPU resources to be allocated is less than the capacity of machine M used to run the blockchain system, then the CPU resource allocation μ is increased. c To accelerate application performance, the trade-off is suboptimal allocation (over-provisioning), resulting in an adjusted CPU resource allocation. ' c Finally, the adjusted CPU resource allocation is executed. ' c ;

[0049] The difference ε between the current container's response time and the target response time is:

[0050]

[0051] Among them, T c For the container's response time, The target response time is set, and ε is the difference between the container's response time and the target response time.

[0052] The described step-based communication node scaling method flexibly addresses the problem of demand fluctuations. The step-based vertical scaling method is an evolution of rule-based methods, such as... Figure 3 As shown, specifically: each communication node's corresponding container is managed by an independent controller. This controller obtains the container's network resource utilization rate (UC). Each controller, based on the current container's network resource utilization rate (UC), determines the network bandwidth allocation (A) according to a preset strategy table. c Each controller will allocate the calculated network bandwidth A c Submitted to the regulator, the regulator allocates all network bandwidth to A c If the total network bandwidth to be allocated exceeds the network bandwidth capacity of machine M running the blockchain system, then the network bandwidth allocation for each container is scaled according to a set strategy to obtain an adjusted network bandwidth allocation A'. c If the total network bandwidth to be allocated does not exceed the network bandwidth capacity of machine M used to run the blockchain system, no scaling will be performed; the regulator will allocate the adjusted network bandwidth to A'. c Or the network bandwidth allocation A calculated by the controller cThe data is transmitted to the container network management tool via HTTP or API, and the container network management tool allocates A' based on the adjusted network bandwidth. c Or the network bandwidth allocation A calculated by the controller c Adjust the network bandwidth limit for each container;

[0053] The strategy table uses different network resource utilization thresholds to divide network resource utilization into different intervals, and sets different network bandwidth adjustment values ​​for each interval. Based on the current network resource utilization of the container, the interval and the corresponding network bandwidth adjustment value are determined, thereby obtaining network bandwidth allocation A. c ;

[0054] In this embodiment, the step-by-step communication node scaling method provides a strategy table to define the scaling operations to be performed when certain conditions are met. By limiting the bandwidth of the container, server resources can be allocated more effectively, preventing a single service from consuming too much network bandwidth.

[0055] In this embodiment, when formula (2) is satisfied, the bandwidth is increased by 20%; when formula (3) is satisfied, the bandwidth is increased by 15%; when formula (4) is satisfied, the bandwidth is increased by 10%; when formula (5) is satisfied, the bandwidth is decreased by 10%; when formula (6) is satisfied, the bandwidth is decreased by 15%; when formula (7) is satisfied, the bandwidth is decreased by 20%.

[0056] if(U c >90%) (2)

[0057] if (80%) c ≤90%) (3)

[0058] if (70%) c ≤80%) (4)

[0059] if (30%) c ≤70%) (5)

[0060] if (20%) c ≤30% (6)

[0061] if(U c ≤20% (7)

[0062] Among them, U c Real-time network resource utilization rate;

[0063] ​​​​In this embodiment, the container network management tool Docker Traffic Control automatically detects and processes containers with specific tags by listening to events from the Docker engine. When a container starts, if com.docker-tc.enabled=1 is set, this tool will set network rules based on other tags with the com.docker-tc prefix, such as bandwidth limits, delays, and packet loss. It utilizes the Linux tc command to control the network interface, achieving these functions without complex configuration or additional dependencies.

[0064] The hot and cold data separation storage scaling method utilizes Ceph multi-source configuration technology to retain frequently accessed data (hot data) in a high-performance cluster and migrate less frequently accessed data (cold data) to a low-performance cluster, achieving seamless horizontal scaling and thus optimizing the utilization efficiency of storage resources. The storage cluster is a unified storage resource pool composed of multiple storage nodes (servers, hard drives, etc.) collaboratively through distributed software, possessing characteristics such as high availability, elastic scaling, and data redundancy. Figure 4 As shown, specifically: hot data (within 30 days) is stored in a high-performance cluster, while cold data (before 30 days) is copied to another low-cost cluster through a multi-source configuration. Then, the data in the original cluster is cleared to achieve the storage and querying of hot and cold data. Through data replication and automatic cleanup mechanisms, the storage cluster can be seamlessly expanded, avoiding the service interruption problem in traditional expansion solutions.

[0065] These three methods coordinate with each other in resource scheduling based on their respective characteristics and load requirements. In specific applications, the blockchain system automatically selects the most suitable scheduling scheme according to different node load types. When the blockchain system faces computationally intensive tasks (such as transaction verification and consensus processes), it prioritizes the use of a consensus node scaling method based on cybernetics. An independent controller adjusts CPU resources in real time to ensure that the response time of consensus nodes does not exceed a set threshold, avoiding response delays due to insufficient computing resources. For network-intensive tasks (such as data transmission and inter-node communication), a step-by-step communication node scaling method is used to optimize bandwidth resources. Dynamic adjustments are made based on a network resource utilization threshold table to prevent a single service from consuming excessive bandwidth and ensure a balanced distribution of network resources across multiple services. When the blockchain system faces high storage resource demands, especially when the demand for accessing hot and cold data changes, it automatically activates a hot and cold data separation storage scaling method. Storage resources are adjusted according to the data access frequency, storing hot data in a high-performance cluster and migrating cold data to a low-cost cluster, ensuring that storage expansion is both efficient and cost-effective.

[0066] This embodiment takes prescription circulation in the medical field as an example. Traditional models suffer from problems such as poor data sharing, information silos, difficulty in ensuring data security and privacy, and susceptibility to data tampering. Using a blockchain system, for example, in the prescription review process, prescription information and review records are written to the blockchain, ensuring data immutability. Patients can check their prescription history at any time, and doctors can quickly obtain accurate patient prescription information. Medical insurance institutions can also accurately monitor prescription circulation, preventing fraud and abuse. Furthermore, with fluctuations in business volume, an adaptive scaling method is adopted to dynamically adjust the allocation of blockchain system resources based on data volume and access frequency. During peak periods, computing and storage resources are automatically increased to ensure smooth operation of the blockchain system, while idle resources are released during off-peak periods to reduce costs.

[0067] In this embodiment, the three proposed scaling methods were verified, and the verification results are as follows:

[0068] (1) A consensus node scaling method based on cybernetics

[0069] The performance testing tool Locust was used to test the transaction sending volume, which increased linearly from an initial 0 to 2000, then from 2000 to 4000, and finally the transaction sending rate stabilized at 4000.

[0070] Experimental results are as follows Figure 5 and Figure 6 As shown, Figure 5 The dashed lines represent the transaction volume, and the solid lines represent the CPU allocated at different times. Figure 6 The dashed line represents the target response time, and the solid line represents the response time of the consensus node at different times. Experimental results show that when the response time of the consensus node exceeds the target response time, the consensus node scheduling optimization algorithm based on cybernetics can respond quickly and ensure that the response time does not exceed the target response time.

[0071] (2) Communication node scaling method based on stepping

[0072] The load testing tool tm-load-test was used to send load continuously for 20 seconds at a rate of 10,000 transactions per second, with each transaction being 250 bytes in size. The number of transactions sent increased linearly from an initial 0 to 2,000, then to 6,000, then to 10,000, and finally the transaction sending rate stabilized at 10,000.

[0073] Experimental results are as follows Figure 7 and Figure 8As shown, the fixed resource allocation method resulted in network usage consistently below 1 Mbps, while the step-based strategy continuously adjusted bandwidth allocation according to changing demand, leading to bandwidth usage that could be higher or lower than 1 Mbps. Throughput increased from 4.326 kTPS to 5.937 kTPS, a 23.94% improvement. Experimental results demonstrate that the step-based communication node scheduling optimization scheme can effectively allocate network resources and improve the system's service quality.

[0074] (3) Scaling method based on cold and hot data separation storage

[0075] The performance of the Ceph cluster was tested using the performance testing tool cosbench. Each thread sent 30 read requests per second, and the query throughput and response time performance were tested for single-cluster and multi-cluster scenarios with 1, 2, 4, 8, and 12 threads. Single-cluster refers to queries being performed only on the storage cluster with poor disk performance, while multi-cluster refers to queries being performed on both storage clusters with good disk performance and storage clusters with poor disk performance.

[0076] Experimental results are as follows Figure 9 and Figure 10 As shown, the throughput of queries in a multi-cluster scenario is higher than that in a single-cluster scenario, while the response time is lower. Experimental results demonstrate that the storage scheduling optimization scheme based on hot and cold data separation can not only achieve storage expansion and reduce storage costs, but also improve the average query throughput, reduce the average query response time, and improve the system's service quality.

[0077] This embodiment also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the adaptive scaling method for a containerized blockchain system are performed.

[0078] This embodiment also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the adaptive scaling method for a containerized blockchain system as described above.

Claims

1. An adaptive scaling method for a blockchain system based on containerized deployment, characterized in that, Includes the following steps: The blockchain system is modularized into communication components, consensus components, and storage components; the storage components include on-chain storage components and off-chain Ceph storage components. The modularized blockchain system is deployed in a distributed manner using containerization technology. Nodes are used as running instances of the blockchain system. Different types of nodes run different components of the blockchain system. The nodes include consensus nodes, communication nodes, and storage nodes, which correspond to the consensus component, communication component, and storage component of the blockchain system, respectively. Each node corresponds to a container. The storage component is used to implement multimodal data storage services, the consensus component is used to implement query and transaction processing services, and the communication component is responsible for information exchange and coordination between components to ensure the collaborative operation of each component. The operation status of the blockchain system is monitored in real time, and the operation status of the blockchain system is represented by three monitoring indicators, including CPU utilization, storage capacity and network traffic. Based on the monitoring indicators of the blockchain system, an autoscaling method is used to achieve elastic allocation of resources in the blockchain system; the autoscaling method includes a consensus node scaling method based on cybernetics, a communication node scaling method based on step-by-step scaling, and a scaling method for separating and storing hot and cold data. The consensus node scaling method based on cybernetics specifically involves: each consensus node's corresponding container being managed by an independent controller; each controller monitoring the response time of its corresponding container in real time and calculating the difference between the current container's response time and the target response time at each control step. According to the difference The CPU resource allocation of the current container is calculated. Then, a regulator is used to allocate CPU resources to all controllers. aggregated into a vector If the total amount of CPU resources to be allocated exceeds the capacity of machine M used to run the blockchain system, then the CPU resource allocation for each container is scaled according to a set strategy to obtain an adjusted CPU resource allocation. If the total amount of CPU resources to be allocated is less than the capacity of machine M used to run the blockchain system, then the allocation of CPU resources will be increased. The adjusted CPU resource allocation was obtained. Finally, the adjusted CPU resource allocation is executed. Alternatively, CPU resource allocation can be performed directly. ; The step-by-step communication node scaling method specifically involves: each communication node's corresponding container being managed by an independent controller, which obtains the container's network resource utilization rate (UC). Each controller allocates network bandwidth according to a preset strategy table based on the current container's network resource utilization rate (UC). Each controller will calculate the network bandwidth allocation. Submitted to the regulator, which then allocates all network bandwidth. If the total network bandwidth to be allocated exceeds the network bandwidth capacity of machine M running the blockchain system, then the network bandwidth allocation for each container is scaled according to a set strategy to obtain an adjusted network bandwidth allocation. If the total network bandwidth to be allocated is not higher than the network bandwidth capacity of machine M used to run the blockchain system, then scaling will not be performed; The regulator will adjust the network bandwidth allocation. Or the network bandwidth allocation calculated by the controller The data is transmitted to the container network management tool, which then allocates bandwidth based on the adjusted network bandwidth. Or the network bandwidth allocation calculated by the controller Adjust the network bandwidth limit for each container; The scaling method for separating hot and cold data storage specifically involves storing hot data in a high-performance cluster with performance exceeding a set threshold, replicating cold data to a low-cost cluster with performance below the set threshold via a multi-source configuration, and then clearing the data from the original cluster.

2. The adaptive scaling method for a blockchain system based on containerized deployment according to claim 1, characterized in that, For consensus nodes, a cybernetics-based consensus node scaling method is used to allocate CPU resources; for communication nodes, a step-based communication node scaling method is used to allocate network resources; and for storage nodes, a cold and hot data separation storage scaling method is used to allocate storage resources.

3. The adaptive scaling method for a blockchain system based on containerized deployment according to claim 1, characterized in that, The strategy table uses different network resource utilization thresholds to divide network resource utilization into different intervals, and sets different network bandwidth adjustment values ​​for each interval. Based on the current network resource utilization of the container, the interval and the corresponding network bandwidth adjustment value are determined, thereby obtaining network bandwidth allocation. .

4. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the adaptive scaling method for a containerized blockchain system as described in any one of claims 1-3.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the adaptive scaling method for a containerized blockchain system as described in any one of claims 1-3.

Images