Unmanned aerial vehicle cluster downloading data load balancing algorithm based on micro service

Abstract

The invention particularly relates to an unmanned aerial vehicle cluster downloading data load balancing algorithm based on micro-service, which comprises the following steps of: replacing periodic synchronization by combining multi-round sampling and instant calculation, and ensuring that average response time can reflect the real-time state of the micro-service; and the optimal micro-service node is dynamically screened by monitoring the micro-service response state in real time, so that the efficient distribution of the data downloaded by the unmanned aerial vehicle in the micro-service cluster is realized. On the basis, a real-time response time decision and hot registration dynamic management are deeply combined, so that not only is the optimality of data distribution ensured through response time, but also the capacity expansion cost is reduced through hot registration. According to the invention, the technical problems of inaccurate response time perception, dependence on manual intervention on capacity expansion and shrinkage, long-term resource occupation of fault nodes and encumberment of overall data flow in a mass unmanned aerial vehicle data downloading scene in the existing load balancing scheme are solved; the method is suitable for scenes requiring massive unmanned aerial vehicle collaborative operation, such as regional emergency monitoring, large-scale training and urban air traffic management.

Description

Technical Field

[0001] This invention relates to the field of UAV swarm data transmission and microservice load balancing technology, specifically to a microservice-based UAV swarm downlink data load balancing algorithm. Background Technology

[0002] Currently, drone swarm technology is widely used in emergency monitoring, military exercises, and urban air traffic control. To improve mission coordination and environmental perception accuracy, swarm sizes have gradually expanded from a dozen or so drones to dozens or even hundreds. During missions, a large number of drones continuously transmit multi-source data, including flight status, mission payload, and health management information, to ground control centers or backend servers. This data transmission typically uses a connectionless method based on the User Datagram Protocol (UDP), characterized by large data volumes, high burstiness, and high real-time requirements. Therefore, how to efficiently and reliably load balance and distribute drone swarm data on the backend server side has become a key issue in ensuring stable system operation.

[0003] In existing technologies, various load balancing strategies are widely used for internet services, such as load balancing solutions represented by Nginx and F5. Commonly used scheduling algorithms include round-robin, least connections, and static weight-based scheduling algorithms. These load balancing algorithms typically use the number of requests, the number of current connections, or pre-configured weights as the main decision-making criteria, and are suitable for relatively stable Hypertext Transfer Protocol (HTTP) request scenarios. However, in the scenario of data transmission from a drone swarm, the following differences and problems exist: (1) Data model does not match business characteristics Traditional load balancing algorithms are mostly geared towards short-connection or session-based requests, assuming relatively stable request size and arrival times. However, drone swarm data transmission typically occurs periodically or aperiodically in the form of UDP packets. When the swarm size exceeds a certain number (e.g., more than 20-50 drones), the transmitted data exhibits a clear "tidal burst" characteristic, with packet arrival rates significantly higher than average at certain moments within a short period. In this situation, allocating requests solely based on the number of connections or round-robin order can easily lead to a sharp increase in the instantaneous queue length of some backend nodes, resulting in a significant increase in data congestion rate and average forwarding latency. This affects real-time monitoring of flight status and mission execution, reducing system security and reliability.

[0004] (2) Lack of real-time awareness of the processing capabilities of microservice nodes With the increasing adoption of microservice architecture in UAV ground systems, the backend typically consists of several microservice nodes responsible for different functions. The hardware resources, current load, and processing capabilities of these nodes are dynamically changing. Existing solutions based on polling or least connections cannot reflect the actual processing latency and queuing status of each microservice node, leading to a situation where "busy nodes are busier, while idle nodes are idle." This makes it impossible to dynamically track the response status of microservices and to promptly redirect sudden bursts of data to faster-processing nodes.

[0005] (3) The expansion and contraction process relies on human intervention and is difficult to adapt to dynamic fluctuations. Existing load balancing solutions often require manual modification of configuration files, restarting of the load balancing service, or complex maintenance operations when scaling microservice nodes, resulting in long configuration activation cycles. Furthermore, they cannot automatically detect node status and quickly incorporate new nodes into the schedule when facing dynamic changes in drone swarm size and downlink data traffic, making it difficult to respond promptly to pressure changes caused by sudden business surges or node failures.

[0006] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0007] This invention provides a microservice-based drone cluster downlink data load balancing algorithm, a computer-readable storage medium, and a computer program product, which can effectively overcome the defects existing in the prior art.

[0008] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0009] According to a first aspect of the present invention, a microservice-based unmanned aerial vehicle (UAV) cluster downlink data load balancing algorithm is provided, the method comprising: According to the preset status monitoring cycle, status probe requests are sent to microservice nodes, and the average response time of microservice nodes is determined based on the request sending timestamp of the status probe request and the response receiving timestamp of the status probe response returned by the microservice node. Microservice nodes are filtered based on their average response time and a preset response time threshold to determine the effective set of microservice nodes; When receiving downlink data from the drone cluster, the target microservice node is selected from the set of effective microservice nodes based on the average response time of the effective microservice nodes in the set of effective microservice nodes, and the downlink data is forwarded to the target microservice node. Obtain the forwarding result of the target microservice node for the downlinked data, and dynamically update the set of valid microservice nodes based on the forwarding result.

[0010] In some exemplary embodiments, determining the average response time of a microservice node based on the request sending timestamp of the state probe request and the response receiving timestamp of the state probe response returned by the microservice node includes: Within a preset status monitoring period, multiple status probe requests are sent to each microservice node, and the timestamp of the request is recorded; and it is determined whether the microservice node responds to the status probe request within a preset response timeout threshold. If a status probe response is received from a microservice node within the preset response timeout threshold, the response reception timestamp is recorded, and the difference between the response reception timestamp and the corresponding request sending timestamp is used as the single response time. In addition, the corresponding status probe request is marked as a valid sample. If no status probe response is received from the microservice node within the preset response timeout threshold, the response reception timestamp will be determined as the preset response time threshold, and the corresponding status probe request will be marked as invalid sampling. The average response time of microservice nodes is determined based on valid and invalid sampling.

[0011] In some exemplary implementations, determining the average response time of a microservice node based on valid and invalid sampling includes: If the status probe requests within the preset status monitoring period contain valid samples, the average response time of each valid sample is calculated to determine the average response time of the microservice node. If all state probe requests within the preset state monitoring period are invalid samples, the average response time of the microservice node will be set to the preset response time threshold.

[0012] In some exemplary embodiments, the step of filtering microservice nodes based on their average response time and a preset response time threshold to obtain a set of effective microservice nodes includes: The average response time is compared with a preset response time threshold. Microservice nodes with an average response time less than a preset response time threshold are included in the set of effective microservice nodes.

[0013] In some exemplary embodiments, the step of selecting the target microservice node from the set of effective microservice nodes based on the average response time of the effective microservice nodes in the set of effective microservice nodes when receiving downlink data from the drone cluster includes: For each received downlink data, find the effective microservice node with the smallest average response time in the set of effective microservice nodes; When there is only one valid microservice node with the smallest average response time, the valid microservice node with the smallest average response time is directly selected as the target microservice node. When the average response time of multiple valid microservice nodes is minimized, a target microservice node is determined by random selection among the multiple valid microservice nodes.

[0014] In some exemplary embodiments, dynamically updating the set of valid microservice nodes based on forwarding results includes: When the forwarding result is successful, maintain the target microservice node in the set of valid microservice nodes; When the forwarding result fails, the target microservice node is removed from the set of valid microservice nodes, and the microservice nodes are selected again from the updated set of valid microservice nodes to forward the data.

[0015] In some exemplary embodiments, the method further includes: Based on the preset status monitoring cycle, the effective microservice nodes in the effective microservice node set are continuously monitored; If the average response time of a valid microservice node is the same as the preset response time threshold over multiple consecutive preset status monitoring periods, then the valid microservice node will be removed from the set of valid microservice nodes. When a removed microservice node recovers its response within a subsequent preset status monitoring period, and the average response time is less than a preset response time threshold, the removed microservice node will be added back to the set of valid microservice nodes.

[0016] In some exemplary embodiments, the method further includes: When the effective set of microservices is empty, the standby microservice node is activated.

[0017] According to a second aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the storage medium is located to execute the above-described microservice-based UAV swarm downlink data load balancing algorithm.

[0018] According to a third aspect of the present invention, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aforementioned microservice-based drone swarm downlink data load balancing algorithm.

[0019] According to a fourth aspect of the present invention, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to implement the aforementioned microservice-based drone cluster downlink data load balancing algorithm when executing the executable instructions.

[0020] The embodiments of this invention provide a microservice-based drone cluster downlink data load balancing algorithm. This algorithm achieves real-time perception of the processing capacity of microservice nodes and dynamic data distribution based on average response time by sending multiple rounds of status probe requests to each microservice node within a preset status monitoring period, calculating the average response time based on the request sending timestamp and response receiving timestamp, and constructing an effective set of microservice nodes accordingly. Furthermore, by utilizing a hot registration mechanism for microservice nodes and combining the average response time with the forwarding results of microservice nodes, effective microservice nodes are eliminated or restored. This enables rapid online access of new microservice nodes during system operation and automatic isolation and recovery of abnormal nodes. Ultimately, this achieves the goal of ensuring low blocking rate, low latency, and scalable processing capabilities for downlink data at a low cost in scenarios with a large number of drones. It solves the technical problems of existing load balancing schemes in scenarios with massive drone downlink data, such as inaccurate response time perception, reliance on manual intervention for scaling up and down, and long-term resource occupation by faulty nodes, which hinders the overall data flow.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 This schematically illustrates a flowchart of a microservice-based drone cluster downlink data load balancing algorithm, an exemplary embodiment of the present invention. Figure 2 This schematically illustrates a flow diagram of a drone cluster downlink data load balancing distribution algorithm based on microservices, as described in an exemplary embodiment of the present invention. Figure 3 This schematic diagram illustrates the calculation of the average response time of microservice nodes in a microservice-based drone cluster downlink data load balancing algorithm, an exemplary embodiment of the present invention. Figure 4 The diagram illustrates the composition of an electronic device according to an exemplary embodiment of the present invention. Detailed Implementation

[0024] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0025] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0026] In existing technologies, various load balancing strategies are widely used for internet services, such as load balancing solutions represented by Nginx and F5. Commonly used scheduling algorithms include round-robin and least connections algorithms. Details are as follows: (1) Round-robin algorithm (such as Nginx's default load balancing strategy) According to the official Nginx documentation, "Nginx Plus R29 Load Balancing Technology White Paper" (document number: NGINX-TECH-2024-001), this algorithm achieves load balancing by "distributing requests sequentially to microservices," without considering the real-time response status of microservices. When the number of drones exceeds 20, the data blocking rate is ≥75%, and the average forwarding latency is ≥9.2 seconds. Adding a new microservice node requires manual modification of the configuration file and restarting the service, with an adaptation period of ≥4 hours, making it unable to cope with the dynamic fluctuations of massive drone data.

[0027] (2) Least Connections Algorithm (e.g., F5 BIG-IP Commercial Load Balancer) Referring to F5's official BIG-IP LTM V17.1 technical specification, this algorithm uses "minimum number of current microservice connections" as its decision-making criterion, but it does not update the microservice response time in real time. When a microservice experiences response delays due to high CPU usage (but the number of connections has not reached the limit), it continues to allocate data, leading to data accumulation. Real-world testing shows that with 30 drones transmitting data, the algorithm's data processing latency is ≥8 seconds, the monthly failure rate is ≥10.5%, and the equipment deployment cost exceeds 150,000 yuan (not suitable for small to medium budget scenarios).

[0028] (3) Open source microservice load balancing algorithm A GitHub repository has released the "V4.1.0 User Guide" for Spring Cloud LoadBalancer, a utility library used for client-side load balancing across multiple service instances within the Spring Cloud ecosystem (the open-source implementation can be found at https: / / github.com / spring-cloud / spring-cloud-commons). The guide clarifies that this open-source microservice load balancing algorithm relies on "periodic state synchronization with the service registry" (synchronization period ≥ 10 seconds). This method cannot detect changes in microservice response in real time. When drone data experiences a sudden surge (e.g., data volume exceeding 100MB per second), the synchronization delay leads to an "optimal node misjudgment rate" ≥ 30%, potentially causing some microservices to overload and crash.

[0029] To address the shortcomings and deficiencies of existing technologies, this example implementation provides a microservice-based drone swarm data downlink load balancing algorithm. (Reference) Figure 1 As shown, the executing entity is a load balancer, which can specifically include: Step S10: Send a status probe request to the microservice node according to the preset status monitoring cycle, and determine the average response time of the microservice node based on the request sending timestamp of the status probe request and the response receiving timestamp of the status probe response returned by the microservice node. Step S12: Filter microservice nodes based on their average response time and a preset response time threshold to determine the set of valid microservice nodes; Step S14: When receiving downlink data from the drone cluster, select the target microservice node from the set of effective microservice nodes based on the average response time of the effective microservice nodes in the set of effective microservice nodes, and forward the downlink data to the target microservice node. Step S16: Obtain the forwarding result of the target microservice node for the downlinked data, and dynamically update the set of valid microservice nodes based on the forwarding result.

[0030] Based on steps S10 to S16 above, by sending multiple rounds of status probe requests to each microservice node within a preset status monitoring period, calculating the average response time based on the request sending timestamp and response receiving timestamp, and constructing an effective set of microservice nodes accordingly, real-time perception of the processing capacity of microservice nodes and dynamic data distribution optimized based on the average response time are achieved. On this basis, effective microservice nodes are eliminated or restored by combining the average response time and the forwarding results of microservice nodes, realizing automatic isolation and recovery of abnormal nodes. This achieves the goal of ensuring low blocking rate, low latency, and scalable processing capacity of downlink data at a low cost in scenarios with a large number of drones. It solves the technical problems of inaccurate response time perception, reliance on manual intervention for scaling up and down, and long-term resource occupation by faulty nodes in scenarios with massive drone downlink data in existing load balancing solutions.

[0031] The following will describe in more detail each step of a microservice-based drone cluster downlink data load balancing algorithm in this example embodiment, with reference to the accompanying drawings and embodiments.

[0032] For example, refer to Figure 2 As shown. Figure 2 The unmanned aerial vehicle (UAV) cluster UDP data load balancing distribution process provided in this embodiment of the invention includes a UAV cluster ①, a load balancer processing ②, and a microservice node cluster ③.

[0033] ① in the diagram represents a drone swarm, consisting of multiple drones ( Each UAV periodically or as needed sends downlink data such as flight status and mission payload to the ground terminal in the form of UDP data streams. As the source of UDP downlink data, it connects to the load balancer via UDP data streams.

[0034] ② in the diagram represents the load balancer processing flow, which includes a data receiving module, an optimal node decision module, and a data forwarding module. The data receiving module receives UDP downlink data from the drone cluster; the optimal node decision module is based on a pre-maintained average response time dictionary. The average response time of each microservice node is compared to select the optimal target microservice node; the data forwarding module then forwards the received UDP data to the selected target microservice node.

[0035] In the diagram, ③ represents a microservice node cluster consisting of multiple microservice nodes, each of which... Each corresponds to an average response time This characterizes the processing capacity of the node within the current monitoring period. Each node is labeled with "". This is used to display the average response time in real time. The load balancer calculates the response time based on the performance of each microservice node. The system dynamically distributes UDP downlink data from the drone swarm to target microservice nodes, achieving load balancing of downlink data from the drone swarm. Furthermore, the microservice swarm feeds back the data reception status (success / failure) to the load balancer.

[0036] For example, in step S10, determining the average response time of a microservice node based on the request sending timestamp of the state probe request and the response receiving timestamp of the state probe response returned by the microservice node includes: Step S101: Within the preset status monitoring period, send multiple status probe requests to each microservice node, record the request sending timestamp, and determine whether the microservice node responds to the status probe request within the preset response timeout threshold. In step S101, the aforementioned preset state monitoring period This is used to characterize the time interval between two consecutive state updates of microservice nodes by the load balancer. For example, setting a preset state monitoring period. .

[0037] The above-mentioned preset response timeout threshold This is used to characterize the maximum time waiting for a microservice response. For example, setting a preset response timeout threshold. .

[0038] Step S102: If a status probe response is received from a microservice node within the preset response timeout threshold, record the response reception timestamp, and use the difference between the response reception timestamp and the corresponding request sending timestamp as the single response time, and mark the corresponding status probe request as a valid sample. In step S102, the above-mentioned single response time A timestamp used to characterize the request sent by the load balancer to issue a status probe request. , and received the The response timestamp of the status probe response returned by each microservice node The time difference between them, that is .

[0039] Step S103: If no status probe response is received from the microservice node within the preset response timeout threshold, the response reception timestamp is determined as the preset response time threshold, and the corresponding status probe request is marked as invalid sampling. Step S104: Determine the average response time of the microservice node based on valid and invalid sampling.

[0040] Specifically, based on the request sending timestamp of the state probe request and the response receiving timestamp of the state probe response returned by the microservice node, the average response time of the microservice node is determined and used to update the state of the microservice node in real time.

[0041] This process is initiated proactively by the load balancer, each It executes once per second, and its core function is to calculate and update the average response time of all microservices. The steps are as follows: (1) Initialization configuration: The load balancer reads the XML configuration file. For example, the configuration file path is: . / config / loadbalance_config.xml. It retrieves the preset status monitoring period from the configuration file. Preset response timeout threshold Initial registration information for microservice nodes (e.g., service ID, IP address, port), initializing the microservice node set. and average response time dictionary (Initial value set to) ).in, This is used to characterize the mapping relationship where the microservice node identifier is the key and the average response time of the corresponding microservice node is the value. It is used to record and update the average response time of each microservice node within the current status monitoring period, providing a basis for subsequent screening of effective microservice nodes and selection of target microservice nodes.

[0042] (2) Periodic trigger judgment: The load balancer uses a timer to determine whether the difference between the current time and the last monitoring time is ≥ T. If not, it waits; if so, it enters the multi-round request sending and response collection phase.

[0043] (3) Multi-round request sending and response collection: For each microservice Load balancer in Internal Send Each "state probe request" (e.g., a request packet size of 128 bytes, including the request sending timestamp) records the request sending timestamp for each state probe request. (k is the k-th state probe request sent) and response reception timestamp If the load balancer is in If a status probe response is received from a microservice node, the single response time is calculated. And mark the corresponding status probe request as a valid sample; if the load balancer is in If no status probe response is received from the microservice node, set the response reception timestamp as the preset response time threshold. = And mark the corresponding state probe request as invalid sampling.

[0044] Based on steps S101 to S104 above, by combining effective and invalid sampling within a preset status monitoring period, the average response time of each microservice node can be accurately obtained, thereby truly reflecting the actual processing capacity of the microservice node and providing a reliable basis for subsequent microservice node selection and load balancing decisions.

[0045] For example, in step S104, determining the average response time of the microservice node based on valid and invalid samples includes: Step S201: If the status detection request within the preset status monitoring period contains valid samples, the average response time of the single response corresponding to the valid samples is calculated to determine the average response time of the microservice node. Step S202: If all state probe requests within the preset state monitoring period are invalid samples, set the average response time of the microservice node to the preset response time threshold.

[0046] Specifically, if all state probe requests within the preset state monitoring period are invalid samples, the average response time of the microservice node is set to a preset response time threshold, i.e. = ; If the status probe requests within the preset status monitoring period contain both valid and invalid samples, then the portion of the single response time is discarded. The value is calculated by averaging the single response time corresponding to the valid samples. The specific calculation process is shown in the following formula:

[0047] in, For the first Average response time of each microservice node; For the load balancer to perform a preset status monitoring cycle The number of state probe requests initiated internally; For indicator functions, when hour, ,otherwise .

[0048] Furthermore, the calculated Update to average response time dictionary .

[0049] For details, please refer to Figure 3 As shown. Figure 3This diagram illustrates the process of calculating the average response time of microservice nodes. The process mainly includes the average response time calculation process on the left and the microservice node cluster on the right.

[0050] In the process flow on the left, module A is the "initialization" step, where the load balancer reads the preset monitoring period. Response timeout threshold and microservice node set Configure parameters such as microservice node registration and initial parameter settings; Module B is the "Periodic Monitoring" step, where the load balancer uses a timer to monitor according to the specified period. Triggered, a status probe request is periodically sent to each registered microservice node, and multiple probe requests are sent to each microservice node within each period to collect subsequent response times; Module C is the "Response Processing" step. The load balancer receives the status probe responses returned by each microservice node and calculates the single response time based on the sending time of the status probe request and the response reception time of the status probe responses returned by the microservice nodes. Based on this, the average response time of each microservice node is calculated. ; Module D is the "state update" step, where the load balancer updates the state based on the calculated values. Update the average response time dictionary And update the set of valid microservice nodes accordingly. This is used for subsequent load balancing decisions.

[0051] In the diagram, ③ on the right represents a microservice node cluster, which includes multiple microservice nodes. Each microservice node corresponds to an average response time. This is used to characterize the processing capacity of the microservice node within the current monitoring period. Figure 2 The process shown enables periodic monitoring and updating of the response time of each microservice node, providing basic support for dynamic load balancing of data transmitted by the drone swarm.

[0052] Based on the above steps S201 to S202, a unique and comparable average response time can be given for each microservice node, taking into account both normal response and timeout failure scenarios. This serves to uniformly characterize the processing capabilities of each microservice node and provides a reliable basis for subsequent effective microservice node selection and load balancing decisions.

[0053] For example, in step S12, the process of filtering microservice nodes based on their average response time and a preset response time threshold to obtain a set of valid microservice nodes includes: Step S121: Compare the average response time with the preset response time threshold; Step S122: Include microservice nodes with an average response time less than a preset response time threshold into the set of valid microservice nodes.

[0054] Specifically, microservice nodes with an average response time less than a preset response time threshold are included in the set of effective microservice nodes. < .if If empty, an alarm will be triggered and a backup microservice node will be enabled.

[0055] Based on the above steps S121 to S122, microservice nodes with degraded processing performance or timeouts can be automatically eliminated under the response time threshold constraint, and an effective set of microservice nodes consisting only of microservice nodes that meet the latency requirements can be constructed. This provides a reliable node foundation for the selection of target microservice nodes and load balancing distribution of subsequent data transmission, thereby improving the overall real-time performance and reliability of the system.

[0056] For example, in step S14, when receiving downlink data from the drone cluster, selecting the target microservice node from the set of valid microservice nodes based on the average response time of the valid microservice nodes in the set of valid microservice nodes includes: Step S141: For each received downlink data, obtain the effective microservice node with the smallest average response time in the set of effective microservice nodes; Step S142: When there is only one effective microservice node with the smallest average response time, the effective microservice node with the smallest average response time is directly selected as the target microservice node. Step S143: When the average response time of multiple valid microservice nodes is the minimum, a random selection is made among the multiple valid microservice nodes to determine the target microservice node.

[0057] Specifically, this process is executed in real time when the data transmitted from the drone arrives, and the core is from... The system selects the effective microservice nodes with the shortest average response time to achieve efficient data forwarding.

[0058] The load balancer receives the data stream D transmitted from the drone via a bound UDP port (default port: 50000), and parses metadata such as "drone ID," "data type," and "data length" from the data. The microservice node with the shortest average response time is selected as the target microservice node for data forwarding. .

[0059] When there is only one valid microservice node with the smallest average response time, the valid microservice node with the smallest average response time is directly selected as the target microservice node. When the average response time of multiple valid microservice nodes is the shortest, a target microservice node is determined by randomly selecting one to break the tie and avoid overloading a single node.

[0060] The load balancer calls the Boost.Asio async_send_to() interface to forward data D to... The IP address and port number are recorded, along with the "forwarding time". Information such as "target microservice node ID" and "data length" is written to a log file. For example, the path to the log file could be . / log / forward.log.

[0061] Based on steps S141 to S143 above, when each piece of downlink data arrives, the microservice node with the shortest average response time can be selected as the processing target first, and when there are multiple equally optimal nodes, the data can be distributed by random selection. This not only meets the real-time requirements but also avoids overloading of a single node, thus achieving balanced and efficient distribution of downlink data from the drone cluster.

[0062] For example, in step S16, dynamically updating the set of valid microservice nodes based on the forwarding results includes: Step S161: When the forwarding result is successful, maintain the target microservice node in the valid microservice node set. Step S162: When the forwarding result fails, the target microservice node is removed from the set of valid microservice nodes, and microservice nodes are selected again from the updated set of valid microservice nodes to forward the data.

[0063] Specifically, if the target microservice node successfully forwards the downlink data to the corresponding business processing module, the data forwarding process ends, and the target microservice node remains valid within the set of effective microservice nodes. If the target microservice node fails to forward the downlink data to the corresponding business processing module (e.g., ...), ... If suddenly offline, then immediately from The data is removed from the list and new target microservice nodes are selected for forwarding to ensure no data loss. For example, the bytes_transferred callback is used to confirm whether the target microservice node has successfully forwarded the downlink data to the corresponding business processing module.

[0064] Based on the above steps S161 to S162, the effective set of microservice nodes can be adjusted in real time under the drive of the actual forwarding result of the downlink data, timely remove microservice nodes with forwarding abnormalities and reselect available nodes to complete data forwarding, thereby avoiding faulty nodes from continuously occupying requests and reducing system availability, and ensuring the stability and reliability of the downlink data forwarding process of the UAV cluster.

[0065] For example, the method further includes: Step S301: Continuously monitor the valid microservice nodes in the set of valid microservice nodes according to the preset status monitoring cycle; Step S302: If the average response time of the effective microservice node is the preset response time threshold in multiple consecutive preset status monitoring periods, then the effective microservice node will be removed from the set of effective microservice nodes. Step S303: When the removed microservice node recovers its response within the subsequent preset status monitoring period and the average response time is less than the preset response time threshold, the removed microservice node is added back to the set of valid microservice nodes.

[0066] Specifically, a fault isolation mechanism is set up to enable dynamic admission and exit management of microservice nodes.

[0067] Based on a preset status monitoring cycle, continuous monitoring is performed on the valid microservice nodes in the set of valid microservice nodes. For a single microservice node... If multiple preset state monitoring cycles are consecutive They will be automatically removed. Once it recovers its response, rejoin. This prevents faulty nodes from affecting the overall data flow. For example, a single microservice Continuously within 2 preset status monitoring cycles They will be automatically removed. If it recovers its response within the subsequent preset status monitoring cycle, and, < Then add it back. This is to prevent faulty nodes from affecting the overall data flow.

[0068] Furthermore, the load balancer sends each status probe request to every microservice node in the microservice set S. It then filters the set of valid microservice nodes from the microservice set S. For those not included in the effective set of microservice nodes The microservice nodes will be continuously monitored, and when they recover their response, and... < The load balancer adds it in real time. It also initiates response monitoring without requiring a restart of core services, with an adaptation period of ≤1 hour.

[0069] Furthermore, microservice nodes support "hot registration." When a new microservice node starts, it can proactively report information (service ID, IP, port, etc.) to the load balancer via an HTTP request, and the load balancer will add it in real time. S It also initiates response monitoring without requiring a restart of core services, with an adaptation period of ≤1 hour.

[0070] Based on the above steps S301 to S303, the status of effective microservice nodes can be continuously tracked within a preset status monitoring period. Microservice nodes with long-term deterioration in average response time can be automatically removed and re-included into the set of effective microservice nodes through a hot registration mechanism after their performance recovers. This enables dynamic admission and exit management of microservice nodes, ensuring that the microservice nodes participating in load balancing are always in a stable and available state.

[0071] For example, the method further includes: Step S401: When the effective microservice set is empty, enable the standby microservice node.

[0072] Specifically, when the load balancer detects that there are no available microservice nodes in the set of valid microservice nodes, it triggers the standby takeover process. It selects one or more standby microservice nodes from the pre-configured standby microservice node list, adds the standby microservice nodes to the microservice node set, and uses them as new valid microservice nodes to participate in subsequent data forwarding. In this process, status monitoring and average response time monitoring are also performed on the enabled standby microservice nodes to ensure that even if the original microservice nodes fail or all of them fail, the drone cluster data can still be received and processed through the standby microservice nodes, thus avoiding business interruption.

[0073] Based on the above step S401, backup microservice nodes can be activated in a timely manner in the abnormal situation where the effective microservice node set is temporarily empty, avoiding situations where the drone cluster data cannot be forwarded for a long time or is lost on a large scale, thereby ensuring the business continuity and reliability of the system under extreme conditions.

[0074] Specifically, according to the method provided in the embodiments of the present invention, a specific implementation method is provided, and the specific implementation process is as follows: 1. Implementation Scenario: Regional emergency monitoring scenario with 50 medium and large-sized UAVs. Fifty drones simultaneously transmit flight status data (20 data points per drone per second, 128 bytes per data point) and mission payload data (10 data points per drone per second, 512 bytes per data point). The ground control terminal needs to process the data through a microservice cluster (8 microservice nodes) to ensure that emergency monitoring data is transmitted back in real time.

[0075] 2. Test environment parameters (1) Hardware environment - CPU: Intel Xeon W-1370P (8 cores, 16 threads, base frequency 3.6GHz, maximum turbo frequency 5.2GHz). - Memory: 32GB DDR4-3200 (dual channel, timings 16-18-18-36); -Hard drive: 1TB NVMe SSD (read speed 3800MB / s, write speed 3200MB / s); - Network card: Intel Ethernet Controller I225-V (Gigabit wired network card, link speed 1000Mbps, latency ≤0.8ms); - Drones: 50 medium and large drones of a certain type (maximum UDP download rate 50Mbps / drone).

[0076] (2) Software environment - Operating system: Ubuntu 22.04 LTS (kernel version 5.15.0-78-generic, firewall disabled); - Development languages ​​and libraries: C++17, Boost.Asio 1.82.0 (UDP communication), RapidXML 1.13 (XML parsing); - Compiler: GCC 11.4.0 (Compilation parameters: -std=c++17 -O3 -lpthread, generates Release version executable file, size 4.2MB); - Monitoring tools: Wireshark (network packet loss rate monitoring), htop (CPU / memory usage monitoring).

[0077] (3) Network environment - Network topology: The drone swarm is connected to the local area network via a gigabit wireless AP (Huawei AP7060DN), and the load balancer is connected to the microservice cluster via a gigabit switch; -UDP parameters: Time to Live (TTL) = 64, maximum packet length 1472B, no checksum (to meet the real-time data requirements of drones). - Interference control: During the test, other wireless devices were turned off, and Wireshark monitored a network packet loss rate of ≤0.1%.

[0078] 3. Implementation Steps Step 1: System Initialization (1) Load the configuration file ". / config / loadbalance_config.xml" with the following configuration parameters: - Monitoring cycle Timeout threshold ; - Initial registration of the microservice cluster includes 8 microservice nodes ( IP range 192.168.1.101-192.168.1.108, UDP ports 60010-60017; - The load balancer is bound to UDP receive port 50000, and the log path is ". / log / forward.log".

[0079] (2) The load balancer starts the "response time monitoring thread" and the "data receiving thread", and sets the thread priority to "real-time priority" (to avoid system scheduling delay).

[0080] Step 2: Microservice response time monitoring (1) Periodic triggering: Every 5 seconds, the load balancer sends to Each sends 3 "state probe requests" (the request includes a timestamp of the sending). ); (2) Response Acquisition: Example: In the three samplings,

[0081] =1698765432.123s, =1698765432.245s, =122ms; =1698765433.124s, =1698765433.242s, =118ms; =1698765434.125s, =1698765434.247s, =122ms; -calculate Average response time: =(122+118+122) / 3=120.67ms, which is rounded to 121ms; (3) Status update: ~ Write ,filter ={ (All satisfy) <1000ms).

[0082] Step 3: Drone UDP Data Distribution (1) Data reception: The load balancer receives downlink data from 50 drones through port 50000. The metadata of example data D is "droneId=23, dataType=task payload, length=512B". (2) Target microservice node filtering: query Assuming =105ms (minimum), then = (IP: 192.168.1.103, port 60012); (3) Data forwarding: Call async_send_to() to forward D to The callback confirms "512B data sent successfully" and records the following log: [2025-11-03 14:30:00] Forward to S_3 (192.168.1.103:60012),droneId=23, dataType=task payload, length=512B.

[0083] Step 4: Fault Simulation and Recovery (1) Fault simulation: Terminate by killing command The process was rendered unable to respond to probe requests; (2) Status update: Next monitoring cycle (after 5 seconds), All three sampling attempts timed out. =1000ms, was removed ; (3) Data redistribution: When the load balancer receives drone data, it automatically selects new target microservice nodes. ( =110ms), no data was lost during forwarding; (4) Fault recovery: Restart It actively registers with the load balancer and will be available in the next monitoring cycle. Rejoin .

[0084] 4. Test Results The test lasted 24 hours, with performance data sampled every 10 seconds, resulting in 8640 sets of data. The results are as follows: (1) Average data forwarding latency: 1.8 seconds (maximum 2.3 seconds, minimum 1.5 seconds, standard deviation 0.3 seconds), an improvement of 80.4% compared to Nginx polling (9.2 seconds); (2) Data blocking rate: 0.8% (only a brief blocking occurs during sudden peaks in UAV data, lasting ≤0.5 seconds); (3) System resource usage: CPU average utilization rate 32% (peak 48%), memory usage stable at 1.5GB-2.0GB; (4) Fault recovery time: The average recovery time after a microservice failure is 45 seconds (including monitoring period + hot registration time). (5) New node adaptation: Adding 2 microservice nodes takes only 38 minutes from registration to participation in data distribution, without needing to restart the load balancer.

[0085] Test results show that, in a scenario with massive data from 50 drones, this algorithm fully meets the real-time, stability, and scalability requirements of regional emergency monitoring, and its performance is significantly better than existing technologies.

[0086] Furthermore, the invention underwent a month of field testing. The test results are shown in Table 1. Table 1 also provides a comparison of the core performance indicators of the invention with existing solutions. As can be seen from Table 1, the microservice-based drone cluster downlink data load balancing algorithm provided by the invention, characterized by high real-time performance, high scalability, and low blocking rate, solves the problems of uneven load distribution, excessive latency, and rigid adaptation in existing solutions (such as Nginx round-robin and F5 minimum connection count) under massive drone scenarios. Compared with existing solutions, the invention has the following significant advantages: (1) Supports simultaneous UDP data transmission from 50 or more medium to large-sized UAVs with a data blocking rate of ≤1%; (2) The average data forwarding delay is ≤2 seconds, which meets the real-time requirements of the UAV scenario; (3) The adaptation period for newly added microservice nodes is ≤1 hour, and there is no need to restart the core service; (4) Monthly failure rate ≤ 4%, and failure of a single microservice does not affect the overall data flow.

[0087] Table 1 Comparison of Core Performance Indicators

[0088] The beneficial effects of this invention are as follows: (1) Improve the accuracy of response time perception and reduce sampling error in UDP scenarios. By implementing an average response time calculation mechanism of "multi-round status probe requests + timeout removal" for each microservice node within a preset status monitoring period, this invention can accurately reflect the actual processing capacity of each microservice node under the "high burst, connectionless" transmission characteristics of UAV downlink data. This avoids the response time statistical errors generated by traditional single sampling or simple monitoring schemes in UDP scenarios, thereby providing a more reliable latency basis for subsequent load balancing decisions.

[0089] (2) Achieve integrated dynamic load balancing and node management driven by response time. This invention organically combines target node selection based on average response time with microservice node hot registration, fault removal, and recovery mechanisms: on the one hand, it selects target microservice nodes based on average response time to ensure that downlink data is preferentially distributed to nodes with better processing capabilities; on the other hand, through hot registration, newly added microservice nodes can automatically access and participate in monitoring and scheduling during system operation, while combining average response time and downlink data forwarding results to automatically isolate and recover abnormal microservice nodes, thereby achieving a synergistic improvement in data distribution optimization, expansion costs, and system stability.

[0090] (3) Achieve low-cost, low-latency and fast-adaptive load balancing in medium-sized UAV swarm scenarios. For scenarios involving data transmission from a cluster of approximately 50 drones, this invention, based on a microservice cluster deployment, achieves low-cost deployment (approximately 80,000 RMB / 50 drones), low average forwarding latency (approximately 1.8 seconds), and short node adaptation cycle (approximately 45 minutes) through response time awareness and dynamic node management mechanisms. This effectively supports the real-time data processing needs of medium-sized drone clusters and fills the application gap between existing technologies that address "small-scale without load balancing" and "ultra-large-scale high-cost architecture."

[0091] It should be noted that the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is readily understood that these processes may, for example, be executed synchronously or asynchronously in multiple modules.

[0092] It should be noted that although several modules or units of the device for performing actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0093] Figure 4 A schematic diagram of an electronic device suitable for implementing embodiments of the present invention is shown.

[0094] It should be noted that, Figure 4 The illustrated electronic device 1000 is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0095] like Figure 4 As shown, the electronic device 1000 includes a Central Processing Unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1002 or programs loaded from storage section 1008 into Random Access Memory (RAM) 1003. The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An Input / Output (I / O) interface 1005 is also connected to the bus 1004. Furthermore, the electronic device 1000 also includes an FPGA device and a System-on-a-Chip (SoC) device.

[0096] The following components are connected to I / O interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to I / O interface 1005 as needed. Removable media 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1010 as needed so that computer programs read from them can be installed into storage section 1008 as needed.

[0097] In particular, according to embodiments of the present invention, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit (CPU) 1001, it performs various functions defined in the system of this application.

[0098] Specifically, the aforementioned electronic devices can be airborne intelligent electronic devices.

[0099] It should be noted that the storage medium shown in the embodiments of the present invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In the present invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, wherein computer-readable program code is carried. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0100] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0101] The units described in the embodiments of the present invention can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0102] It should be noted that, as another aspect, this application also provides a storage medium, which may be included in an electronic device or may exist independently without being assembled into the electronic device. The aforementioned storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the methods described in the following embodiments. For example, the electronic device may perform... Figure 1 The steps of the method shown.

[0103] In one embodiment, this application provides a computer program product including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0104] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0105] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0106] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A microservice-based unmanned aerial vehicle (UAV) swarm data downlink load balancing algorithm, characterized in that, The method includes: According to the preset status monitoring cycle, status probe requests are sent to microservice nodes, and the average response time of microservice nodes is determined based on the request sending timestamp of the status probe request and the response receiving timestamp of the status probe response returned by the microservice node. Microservice nodes are filtered based on their average response time and a preset response time threshold to determine the effective set of microservice nodes; When receiving downlink data from the drone cluster, the target microservice node is selected from the set of effective microservice nodes based on the average response time of the effective microservice nodes in the set of effective microservice nodes, and the downlink data is forwarded to the target microservice node. Obtain the forwarding result of the target microservice node for the downlinked data, and dynamically update the set of valid microservice nodes based on the forwarding result.

2. The method according to claim 1, characterized in that, The average response time of a microservice node is determined based on the request sending timestamp of the state probe request and the response receiving timestamp of the state probe response returned by the microservice node, including: Within a preset status monitoring period, multiple status probe requests are sent to each microservice node, and the timestamp of the request is recorded; and it is determined whether the microservice node responds to the status probe request within a preset response timeout threshold. If a status probe response is received from a microservice node within the preset response timeout threshold, the response reception timestamp is recorded, and the difference between the response reception timestamp and the corresponding request sending timestamp is used as the single response time. In addition, the corresponding status probe request is marked as a valid sample. If no status probe response is received from the microservice node within the preset response timeout threshold, the response reception timestamp will be determined as the preset response time threshold, and the corresponding status probe request will be marked as invalid sampling. The average response time of microservice nodes is determined based on valid and invalid sampling.

3. The method according to claim 2, characterized in that, The determination of the average response time of microservice nodes based on effective and invalid sampling includes: If the status probe requests within the preset status monitoring period contain valid samples, the average response time of each valid sample is calculated to determine the average response time of the microservice node. If all state probe requests within the preset state monitoring period are invalid samples, the average response time of the microservice node will be set to the preset response time threshold.

4. The method according to claim 1, characterized in that, The process of filtering microservice nodes based on their average response time and a preset response time threshold to obtain a set of effective microservice nodes includes: The average response time is compared with a preset response time threshold. Microservice nodes with an average response time less than a preset response time threshold are included in the set of effective microservice nodes.

5. The method according to claim 1, characterized in that, Upon receiving downlink data from the drone cluster, the process of selecting target microservice nodes from the set of effective microservice nodes based on the average response time of the effective microservice nodes includes: For each received downlink data, find the effective microservice node with the smallest average response time in the set of effective microservice nodes; When there is only one valid microservice node with the smallest average response time, the valid microservice node with the smallest average response time is directly selected as the target microservice node. When the average response time of multiple valid microservice nodes is minimized, a target microservice node is determined by random selection among the multiple valid microservice nodes.

6. The method according to claim 1, characterized in that, The dynamic updating of the effective microservice node set based on forwarding results includes: When the forwarding result is successful, maintain the target microservice node in the set of valid microservice nodes; When the forwarding result fails, the target microservice node is removed from the set of valid microservice nodes, and the microservice nodes are selected again from the updated set of valid microservice nodes to forward the data.

7. The method according to claim 1, characterized in that, The method further includes: Based on the preset status monitoring cycle, the effective microservice nodes in the effective microservice node set are continuously monitored; If the average response time of a valid microservice node is the same as the preset response time threshold over multiple consecutive preset status monitoring periods, then the valid microservice node will be removed from the set of valid microservice nodes. When a removed microservice node recovers its response within a subsequent preset status monitoring period, and the average response time is less than a preset response time threshold, the removed microservice node will be added back to the set of valid microservice nodes.

8. The method according to claim 1, characterized in that, The method further includes: When the effective set of microservices is empty, the standby microservice node is activated.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 8.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 8.

Images