Sounding data center management method, system and device and storage medium

Abstract

The invention discloses a sounding data center management method, system and device and a storage medium. The method comprises the following steps: receiving a health state of a respective processing node monitored by each service probe in real time through a management node, and periodically calculating a health score of each processing node; when a transmission party requests to access, the management node preferentially allocates a current access request to a processing node of which the health score meets a first constraint condition to execute the following steps: based on the access request, selecting an authentication server meeting a second constraint condition from the distributed authentication servers to perform equipment authentication and equipment registration on the transmission party; filtering the equipment of the transmission amplifier according to a built-in data counter; performing data analysis and partition storage on the received sounding data; and distributing the analyzed sounding data to different back-end services according to a set routing rule. According to the invention, the sounding data full life cycle management is realized, the sounding data transmission rate is improved, the authentication pressure is effectively dispersed, and the authentication and management cost is reduced.

Description

Technical Field

[0001] This application relates to the field of meteorological radiosonde technology, specifically to the technical fields of radiosonde data central service cluster and full life cycle management, and particularly to a radiosonde data central management method, system, equipment and storage medium. Background Technology

[0002] In the field of upper-air meteorological monitoring, radiosonde data serves as the core foundational data for weather forecasting, climate research, and disaster early warning. The performance and reliability of its processing system directly determine the accuracy and timeliness of meteorological services. With the large-scale construction of a nationwide network of upper-air meteorological monitoring radiosonde equipment, and the expansion of cross-domain application needs such as environmental monitoring data acquisition and aerospace data transmission, radiosonde data processing systems must achieve centralized management, efficient transmission, and stable distribution of massive amounts of radiosonde data. However, existing radiosonde data processing systems, under the conditions of business expansion and high concurrency scenarios, have gradually exposed multi-dimensional technical deficiencies, making it difficult to adapt to the operational needs of a nationwide monitoring network.

[0003] Current mainstream radiosonde data processing systems generally adopt an architecture of "traditional message queues + relational databases". Specifically, the system uses traditional message queues (such as RabbitMQ) to establish a data transmission channel between radiosonde equipment distributed across the country and the data center. This transmits radiosonde data, such as temperature, air pressure, and humidity, collected by the equipment to the data center in real time, where a relational database (such as MySQL) handles data storage and subsequent retrieval. This architecture was initially used in small- to medium-sized radiosonde networks to support basic radiosonde data processing needs and has gradually extended to scenarios such as environmental monitoring data acquisition systems and aerospace data transmission platforms, undertaking the core functions of centralized data management and distribution.

[0004] As the number of sounding devices has increased from thousands to tens of thousands, and the data volume continues to expand with business growth, the technical bottlenecks of the existing system have become fully apparent, specifically in the following aspects: 1. High data transmission latency, resulting in significant performance bottlenecks. The existing system relies on a traditional message queue model that uses a blocking I / O model. When the number of devices connected increases, the data transmission link is prone to blockage. When the number of connected devices reaches tens of thousands, the data transmission latency will soar from milliseconds to seconds, which is completely unable to meet the real-time requirement of "millisecond response" for upper-air meteorological monitoring. Excessive latency will lead to a decrease in the timeliness of meteorological data, directly affecting the accuracy of short-term weather forecasts, and even delaying the warning of extreme weather.

[0005] 2. Decentralized and inefficient equipment management, resulting in an imbalance between security and maintenance costs. The existing system lacks a unified device registration and verification mechanism, requiring each device to register individually upon connection, which can easily lead to registration congestion. Furthermore, device authentication relies solely on a "username / password" method, resulting in low security and vulnerability to identity forgery and unauthorized access. Adding a separate authentication server to improve security would require additional hardware costs and maintenance resources, significantly increasing device management costs and creating a dilemma between security and cost.

[0006] The existing radiosonde data processing system's architectural shortcomings can no longer meet the core requirements of a nationwide network of upper-air meteorological monitoring radiosonde equipment for "low latency, high availability, high scalability, strong security, and low cost." Therefore, it is necessary to design a completely new radiosonde data processing system architecture to overcome existing technological bottlenecks and provide stable and efficient data processing support for scenarios such as upper-air meteorological monitoring, environmental monitoring, and aerospace data transmission. Summary of the Invention

[0007] This application provides a method, system, device, and storage medium for managing radiosonde data hubs, in order to solve the problems of high latency, significant performance bottlenecks, and inefficient, decentralized device management, as well as the imbalance between authentication security and maintenance costs in existing radiosonde data transmission.

[0008] The technical solution is as follows: Firstly, a method for managing radiosonde data hubs is provided, applied to a service cluster containing multiple hub service nodes; the multiple hub service nodes are defined as at least one management node and multiple processing nodes, and each processing node is deployed with a business probe; the service cluster is used to implement full lifecycle management of radiosonde data; the method includes: The at least one management node receives in real time the health status information of each processing node monitored by each service probe, and periodically calculates the health score of each processing node based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of the processing node; When a transmitter of radiosonde data requests access, the at least one management node will preferentially allocate the current access request to a processing node whose health score meets the first constraint condition; the transmitter includes: a satellite navigation radiosonde integrated processor and / or a cloud integrated processor; For each processing node that assigns an access request, the following data processing operations are performed: Device authentication and registration: Based on the access request, select an authentication server from the distributed authentication servers that currently meets the second constraint to authenticate the device of the transmission party of the access request, and complete the device registration of the transmission party after successful authentication; Device filtering: After device registration is completed, the device receives the radiosonde data sent by the transmitter and determines whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, the transmitter is disabled; otherwise, the device continues to receive radiosonde data. Data parsing and storage: The received radiosonde data is parsed, and based on the subscription requirements of the backend service, the parsed radiosonde data is partitioned and stored according to the radiosonde number and / or the radiosonde station number. Data distribution: An event bus is used as the internal message bus, and a high-performance remote procedure call protocol is used as the external service protocol to distribute the parsed radiosonde data to different backend services according to the set routing rules.

[0009] In one possible implementation, the first constraint is: the health score of the processing node is greater than a first threshold, and the computing resources, network resources, and business resources are all within their respective normal ranges.

[0010] In one possible implementation, during the data processing operation performed by the processing node that allocates the access request, the method further includes: The at least one management node provides an early warning to processing nodes whose health scores are less than the second threshold; and / or; When at least one management node detects that the health score of a processing node performing data processing operations is decreasing and falling below a third threshold, it switches the access request being processed from the processing node performing the data processing operations to the processing node with the highest current health score.

[0011] In one possible implementation, the access request carries the device identifier of the transmitting party and the estimated data volume; and each transmitting party is pre-allocated a corresponding set of candidate authentication servers; then, based on the access request, an authentication server that currently meets the second constraint condition is selected from the distributed authentication servers to perform device authentication on the transmitting party of the access request, specifically including: Based on the device identifier carried in the access request, a set of candidate authentication servers corresponding to the transmitting party is selected from the distributed authentication servers, and the resource utilization rate of each candidate authentication server is calculated respectively. If the estimated data volume is greater than or equal to the transmission volume threshold, the candidate authentication server with the lowest resource utilization rate is selected as the authentication server for that transmission party. The selected authentication server of the transmitting party verifies the dynamic key and the device's legitimacy.

[0012] In one possible implementation, the dynamic key verification and device legitimacy verification of the transceiver are performed based on the selected authentication server of the transceiver, specifically including: A connection request is initiated via a custom TCP protocol, and the dynamic key and device legitimacy are verified using a two-way TLS encrypted channel certificate chain verification method. The dynamic key is generated as follows: a hash calculation is performed on the master key, the current timestamp, the station number of the sounding station, and the device identifier. Dynamic parameters are obtained based on the hash calculation result and the hash calculation message authentication code. A dynamic key is then generated using a relevant key algorithm based on the dynamic parameters. After successful verification, a unique device identifier and a validity token are generated. When connecting, the unique device identifier, validity token, sounding data, and a timestamp-based dynamic signature are submitted and verified in real time by Netty's channel processor to avoid replay attacks.

[0013] In one possible implementation, the method further includes, during the process of receiving radiosonde data: Equipment monitoring: The detection frequency is dynamically adjusted based on the transmission rate of the radiosonde data. The higher the transmission rate, the lower the detection frequency. When the transmission rate is less than the set transmission threshold and the detection frequency is less than the frequency threshold, the transmitting device is determined to be offline. If the transmitting device is determined to be offline for more than a preset time, or if the device is detected to be turned off, the device registration of the transmitting device is deregistered.

[0014] In one possible implementation, the parsed radiosonde data is distributed to different backend services according to predefined routing rules, specifically including: The parsed radiosonde data, which is partitioned and stored according to the radiosonde number and the radiosonde station number, will be distributed to the backend service that has a data storage subscription requirement. The parsed radiosonde data, which is partitioned and stored according to the station number, is distributed to the backend service that has a subscription requirement for business monitoring.

[0015] Secondly, a radiosonde data central management system is provided. This system is a service cluster comprising multiple central service nodes. The multiple central service nodes are defined as at least one management node and multiple processing nodes, and each processing node is deployed with a business probe. The service cluster is used to implement full lifecycle management of radiosonde data. The at least one management node receives in real time the health status information of each processing node monitored by each service probe, and periodically calculates the health score of each processing node based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of the processing node; When a transmitter of radiosonde data requests access, the at least one management node will preferentially allocate the current access request to a processing node whose health score meets the first constraint condition; the transmitter includes: a satellite navigation radiosonde integrated processor and / or a cloud integrated processor; For the processing nodes that handle access requests, data processing operations are performed through the following modules: Device authentication and registration module: Based on the access request, selects an authentication server from the distributed authentication servers that currently meets the second constraint condition to perform device authentication on the transceiver of the access request, and completes device registration for the transceiver after successful authentication; Device filtering module: After device registration is completed, it receives the radiosonde data sent by the transmitter and determines whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, the transmitter is disabled; otherwise, radiosonde data continues to be received. Data parsing and storage module: Parses the received radiosonde data and, based on the subscription requirements of the backend service, stores the parsed radiosonde data in partitions according to the radiosonde number and / or the radiosonde station number; Data distribution module: It adopts an event bus as the internal message bus and a high-performance remote procedure call protocol as the external service protocol to distribute the parsed radiosonde data to different backend services according to the set routing rules.

[0016] Thirdly, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0017] Fourthly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the aspects described above and any possible implementation thereof.

[0018] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aspects and any possible implementations described above.

[0019] The beneficial effects of the technical solution provided in this application include at least the following: As can be seen from the above technical solution, this application embodiment achieves full lifecycle management of radiosonde data by deploying a service cluster containing multiple central service nodes. First, the management node receives the health status information of each processing node monitored by each business probe in real time. Then, it periodically calculates the health score of each processing node. When a transmitter of radiosonde data requests access, the management node prioritizes allocating the current access request to the processing node whose health score meets the first constraint condition to perform data processing operations: based on the access request, it selects the authentication server that currently meets the second constraint condition from the distributed authentication server to perform device authentication and device registration for the transmitter; then, it filters the devices of the transmitter according to the built-in data counter; it parses and partitions the received radiosonde data; finally, it distributes the parsed radiosonde data to different backend services according to the set routing rules. This application designs a central management layer for radiosonde data to achieve full lifecycle management of radiosonde data. In particular, the node classification management of the service cluster and the authentication and registration method of the distributed authentication server not only improve the data transmission rate of radiosonde data and ensure data latency, but also effectively distribute the authentication pressure and reduce authentication and management costs. At the same time, moving the data parsing operation forward facilitates partitioned storage and provides effective support for subsequent distribution to backend services with different subscription needs.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the radiosonde network architecture applicable to the radiosonde data hub management method provided in the embodiments of this application.

[0023] Figures 2a-2b This is a schematic diagram illustrating the steps of a sounding data hub management method provided in an embodiment of this application.

[0024] Figure 3 This is a schematic diagram of the service cluster module deployment provided in the embodiments of this application.

[0025] Figure 4 This is a schematic diagram of a device authentication and registration process provided in one embodiment of this application.

[0026] Figure 5 This is a structural block diagram of a sounding data central management system provided in another embodiment of this application.

[0027] Figure 6 This is a block diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0028] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0029] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0030] It should be noted that the terminal devices involved in the embodiments of this application may include, but are not limited to, smart devices such as mobile phones, personal digital assistants (PDAs), wireless handheld devices, and tablet computers; the display devices may include, but are not limited to, personal computers, televisions, and other devices with display functions.

[0031] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0032] In view of the problems of high latency, significant performance bottlenecks, and inefficient decentralized equipment management in existing radiosonde data transmission, as well as the imbalance between authentication security and maintenance costs, this application proposes a radiosonde data central management scheme. The main inventive concept is as follows: Full lifecycle management of radiosonde data is achieved by deploying a service cluster containing multiple central service nodes. First, the management node receives real-time health status information from each business probe monitoring its respective processing node. Then, it periodically calculates the health score of each processing node. When a transmitter of radiosonde data requests access, the management node prioritizes allocating the current access request to a processing node whose health score meets the first constraint condition for data processing operations. Based on the access request, it selects an authentication server from the distributed authentication server that currently meets the second constraint condition to perform device authentication and registration for the transmitter. Then, it filters the transmitter's devices based on a built-in data counter. The received radiosonde data is parsed and partitioned for storage. Finally, the parsed radiosonde data is distributed to different backend services according to set routing rules. This application designs a central management layer for sounding data to achieve full lifecycle management of sounding data. In particular, it adopts a service cluster node classification management and a distributed authentication server authentication and registration method, which not only improves the sounding data transmission rate and ensures data latency, but also effectively distributes authentication pressure and reduces authentication and management costs. At the same time, moving the data parsing operation forward facilitates partitioned storage and provides effective support for subsequent distribution to backend services with different subscription needs.

[0033] Reference Figure 1 The diagram shown is a schematic of the radiosonde network architecture applicable to the radiosonde data hub management method provided in this application embodiment.

[0034] like Figure 1 In this radiosonde network architecture, multiple radiosondes 101, multiple radiosonde receivers 102, multiple integrated processors 103, cloud integrated processors 104, radiosonde data hub system 105, and data center equipment 106 can be deployed, and business servers 107 can also be included.

[0035] Among them, multiple radiosondes 101 can be launched from different launch stations and perform corresponding radiosonde tasks in different radiosonde areas through different flight stages such as ascent, drift, and descent.

[0036] Multiple radiosonde receivers 102 can be distributed at different receiving stations to receive radiosonde data while matching the frequency of the radiosonde 101. For example... Figure 1 As shown, one radiosonde receiver 102 can receive radiosonde data from one radiosonde 101, multiple radiosonde receivers 102 can simultaneously receive radiosonde data from one radiosonde 101, and one radiosonde receiver 102 can also simultaneously receive radiosonde data from two radiosondes 101.

[0037] Subsequently, the sounding data can be processed by the integrated processor 103 or the cloud integrated processor 104, sent to the sounding data central system 105 for central management, and then forwarded to the data center equipment 106 for data fusion processing. The data fusion scheme of this application mainly occurs in the sounding data central system 105; other parts are not the core improvements of this application, so they will not be described in detail.

[0038] The solutions involved in this application will be described in detail below through specific embodiments.

[0039] Reference Figures 2a-2b The diagram illustrates the steps of a radiosonde data central management method according to an embodiment of this application. This method primarily involves the management of the entire lifecycle of radiosonde data, and its execution entity can be a radiosonde data central management system. This system can be a hardware device with computer functions such as data calculation, processing, and storage, or a software module or component integrated into such hardware device. These hardware devices can be, for example, smart electronic devices such as computers, tablets, smartphones, and smart wearable devices, or various types of servers such as cloud servers and distributed servers. Preferably, the execution entity of the radiosonde data central management method involved in this application can be a server or server cluster, which, by deploying corresponding functions, provides central management services for the entire lifecycle of radiosonde data in the radiosonde data central system 105.

[0040] In this application, the sounding data central management system is deployed as a service cluster (or server cluster). (Refer to...) Figure 3 The diagram shown is a schematic of the service cluster module deployment provided in an embodiment of this application. The service cluster includes multiple central service nodes, which are defined as at least one management node and multiple processing nodes, and each processing node is equipped with a business probe; the service cluster is used to implement full lifecycle management of sounding data.

[0041] Combination Figure 2a , Figure 2b and Figure 3 The central management method for the entire lifecycle of sounding data includes: Step 202: The at least one management node receives in real time the health status information of each processing node monitored by each service probe, and periodically calculates the health score of each processing node based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of the processing node.

[0042] Optionally, the first constraint is that the health score of the processing node is greater than a first threshold, and the computing resources, network resources, and service resources are all within their respective normal ranges. The first threshold can be 80, or other values; this application does not limit this value.

[0043] In this application, a multi-dimensional health assessment model is preset as shown in the table below. The data indicators collected by the management node are weighted and scored, with a maximum score of 100.

[0044] Therefore, the advantages of the multi-dimensional health assessment model in this application are: when expanding processing nodes, the nodes with the highest scores can be expanded first; the management node automatically identifies nodes with health scores less than 80 and issues warnings, and if the score is less than 50, it automatically switches to the node with the highest score.

[0045] This application's service cluster supports a sharded cluster mode. Each shard is responsible for receiving radiosonde data uploaded from different regions (due to the characteristics of radiosonde data, sharding is based on the region of the device, i.e., the region where the radiosonde station is located), and distributing it to subsequent services according to distribution rules (radiosonde data is distributed by radiosonde number, and device status data such as spectrum is distributed by station number). The sharded cluster mode means that the national radiosonde data integration equipment transmits data to different server nodes according to regions. The clustered service deployment can be distributed across different servers using Kubernetes (k8s) NodePort mode.

[0046] In this application, the health status of the data acquisition and processing nodes can be monitored in real time through business probes, and the availability of the processing nodes can be obtained in a timely manner.

[0047] Step 204: When a transmitter with radiosonde data requests access, the at least one management node will preferentially allocate the current access request to a processing node whose health score meets the first constraint condition; the transmitter includes: a satellite navigation radiosonde integrated processor and / or a cloud integrated processor.

[0048] Step 206: For the processing node that assigns the access request, perform the following data processing operations respectively: device authentication and registration, device filtering, data parsing and storage, and data distribution.

[0049] Specifically, the data processing operation in step 206 may include the following sub-steps: Sub-step 2062: Device authentication and registration: Based on the access request, select an authentication server from the distributed authentication servers that currently meets the second constraint to perform device authentication on the transceiver of the access request, and complete the device registration of the transceiver after successful authentication.

[0050] Optionally, in this application's scheme, the access request carries the device identifier of the transmitting party and the estimated data volume; and each transmitting party is pre-allocated a corresponding set of candidate authentication servers; then, based on the access request, an authentication server that currently meets the second constraint condition is selected from the distributed authentication servers to perform device authentication on the transmitting party of the access request, specifically including: selecting the set of candidate authentication servers corresponding to the transmitting party from the distributed authentication servers based on the device identifier carried in the access request, and calculating the resource utilization rate of each candidate authentication server; if the estimated data volume is greater than or equal to the transmission volume threshold, then selecting the candidate authentication server with the smallest resource utilization rate as the authentication server of the transmitting party; and performing dynamic key verification and device legitimacy verification on the transmitting party based on the selected authentication server of the transmitting party.

[0051] Furthermore, based on the selected authentication server of the transmitting party, dynamic key verification and device legitimacy verification are performed on the transmitting party. Specifically, this includes: initiating a connection request through a custom TCP protocol, and using a two-way TLS encrypted channel certificate chain verification method to verify the dynamic key and device legitimacy. The dynamic key is generated as follows: a hash calculation is performed using the master key, current timestamp, radiosonde station number, and device identifier; dynamic parameters are obtained based on the hash calculation result and the hash calculation message authentication code; and a dynamic key is generated using a relevant key algorithm based on the dynamic parameters. After successful verification, a unique device identifier and validity token are generated. During connection, the unique device identifier, validity token, radiosonde data, and a timestamp-based dynamic signature are submitted and verified in real-time by Netty's ChannelHandler to avoid replay attacks.

[0052] Sub-step 2064: Device filtering: After device registration is completed, receive the radiosonde data sent by the transmitter, and determine whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, disable the transmitter; otherwise, continue to receive radiosonde data.

[0053] Sub-step 2066: Data parsing and storage: Parse the received radiosonde data and, based on the subscription requirements of the backend service, partition and store the parsed radiosonde data according to the radiosonde number and / or the radiosonde station number.

[0054] Sub-step 2068: Data distribution: Using an event bus as the internal message bus and a high-performance remote procedure call protocol as the external service protocol, the parsed radiosonde data is distributed to different backend services according to the set routing rules.

[0055] Optionally, the parsed radiosonde data is distributed to different backend services according to the set routing rules. Specifically, this includes: distributing the parsed radiosonde data, which is partitioned and stored according to the radiosonde number and the radiosonde station number, to the backend service whose subscription requirement is data storage; and distributing the parsed radiosonde data, which is partitioned and stored according to the radiosonde station number, to the backend service whose subscription requirement is business monitoring.

[0056] Furthermore, during the data processing operation performed by the processing node that allocates the access request, the at least one management node may also issue an early warning to the processing node whose health score is less than the second threshold; and / or; the at least one management node may also switch the access request being processed from the processing node that is performing the data processing operation to the processing node with the highest current health score when it detects that the health score of the processing node that is performing the data processing operation is decreasing and is less than the third threshold.

[0057] In this application, the device can be monitored during the reception of radiosonde data. Specifically, the detection frequency can be dynamically adjusted according to the transmission rate of the radiosonde data. The higher the transmission rate, the lower the detection frequency. When the transmission rate is less than the set transmission threshold and the detection frequency is less than the frequency threshold, the transmitting device is determined to be offline. If the transmitting device is determined to be offline for more than a preset time, or the device is detected to be turned off, the device registration of the transmitting device is deactivated.

[0058] (1) Equipment certification and registration Reference Figure 4 The diagram illustrates the device authentication and registration process. This process can be achieved through interaction between the radiosonde integrated processor and the radiosonde data hub system (essentially the processing node and related authentication server within the system). After startup, the radiosonde integrated processor initiates a connection request via a custom protocol (based on TCP). Upon initial connection, security authentication is performed through a bidirectional TLS encrypted channel certificate chain verification, validating the dynamic key and device legitimacy (radiosonde device serial number and device validity period). After successful verification by the radiosonde data hub service, a unique device ID and a validity token are generated. For subsequent connections, the radiosonde integrated processor must submit the device ID, token, radiosonde data, and dynamic signature (HMAC-SHA256 encryption based on timestamps). The radiosonde data hub service verifies in real-time using Netty's ChannelHandler to prevent replay attacks. The device sends radiosonde data (500 bytes / data) at a rate of 1 data point / second, containing meteorological elements such as air pressure, temperature, humidity, wind speed, and altitude, using a custom radiosonde format binary encoding.

[0059] Each device is pre-configured with a high-strength master key, MasterKey. This key is stored in the radiosonde integrated processor and the radiosonde data center. Dynamic key generation is as follows: Obtain the current timestamp T (accurate to the minute) => Obtain the station number N => Calculate the dynamic parameter P = HMAC-SHA256(MasterKey, T || N || DeviceID), and generate the key K = HKDF(P, "SessionKey", 32). The transmitted data includes {time T, station number N, device SN, device validity period, and dynamic key K}. Dynamic key verification is as follows: Receive data => Verify if the timestamp T is within the valid window (±5 minutes) => Obtain the corresponding device's MasterKey from storage, calculate the dynamic parameter P' = HMAC-SHA256(MasterKey, T || N || DeviceID), K' = HKDF(P', "SessionKey", 32), and compare the key K' with the transmitted key K to see if they match.

[0060] (2) Equipment filtration The device management system includes basic device information, validity period, device disabled status, and device monitoring. A built-in data counter tracks the number of data entries received by the device; if the threshold is exceeded, the device can be automatically disabled.

[0061] (3) Data Analysis Due to the characteristics of sounding data, the received data needs to be parsed before it can be distributed to subsequent services.

[0062] The raw data format sent by the device: BG,000,51709,YSRP,001,007,01,GAA,400562500,GAB,91,GAC,178,GAF,0,GAI,1,GFA,7FF FFFEE253264320B0150E001F0ADAA3F515F2F3FD75F0000DDFFC3FDABFA18067496291E8191291 849BC284146FF2500000000000014AA030032DC5D00A54200007B3E00006D27010AA821001F18 131F330753EF5611CB2601FF00000023835AF5FB,GZA,1751073376832,9999999,z,0,6893,ED Data after data parsing: Time, air pressure (hPa), temperature (°C), humidity (%), northward velocity (m / s), eastward velocity (m / s), ascent velocity (m / s), longitude (°), latitude (°), altitude (m), channel number, receiving station number, battery voltage (V), box temperature, frequency (mHz), signal strength (dBm), number of satellites, satellite number 1, satellite signal-to-noise ratio 1, satellite elevation 1, satellite azimuth 1, satellite number 2, satellite signal-to-noise ratio 2, satellite elevation 2, satellite azimuth 2, satellite number 3, satellite signal-to-noise ratio 3, satellite elevation 3, satellite azimuth 3; The corresponding values ​​are as follows: 07:16:58, 997.20, 24.20, 94.00, 0.04, 1.22, 2.68, 113.0841980, 23.7103004, 80.40, 59280, 2.8, 42, 400.712, 53.0, 17, 80, 30.0, 16.0, 39.0, 17, 29.0, 14.0, 244.0, 0, 29.0, 14.0, 0.0.

[0063] Basic information after analysis: Launching station number: 59XXX; Station name: XX station; Station longitude (°): 113.0842; Station latitude (°): 23.7103; Station altitude (m): 80.40; Radiosonde number: 24208391; Radiosonde manufacturer: GTH1.

[0064] (4) Data storage Data is partitioned by radiosonde station number, with each partition containing multiple log segments (1GB of data + index per segment). Sequential appending to disk is used, combined with zero-copy technology and a producer-consumer batch disk flushing mechanism. A scheduled task scans the creation time of log segments and deletes data older than 48 hours to free up disk space.

[0065] (5) Data distribution Due to the characteristics of radiosonde data, each receiver uploads data from 8 channels. Data information includes time, receiving station, latitude and longitude, radiosonde number, altitude, temperature, humidity, and pressure. Distribution rules require parsing the radiosonde number or station number to create custom routing rules. This application utilizes Vert.x's EventBus as the internal message bus and GRPC as the external service protocol to ensure efficient routing rules. The data distribution latency in this application is controlled within 80ms, supporting concurrent subscriptions from 100 backend services, representing a 3x improvement in distribution efficiency compared to existing solutions.

[0066] (6) Equipment Management A distributed registry center is built to ensure the stability and scalability of service discovery and to manage devices. This includes device authentication, device filtering, device data statistics, and a heartbeat detection mechanism. A multi-level heartbeat detection mechanism is established: the probe device sends a heartbeat request every 30 seconds. Upon receiving a heartbeat, the device status is updated; if no heartbeat is received, it is updated to offline. The detection frequency is dynamically adjusted based on device activity (the heartbeat frequency is reduced during business periods when data transmission occurs). Probe device status awareness: the probe device reports its status upon initial authentication and upon shutdown.

[0067] This application designs a central management layer for sounding data to achieve full lifecycle management of sounding data. In particular, the use of a distributed authentication server for authentication and registration not only improves the data transmission rate and ensures data latency, but also effectively distributes authentication pressure and reduces authentication and management costs. Simultaneously, moving data parsing operations forward facilitates partitioned storage, providing effective support for subsequent distribution to backend services with different subscription needs.

[0068] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0069] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0070] Figure 5 This application provides a structural block diagram of a sounding data central management system according to an embodiment of the present application. Figure 5As shown. The radiosonde data central management system 500 of this embodiment may include: multiple central service nodes, which are defined as at least one management node 501 and multiple processing nodes 502, and each processing node 502 is deployed with a service probe (not shown); the service cluster is used to realize full lifecycle management of radiosonde data; wherein, the at least one management node 501 receives in real time the health status information of each processing node 502 monitored by each service probe, and periodically calculates the health score of each processing node 502 based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of processing nodes; when a radiosonde data transmitter requests access, the at least one management node 501 will preferentially allocate the current access request to the processing node 502 whose health score meets the first constraint condition; the transmitter includes: satellite navigation radiosonde integrated processor and / or cloud integrated processor. The processing node 502, which handles access requests, performs data processing operations through the following modules: Device authentication and registration module 5021: Based on the access request, it selects an authentication server from the distributed authentication servers that currently meets the second constraint condition to authenticate the transmitting party of the access request, and completes device registration for the transmitting party after successful authentication. Device filtering module 5022: After device registration, it receives the radiosonde data sent by the transmitting party and determines whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, it disables the transmitting party; otherwise, it continues to receive radiosonde data. Data parsing and storage module 5023: It parses the received radiosonde data and, based on the subscription requirements of the backend services, partitions and stores the parsed radiosonde data according to the radiosonde number and / or the radiosonde station number. Data distribution module 5024: Using EventBus as the internal message bus and the high-performance remote procedure call protocol GRPC as the external service protocol, it distributes the parsed radiosonde data to different backend services according to the set routing rules.

[0071] It should be noted that some or all of the radiosonde data central management system in this embodiment may be an application located on a local terminal, or it may be a plugin or software development kit (SDK) or other functional unit set in an application located on a local terminal, or it may be a processing engine located on a network-side server, or it may be a distributed system located on the network side. This embodiment does not impose any particular limitations on this.

[0072] It is understood that the application may be a native program installed on the local terminal, or it may be a web application of a browser on the local terminal. This embodiment does not limit this.

[0073] Optionally, in one possible implementation of this embodiment, the first constraint is: the health score of the processing node is greater than a first threshold, and the computing resources, network resources, and service resources are all within their respective normal ranges.

[0074] Optionally, in one possible implementation of this embodiment, during the data processing operation performed by the processing node that allocates the access request, the at least one management node 501 is further configured to issue a warning to the processing node whose health score is less than a second threshold; and / or; the at least one management node 501 is further configured to switch the access request being processed from the processing node that is performing the data processing operation to the processing node with the highest current health score when it detects that the health score of the processing node that is performing the data processing operation is decreasing and is less than a third threshold.

[0075] Optionally, in one possible implementation of this embodiment, the access request carries the device identifier of the transmitting party and the estimated data volume; and each transmitting party is pre-allocated a corresponding set of candidate authentication servers; then, when the device authentication registration module 5021 selects an authentication server that currently meets the second constraint condition from the distributed authentication servers based on the access request to perform device authentication for the transmitting party of the access request, it is specifically used to select the set of candidate authentication servers corresponding to the transmitting party from the distributed authentication servers based on the device identifier carried in the access request, and calculate the resource occupancy rate of each candidate authentication server; if the estimated data volume is greater than or equal to the transmission volume threshold, then the candidate authentication server with the smallest resource occupancy rate is selected as the authentication server of the transmitting party; and the transmitting party is verified for dynamic key and device legitimacy based on the selected authentication server of the transmitting party.

[0076] Optionally, in one possible implementation of this embodiment, when the device authentication and registration module 5021 verifies the dynamic key and device legitimacy of the transmitting party based on the selected authentication server of the transmitting party, it is specifically used to initiate a connection request through a custom protocol TCP, and use a two-way TLS encrypted channel certificate chain verification method to verify the dynamic key and device legitimacy. The dynamic key is generated as follows: a hash calculation is performed using the master key, the current timestamp, the radiosonde station number, and the device identifier; dynamic parameters are obtained based on the hash calculation result and the hash calculation message authentication code; and a dynamic key is generated using a relevant key algorithm based on the dynamic parameters. After successful verification, a unique device identifier and a validity token are generated. During connection, the unique device identifier, validity token, radiosonde data, and a timestamp-based dynamic signature are submitted and verified in real-time by Netty's ChannelHandler to avoid replay attacks.

[0077] Optionally, in one possible implementation of this embodiment, the system further includes: a device monitoring module: used to dynamically adjust the detection frequency according to the transmission rate of the radiosonde data during the reception of radiosonde data; the higher the transmission rate, the lower the detection frequency; when the transmission rate is less than a set transmission threshold and the detection frequency is less than a frequency threshold, it is determined that the transmitting device is offline; if it is determined that the transmitting device is offline for more than a preset time, or the device is detected to be turned off, the device registration of the transmitting device is deactivated.

[0078] Optionally, in one possible implementation of this embodiment, when the data distribution module 5024 distributes the parsed radiosonde data to different backend services according to the set routing rules, it specifically distributes the parsed radiosonde data, which is partitioned and stored according to the radiosonde number and the radiosonde station number, to the backend service whose subscription requirement is data storage; and distributes the parsed radiosonde data, which is partitioned and stored according to the radiosonde station number, to the backend service whose subscription requirement is business monitoring.

[0079] In this embodiment, an authentication request sent by the transmitter of radiosonde data can be received. Based on the authentication request, an authentication server that currently meets the first availability condition is selected from the distributed authentication servers to authenticate the transmitter's device. After successful authentication, the device registration of the transmitter is completed. After device registration, radiosonde data sent by the transmitter is received, and the transmitter is disabled when the received radiosonde data exceeds the counting threshold within a counting period. The received radiosonde data is parsed, and based on the subscription requirements of backend services, the parsed radiosonde data is partitioned and stored according to the radiosonde number, launch station number, or receiver number. An EventBus is used as the internal message bus, and a high-performance remote procedure call protocol (GRPC) is used as the external service protocol to distribute the parsed radiosonde data to different backend services according to the set routing rules. This application designs a central management layer for radiosonde data to achieve full lifecycle management of radiosonde data. In particular, the authentication and registration method using a distributed authentication server not only improves the radiosonde data transmission rate and ensures data latency, but also effectively distributes authentication pressure and reduces authentication and management costs. At the same time, moving the data parsing operation forward facilitates partitioned storage and provides effective support for subsequent distribution to backend services with different subscription needs.

[0080] One embodiment of this application provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to implement the method for managing a sounding data hub as described above.

[0081] One embodiment of this application provides an electronic device, which includes a processor and a memory, wherein the memory stores at least one instruction, which is loaded and executed by the processor to implement the method for managing the sounding data hub as described above.

[0082] One embodiment of this application provides a sounding data hub device, including the electronic equipment described above.

[0083] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0084] Figure 6A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0085] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0086] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0087] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the method of radiosonde data hub management. For example, in some embodiments, the method of radiosonde data hub management can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method of radiosonde data hub management described above can be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform a method of sounding data hub management by any other suitable means (e.g., by means of firmware).

[0088] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, at least one input device, and at least one output device.

[0089] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0090] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0091] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0092] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0093] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0094] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0095] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing a sounding data hub, characterized in that, It is applied to a service cluster containing multiple central service nodes; the multiple central service nodes are defined as at least one management node and multiple processing nodes, and each processing node is deployed with a business probe; The service cluster is used to implement full lifecycle management of sounding data; the method includes: The at least one management node receives in real time the health status information of each processing node monitored by each service probe, and periodically calculates the health score of each processing node based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of the processing node; When a transmitter of radiosonde data requests access, the at least one management node will preferentially allocate the current access request to a processing node whose health score meets the first constraint condition; the transmitter includes: a satellite navigation radiosonde integrated processor and / or a cloud integrated processor; For each processing node that assigns an access request, the following data processing operations are performed: Device authentication and registration: Based on the access request, select an authentication server from the distributed authentication servers that currently meets the second constraint to authenticate the device of the transmission party of the access request, and complete the device registration of the transmission party after successful authentication; Device filtering: After device registration is completed, the device receives the radiosonde data sent by the transmitter and determines whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, the transmitter is disabled; otherwise, the device continues to receive radiosonde data. Data parsing and storage: The received radiosonde data is parsed, and based on the subscription requirements of the backend service, the parsed radiosonde data is partitioned and stored according to the radiosonde number and / or the radiosonde station number. Data distribution: An event bus is used as the internal message bus, and a high-performance remote procedure call protocol is used as the external service protocol to distribute the parsed radiosonde data to different backend services according to the set routing rules.

2. The method as described in claim 1, characterized in that, The first constraint is that the health score of the processing node is greater than the first threshold, and the computing resources, network resources and business resources are all within their respective normal ranges.

3. The method as described in claim 1 or 2, characterized in that, During the data processing operation performed by the processing node that allocates the access request, the method further includes: The at least one management node provides an early warning to processing nodes whose health scores are less than the second threshold; and / or; When at least one management node detects that the health score of a processing node performing data processing operations is decreasing and falling below a third threshold, it switches the access request being processed from the processing node performing the data processing operations to the processing node with the highest current health score.

4. The method as described in claim 1, characterized in that, The access request carries the device identifier of the transmitting party and the estimated data volume; and each transmitting party is pre-allocated a corresponding set of candidate authentication servers; then, based on the access request, an authentication server that currently meets the second constraint condition is selected from the distributed authentication servers to perform device authentication on the transmitting party of the access request, specifically including: Based on the device identifier carried in the access request, a set of candidate authentication servers corresponding to the transmitting party is selected from the distributed authentication servers, and the resource utilization rate of each candidate authentication server is calculated respectively. If the estimated data volume is greater than or equal to the transmission volume threshold, the candidate authentication server with the lowest resource utilization rate is selected as the authentication server for that transmission party. The selected authentication server of the transmitting party verifies the dynamic key and the device's legitimacy.

5. The method as described in claim 4, characterized in that, Based on the selected authentication server of the transmitting party, the dynamic key verification and device legitimacy verification of the transmitting party are performed, specifically including: A connection request is initiated via a custom TCP protocol, and the dynamic key and device legitimacy are verified using a two-way TLS encrypted channel certificate chain verification method. The dynamic key is generated as follows: a hash calculation is performed on the master key, the current timestamp, the station number of the sounding station, and the device identifier. Dynamic parameters are obtained based on the hash calculation result and the hash calculation message authentication code. A dynamic key is then generated using a relevant key algorithm based on the dynamic parameters. After successful verification, a unique device identifier and a validity token are generated. When connecting, the unique device identifier, validity token, sounding data, and a timestamp-based dynamic signature are submitted and verified in real time by Netty's channel processor to avoid replay attacks.

6. The method according to any one of claims 1, 2, 4, and 5, characterized in that, The method further includes the following steps during the reception of radiosonde data: Equipment monitoring: The detection frequency is dynamically adjusted based on the transmission rate of the radiosonde data. The higher the transmission rate, the lower the detection frequency. When the transmission rate is less than the set transmission threshold and the detection frequency is less than the frequency threshold, the transmitting device is determined to be offline. If the transmitting device is determined to be offline for more than a preset time, or if the device is detected to be turned off, the device registration of the transmitting device is deregistered.

7. The method as described in claim 1, characterized in that, The parsed radiosonde data is distributed to different backend services according to the set routing rules, specifically including: The parsed radiosonde data, which is partitioned and stored according to the radiosonde number and the radiosonde station number, will be distributed to the backend service that has a data storage subscription requirement. The parsed radiosonde data, which is partitioned and stored according to the station number, is distributed to the backend service that has a subscription requirement for business monitoring.

8. A sounding data central management system, characterized in that, The management system is a service cluster comprising multiple central service nodes; these central service nodes are defined as at least one management node and multiple processing nodes, with each processing node deployed with a business probe; the service cluster is used to implement full lifecycle management of sounding data; wherein, The at least one management node receives in real time the health status information of each processing node monitored by each service probe, and periodically calculates the health score of each processing node based on the health status information using a preset multi-dimensional health assessment model; wherein, the health status information includes at least: computing resources, network resources and service resources; the health score is used to characterize the availability of the processing node; When a transmitter of radiosonde data requests access, the at least one management node will preferentially allocate the current access request to a processing node whose health score meets the first constraint condition; the transmitter includes: a satellite navigation radiosonde integrated processor and / or a cloud integrated processor; For the processing nodes that handle access requests, data processing operations are performed through the following modules: Device authentication and registration module: Based on the access request, selects an authentication server from the distributed authentication servers that currently meets the second constraint condition to perform device authentication on the transceiver of the access request, and completes device registration for the transceiver after successful authentication; Device filtering module: After device registration is completed, it receives the radiosonde data sent by the transmitter and determines whether the received radiosonde data within the counting period exceeds the counting threshold based on the built-in data counter. If so, the transmitter is disabled; otherwise, radiosonde data continues to be received. Data parsing and storage module: Parses the received radiosonde data and, based on the subscription requirements of the backend service, stores the parsed radiosonde data in partitions according to the radiosonde number and / or the radiosonde station number; Data distribution module: It adopts an event bus as the internal message bus and a high-performance remote procedure call protocol as the external service protocol to distribute the parsed radiosonde data to different backend services according to the set routing rules.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-7.

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-7.

Images