Unmanned aerial vehicle cluster cloud platform elastic scaling method based on decentralized authentication

Abstract

The invention discloses an unmanned aerial vehicle cluster cloud platform elastic scaling method based on decentralized authentication, and belongs to the technical field of unmanned aerial vehicle cluster management, and the method comprises the steps: constructing a global security state vector reflecting an authentication load and a resource state; utilizing a pre-trained elastic prediction model to analyze and output resource demand prediction and scaling quantity suggestions, and generating a scaling instruction set; the instruction is executed through the container arrangement component, the number of authentication micro-service instances is adjusted, and load balancing configuration is updated; and the authentication micro-service instance completes decentralized verification of an access authentication request of the unmanned aerial vehicle node, and feeds back an authentication result to the security state vector. According to the method, the problems of resource allocation rigidness and response lag when a cloud platform provides dynamic authentication service for a large-scale unmanned aerial vehicle cluster are solved, intelligent and forward-looking elastic expansion and contraction of authentication resources can be realized, and the security of decentralized authentication is ensured while the security of the decentralized authentication is ensured. And the response efficiency of the unmanned aerial vehicle cluster cloud platform to the dynamic load and the resource utilization rationality are improved.

Description

Technical Field

[0001] This invention relates to the field of drone swarm management technology, and in particular to a method for elastic scaling of a drone swarm cloud platform based on decentralized authentication. Background Technology

[0002] With the rapid development of drone technology, drone swarms are increasingly being used in logistics, agricultural plant protection, emergency rescue, and geographic surveying. To achieve centralized management, data aggregation, and task collaboration for large-scale drone swarms, a cloud platform is typically needed as the command and control hub. In this application scenario, drone nodes need to securely and reliably access the cloud platform and maintain continuous communication connections. This process relies primarily on a strict authentication mechanism. Given the large number and wide distribution of drone nodes, and their potential for dynamic joining or leaving the network, the cloud platform must possess efficient and elastic authentication service capabilities to handle sudden surges in authentication requests and dynamically changing concurrent connections.

[0003] Traditional cloud platform resource management methods have several limitations when facing such scenarios. On the one hand, most elastic scaling strategies are primarily geared towards general-purpose web services or compute-intensive applications, and their decisions are typically based on general metrics such as CPU utilization, memory usage, or network throughput. However, the access authentication load of drone swarms has its own unique characteristics. For example, the request rate may suddenly surge due to collective swarm action commands, and the number of active nodes directly determines the pressure on maintaining subsequent service sessions. Relying solely on general system metrics makes it difficult to accurately depict the true pressure state of the authentication service, which is a specific business, potentially leading to a disconnect between resource supply and actual demand, resulting in response delays or resource waste. On the other hand, existing scaling decision logic is often based on static thresholds or simple reactive rules. For example, scaling is triggered when the average CPU utilization exceeds 80%. This approach lacks foresight, always taking action only when the system load has already reached a high level or even shown signs of overload, causing service response performance degradation before the scaled-up instances are ready. Furthermore, static thresholds cannot adapt to long-term changes in load patterns. For example, as business grows, the system's baseline load will gradually increase, and the originally set thresholds may become inapplicable, requiring frequent manual adjustments, which are costly to maintain and prone to inaccuracy.

[0004] At the execution level of resource scaling, ensuring the smooth online and offline deployment of microservice instances to avoid service interruptions or request loss is also a challenge. Directly creating or destroying service instances without rigorous checks on instance health and synchronized, seamless updates to load balancing configurations may result in user requests being distributed to instances that are not yet ready or are about to terminate, impacting authentication success rates and user experience. Furthermore, traditional centralized certificate authentication methods suffer from single points of failure. If the authentication server fails, the entire cluster will be unable to connect. While decentralized authentication technology can improve system robustness and trustworthiness, designing a closed-loop system that allows the authentication service's resource scheduling to perceive and respond to the actual load and security status of the decentralized authentication process, rather than managing resources in isolation, remains a problem that current solutions have not fully addressed. Therefore, a resource elastic scaling method specifically designed for drone swarm cloud platform authentication scenarios is needed to achieve intelligent and forward-looking resource prediction and decision-making, support smooth and reliable service instance changes, and deeply collaborate with decentralized security authentication mechanisms, thereby ensuring high availability, high performance, and high security of authentication services in complex and dynamic environments. Summary of the Invention

[0005] This invention overcomes the problems of rigid resource allocation and delayed response when cloud platforms provide dynamic authentication services for large-scale drone swarms, and provides an elastic scaling method for drone swarm cloud platforms based on decentralized authentication. It enables intelligent and forward-looking elastic scaling of authentication resources, significantly improving the response efficiency and resource utilization rationality of drone swarm cloud platforms in the face of dynamic loads while ensuring the security of decentralized authentication.

[0006] To achieve the above objectives, the present invention adopts the following solution: The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication includes the following steps: S1: Construct a global security state vector and continuously collect data from the authentication service node to update the security state vector. The collected data sources include the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances processing authentication requests in the current cloud platform, and the CPU utilization of each microservice instance. S2: The authentication arbitration node receives the security state vector and inputs it into a pre-trained elastic prediction model. Based on the historical data sequence and current data in the security state vector, the elastic prediction model outputs an authentication resource demand prediction value and a suggested number of microservice instance scaling values. S3: Receive the predicted value of certified resource demand and the suggested number of microservice instances to scale up through the cloud platform resource scheduler, and make a decision based on the preset resource threshold policy. The resource threshold policy defines the logical conditions for triggering scaling operations based on the CPU utilization and the length of the certified request queue, and generates a scaling instruction set containing specific scaling instructions. S4: Receive and execute scaling instruction sets through container orchestration components, call the cloud platform's application programming interface to deploy or destroy certified microservice instances, update a load balancing configuration list, and include the newly deployed certified microservice instances in the authentication request allocation pool. S5: When any drone node in the drone cluster initiates an access authentication request, the access authentication request is distributed to an available authentication microservice instance in the load balancer according to the load balancing configuration list. The authentication microservice instance completes the decentralized verification of the drone node based on the distributed identity identifier stored on the blockchain, and synchronizes the state of the drone node after successful verification to the global security state vector.

[0007] Preferably, step S1, which involves constructing and maintaining the global security state vector, specifically includes: The authentication service node collects data at fixed time intervals from multiple data collection agents deployed at the edge of the cloud platform. This data includes the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances currently processing authentication requests in the cloud platform, and the CPU utilization of each microservice instance. The authentication service node applies a sliding window of length T to the collected network access request rate and CPU utilization, calculating the moving average of these values. These moving averages replace the original instantaneous values ​​and form part of the security state vector. The authentication service node periodically broadcasts heartbeat messages to the drone cluster and dynamically adjusts the number of active drone nodes based on the number of response messages and latency to eliminate drone nodes mistakenly identified as inactive due to temporary network failures. The data processed by the sliding window and heartbeat adjustment is integrated into a global security state vector, which is then published to a distributed message queue for the authentication arbitration node to subscribe to and retrieve.

[0008] Preferably, in step S2, the process by which the authentication arbitration node generates the predicted value and the number of recommendations based on the security state vector specifically includes: The authentication arbitration node continuously retrieves the global security state vector published by the authentication service node from the distributed message queue and maintains a historical security state vector sequence containing N consecutive time intervals. A resilient prediction model is constructed by cascading a time series prediction algorithm based on a long short-term memory network model and a rule-based analysis engine. The time series prediction algorithm takes the historical security state vector sequence as input and outputs predicted values ​​for the network access request rate and CPU utilization for a future time interval. The rule-based analysis engine receives the predicted values ​​and, combined with a preset baseline processing capacity of a single authentication microservice instance, calculates the ratio of the predicted network access request rate to the baseline processing capacity and rounds it up to obtain the predicted authentication resource demand value. Simultaneously, the analysis engine dynamically adjusts a security redundancy coefficient based on the comparison between the predicted CPU utilization and a utilization threshold, multiplying the predicted authentication resource demand value by the security redundancy coefficient to obtain the final recommended number of microservice instances to scale. After each generation of a recommended number, the authentication arbitration node uses the historical security state vector sequence used this time and the corresponding actual subsequent load data as new training samples to incrementally update the long short-term memory network model.

[0009] As a preferred approach, the process by which a rule-based analytics engine dynamically adjusts the safety redundancy coefficient specifically includes: The analytics engine presets a CPU utilization threshold and a basic safety redundancy coefficient. It compares the predicted CPU utilization output by the elastic prediction model with the CPU utilization threshold. When the predicted CPU utilization consistently exceeds the threshold, the analytics engine initiates overload protection logic. This logic linearly searches a predefined mapping table based on the percentage of CPU utilization exceeding the limit and selects an adjusted safety redundancy coefficient greater than the basic safety redundancy coefficient. This adjusted safety redundancy coefficient is applied to the calculation process, ensuring that the recommended number of microservice instances to scale includes preventative additional instances when computational resource constraints are predicted. The actual system load data is recorded each time a value greater than the basic safety redundancy coefficient is used. If the actual load consistently falls below the predicted load, a feedback loop lowers the coefficient value in the mapping table to gradually approximate the actual resource demand. Finally, the product of the certified resource demand prediction and the adjusted safety redundancy coefficient is calculated and rounded up to obtain the recommended number of microservice instances to scale for subsequent resource scheduling.

[0010] Preferably, step S3, in which the cloud platform resource scheduler generates the scaling instruction set, specifically includes: The cloud platform resource scheduler synchronously receives the predicted value of authentication resource demand and the suggested number of microservice instance scaling from the authentication arbitration node. Simultaneously, it obtains the aggregate CPU utilization and the real-time length of the authentication request queue for all currently running authentication microservice instances through the cloud platform monitoring system. It compares the real-time aggregate CPU utilization with a preset first utilization threshold and a preset second utilization threshold, and compares the real-time length of the authentication request queue with a preset queue length threshold. Based on the designed resource threshold strategy, it determines whether the aggregate CPU utilization exceeds the first utilization threshold or the authentication request queue length simultaneously exceeds the queue length threshold. When the first type of scaling instruction is generated, the number of instances required by the first type of scaling instruction is directly adopted from the suggested number of microservice instances to scale. When only the aggregate CPU utilization exceeds the second utilization threshold but the authentication request queue length does not exceed the limit, the second type of scaling instruction is generated. The number of instances required by the second type of scaling instruction is half of the suggested number of microservice instances to scale. Before generating the instruction, it is also verified whether the available computing resources in the current cloud platform resource pool meet the instance requirements corresponding to the instruction. If not, a limited scaling instruction set is generated based on the maximum allocable resources. The final generated scaling instruction set includes the instruction type, the target number of instances, and the specified cloud platform availability zone deployment information.

[0011] Preferably, in the resource threshold strategy, the preset first utilization threshold, second utilization threshold, and queue length threshold are dynamic values, which are dynamically adjusted by the cloud platform resource scheduler based on historical decision-making results; the dynamic adjustment process specifically includes: After each execution of a scaling instruction set, the maximum values ​​of the aggregated CPU utilization and authentication request queue length observed in the next monitoring cycle are recorded and compared with the threshold that triggered the last decision. A decision effect table is constructed to store the type of each scaling decision, the threshold used, and whether the system has recovered to the normal load zone after the decision. The decision effect table is analyzed periodically. If the statistics show that the system state has not improved effectively after consecutive scaling decisions triggered based on the current threshold, the threshold adjustment logic is initiated. The threshold adjustment logic increases or decreases the values ​​of the first utilization threshold, the second utilization threshold, and the queue length threshold by a predetermined adjustment step value according to the historical load pattern, and continues to monitor the decision effect after adjustment.

[0012] Preferably, step S4, the specific process of executing the scaling instruction set through the container orchestration component, includes: The container orchestration component receives scaling instruction sets from the cloud platform resource scheduler, parses the instruction type, target number of instances, and cloud platform availability zone deployment information. Depending on whether the instruction is a scaling-up or scaling-down instruction, the container orchestration component calls the container service application programming interface provided by the cloud platform to create or delete the corresponding number of certified microservice instance containers within the specified availability zone. During the creation of new certified microservice instance containers, the container orchestration component pulls the specified version of the certified microservice image from a pre-defined container image repository and allocates compute and storage resources to each new container according to a predefined resource configuration template. After each newly created certified microservice instance container starts, it executes its embedded health check script and registers its network endpoint information with the container orchestration component. The container orchestration component continuously monitors the running status of all certified microservice instance containers, adding their network endpoint information to the load balancing configuration list only after confirming that a new instance has passed the health check and reached a ready state. For scaling-down instructions, the container orchestration component selects instances to be deleted based on the least recently used principle, removes them from the load balancing configuration list, waits for them to finish processing existing requests, and then calls the application programming interface to terminate the corresponding container.

[0013] Preferably, the process by which the container orchestration component updates the load balancer configuration list specifically includes: The container orchestration component maintains a primary load balancer configuration list and a list of load balancer configurations to be updated. When new authentication microservice instance network endpoint information needs to be added or removed, the container orchestration component first performs the corresponding addition or removal operation in the list of load balancer configurations to be updated and generates a version identifier for the list. Subsequently, the container orchestration component sends a configuration update request to the load balancer, which includes the version identifier and the complete content of the list of load balancer configurations to be updated. After receiving the request, the load balancer atomically replaces the received list of load balancer configurations to be updated with the currently effective primary load balancer configuration list within a predetermined millisecond time window, and immediately routes subsequent access authentication requests based on the new list. After completing the switchover, the load balancer returns a confirmation response to the container orchestration component and discards the old configuration list. After receiving the confirmation response, the container orchestration component synchronizes the content of the list of load balancer configurations to be updated to the primary load balancer configuration list and clears the list of load balancer configurations to be updated to await the next modification.

[0014] Preferably, step S5, the process of drone node access authentication and status synchronization specifically includes: When any drone node in a drone swarm needs to access the network, its built-in communication module sends an access authentication request containing its unique hardware identifier to the load balancer. Upon receiving the access authentication request, the load balancer queries the currently active load balancing configuration list in real time and selects an available authentication microservice instance from the list using a weighted round-robin algorithm. The load balancer then forwards the access authentication request to the network endpoint of that authentication microservice instance. Upon receiving the forwarded request, the authentication microservice instance extracts the hardware identifier and constructs a query transaction based on it. It then initiates a query to a pre-configured permissioned blockchain network node to obtain the distributed identity identifier bound to the hardware identifier and the corresponding public key. Certificate; After receiving a response from the blockchain network, the authentication microservice instance uses a public key certificate to verify the digital signature of the access authentication request. If the verification is successful, a temporary session token is generated for the drone node and a secure connection is established. If the verification fails or no blockchain response is received within a preset timeout period, the authentication microservice instance marks the authentication as failed and allows the drone node to re-initiate the request after waiting for a random backoff time. Regardless of whether the authentication is successful or not, the authentication microservice instance generates a status record containing the drone node identifier, timestamp, and processing result after processing, and sends the status record back to the authentication service node to update the global security state vector with statistics on node activity and authentication load.

[0015] Preferably, the process of updating the security state vector in the event of authentication microservice instance failure or timeout includes: The authentication microservice instance maintains a local failure request counter and a corresponding list of hardware identifiers. When an access authentication request is marked as failed due to digital signature verification failure, the authentication microservice instance first checks if the hardware identifier already exists in the local list. If it exists, it increments the corresponding failure counter; otherwise, it adds the hardware identifier to the list and initializes the counter to 1. When the failure counter reaches a preset failure threshold within a continuous time window, the instance determines that the drone node has a potential security risk and generates a high-risk event alarm record including the hardware identifier, cumulative failure count, and time window information. The high-risk event alarm record, along with the regular status record, is sent to the authentication service node. Upon receiving the high-risk event alarm record, the authentication service node updates the load statistics in the global security state vector and adds the hardware identifier and its risk level to a dedicated risk identifier field in the global security state vector. When the authentication arbitration node subsequently performs predictions and decisions, it incorporates the risk identifier field in the security state vector as a negative weighting factor into the prediction and decision-making considerations.

[0016] The present invention has at least the following beneficial effects: (1) The present invention realizes intelligent elastic scaling of UAV cluster authentication resources by constructing a complete closed-loop control of state vector-prediction decision-scheduling execution-authentication feedback, deeply coupling the decentralized authentication business process with the cloud platform's resource management, so that resource adjustment not only responds to general system indicators, but also accurately matches the dynamic changes of authentication business load, thereby significantly improving the overall adaptability and service guarantee capability of cloud platform resource scheduling while ensuring authentication security; (2) By using sliding window smoothing and heartbeat dynamic correction to construct a high-quality security state vector, and combining it with a long short-term memory network model for time-series prediction, a more stable and accurate forward-looking load view is obtained, effectively overcoming the prediction distortion caused by data noise and node state misjudgment, and substantially enhancing the prediction accuracy and reliability of resource demand; (3) By introducing a dynamically adjusted security redundancy coefficient to deal with prediction risks, and combining it with dynamic optimization of decision thresholds based on historical effects, a set of self- My learning and adaptive decision-making mechanism enables the timing and intensity of resource scaling to dynamically approximate real business needs, achieving a better balance between effectively preventing overload risks and avoiding resource waste, and improving the refinement and intelligence of resource utilization; (4) Through the container orchestration component, the instance lifecycle is refined and managed, and the load balancing configuration is updated without interruption by combining dual lists and atomic switching, ensuring the smoothness and high reliability of the resource scaling operation execution process, reducing the impact of service instance changes on the authentication requests being processed, and ensuring the service continuity and stability perceived by the user side; (5) By combining the decentralized blockchain verification process with load balancing distribution, and accumulating local risks and reporting global risk information when authentication fails, not only is secure and scalable authentication achieved, but also micro-level business security events are elevated to factors affecting macro-level resource decisions, realizing the synergistic linkage between performance elastic scaling and security threat perception, and enhancing the system's comprehensive defense and elastic response capabilities when facing malicious attacks or abnormal traffic. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the principle of the method of the present invention. Detailed Implementation

[0018] The present invention will now be described in further detail with reference to the accompanying drawings, so that those skilled in the art can implement it based on the description.

[0019] like Figure 1 As shown, the present invention provides a method for elastic scaling of a drone swarm cloud platform based on decentralized authentication, which includes the following steps: S1: Construct a global security state vector and continuously collect data from the authentication service node to update the security state vector. The collected data sources include the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances processing authentication requests in the current cloud platform, and the CPU utilization of each microservice instance.

[0020] The security state vector is essentially a multidimensional dataset used to reflect the overall operational status and security condition of the drone swarm authentication service in real time. Its data is continuously collected by the authentication service nodes and mainly includes four key indicators: the drone node's network access request rate, i.e., the number of new authentication requests initiated per unit time; the number of active drone nodes, referring to the total number of nodes that have successfully authenticated and maintained a communication connection; the number of microservice instances currently running in the cloud platform processing authentication requests, reflecting the real-time supply capacity of service resources; and the CPU utilization of each microservice instance, used to measure the computing load level of each service instance. This data collection can be achieved through data collection agents deployed at the edge of the cloud platform or within the cluster. The agents collect information through periodic polling or event triggering. For example, the network access request rate can be obtained by statistically analyzing the logs of the authentication service access point or listening to data packets on specific network ports; the number of active nodes can be confirmed through periodic heartbeat checks or session persistence mechanisms; and the number of microservice instances and CPU utilization can be obtained directly through the monitoring interfaces provided by the cloud platform or the container runtime environment. By continuously updating this vector, the system can form a dynamic view that changes over time, reflecting the authentication load and resource usage, providing accurate and timely input for subsequent predictions and decisions.

[0021] S2: The authentication arbitration node receives the security state vector and inputs it into a pre-trained elastic prediction model. Based on the historical data sequence and current data in the security state vector, the elastic prediction model outputs an authentication resource demand prediction value and a suggested number of microservice instance scaling values.

[0022] The elastic prediction model is a hybrid model combining time series analysis and rule-based reasoning. It utilizes historical security state vector data sequences (e.g., data from the past few minutes or hours) and the latest vector data to identify patterns and trends in load changes. Internally, the model employs algorithms such as Long Short-Term Memory (LSTM) networks to capture temporal dependencies in the data, predicting authentication resource demands in the near future, such as the expected request rate and system load in the next time interval. Simultaneously, the model incorporates pre-defined business rules, such as the theoretical processing capacity of a single authentication microservice instance (e.g., the number of authentication requests per second), converting the predicted request rate into a predicted number of instances—the authentication resource demand forecast. Furthermore, the model comprehensively considers current and predicted CPU utilization and other health indicators to determine resource scarcity or sufficiency, thus outputting a suggested number of microservice instances to scale. This number typically includes buffers or redundancy to handle prediction errors or sudden traffic spikes.

[0023] S3: Receives the predicted value of certified resource demand and the suggested number of microservice instances to scale up or down through the cloud platform resource scheduler, and makes a decision based on the preset resource threshold policy. The resource threshold policy defines the logical conditions for triggering scaling operations based on the CPU utilization and the length of the certified request queue, and generates a scaling instruction set containing specific expansion or contraction instructions.

[0024] The cloud platform resource scheduler receives predicted authentication resource demand and suggested scaling quantities from the authentication arbitration node, but does not execute them directly. Instead, it comprehensively compares and makes policy judgments based on the real-time operating status of the cloud platform. The cloud platform resource scheduler also obtains more granular real-time information from the cloud platform monitoring system, primarily including the aggregate CPU utilization (i.e., overall average or weighted average utilization) of all running authentication microservice instances, and the current queue length of pending authentication requests. The resource scheduler has a pre-defined set of resource threshold policies that define the specific conditions under which scaling up or down should be triggered. For example, the policy might stipulate that when the aggregate CPU utilization exceeds a certain high threshold (e.g., a value between 70% and 85%) and the authentication request queue length also exceeds a certain threshold, the system is overloaded and needs immediate scaling up; or, when the CPU utilization is below a certain low threshold (e.g., a value between 20% and 35%) and the queue remains empty, scaling down can be triggered to save resources. The scheduler compares real-time data with these policy conditions and makes a final decision based on the predicted suggested quantities. The decision outcome is a specific set of scaling instructions, which specifies whether to perform a scaling-up or scaling-down operation, the target number of instances, and the possible deployment regions involved. This process ensures that resource adjustments are not only based on predictions but also respect the system's real-time load, avoiding erroneous operations caused by prediction biases.

[0025] S4: Receives and executes scaling instruction sets through container orchestration components, calls the cloud platform's application programming interface to deploy or destroy authentication microservice instances, updates a load balancing configuration list, and includes the newly deployed authentication microservice instances in the authentication request allocation pool.

[0026] After receiving a scaling instruction set from the cloud platform's resource scheduler, the container orchestration component (such as Kubernetes) parses the instructions and calls the application programming interfaces (APIs) provided by the cloud platform or container service to actually perform the creation or destruction of microservice instances. If it's a scaling instruction, the component starts new certified microservice instance containers in the corresponding availability zone of the cloud platform according to the specified number and resource configuration template. These new containers pull software images containing the certification service logic from a pre-defined image repository, complete initialization, and start the service process. After starting, the new instance performs a self-health check to confirm that it is ready and can handle requests. Subsequently, the container orchestration component updates a load balancing configuration list, adding the network address (endpoint) of the new instance to the list. If it's a scaling-down instruction, the component removes the endpoint of a specific instance from the list according to a certain strategy (such as selecting the instance with the lowest load or the longest inactive instance) and terminates its corresponding container, ensuring that currently processed requests are not affected.

[0027] S5: When any drone node in the drone cluster initiates an access authentication request, the access authentication request is distributed to an available authentication microservice instance in the load balancer according to the load balancing configuration list. The authentication microservice instance completes the decentralized verification of the drone node based on the distributed identity identifier stored on the blockchain, and synchronizes the state of the drone node after successful verification to the global security state vector.

[0028] When any drone node in a drone swarm needs to access the network, it initiates an access authentication request to the system. This request first reaches the load balancer. The load balancer, based on the latest load balancing configuration list, uses an allocation algorithm (such as round-robin, least connections, etc.) to distribute the request to a currently available authentication microservice instance. The selected authentication microservice instance handles the authentication request, based on a decentralized authentication mechanism: the instance extracts the drone node's unique identifier from the request and then queries a pre-deployed blockchain network. The blockchain stores the distributed identity identifiers (such as DIDs) and related public key certificates of all legitimate drone nodes. The authentication microservice instance verifies the drone node's identity by checking whether the digital signature in the request matches the public key stored on the blockchain, without relying on a traditional centralized certificate authority. Upon successful verification, the instance establishes a session for the node and updates its state. Simultaneously, regardless of whether authentication is successful or not, the processing result (such as successful authentication, failure, or timeout) is generated as a status record and sent back to the authentication service node. The authentication service node then uses this feedback information to update the global security state vector with statistics such as the number of active nodes and the authentication success / failure rate, thereby completing the closed loop of data collection, decision-making, execution, and feedback.

[0029] Compared to traditional cloud resource scaling methods based on static thresholds or simple rules, this method introduces a global security state vector and a pre-trained elastic prediction model to achieve more accurate and proactive prediction of drone authentication load. This allows for earlier and more proactive resource expansion, effectively reducing the risk of authentication delays or service rejections due to insufficient resources. Simultaneously, by combining a decentralized blockchain identity verification mechanism, the authentication process's security and resistance to single points of failure are enhanced, while the authentication load itself becomes an input to elastic scaling decisions, enabling resource scheduling to be closely linked to the actual pressure of security authentication. Compared to passive scaling solutions that rely solely on real-time monitoring metrics, this method significantly improves the intelligence and overall efficiency of resource utilization through a closed loop of prediction-decision-execution-feedback. It can more precisely control computing resource costs while ensuring service response speed, making it particularly suitable for complex scenarios with dynamically changing drone swarm sizes and sudden or periodic fluctuations in access requests, thus enhancing the overall elasticity, adaptability, and reliability of cloud platform authentication services.

[0030] In another technical solution, step S1, the process of constructing and maintaining the global security state vector, specifically includes: The authentication service node collects data at fixed time intervals from multiple data collection agents deployed at the edge of the cloud platform. This data includes the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances currently processing authentication requests in the cloud platform, and the CPU utilization of each microservice instance. The authentication service node applies a sliding window of length T to the collected network access request rate and CPU utilization, calculating the moving average of these values. These moving averages replace the original instantaneous values ​​and form part of the security state vector. The authentication service node periodically broadcasts heartbeat messages to the drone cluster and dynamically adjusts the number of active drone nodes based on the number of response messages and latency to eliminate drone nodes mistakenly identified as inactive due to temporary network failures. The data processed by the sliding window and heartbeat adjustment is integrated into a global security state vector, which is then published to a distributed message queue for the authentication arbitration node to subscribe to and retrieve.

[0031] The system collects basic data through multiple data acquisition agents deployed at the edge of the cloud platform or on the critical paths of the drone swarm network. These agents can be lightweight programs existing as software daemons, responsible for collecting four core metrics at fixed time intervals, such as every 10 seconds, 30 seconds, or 1 minute. The drone node's network inbound request rate is calculated by monitoring the access logs of the authentication service's inbound gateway or directly analyzing network traffic packets, determining the number of requests per unit time. The initial value for the number of active drone nodes can be derived from the list of successfully authenticated sessions, but requires subsequent correction. The number of running microservice instances handling authentication requests and the CPU utilization of each instance are obtained directly by calling the monitoring interfaces of the cloud platform (such as Kubernetes' Metrics Server) or container runtime (such as DockerStats). After collecting this raw data, the authentication service node does not directly use instantaneous values, as instantaneous values ​​can fluctuate drastically due to network jitter or instantaneous tasks, potentially misleading judgments. Therefore, the node applies a sliding window of length T to calculate both the network inbound request rate and CPU utilization, which vary over time. The sliding window duration T can be pre-calibrated experimentally based on the specific cloud platform's monitoring granularity, business load characteristics, and historical data. For example, T can be chosen as a duration of 5 minutes or 10 minutes to cover short-term fluctuation cycles. The sliding window continuously retains all sampled values ​​within the most recent period T and calculates the moving average of these values. Whenever a new sampled value arrives, the window slides forward, discarding the oldest value, incorporating the latest value, and recalculating the average. This process smooths out short-term spikes and troughs in the data, allowing the moving average of the network access request rate and the moving average of CPU utilization to more stably reflect the system's recent trend load, rather than instantaneous states. These smoothed moving averages will serve as an important component of the security state vector, replacing the original instantaneous sampled values ​​and providing the system with a denoised load view. However, smoothing alone is insufficient to accurately determine the true activity status of drones, as temporary network outages may cause healthy nodes to be mistakenly identified as offline. Therefore, a dynamic heartbeat correction mechanism is introduced to specifically verify and correct the number of active drone nodes. The authentication service node periodically broadcasts a lightweight heartbeat probe message to the entire drone swarm, for example, every 20 seconds or every minute. This message can be designed as a simple "Ping" command or a specific protocol data packet with a timestamp. Upon receiving this message, online, functional drone nodes in the cluster will immediately reply with a response message. The authentication service node then collects these responses within a pre-defined waiting time window (e.g., 3 to 5 seconds after the broadcast). The core of the correction logic lies in analyzing the number and latency of the response messages.If a previously marked active node fails to respond to heartbeats for several consecutive times (e.g., 2 to 3 times), but its neighboring nodes or gateway report transient network instability while other service data streams for that node still occasionally arrive, the system may determine that the node is out of contact due to a temporary network failure (such as brief wireless signal obstruction), rather than being truly offline or damaged. In this case, the system will not immediately remove it from the active count, but will instead place it in a "suspected inactive" observation state and continue sending heartbeats. Once the node resumes response in subsequent heartbeat cycles, its active status will be reconfirmed and added back to the total count. This process dynamically corrects the number of active nodes, effectively eliminating misjudgments caused by transient network problems, making the cluster size data in the security state vector more accurate and robust, and avoiding unnecessary resource scaling triggered by misjudgments.

[0032] After the aforementioned sliding window smoothing and heartbeat dynamic correction, the authentication service node integrates the processed data into a complete, global security state vector according to a predetermined format and data structure. This data includes the smoothed moving average of the inbound request rate, the corrected number of active drone nodes, the real-time number of microservice instances (this number is usually the latest value, as it represents a discrete management state), and the moving average of CPU utilization for each instance. This security state vector can be a JSON object, a Protobuf message, or a custom structured data body, containing timestamps, metric values, and metadata. Subsequently, the authentication service node publishes this vector to a distributed message queue, such as a specific topic in Apache Kafka or RabbitMQ. The advantage of asynchronous publishing using a message queue is that it decouples the data producer (authentication service node) and the consumer (authentication arbitrator node), improving the system's scalability and reliability. By subscribing to this topic, the authentication arbitrator node can obtain the latest version of the security state vector in near real-time without direct synchronous request-response communication with the authentication service node. The entire maintenance process runs continuously at fixed intervals (such as in sync with the data acquisition interval) to ensure that the safety state vector can serve as a fresh, accurate, and reliable data source, continuously supporting downstream prediction and decision-making modules.

[0033] Compared to directly using raw instantaneous sampled data to build a status monitoring system, this solution significantly smooths out short-term, drastic fluctuations in monitoring indicators through sliding window moving average processing. It effectively filters out random noise interference, making the state vector reflecting system load more stable and representative of trends, thus avoiding erroneous decisions based on instantaneous spikes. Simultaneously, through proactive heartbeat detection and a dynamic correction mechanism based on response analysis, the accuracy of judging the activity status of UAV nodes is greatly improved. This effectively distinguishes between permanent node offline status and temporary network failures, preventing misjudgments that could distort the perception of cluster size and affect the accuracy of resource demand forecasting. Overall, these preprocessing and correction steps, combined, provide a high-quality, highly reliable input data foundation for subsequent elastic prediction models, fundamentally improving the accuracy and robustness of the entire elastic scaling system's decisions. This allows the system to exhibit superior stability and adaptability when facing real, complex network environments and load fluctuations.

[0034] In another technical solution, step S2, where the authentication arbitration node generates the predicted value and the number of recommendations based on the security state vector, specifically includes: The authentication arbitration node continuously retrieves the global security state vector published by the authentication service node from the distributed message queue and maintains a historical security state vector sequence containing N consecutive time intervals. A resilient prediction model is constructed by cascading a time series prediction algorithm based on a long short-term memory network model and a rule-based analysis engine. The time series prediction algorithm takes the historical security state vector sequence as input and outputs predicted values ​​for the network access request rate and CPU utilization for a future time interval. The rule-based analysis engine receives the predicted values ​​and, combined with a preset baseline processing capacity of a single authentication microservice instance, calculates the ratio of the predicted network access request rate to the baseline processing capacity and rounds it up to obtain the predicted authentication resource demand value. Simultaneously, the analysis engine dynamically adjusts a security redundancy coefficient based on the comparison between the predicted CPU utilization and a utilization threshold, multiplying the predicted authentication resource demand value by the security redundancy coefficient to obtain the final recommended number of microservice instances to scale. After each generation of a recommended number, the authentication arbitration node uses the historical security state vector sequence used this time and the corresponding actual subsequent load data as new training samples to incrementally update the long short-term memory network model.

[0035] As the intelligent decision-making center, the authentication arbitration node needs to build a time-series-deep analytical foundation. The node continuously listens to and consumes the global security state vector published by the authentication service node to a distributed message queue (such as a Kafka topic). Upon receiving a new vector, the node appends it to a historical sequence maintained in memory or a cache. This sequence retains data over N consecutive time intervals, such as records from the most recent 30 or 60 time points (each time interval can correspond to a fixed data collection period, such as 1 minute). This historical sequence constitutes the memory content of the time series prediction algorithm. The first part of the resilient prediction model, namely the time series prediction algorithm based on Long Short-Term Memory (LSTM) networks, uses this historical sequence as input. LSTM networks are a special type of recurrent neural network that selectively retains long-term historical information, forgets irrelevant information, and focuses on the current input through internal gating mechanisms (such as forget gates, input gates, and output gates). This makes it particularly adept at capturing complex dependencies and change patterns in data over time, such as periodicity and trends. In this scheme, the algorithm, through training, can learn the evolution of metrics such as network access request rate and CPU utilization over time. When the current historical sequence is input, the model outputs predicted values ​​for the inbound request rate and CPU utilization for a future time interval (e.g., the next 1 minute). This step transforms static historical observation data into a dynamic prediction of future system load. Simple numerical prediction is not directly equivalent to resource instructions; it needs to be translated in conjunction with business logic and engineering experience. This is accomplished by the rule-based analysis engine, the second part of the elastic prediction model. This analysis engine receives the predicted values ​​output by the LSTM model and performs calculations based on predefined business parameters. One key parameter is the baseline processing capacity of a single authentication microservice instance, an empirical value derived from stress testing or historical operational data analysis. For example, an instance can handle an average of 50 to 200 authentication requests per second. The analysis engine divides the predicted future inbound request rate by this baseline processing capacity to obtain a theoretically required lower limit for the number of instances. This result is usually rounded up to form a preliminary prediction of authentication resource requirements. However, this prediction only considers processing capacity and does not account for instance health margins or sudden risks. Therefore, the engine also evaluates the predicted CPU utilization. The system presets a utilization threshold, such as 70% or 80%, as a benchmark for judging whether computing resources are becoming strained. The analysis engine compares the predicted CPU utilization with this threshold and dynamically adjusts a safety redundancy coefficient based on the comparison result. If the predicted utilization consistently approaches or exceeds the threshold, the engine activates protection logic, selecting a redundancy coefficient greater than 1.0 (e.g., 1.2 or 1.5), multiplying this coefficient by the previously calculated predicted resource demand value, thus obtaining a final recommended number of microservice instances to scale, which includes a certain preventative buffer.In this way, the output is not only based on the prediction of the request volume, but also includes proactive protection of resource health.

[0036] To ensure the predictive model can adapt to potential changes in load patterns (such as changes in drone swarm operation patterns), the system employs an online learning mechanism. The authentication arbitration node does not use the model once; instead, after each prediction and the generation of a number of suggestions, it packages the historical safety state vector sequence upon which the prediction was based, along with subsequent load data (i.e., true values) actually observed within the corresponding time interval, into a new training sample. This sample is used to incrementally update the underlying LSTM model. Incremental updates fine-tune the model parameters using new sample data without retraining the entire massive model, allowing its predictive logic to slowly adapt to the latest operational characteristics of the system. This process makes the resilient predictive model a dynamically evolving learning system, rather than a static, unchanging rule base, thus maintaining its predictive accuracy and adaptability to various scenarios over the long term. Compared to methods that only use current instantaneous indicators or simple linear extrapolation for resource estimation, this solution, by introducing an LSTM model with temporal memory capabilities, can more profoundly capture the underlying patterns and trends of load changes, significantly enhancing the foresight and accuracy of resource demand prediction. Simultaneously, by combining rule-based analysis engines to process and redundancy-adjust the prediction results, the final recommended scaling not only theoretically meets processing capacity but also provides a safety buffer for potential prediction biases, instantaneous peaks, or instance performance fluctuations, effectively reducing the risk of service overload due to insufficient resource preparation. Furthermore, a continuous incremental learning mechanism ensures that the entire prediction system can self-optimize as actual load patterns evolve, maintaining intelligent decision-making over the long term and enhancing the system's robustness and adaptability in long-term operation.

[0037] The process by which a rule-based analytics engine dynamically adjusts the safety redundancy coefficient specifically includes: The analytics engine presets a CPU utilization threshold and a basic safety redundancy coefficient. It compares the predicted CPU utilization output by the elastic prediction model with the CPU utilization threshold. When the predicted CPU utilization consistently exceeds the threshold, the analytics engine initiates overload protection logic. This logic linearly searches a predefined mapping table based on the percentage of CPU utilization exceeding the limit and selects an adjusted safety redundancy coefficient greater than the basic safety redundancy coefficient. This adjusted safety redundancy coefficient is applied to the calculation process, ensuring that the recommended number of microservice instances to scale includes preventative additional instances when computational resource constraints are predicted. The actual system load data is recorded each time a value greater than the basic safety redundancy coefficient is used. If the actual load consistently falls below the predicted load, a feedback loop lowers the coefficient value in the mapping table to gradually approximate the actual resource demand. Finally, the product of the certified resource demand prediction and the adjusted safety redundancy coefficient is calculated and rounded up to obtain the recommended number of microservice instances to scale for subsequent resource scheduling.

[0038] The analytics engine has two key preset parameters: a CPU utilization threshold and a basic safety redundancy coefficient. The CPU utilization threshold serves as a warning line to determine if the system is likely to enter a resource-strained state. Its value can be set according to the business's sensitivity to latency and cost control requirements, for example, a value between 75% and 85%. The basic safety redundancy coefficient is a default buffer coefficient when the system load is normal and the forecast is stable. It is usually a value slightly greater than 1.0, such as 1.1 or 1.2, to handle minor forecast fluctuations. The analytics engine continuously monitors the predicted CPU utilization output by the elastic forecasting model and compares it with the preset utilization threshold. When the system predicts that the CPU utilization will consistently exceed this threshold for a future time interval (e.g., exceeding it for two consecutive forecast cycles), the analytics engine determines that the system is at risk of overload and immediately activates its internal overload protection logic. This determination mechanism uses the predicted future state as a warning signal, allowing the system to enter a state of alert before actual overload occurs. After the overload protection logic is activated, its primary task is to determine an appropriate, increased safety redundancy coefficient. To this end, the system maintains a predefined mapping table. This mapping table establishes a correspondence between the "predicted percentage of CPU utilization exceeding the threshold" and the "recommended adjustment value for the safety redundancy coefficient." For example, when the predicted utilization exceeds the threshold by 5%, the mapping table might indicate a coefficient of 1.3; when it exceeds 10%, it might indicate a coefficient of 1.5. The adjustment process can be linear or a step-by-step increase based on experience. The analysis engine, based on the currently calculated percentage of over-limit, looks up and selects the corresponding adjusted safety redundancy coefficient from this mapping table, which is greater than the base safety redundancy coefficient. Subsequently, the engine applies this adjusted coefficient to the calculation: multiplying the previously obtained certified resource demand prediction value by this coefficient and rounding the product up. The result of this operation is that the final output of the recommended number of microservice instance scaling, in addition to the number of instances meeting the baseline predicted demand, explicitly includes a portion of preventative additional instances. These additional instances are buffer resources specifically prepared to address the resource strain risks indicated by the prediction, aiming to nip potential service quality degradation risks in the bud.

[0039] To prevent over-conservatism or adjustment failures, the system does not set the mapping table permanently; instead, it introduces a feedback loop for dynamic optimization. Each time the analysis engine predicts overload risk and uses an adjustment coefficient higher than the base value, generating a scaling recommendation accordingly, the system specifically records the actual system load data (such as actual average CPU utilization, request processing latency, etc.) in the subsequent monitoring period. This actual data is compared with the previous predictions. The logic of the feedback loop is: if, after repeatedly using a high safety redundancy coefficient, the observed actual load data is consistently and significantly lower than the previously predicted load, it indicates that the current mapping table may be too conservative, leading to over-allocation of resources and wasted resources. In this case, the system automatically starts an optimization program, adjusting the coefficient value corresponding to the corresponding over-limit percentage in the mapping table according to a preset algorithm (such as gradual reduction). This process is gradual, with each adjustment being a small step size. By periodically analyzing the effects of decisions and fine-tuning the mapping table, the system can gradually bring its safety redundancy coefficient setting closer to the actual required risk buffer level, achieving a more precise balance between performance and cost while ensuring service stability. Compared to schemes that use fixed safety factors or adjust based solely on simple hierarchical rules, establishing a fine-grained mapping relationship between predicted overload levels and adjustment factors provides a clear quantitative basis and gradient for introducing safety redundancy. This allows for more precise matching of the buffer strength required for different levels of overload risk, avoiding resource waste or insufficient buffering caused by a "one-size-fits-all" approach. In particular, by introducing a dynamic optimization mechanism based on actual load feedback, the entire safety factor adjustment strategy possesses the ability to self-learn and continuously improve. It can gradually adapt to the real risk characteristics of the current business scenario. In the long run, it can effectively defend against overload risks while significantly improving the precision and economy of computing resource usage, making the system's elastic scaling behavior more intelligent and adaptive.

[0040] In another technical solution, step S3, in which the cloud platform resource scheduler generates the scaling instruction set, specifically includes: The cloud platform resource scheduler synchronously receives the predicted value of authentication resource demand and the suggested number of microservice instance scaling from the authentication arbitration node. Simultaneously, it obtains the aggregate CPU utilization and the real-time length of the authentication request queue for all currently running authentication microservice instances through the cloud platform monitoring system. It compares the real-time aggregate CPU utilization with a preset first utilization threshold and a preset second utilization threshold, and compares the real-time length of the authentication request queue with a preset queue length threshold. Based on the designed resource threshold strategy, it determines whether the aggregate CPU utilization exceeds the first utilization threshold or the authentication request queue length simultaneously exceeds the queue length threshold. When the first type of scaling instruction is generated, the number of instances required by the first type of scaling instruction is directly adopted from the suggested number of microservice instances to scale. When only the aggregate CPU utilization exceeds the second utilization threshold but the authentication request queue length does not exceed the limit, the second type of scaling instruction is generated. The number of instances required by the second type of scaling instruction is half of the suggested number of microservice instances to scale. Before generating the instruction, it is also verified whether the available computing resources in the current cloud platform resource pool meet the instance requirements corresponding to the instruction. If not, a limited scaling instruction set is generated based on the maximum allocable resources. The final generated scaling instruction set includes the instruction type, the target number of instances, and the specified cloud platform availability zone deployment information.

[0041] During the initial data aggregation phase, the cloud platform resource scheduler acts as an information aggregation center. It simultaneously receives two types of output from the upstream authentication arbitration nodes: a forecast of future authentication resource demand and a suggested number of microservice instances to scale, derived from intelligent analysis. Meanwhile, the scheduler maintains a close connection with the cloud platform's underlying monitoring system, acquiring two key metrics reflecting the system's immediate pressure at high frequency (e.g., once per second or every few seconds): the aggregated CPU utilization of all currently running authentication microservice instances, calculated by averaging or weighted averaging the CPU utilization of all instances, reflecting the overall computing resource consumption level of the authentication service cluster; and the real-time length of the authentication request queue, i.e., the number of pending authentication requests that have reached the load balancer but have not yet been processed by any instance, directly reflecting the service's backlog pressure. By simultaneously grasping both the predicted future demand and the urgent current pressure, the scheduler possesses a complete information view for comprehensive decision-making.

[0042] The resource threshold strategy employs multi-condition, tiered judgment. Several key thresholds are defined, such as a first utilization threshold, a second utilization threshold, and a queue length threshold. These thresholds set the boundaries for different system stress states. Their specific values ​​can be set according to the business's trade-off between performance and cost. For example, the first utilization threshold can be set at a high level, such as 80% to 90%, indicating that the system has entered a high-load state; the second utilization threshold can be set between 70% and 80%, indicating that the system load has significantly increased but has not yet reached an emergency state; the queue length threshold can be set to tens to hundreds of requests, depending on the processing time of a single request. The scheduler compares the real-time aggregated CPU utilization with these two utilization thresholds, and also compares the real-time queue length with the queue length threshold. The decision rule is composite and hierarchical: the most urgent first-type expansion instruction is triggered only when the system simultaneously exhibits severe computing resource pressure and backlog pressure—that is, when the aggregated CPU utilization exceeds the higher first utilization threshold and the authentication request queue length simultaneously exceeds its threshold. At this point, the system is on the verge of overload, so the instruction requests the full and direct adoption of the scaling recommendation from the accredited arbitrator node to quickly alleviate the pressure. However, when the system only exhibits persistent computing resource strain (aggregate CPU utilization exceeds the second utilization threshold) but the service queue is not severely congested (queue length is not exceeded), a more moderate second-type scaling instruction is triggered. In this case, to prevent potential overscaling, the instruction requests only half the recommended number of instances. This is a more gradual and conservative response strategy, and this tiered strategy ensures that the intensity of resource response matches the actual urgency.

[0043] Before generating specific instructions, resource feasibility is verified. Cloud platform resources are not unlimited and may have quota limitations or physical resource constraints. Therefore, after determining the target number of instances based on the above logic, the scheduler immediately queries the available computing resources (such as allocable vCPUs and memory) in the current cloud platform resource pool (e.g., virtual machine resources or container host resources within a specific availability zone). If the available resources are sufficient to meet the needs of the target instances, instructions are generated as originally planned. If the available resources are insufficient, the scheduler generates a limited scaling instruction set based on the maximum allocable resources. For example, if 10 instances need to be added, but the resource pool only has enough for 6 more, the instructions will only include adding 6 instances. Regardless of whether it is limited or not, the final generated scaling instruction set is a structured instruction package, which explicitly includes the instruction type (whether it is the first or second type of scaling instruction mentioned above, or a scaling down instruction), the actual number of target instances that can be executed after verification, and the specific cloud platform "availability zone" deployment information specified to optimize disaster recovery and access latency. Compared to simple scheduling schemes that rely solely on a single threshold or directly execute predictive suggestions, this composite decision-making strategy, which incorporates both aggregated CPU utilization and request queue length metrics and sets tiered thresholds, provides a more comprehensive and precise assessment of system pressure. This effectively distinguishes between two fundamentally different emergency states: "resource scarcity but service still able to respond promptly" and "resource exhaustion and service backlog." Based on this, differentiated scaling efforts (full scaling and half-scaling) are implemented, significantly improving the accuracy and cost-effectiveness of resource scheduling and preventing over-allocation of resources in non-emergency situations. Furthermore, the addition of a resource feasibility verification step ensures that all generated instructions are based on the actual conditions of the cloud platform and are implementable, preventing scheduling instructions from failing or causing platform errors due to insufficient resources, greatly enhancing the robustness and reliability of the entire scaling process.

[0044] In the resource threshold strategy, the preset first utilization threshold, second utilization threshold, and queue length threshold are dynamic values, which are dynamically adjusted by the cloud platform resource scheduler based on historical decision-making results. The dynamic adjustment process specifically includes: After each execution of a scaling instruction set, the maximum values ​​of the aggregated CPU utilization and authentication request queue length observed in the next monitoring cycle are recorded and compared with the threshold that triggered the last decision. A decision effect table is constructed to store the type of each scaling decision, the threshold used, and whether the system has recovered to the normal load zone after the decision. The decision effect table is analyzed periodically. If the statistics show that the system state has not improved effectively after consecutive scaling decisions triggered based on the current threshold, the threshold adjustment logic is initiated. The threshold adjustment logic increases or decreases the values ​​of the first utilization threshold, the second utilization threshold, and the queue length threshold by a predetermined adjustment step value according to the historical load pattern, and continues to monitor the decision effect after adjustment.

[0045] Each time the resource scheduler generates and executes a scaling instruction set (whether for expansion or contraction) based on the current threshold settings, the system does not immediately consider the task complete. Instead, it initiates a subsequent monitoring cycle, such as the next 5 to 15 minutes. During this cycle, the system closely observes and records the actual system state, particularly capturing the peak or most representative values ​​of aggregate CPU utilization and authentication request queue length during this period. These actual observations form a direct comparison sample with the instantaneous thresholds used to trigger the last decision. All this information, including the type of the last decision (first-class expansion, second-class expansion, etc.), the specific values ​​of the various thresholds used in the decision, and whether the system state successfully recovered to a preset normal load range after the decision was executed (e.g., CPU utilization dropped below 60% and the queue was cleared), is compiled and stored in a dedicated decision effect table. Over time, the decision effect table accumulates rich historical experience data.

[0046] Once a sufficient number of decision records have been accumulated, the system will periodically (e.g., daily or weekly) perform effect analysis and adjustment triggers. At this time, the system will invoke analysis logic to statistically analyze the decision effect table and determine whether the current threshold settings are still effective. For example, the system may repeatedly detect situations where, based on the current first utilization threshold (e.g., 85%), a first-type expansion command is triggered, but during the monitoring period after the expansion action, although the system's actual load (CPU utilization) decreases, it remains high and fails to effectively return to the normal load range; or the queue length repeatedly touches the threshold. This is a strong signal that the current threshold setting may be too lenient (the threshold is too high), causing the system to only intervene when the problem is severe, and the intervention is ineffective. Once the statistical pattern (e.g., the state does not improve significantly after several consecutive decisions) meets the preset adjustment trigger conditions, the system will automatically initiate the threshold adjustment logic and enter the parameter optimization process. The threshold adjustment logic fine-tunes the relevant thresholds based on the analysis of historical load patterns (e.g., finding that the system's normal load has generally increased) and following a robust adjustment step size. The step size for threshold adjustments can be pre-calibrated experimentally based on the specific cloud platform's monitoring granularity, business load characteristics, and historical data. The adjustment step size is a small, carefully set value; for example, for CPU utilization thresholds, the step size could be 2% or 3%; for queue length thresholds, it could be 10 or 20 requests. If the analysis concludes that the current threshold is set too high, causing response lag, the adjustment logic will lower the relevant threshold by a step size (e.g., lowering the first utilization threshold from 85% to 82%), allowing the system to trigger responses earlier in the future. Conversely, if historical records show that the system frequently triggers unnecessary minor scaling due to thresholds set too low, the adjustment logic will increase the threshold by a step size. After adjustment, the new threshold will take effect immediately for subsequent scaling decisions. The system does not stop there but continues to rigorously monitor the effects of decisions made based on the new threshold and record them again in the decision effect table, thus initiating a new cycle of learning and optimization. This process allows the threshold to gradually approach an optimal value that matches the current system's actual operating characteristics and business objectives.

[0047] Compared to static strategies using fixed thresholds, this solution introduces a dynamic threshold adjustment mechanism based on historical decision-making effects. This eliminates the reliance on potentially inaccurate empirical values ​​set during initialization, giving the entire elastic scaling system strong environmental adaptability. The system can automatically detect changes in its own load characteristics (such as baseline shifts due to business growth, code optimization, or hardware aging) and correspondingly fine-tune the sensitivity of its decision triggers. This significantly reduces two negative consequences caused by improper threshold settings: first, overly sensitive thresholds leading to frequent and unnecessary resource fluctuations and cost waste; and second, overly insensitive thresholds increasing the risk of system response delays and service performance degradation. In the long run, this mechanism enables the system to continuously self-optimize, maintaining a good balance between the timeliness and economy of scaling decisions.

[0048] In another technical solution, step S4, the specific process of executing the scaling instruction set through the container orchestration component includes: The container orchestration component receives scaling instruction sets from the cloud platform resource scheduler, parses the instruction type, target number of instances, and cloud platform availability zone deployment information. Depending on whether the instruction is a scaling-up or scaling-down instruction, the container orchestration component calls the container service application programming interface provided by the cloud platform to create or delete the corresponding number of certified microservice instance containers within the specified availability zone. During the creation of new certified microservice instance containers, the container orchestration component pulls the specified version of the certified microservice image from a pre-defined container image repository and allocates compute and storage resources to each new container according to a predefined resource configuration template. After each newly created certified microservice instance container starts, it executes its embedded health check script and registers its network endpoint information with the container orchestration component. The container orchestration component continuously monitors the running status of all certified microservice instance containers, adding their network endpoint information to the load balancing configuration list only after confirming that a new instance has passed the health check and reached a ready state. For scaling-down instructions, the container orchestration component selects instances to be deleted based on the least recently used principle, removes them from the load balancing configuration list, waits for them to finish processing existing requests, and then calls the application programming interface to terminate the corresponding container.

[0049] First, the container orchestration component (such as Kubernetes Controller Manager or a custom Operator) receives a scaling instruction set from the cloud platform resource scheduler. This instruction set is a structured data object that the component needs to parse to extract three key operational elements: instruction type (specifying whether it's "scaling up" or "scaling down"), target instance count (the specific number to create or delete), and cloud platform availability zone deployment information (specifying the physical or logical region where the operation will be performed). After parsing, the component will call the standardized application programming interfaces exposed by the cloud platform or container service, depending on the instruction type. For mainstream cloud platforms, this might be calling the APIs of AWS ECS, Google CloudRun, or Alibaba Cloud ACK; in a self-built Kubernetes cluster, it involves interacting with the APIServer through interfaces such as its Client-go library to operate on specific workload resource objects, such as Deployments or StatefulSets. This step completes the translation from business instructions to underlying platform operation instructions.

[0050] Based on the translated operation instructions, the system enters the specific provisioning or recycling process for container instances. For scaling instructions, the container orchestration component creates new certified microservice instance containers within the availability zone specified by the instruction, according to a predefined resource configuration template. This template defines the resource specifications for each container, such as requesting 0.5 vCPU cores and 1GB of memory, and limiting the use to a maximum of 1 vCPU core and 2GB of memory, while mounting the necessary configuration file volumes. The component first pulls the specified version of the certified microservice image from a pre-defined container image repository (such as a private Harbor or a public Docker Hub), which contains the complete application code and runtime environment. Then, it calls the platform API to create a specified number of container Pods in batches according to the template configuration. For scaling down instructions, the process is exactly the opposite, but it needs to follow certain selection strategies to reduce the impact on the service. The component selects instances to be deleted based on the "least recently used principle," which means that the component evaluates the processing activity (such as the current number of connections) or creation time of each running instance, prioritizing the least active or earliest created instances as scaling down targets, thereby preserving the instance cluster with the strongest processing capacity as much as possible. Newly created containers are not immediately included in the service traffic pool after startup. Each container has an embedded health check script, which can be an HTTP endpoint (e.g., / health) to report whether the application has been initialized and whether dependent services (e.g., databases, blockchain nodes) are connected; or it can be a script that executes a specific command. The container orchestration component performs these health checks periodically (e.g., every 10 seconds). Only when a new instance passes several health checks consecutively (e.g., two consecutive successes) does the component determine that it has reached a ready state. At this point, the instance will proactively or with the assistance of the component register its network endpoint information (usually IP address and port) with the container orchestration component's service discovery mechanism. Next, the component performs the most critical step: adding the ready new instance endpoint to the load balancer configuration list. For selected shrinking instances, the component will first remove them from the load balancer configuration list to ensure that subsequent new requests are no longer routed to them. Then, it will wait for a short grace period (e.g., 30 seconds) to allow the instance to process existing requests or send a termination signal to gracefully shut down the instance before finally calling the platform API to completely terminate the corresponding container process. This series of state-driven operations ensures a smooth transition of traffic and business continuity during service scaling.

[0051] Compared to traditional scaling methods that directly create or delete virtual machines or containers without fine-grained state management, this solution achieves a high degree of automation and standardization in resource provisioning through precise command parsing by container orchestration components, standardized application of resource templates, and strict control over instance health status. This significantly improves the execution efficiency and reliability of scaling operations. In particular, the introduction of a scaling-down selection based on the least recently used principle and a graceful termination mechanism that waits for existing requests to be processed effectively avoids accidentally deleting high-load instances or forcibly interrupting user sessions during scaling down, thereby greatly enhancing service stability and user experience during elastic scaling.

[0052] The process of updating the load balancer configuration list by the container orchestration component specifically includes: The container orchestration component maintains a primary load balancer configuration list and a list of load balancer configurations to be updated. When new authentication microservice instance network endpoint information needs to be added or removed, the container orchestration component first performs the corresponding addition or removal operation in the list of load balancer configurations to be updated and generates a version identifier for the list. Subsequently, the container orchestration component sends a configuration update request to the load balancer, which includes the version identifier and the complete content of the list of load balancer configurations to be updated. After receiving the request, the load balancer atomically replaces the received list of load balancer configurations to be updated with the currently effective primary load balancer configuration list within a predetermined millisecond time window, and immediately routes subsequent access authentication requests based on the new list. After completing the switchover, the load balancer returns a confirmation response to the container orchestration component and discards the old configuration list. After receiving the confirmation response, the container orchestration component synchronizes the content of the list of load balancer configurations to be updated to the primary load balancer configuration list and clears the list of load balancer configurations to be updated to await the next modification.

[0053] The container orchestration component does not directly modify the currently active load balancer configuration. Instead, it maintains two lists: one for the primary load balancer configuration currently handling traffic, and another for load balancer configurations to be updated in preparation for the next change. When a certified microservice instance needs to be added or removed (e.g., a new instance has passed a health check, or an old instance has been selected for scaling down), the component first operates on the list of load balancer configurations to be updated. This operation is offline and pre-emptive, and does not immediately affect online traffic. To accurately track each change, after modifying the list of configurations to be updated, the component generates a unique version identifier for this new version of the list. This identifier can be an incrementing numeric sequence, a timestamp hash, or any string that ensures uniqueness. This dual-list mechanism decouples the preparation phase from the implementation phase of a change, enabling safe switching.

[0054] Once preparation is complete, the container orchestration component sends a configuration update request to the load balancer (which can be a standalone software such as Nginx, HAProxy, or a load balancing service provided by a cloud platform). This request contains the complete list of load balancer configurations to be updated, along with their version identifiers. Upon receiving the request, the load balancer does not add or remove entries incrementally. Instead, within a very short, predetermined millisecond time window (e.g., within a few milliseconds, or during the interval of the next request processing cycle), it atomically replaces the currently used primary list with the newly received list. Atomicity means that this replacement operation is indivisible; requests arriving simultaneously will see either the entire old list or the entire new list, thus completely avoiding request routing confusion or failures caused by partial list changes during the update process. After the switchover is complete, the load balancer immediately begins routing all subsequent access authentication requests based on the new list. After successfully completing the configuration switchover, the load balancer returns an acknowledgment response to the container orchestration component. This response is a crucial signal of a successful update. Upon receiving confirmation, the container orchestration component knows that the new configuration is already running stably online. It then fully synchronizes the contents of the load balancer configuration list to be updated to the primary load balancer configuration list, ensuring consistency and serving as the baseline for the next change. Subsequently, the component clears the load balancer configuration list to be updated, awaiting the next modification instruction. The old configuration list that has been replaced is safely discarded by the load balancer. This confirmation and synchronization mechanism ensures that the state maintained internally by the container orchestration component is ultimately consistent with the actual effective state of the load balancer, completing the closed loop of the entire update transaction. Compared to traditional methods that may lead to momentary inconsistencies in request routing due to directly and dynamically modifying a single load balancer configuration list, this solution achieves seamless and smooth updates to load balancer configurations during the dynamic scaling of service instances through a collaborative mechanism of dual-list pre-launch, versioned management, and atomic switching. This effectively eliminates problems such as request routing errors, momentary service interruptions, or connection drops caused by delayed or partially effective configuration updates, thus providing a higher level of continuity and reliability for user requests. This solution is particularly suitable for production environments with extremely high requirements for service availability and continuity, making the back-end management operation of elastic scaling completely transparent to front-end users.

[0055] In another technical solution, step S5, the process of drone node access authentication and state synchronization specifically includes: When any drone node in a drone swarm needs to access the network, its built-in communication module sends an access authentication request containing its unique hardware identifier to the load balancer. Upon receiving the access authentication request, the load balancer queries the currently active load balancing configuration list in real time and selects an available authentication microservice instance from the list using a weighted round-robin algorithm. The load balancer then forwards the access authentication request to the network endpoint of that authentication microservice instance. Upon receiving the forwarded request, the authentication microservice instance extracts the hardware identifier and constructs a query transaction based on it. It then initiates a query to a pre-configured permissioned blockchain network node to obtain the distributed identity identifier bound to the hardware identifier and the corresponding public key. Certificate; After receiving a response from the blockchain network, the authentication microservice instance uses a public key certificate to verify the digital signature of the access authentication request. If the verification is successful, a temporary session token is generated for the drone node and a secure connection is established. If the verification fails or no blockchain response is received within a preset timeout period, the authentication microservice instance marks the authentication as failed and allows the drone node to re-initiate the request after waiting for a random backoff time. Regardless of whether the authentication is successful or not, the authentication microservice instance generates a status record containing the drone node identifier, timestamp, and processing result after processing, and sends the status record back to the authentication service node to update the global security state vector with statistics on node activity and authentication load.

[0056] When any drone node in a drone swarm needs to access the network, its built-in communication module constructs and sends an access authentication request. This request typically contains the node's unique hardware identifier (e.g., a serial number burned into a security chip or a device identification number), and the request content can be digitally signed using a private key bound to this identifier to ensure integrity and trustworthiness of the source. This request is first sent to the system's entry point, the load balancer. Upon receiving the request, the load balancer queries the list of load balancer configurations maintained by the container orchestration component and atomically switched over. This list contains the network endpoints (IP addresses and ports) of all healthy and available authentication microservice instances. The load balancer selects an instance from the list based on a preset algorithm (such as a weighted round-robin algorithm). The weighted round-robin algorithm distributes the request to different instances sequentially, taking into account the processing capacity weights of each instance, to achieve relative load balancing. After selection, the load balancer forwards the original access authentication request to the network endpoint of that authentication microservice instance. This stage ensures that authentication requests from a massive number of drones are efficiently and fairly distributed to available backend service resources.

[0057] After the request is forwarded, the authentication microservice instance receiving the request begins its work. It first extracts the crucial hardware identifier from the request. Then, based on this identifier, the instance constructs a formatted query transaction or query request. This query is not sent to a traditional centralized database, but rather to a pre-configured permissioned blockchain network node. This blockchain network (e.g., built on Hyperledger Fabric or FISCO BCOS) stores the distributed identity identifiers and corresponding public key certificates of all legitimate drone nodes. This information is written on-chain during device registration and is difficult to tamper with. The authentication microservice instance queries the blockchain node for the on-chain identity information bound to the hardware identifier. Upon receiving the blockchain network's response, the instance obtains the corresponding public key certificate. Next, it uses this public key to verify the digital signature attached to the access authentication request. Cryptographic principles ensure that only devices holding the corresponding private key can generate a signature that can be verified using the public key. If the verification is successful, it proves that the request indeed originated from a drone node claiming to have a legitimate on-chain identity, and authentication is successful. At this point, the authentication microservice instance generates a time-sensitive temporary session token (such as a JWT token) for the node and establishes an encrypted secure connection (such as a TLS connection) for subsequent business communication. If authentication fails, or if no response is received from the blockchain within a preset timeout period (e.g., 5 or 10 seconds), the instance marks the authentication as failed. To avoid malicious retries or avalanches caused by network problems, the system allows drone nodes to re-initiate the request after waiting for a random backoff time (e.g., a random value between 1 and 10 seconds).

[0058] Regardless of whether authentication is successful or not, the process does not end. After processing each request, the authentication microservice instance generates a structured state record. This record contains at least the drone node's identifier, processing timestamp, and the final processing result (success, failure, or timeout). This record is asynchronously sent back to the system's authentication service node. Upon receiving these scattered state records, the authentication service node performs aggregation analysis. This data is used to update key statistics in the global security state vector. For example, successful authentication is used to correct the number of active drone nodes; the rate and distribution of authentication requests reflect the current system's authentication load and health. Compared to traditional schemes that rely on centralized authentication servers for identity verification, combining load balancing with decentralized blockchain verification not only achieves high efficiency in request distribution and elastic scalability of service instances, but more importantly, it establishes the root of trust for identity verification on an immutable blockchain, significantly enhancing the overall authentication system's resistance to attacks and reliability, and avoiding the risks of single points of failure and centralized certificate management. Meanwhile, the micro-results of each authentication are fed back to the macro-system state vector in real time, enabling the entire elastic scaling system to dynamically adjust based on real business feedback, thereby improving the fit and sensitivity between resource scheduling and business load.

[0059] In the event of authentication microservice instance failure or timeout, the process of updating the security state vector specifically includes: The authentication microservice instance maintains a local failure request counter and a corresponding list of hardware identifiers. When an access authentication request is marked as failed due to digital signature verification failure, the authentication microservice instance first checks if the hardware identifier already exists in the local list. If it exists, it increments the corresponding failure counter; otherwise, it adds the hardware identifier to the list and initializes the counter to 1. When the failure counter reaches a preset failure threshold within a continuous time window, the instance determines that the drone node has a potential security risk and generates a high-risk event alarm record including the hardware identifier, cumulative failure count, and time window information. The high-risk event alarm record, along with the regular status record, is sent to the authentication service node. Upon receiving the high-risk event alarm record, the authentication service node updates the load statistics in the global security state vector and adds the hardware identifier and its risk level to a dedicated risk identifier field in the global security state vector. When the authentication arbitration node subsequently performs predictions and decisions, it incorporates the risk identifier field in the security state vector as a negative weighting factor into the prediction and decision-making considerations.

[0060] Each authentication microservice instance internally maintains two related data structures: a local failed request counter and a corresponding list of hardware identifiers. When an access authentication request is marked as failed due to digital signature verification failure (meaning incorrect credentials or request tampering), the instance doesn't simply record the failure. It checks if the hardware identifier for that request already exists in its local list. If it does, the failure counter corresponding to that identifier is incremented by 1; if it doesn't exist, the hardware identifier is added to the list, and its counter is initialized to 1. This design allows each instance to continuously track consecutive failed attempts from the same device source. The instance sets a continuous time window for these counters, such as the past 5 or 10 minutes, and only counts consecutive failures within this time window; older data is discarded by a sliding window mechanism. This achieves localized awareness of concentrated failure attacks within a short period. The system presets a failure threshold, such as 3 or 5 consecutive failures within the time window. Once the failure counter corresponding to a certain hardware identifier reaches this threshold, the authentication microservice instance determines that the drone node poses a potential security risk, possibly due to a password guessing attack or the use of a forged identity. At this point, the instance will generate a high-risk event alert record that is more severe than a normal status record. This alert record includes the hardware identifier, the cumulative number of failures, the time window information for triggering the alert, and possible event type labels. After generating the alert, the instance will not only process it locally, but will also send this high-risk alert record along with the normal status record for this request to the authentication service node. This means that the authentication service node will receive both the business result feedback and the security threat alert simultaneously.

[0061] Upon receiving a high-risk alert, the authentication service node performs two key operations. First, it still updates the statistics on failed loads in the global security state vector to maintain data integrity. Second, and more importantly, it adds the hardware identifier and its assessed risk level (dynamically categorized based on the number and frequency of failures) to a dedicated field in the global security state vector, such as a "risk identifier field" or a list of risky devices. This field becomes part of the shared security posture information across the entire system. When the authentication arbitration node performs resilient prediction and decision-making in subsequent cycles, it considers this "risk identifier field" in the security state vector as an important negative weighting factor. For example, if the system detects a large number of high-risk identifiers initiating requests (potentially indicating a coordinated attack), even if the predicted request rate is low, the analysis engine can increase the security redundancy coefficient based on security policies, recommending the deployment of more instances to improve the overall resilience and auditing capabilities of the system, thereby directly translating security risk perception into resource defense strategies. Compared to traditional solutions that merely log authentication failures without in-depth analysis and systematic responses, this solution proactively and quickly identifies potential malicious attacks or faulty devices by establishing local risk profiles and threshold alert mechanisms at the service instance level. Furthermore, by elevating and integrating scattered risk alerts into an integral part of the global security state vector, the system's elastic scaling decisions are not only based on load and performance metrics but also incorporate real-time security threat intelligence. This significantly enhances the system's proactive defense capabilities and elastic response levels against security challenges such as identity spoofing attacks and denial-of-service attacks, achieving deep integration and synergy between performance scaling and security protection at the architectural level, thus improving the system's overall resilience.

[0062] It should be noted that although the steps are described in a specific order above, this does not mean that they must be performed in that order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required functionality is achieved. The number of devices and processing scale described herein are for simplification of the invention; applications, modifications, and variations of this invention will be readily apparent to those skilled in the art.

[0063] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A method for elastic scaling of a drone swarm cloud platform based on decentralized authentication, characterized in that, Includes the following steps: S1: Construct a global security state vector and continuously collect data from the authentication service node to update the security state vector. The collected data sources include the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances processing authentication requests in the current cloud platform, and the CPU utilization of each microservice instance. S2: The authentication arbitration node receives the security state vector and inputs it into a pre-trained elastic prediction model. Based on the historical data sequence and current data in the security state vector, the elastic prediction model outputs an authentication resource demand prediction value and a suggested number of microservice instance scaling values. S3: Receive the predicted value of certified resource demand and the suggested number of microservice instances to scale up through the cloud platform resource scheduler, and make a decision based on the preset resource threshold policy. The resource threshold policy defines the logical conditions for triggering scaling operations based on the CPU utilization and the length of the certified request queue, and generates a scaling instruction set containing specific scaling instructions. S4: Receive and execute scaling instruction sets through container orchestration components, call the cloud platform's application programming interface to deploy or destroy certified microservice instances, update a load balancing configuration list, and include the newly deployed certified microservice instances in the authentication request allocation pool. S5: When any drone node in the drone cluster initiates an access authentication request, the access authentication request is distributed to an available authentication microservice instance in the load balancer according to the load balancing configuration list. The authentication microservice instance completes the decentralized verification of the drone node based on the distributed identity identifier stored on the blockchain, and synchronizes the state of the drone node after successful verification to the global security state vector.

2. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 1, characterized in that, In step S1, the process of constructing and maintaining the global security state vector specifically includes: The authentication service node collects data at fixed time intervals from multiple data collection agents deployed at the edge of the cloud platform. This data includes the network access request rate of drone nodes, the number of active drone nodes, the number of microservice instances currently processing authentication requests in the cloud platform, and the CPU utilization of each microservice instance. The authentication service node applies a sliding window of length T to the collected network access request rate and CPU utilization, calculating the moving average of these values. These moving averages replace the original instantaneous values ​​and form part of the security state vector. The authentication service node periodically broadcasts heartbeat messages to the drone cluster and dynamically adjusts the number of active drone nodes based on the number of response messages and latency to eliminate drone nodes mistakenly identified as inactive due to temporary network failures. The data processed by the sliding window and heartbeat adjustment is integrated into a global security state vector, which is then published to a distributed message queue for the authentication arbitration node to subscribe to and retrieve.

3. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 1, characterized in that, In step S2, the process by which the authentication arbitration node generates predicted values ​​and suggested quantities based on the security state vector specifically includes: The authentication arbitration node continuously retrieves the global security state vector published by the authentication service node from the distributed message queue and maintains a historical security state vector sequence containing N consecutive time intervals. A resilient prediction model is constructed by cascading a time series prediction algorithm based on a long short-term memory network model and a rule-based analysis engine. The time series prediction algorithm takes the historical security state vector sequence as input and outputs predicted values ​​for the network access request rate and CPU utilization for a future time interval. The rule-based analysis engine receives the predicted values ​​and, combined with a preset baseline processing capacity of a single authentication microservice instance, calculates the ratio of the predicted network access request rate to the baseline processing capacity and rounds it up to obtain the predicted authentication resource demand value. Simultaneously, the analysis engine dynamically adjusts a security redundancy coefficient based on the comparison between the predicted CPU utilization and a utilization threshold, multiplying the predicted authentication resource demand value by the security redundancy coefficient to obtain the final recommended number of microservice instances to scale. After each generation of a recommended number, the authentication arbitration node uses the historical security state vector sequence used this time and the corresponding actual subsequent load data as new training samples to incrementally update the long short-term memory network model.

4. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 3, characterized in that, The process by which a rule-based analytics engine dynamically adjusts the safety redundancy coefficient specifically includes: The analytics engine presets a CPU utilization threshold and a basic safety redundancy coefficient. It compares the predicted CPU utilization output by the elastic prediction model with the CPU utilization threshold. When the predicted CPU utilization consistently exceeds the threshold, the analytics engine initiates overload protection logic. This logic linearly searches a predefined mapping table based on the percentage of CPU utilization exceeding the limit and selects an adjusted safety redundancy coefficient greater than the basic safety redundancy coefficient. This adjusted safety redundancy coefficient is applied to the calculation process, ensuring that the recommended number of microservice instances to scale includes preventative additional instances when computational resource constraints are predicted. The actual system load data is recorded each time a value greater than the basic safety redundancy coefficient is used. If the actual load consistently falls below the predicted load, a feedback loop lowers the coefficient value in the mapping table to gradually approximate the actual resource demand. Finally, the product of the certified resource demand prediction and the adjusted safety redundancy coefficient is calculated and rounded up to obtain the recommended number of microservice instances to scale for subsequent resource scheduling.

5. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 1, characterized in that, Step S3, the process of generating a scaling instruction set by the cloud platform resource scheduler, specifically includes: The cloud platform resource scheduler synchronously receives the predicted value of authentication resource demand and the suggested number of microservice instance scaling from the authentication arbitration node. Simultaneously, it obtains the aggregate CPU utilization and the real-time length of the authentication request queue for all currently running authentication microservice instances through the cloud platform monitoring system. It compares the real-time aggregate CPU utilization with a preset first utilization threshold and a preset second utilization threshold, and compares the real-time length of the authentication request queue with a preset queue length threshold. Based on the designed resource threshold strategy, it determines whether the aggregate CPU utilization exceeds the first utilization threshold or the authentication request queue length simultaneously exceeds the queue length threshold. When the first type of scaling instruction is generated, the number of instances required by the first type of scaling instruction is directly adopted from the suggested number of microservice instances to scale. When only the aggregate CPU utilization exceeds the second utilization threshold but the authentication request queue length does not exceed the limit, the second type of scaling instruction is generated. The number of instances required by the second type of scaling instruction is half of the suggested number of microservice instances to scale. Before generating the instruction, it is also verified whether the available computing resources in the current cloud platform resource pool meet the instance requirements corresponding to the instruction. If not, a limited scaling instruction set is generated based on the maximum allocable resources. The final generated scaling instruction set includes the instruction type, the target number of instances, and the specified cloud platform availability zone deployment information.

6. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 5, characterized in that, In the resource threshold strategy, the preset first utilization threshold, second utilization threshold, and queue length threshold are dynamic values, which are dynamically adjusted by the cloud platform resource scheduler based on historical decision-making results. The dynamic adjustment process specifically includes: After each execution of a scaling instruction set, the maximum values ​​of the aggregated CPU utilization and authentication request queue length observed in the next monitoring cycle are recorded and compared with the threshold that triggered the last decision. A decision effect table is constructed to store the type of each scaling decision, the threshold used, and whether the system has recovered to the normal load zone after the decision. The decision effect table is analyzed periodically. If the statistics show that the system state has not improved effectively after consecutive scaling decisions triggered based on the current threshold, the threshold adjustment logic is initiated. The threshold adjustment logic increases or decreases the values ​​of the first utilization threshold, the second utilization threshold, and the queue length threshold by a predetermined adjustment step value according to the historical load pattern, and continues to monitor the decision effect after adjustment.

7. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 1, characterized in that, In step S4, the specific process of executing the scaling instruction set through the container orchestration component includes: The container orchestration component receives scaling instruction sets from the cloud platform resource scheduler, parses the instruction type, target number of instances, and cloud platform availability zone deployment information. Depending on whether the instruction is a scaling-up or scaling-down instruction, the container orchestration component calls the container service application programming interface provided by the cloud platform to create or delete the corresponding number of certified microservice instance containers within the specified availability zone. During the creation of new certified microservice instance containers, the container orchestration component pulls the specified version of the certified microservice image from a pre-defined container image repository and allocates compute and storage resources to each new container according to a predefined resource configuration template. After each newly created certified microservice instance container starts, it executes its embedded health check script and registers its network endpoint information with the container orchestration component. The container orchestration component continuously monitors the running status of all certified microservice instance containers, adding their network endpoint information to the load balancing configuration list only after confirming that a new instance has passed the health check and reached a ready state. For scaling-down instructions, the container orchestration component selects instances to be deleted based on the least recently used principle, removes them from the load balancing configuration list, waits for them to finish processing existing requests, and then calls the application programming interface to terminate the corresponding container.

8. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 7, characterized in that, The process of updating the load balancer configuration list by the container orchestration component specifically includes: The container orchestration component maintains a primary load balancer configuration list and a list of load balancer configurations to be updated. When new authentication microservice instance network endpoint information needs to be added or removed, the container orchestration component first performs the corresponding addition or removal operation in the list of load balancer configurations to be updated and generates a version identifier for the list. Subsequently, the container orchestration component sends a configuration update request to the load balancer, which includes the version identifier and the complete content of the list of load balancer configurations to be updated. After receiving the request, the load balancer atomically replaces the received list of load balancer configurations to be updated with the currently effective primary load balancer configuration list within a predetermined millisecond time window, and immediately routes subsequent access authentication requests based on the new list. After completing the switchover, the load balancer returns a confirmation response to the container orchestration component and discards the old configuration list. After receiving the confirmation response, the container orchestration component synchronizes the content of the list of load balancer configurations to be updated to the primary load balancer configuration list and clears the list of load balancer configurations to be updated to await the next modification.

9. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication as described in claim 1, characterized in that, In step S5, the process of drone node access authentication and state synchronization specifically includes: When any drone node in a drone swarm needs to access the network, its built-in communication module sends an access authentication request containing its unique hardware identifier to the load balancer. Upon receiving the access authentication request, the load balancer queries the currently active load balancing configuration list in real time and selects an available authentication microservice instance from the list using a weighted round-robin algorithm. The load balancer then forwards the access authentication request to the network endpoint of that authentication microservice instance. Upon receiving the forwarded request, the authentication microservice instance extracts the hardware identifier and constructs a query transaction based on it. It then initiates a query to a pre-configured permissioned blockchain network node to obtain the distributed identity identifier bound to the hardware identifier and the corresponding public key. Certificate; After receiving a response from the blockchain network, the authentication microservice instance uses a public key certificate to verify the digital signature of the access authentication request. If the verification is successful, a temporary session token is generated for the drone node and a secure connection is established. If the verification fails or no blockchain response is received within a preset timeout period, the authentication microservice instance marks the authentication as failed and allows the drone node to re-initiate the request after waiting for a random backoff time. Regardless of whether the authentication is successful or not, the authentication microservice instance generates a status record containing the drone node identifier, timestamp, and processing result after processing, and sends the status record back to the authentication service node to update the global security state vector with statistics on node activity and authentication load.

10. The method for elastic scaling of a drone swarm cloud platform based on decentralized authentication according to claim 9, characterized in that, In the event of authentication microservice instance failure or timeout, the process of updating the security state vector specifically includes: The authentication microservice instance maintains a local failure request counter and a corresponding list of hardware identifiers. When an access authentication request is marked as failed due to digital signature verification failure, the authentication microservice instance first checks if the hardware identifier already exists in the local list. If it exists, it increments the corresponding failure counter; otherwise, it adds the hardware identifier to the list and initializes the counter to 1. When the failure counter reaches a preset failure threshold within a continuous time window, the instance determines that the drone node has a potential security risk and generates a high-risk event alarm record including the hardware identifier, cumulative failure count, and time window information. The high-risk event alarm record, along with the regular status record, is sent to the authentication service node. Upon receiving the high-risk event alarm record, the authentication service node updates the load statistics in the global security state vector and adds the hardware identifier and its risk level to a dedicated risk identifier field in the global security state vector. When the authentication arbitration node subsequently performs predictions and decisions, it incorporates the risk identifier field in the security state vector as a negative weighting factor into the prediction and decision-making considerations.

Images