High-availability resource management platform for aviation field

Abstract

The invention belongs to the technical field of airborne software architecture. The invention provides a high-availability resource management platform oriented to the aviation field. The method comprises an external system layer, a platform layer, a core framework layer and a high-availability deployment strategy module. According to the embodiment of the invention, by splitting the components and adopting different high-availability deployment strategies for different components, high availability of the data plane and the control plane is ensured in a resource-limited environment, and high stability of the resource management platform is realized.

Description

Technical Field

[0001] The disclosed embodiments relate to the technical field of airborne software architecture, and in particular to a high-availability resource management platform for the aviation field. Background Art

[0002] Traditional resource management platform system designs are mostly based on single-machine deployment, which means that the resource management platform can only run on a single node. Once this node fails, the entire platform will be unusable. On the other hand, when more nodes need to be managed, it is impossible to manage more nodes by horizontally expanding the resource management platform. The single-node architecture has the following problems: single process is unstable. The single-process design means that the failures between functional modules will affect each other, which will not only greatly reduce the stability of the resource management platform, but also affect the overall performance of the resource management platform; database single point hidden dangers. The database of the resource management platform is generally based on local files, which has the risk of single point failure, affecting the high availability of the entire resource management platform; horizontal expansion is limited. The resource management platform with a single-machine deployment architecture does not support horizontal expansion, which limits the system's ability to manage more nodes by adding replicas, thereby affecting the scalability of the system; data plane and control plane coupling. The system control side is tightly coupled with the user traffic side. Once the control side fails, the user traffic side will also be affected, resulting in the unavailability of related services. Since the aviation airborne field has high requirements for software stability, a highly available resource management platform is needed to expand the single-machine deployment architecture to a microservice deployment architecture to solve problems such as single point failures and coupling between the data plane and the control plane, and to achieve the stability of the resource management platform in a resource-constrained environment.

[0003] Therefore, it is necessary to improve one or more problems existing in the above-mentioned related technical solutions.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] The purpose of the embodiments of the present disclosure is to provide a high-availability resource management platform for the aviation field, thereby overcoming one or more problems caused by limitations and defects of related technologies at least to a certain extent.

[0006] According to an embodiment of the present disclosure, a high-availability resource management platform for the aviation field is provided, including: External system layer, platform layer, core framework layer and high availability deployment strategy module; among them, The external system layer, including the UI components displayed on the front end, controls and monitors cluster resources through the HTTP API provided by the platform layer; The platform layer includes a general middleware and a storage and log system component. The general middleware is used to provide a configuration center and data overview statistics functions, communicate with the API server of the core framework layer downward, and provide the HTTP API to the external system layer upward; the storage and log system component is used to adopt an embedded distributed file system, a distributed database, and an in-memory database storage solution, and design a unified log format and flexible log output objects; The core framework layer includes an API server component, a scheduler component, a controller component, a node agent component, a load balancing agent component, and a location center component, which are responsible for data maintenance, container scheduling, container node status control, container deployment, and node data monitoring; The high-availability deployment strategy module is used to provide different deployment strategies for different components; wherein the deployment strategies include multi-instance deployment, active-standby deployment and single-instance deployment.

[0007] Furthermore, the UI component is used to provide a graphical interactive interface, access the resource management platform through a web browser, and the user interacts with the resource management platform by clicking on the page; wherein, the cluster status and container deployment operations can be viewed in the interactive interface, and the creation, operation, deletion, query and pause of containers are supported.

[0008] Furthermore, the general middleware is used to integrate some functions with strong universality and high frequency of change into the general middleware, thereby reducing the complexity of other components.

[0009] Furthermore, the storage and log system components are used to adopt embedded distributed file systems, distributed databases and memory database storage solutions in storage solutions to avoid database single point failure problems; the log system adopts a unified log format design, supports log screening according to different attributes, and can configure log output objects to improve the efficiency of troubleshooting when a failure occurs.

[0010] Furthermore, the API server component is the request processor of the resource management platform and is responsible for all data storage and retrieval operations; The scheduler component is responsible for allocating appropriate nodes for newly created container instances, ensuring that container allocation is based on resource utilization of each node in the cluster and user-specified scheduling requirements; The controller component is responsible for ensuring that the cluster state is consistent with expectations and that the cluster is always in the expected state; The node agent component is used to connect the resource management platform and the container to ensure that the containers within the cluster run normally and stably according to the required status. It is responsible for container management, node resource management, health check and container runtime interface.

[0011] The load balancing proxy component is used for the caller to shield the multi-instance application behind it, so that the caller always accesses an available instance.

[0012] The location center component is responsible for service discovery and registration, and is also responsible for load balancing of calls between services.

[0013] Furthermore, the multi-instance deployment deploys multiple instances of a core component on different or the same nodes, for a core component that is missing or fails and causes the resource management platform to be unavailable.

[0014] Furthermore, the active-standby deployment deploys two instances of components, one active and one standby, on different or the same nodes for important components that are missing or fail and cause the resource management platform to lose some important functions.

[0015] Furthermore, the single instance deployment deploys one instance on one node for components that are missing or fail, causing the resource management platform to lose some non-critical functions.

[0016] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects: In the embodiments of the present disclosure, the above-mentioned high-availability resource management platform for the aviation field is used, which includes an external system layer, a platform layer, a core framework layer and a high-availability deployment strategy module. By splitting components and adopting different high-availability deployment strategies for different components, the high availability of the data plane and the control plane is guaranteed in a resource-constrained environment, thereby achieving high stability of the resource management platform.

[0017] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.

[0019] Figure 1 A schematic diagram showing a high-availability resource management platform for the aviation field in an exemplary embodiment of the present disclosure; Figure 2 A diagram showing the overall deployment architecture of a high-availability resource management platform for the aviation field in an exemplary embodiment of the present disclosure; Figure 3A high-availability traffic architecture diagram of a control plane in an exemplary embodiment of the present disclosure is shown; Figure 4 A diagram showing a high-availability traffic architecture of a data plane in an exemplary embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0020] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the disclosure will be more comprehensive and complete and to fully convey the concepts of the example 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.

[0021] In addition, the accompanying drawings are only schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the figures represent the same or similar parts, and their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0022] In this example implementation, a high-availability resource management platform for the aviation field is provided. Figure 1 As shown in , the high-availability resource management platform for the aviation field may include: an external system layer, a platform layer, a core framework layer and a high-availability deployment strategy module; wherein, The external system layer, including the UI components displayed on the front end, controls and monitors cluster resources through the HTTP API provided by the platform layer; The platform layer includes a general middleware and a storage and log system component. The general middleware is used to provide a configuration center and data overview statistics functions, communicate with the API server of the core framework layer downward, and provide the HTTP API to the external system layer upward; the storage and log system component is used to adopt an embedded distributed file system, a distributed database, and an in-memory database storage solution, and design a unified log format and flexible log output objects; The core framework layer includes an API server component, a scheduler component, a controller component, a node agent component, a load balancing agent component, and a location center component, which are responsible for data maintenance, container scheduling, container node status control, container deployment, and node data monitoring; The high-availability deployment strategy module is used to provide different deployment strategies for different components; wherein the deployment strategies include multi-instance deployment, active-standby deployment and single-instance deployment.

[0023] Through the above-mentioned high-availability resource management platform for the aviation field, the resource management platform includes an external system layer, a platform layer, a core framework layer and a high-availability deployment strategy module. By splitting components and adopting different high-availability deployment strategies for different components, the high availability of the data plane and the control plane is guaranteed in a resource-constrained environment, thereby achieving high stability of the resource management platform.

[0024] Next, we will refer to Figures 1 to 4 The various parts of the above-mentioned high-availability resource management platform for the aviation field in this example implementation are described in more detail.

[0025] In one embodiment, the external system layer includes a UI component displayed on the front end, and implements the control and monitoring functions of cluster resources through a unified HTTP API provided by the platform layer.

[0026] Specifically, the UI component provides a graphical interactive interface. The resource management platform can be accessed through a web browser, and users can interact with the system directly by clicking on the page. In the interactive interface, operations such as viewing cluster status and deploying containers can be performed, and operations such as creating, running, deleting, querying, and pausing containers are supported.

[0027] More specifically, the UI component is designed to improve the interoperability of the resource management platform. Users can easily use the resource management platform to monitor and control the cluster without using command line tools or configuration files. The UI interface can be implemented based on the Vue framework. As the front-end web interface of the resource management platform, you can open the UI interface by accessing the service of the resource management platform through a browser, and complete operations such as container deployment and cluster status viewing by clicking. Optionally, the UI interface can also expand functions such as data statistics and real-time monitoring, monitor node resource usage in real time, and prevent the resource management platform from being unavailable due to excessive node resource usage.

[0028] In one embodiment, the platform layer includes general middleware and storage and log system components. The general middleware provides general functions such as configuration center and data overview statistics, communicates with the API interface of the core framework layer downward, and provides HTTP API to the external system layer upward; the storage and log system components adopt multiple storage solutions such as embedded distributed file system and distributed database, and design a unified log format and flexible log output objects.

[0029] Specifically, the general middleware draws on the idea of ​​microservice architecture to reduce the complexity of each component of the resource management platform, integrates some highly universal and frequently changing functions into the general middleware, and reduces the complexity of other components of the resource management platform.

[0030] The storage and log system components use multiple storage technologies such as embedded distributed file systems, distributed databases, and in-memory databases in storage solutions to avoid single-point failure problems in the database. The log system solution uses a unified log format design and flexible log output objects. It supports log filtering according to different attributes and can flexibly configure log output objects to improve the efficiency of troubleshooting when failures occur.

[0031] More specifically, the platform layer includes general middleware and storage log system components.

[0032] The general middleware is designed to aggregate functions that change frequently and are highly coupled to product customization, such as data overview statistics dimensions and data real-time update strategies. It provides data overview statistics, data real-time update and other functions to UI components, and communicates with the API server component, the core component of the resource management platform. Designing this type of function as a separately running component can, on the one hand, follow the principles of microservice architecture and reduce the complexity of the resource management platform; on the other hand, it can avoid frequent changes to the resource management platform.

[0033] Among the storage and log system components, the storage system is designed to avoid single point failure problems in the database, and the log system is designed to quickly locate and solve problems when failures occur.

[0034] In terms of storage systems, you can choose embedded distributed file systems and distributed databases; for scenarios with high real-time requirements, choose in-memory databases.

[0035] The embedded distributed file system can realize distributed management and storage of data among multiple nodes, integrate the file systems of different computers on the network, and allow users to access and operate files just like locally. Users do not need to pay attention to the location and method of actual data storage. The distributed file system will automatically handle these complex processes, support distributed file storage functions, and support elastic expansion, data redundancy, and remote network access functions.

[0036] Distributed databases ensure the high reliability of the entire system by distributing and storing data on multiple nodes. Even if a node fails, data backups on other nodes can quickly take over, ensuring service continuity and data integrity, and providing users with stable and reliable services. In-memory databases store data in computer memory instead of traditional disk storage, thereby achieving high-performance reading and writing and low latency. They are very suitable for scenarios with high real-time requirements. In-memory databases provide in-memory database servers and clients, cache and data management functions, and have transaction support and atomic operation characteristics to ensure data consistency and integrity.

[0037] In terms of the log system, it should be able to flexibly select the log output object, support standard output, log file output, log middleware or centralized log management system, and support flexible configuration of a single output target or simultaneous output to multiple targets; in terms of log content, a unified log format should be designed according to actual needs. The consistent log format makes the reading, understanding and analysis of information simpler and more direct.

[0038] In one embodiment, the core framework layer includes components such as API server, scheduler, controller, node agent, load balancing agent, location center, etc. These components are responsible for key functions such as data maintenance, container scheduling, container node status control, container deployment, and node data monitoring.

[0039] Specifically, the API server component, the core component of the resource management platform, is the request processor of the entire resource management platform and is responsible for all data storage and retrieval operations.

[0040] The scheduler component is responsible for allocating appropriate nodes to newly created container instances, ensuring that container allocation is based on the resource utilization of each node in the cluster and the scheduling requirements specified by the user.

[0041] The controller component is responsible for ensuring that the cluster status is consistent with expectations, such as node status, container status, and fault recovery, to ensure that the cluster is always in the expected state.

[0042] The node agent component is a bridge connecting the resource management platform and the container runtime. It ensures that the containers within the cluster run normally and stably as required. It is mainly responsible for container management, node resource management, health checks, and container runtime interfaces.

[0043] The load balancing proxy component is mainly used to shield the multi-instance application behind it for the caller, so that the caller always accesses an available instance without worrying about where the instance is located.

[0044] The location center component is responsible for service discovery and registration, as well as load balancing between service calls.

[0045] More specifically, the core framework layer includes six components: API server, scheduler, controller, node agent, load balancing agent, and location center.

[0046] The API server component is the core component of the resource management platform. It is the request processor of the entire resource management platform and can efficiently handle all requests from external clients. Each request will be strictly verified to ensure that it matches the current state of the cluster. Then the component will perform the corresponding logical operation. In addition, the component is also responsible for all data storage and retrieval operations.

[0047] The scheduler component is responsible for allocating appropriate nodes to newly created container instances, ensuring that container allocation is based on the resource utilization of each node in the cluster and the scheduling requirements specified by the user. The independence of this component allows the system to control the scheduler more flexibly, such as updating or customizing scheduling policies; The controller component is responsible for ensuring that the cluster status is consistent with expectations, such as node status, container replica control plan, container status, and fault recovery, to ensure that the cluster is always in the expected state. The independence of this component allows the system to adjust the system's control strategy more flexibly.

[0048] The node agent component is a bridge connecting the resource management platform and the container runtime, ensuring that the containers within the cluster run normally and stably as required. This component receives information from the API server component, starts, stops, and maintains the container, and regularly monitors the resource usage of the node, performs health checks on services and nodes, and reports information to the API server.

[0049] The load balancing proxy component is mainly used to shield the caller from the multiple instance applications behind it, so that the caller always accesses an available instance without worrying about where the instance is located. If a component has multiple instances, multiple IP:PORT addresses will be generated. Through the load balancing proxy component, the caller only needs to access a fixed IP:PORT, and the load balancing proxy component will automatically forward the traffic to an available instance.

[0050] The location center component is responsible for service discovery and registration, as well as load balancing between service calls. This component obtains the service data and health status of the entire cluster through the API server component, and updates the service routing table in real time, so that when a container service fails, the faulty service can be quickly removed and the healthy service address is always returned to the caller.

[0051] In one embodiment, the high-availability deployment strategy includes three deployment strategies: multi-instance deployment, active-standby deployment, and single-instance deployment, providing different deployment strategy options for components of different importance.

[0052] Specifically, multi-instance deployment deploys multiple instances of a core component on different or the same nodes that causes the resource management platform to be unavailable due to its absence or failure.

[0053] Active / standby deployment: For important components that cause the resource management platform to lose some important functions due to loss or failure, two instances of the components, one active and one standby, are deployed on different or the same nodes.

[0054] Single instance deployment: deploy one instance on one node for components that cause the resource management platform to lose some non-critical functions due to loss or failure.

[0055] More specifically, the high-availability deployment strategy includes three strategies. By adopting different deployment strategies for different components, high availability of the control plane and data plane can be achieved.

[0056] Multi-instance deployment: For core components that make the resource management platform unavailable due to loss or failure, such as API server components, you can choose multi-instance deployment to deploy multiple instances of the component on different or the same nodes.

[0057] Active-standby deployment: For important components that may cause the resource management platform to lose some important functions due to loss or failure, such as location center, controller and other components, you can choose active-standby deployment. Deploy components on different or the same nodes, one active and one standby, for a total of two instances.

[0058] Single instance deployment: For components that are missing or fail and cause the resource management platform to lose some non-critical functions, you can choose a single instance deployment strategy and deploy one instance on one node.

[0059] In a specific embodiment, the present application provides a high-availability resource management platform for the aviation field, including an external system layer, a platform layer, a core framework layer, and a high-availability deployment strategy module. The present application is further described below in conjunction with the accompanying drawings and embodiments; Figure 2 This is an implementation method of the high-availability resource management platform of the present application. This system includes four nodes, one of which serves as a management node, namely the Master node, and the other three serve as Node nodes. The Master node communicates data with the Node nodes via an Ethernet data link or other data links.

[0060] In terms of storage systems, the distributed file system can be selected but not limited to the network file system NFS, which realizes the distributed management and storage of data among multiple nodes; the distributed database can be selected but not limited to ETCD, which realizes the configuration management, service discovery and distributed lock functions in the distributed system. Optionally, the distributed file system can also choose Ceph, HDFS and other distributed file systems, and the distributed database can also choose MongoDB, Redis and other distributed databases.

[0061] For the log system, you can refer to the following log format, which includes four parts: timestamp, resource, attribute, and body. When querying logs, you can selectively aggregate the content of each part to increase the efficiency of troubleshooting.

[0062] Optionally, the high-availability resource management platform can connect to multiple Node nodes for management, and each Node node can run multiple containers and services.

[0063] In terms of component deployment, considering that the concurrency of UI and general middleware is relatively small, a master-slave deployment strategy is implemented: deploy the master instance on the Master node, so that it can access the local API server component to obtain and synchronize data to ensure the performance of the resource management platform; deploy the backup instance on the Node node, so that it can replace the master instance when it is abnormal, ensuring the normal operation of the resource management platform. In addition, cross-node deployment can balance the resource consumption of each node to a certain extent, which is more conducive to achieving high availability of the resource management platform.

[0064] The Master node also needs to deploy components such as the API server component, scheduler component, location center component, and controller component. The API server component is responsible for request processing, data storage and retrieval, and cluster management. It is the central nervous system in the cluster and plays a vital role in ensuring the stable operation of the cluster. Therefore, multi-instance deployment is used to ensure the high availability of the resource management platform. The controller component is responsible for ensuring that the cluster status is consistent with expectations, the scheduler component is responsible for allocating appropriate nodes to newly created container instances, and the location center component is responsible for service discovery and registration as well as load balancing of calls between services. The functions of the above three components are relatively clear, and the master node is deployed in a master-slave manner to ensure its high availability.

[0065] The Node node needs to deploy the load balancing proxy component and the node proxy component. The node proxy component is responsible for the management of node containers and resources, and interacts with the container runtime. It is the bridge for the node to connect to the cluster. The load balancing proxy component obtains the service data and health status of the entire cluster through the API server component, and updates the service routing table in real time, so that the caller can always access the available instance. That is, the load balancing proxy component is the key to external traffic, and the node proxy component is the key to the normal operation of the node. Therefore, both use the active-standby deployment method to ensure the high availability of the Node node.

[0066] In the high availability resource management platform of this application, the high availability of the control plane is as follows: Figure 3As shown. External traffic from the resource management platform reaches the load balancing proxy component through the general middleware. The load balancing proxy component maintains the IP:Port addresses of multiple instances of an API server component and always provides an available IP:Port address to the outside. The load balancing proxy component then forwards the traffic to the API server component at the IP:Port address, and the API server performs relevant processing based on the content of the external traffic request. Through the architecture of this application, it is possible to shield the caller from the multi-instance application behind it and always access an available API component instance without having to worry about where the instance is located. When an API server component fails, the load balancing proxy component will forward new external traffic to other available API server components, thereby always maintaining available services to the outside world and achieving high availability of the control plane.

[0067] In terms of data consistency, multiple API server component instances access the same distributed database, and by persisting the state data in the distributed database, the state of the entire cluster in the resource management platform is kept consistent. Externally, multiple API server component instances provide consistent data services to the outside world, and external request traffic will not have data inconsistencies due to accessing different API server component instances.

[0068] In the high availability resource management platform of this application, the high availability of the data plane is as follows: Figure 4 As mentioned above, the location center component is responsible for service registration, discovery, and load balancing of traffic between services within the cluster. This component is deployed independently of other control plane components, ensuring that even if the control plane component fails, the component can still provide services to the outside world. However, data cannot be updated until the control plane component returns to normal.

[0069] When application 1 in the resource management platform needs to access application 2 on the same node or application 3 on other nodes, it first accesses the location center component through the load balancing proxy component to query the target address of the service corresponding to application 2 or application 3, and application 1 accesses application 2 or application 3 through this address. When the control plane component, such as the API server component, fails, the location center component cannot obtain the service data and health status of the entire cluster through the API server component. At this time, the location center component just cannot update the service routing table, but can still discover and load balance services through the original routing service table, achieving high availability of the data plane.

[0070] This embodiment is only one of the embodiments of the present application, and the implementation of the present application is not limited to this embodiment.

[0071] Through the above-mentioned high-availability resource management platform for the aviation field, the resource management platform includes an external system layer, a platform layer, a core framework layer and a high-availability deployment strategy module. By splitting components and adopting different high-availability deployment strategies for different components, the high availability of the data plane and the control plane is guaranteed in a resource-constrained environment, thereby achieving high stability of the resource management platform.

[0072] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0073] It should be noted that although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiment of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of a module or unit described above can be further divided into multiple modules or units for concretization. The components displayed as modules or units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. Those of ordinary skill in the art can understand and implement it without paying creative work.

[0074] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present disclosure are indicated by the appended claims.

Claims

1. A high-availability resource management platform for the aviation field, characterized in that: include: External system layer, platform layer, core framework layer and high availability deployment strategy module; among them, The external system layer, including the UI components displayed on the front end, controls and monitors cluster resources through the HTTP API provided by the platform layer; The platform layer includes a general middleware and a storage and log system component. The general middleware is used to provide a configuration center and data overview statistics functions, communicate with the API server of the core framework layer downward, and provide the HTTP API to the external system layer upward; the storage and log system component is used to adopt an embedded distributed file system, a distributed database, and an in-memory database storage solution, and design a unified log format and flexible log output objects; The core framework layer includes an API server component, a scheduler component, a controller component, a node agent component, a load balancing agent component, and a location center component, which are responsible for data maintenance, container scheduling, container node status control, container deployment, and node data monitoring; The high-availability deployment strategy module is used to provide different deployment strategies for different components; wherein the deployment strategies include multi-instance deployment, active-standby deployment and single-instance deployment.

2. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The UI component is used to provide a graphical interactive interface, access the resource management platform through a web browser, and the user interacts with the resource management platform by clicking on the page; wherein, the cluster status and container deployment operations can be viewed in the interactive interface, and the creation, operation, deletion, query and suspension of containers are supported.

3. The high-availability resource management platform for the aviation field according to claim 1 is characterized in that: The general middleware is used to integrate some functions with strong universality and high frequency of change into the general middleware, thereby reducing the complexity of other components.

4. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The storage and log system components are used to adopt embedded distributed file systems, distributed databases and memory database storage solutions in storage solutions to avoid single point failure problems of databases; the log system adopts a unified log format design, supports log screening according to different attributes, and can configure log output objects to improve the efficiency of troubleshooting when failures occur.

5. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The API server component is the request processor of the resource management platform and is responsible for all data storage and retrieval operations; The scheduler component is responsible for allocating appropriate nodes for newly created container instances, ensuring that container allocation is based on resource utilization of each node in the cluster and user-specified scheduling requirements; The controller component is responsible for ensuring that the cluster state is consistent with expectations and that the cluster is always in the expected state; The node agent component is used to connect the resource management platform and the container to ensure that the containers within the cluster run normally and stably according to the required status. It is responsible for container management, node resource management, health check and container runtime interface. The load balancing proxy component is used for the caller to shield the multi-instance application behind it, so that the caller always accesses an available instance. The location center component is responsible for service discovery and registration, and is also responsible for load balancing of calls between services.

6. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The multi-instance deployment deploys multiple instances of a core component that makes the resource management platform unavailable due to its absence or failure, on different or the same nodes.

7. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The active-standby deployment deploys two instances of a component, one active and one standby, on different or the same nodes for important components that are missing or fail and cause the resource management platform to lose some important functions.

8. The high-availability resource management platform for the aviation field according to claim 1, characterized in that: The single instance deployment deploys one instance on one node for components that are missing or fail, causing the resource management platform to lose some non-important functions.

Images