A multi-application container management method and system supporting custom resource sharing

Abstract

The present invention relates to a multi-application container management method and system supporting customized resource sharing. By setting internal container policies, resource synchronization mechanism and scheduling mechanism are added on the basis of basic containers, a registration mechanism is provided for applications that need to share resources to meet the controllable sharing of resources between applications, and a unified external interface and scheduling strategy are provided for all applications belonging to the system to better utilize various system resources, match global asynchronous tasks, and process asynchronous tasks with high resource consumption and timed execution tasks in a more flexible and efficient manner to meet the control requirements of relatively independent and partially synchronized control between applications.

Description

Technical Field

[0001] The present invention relates to the technical field of computer application information processing, and in particular to a multi-application container management method and system supporting user-defined resource sharing. Background Art

[0002] Containers provide isolated operating spaces for applications: each container contains a complete user environment space, and changes in one container will not affect the operating environment of other containers. The use of containerization technology can optimize resource usage, meet environmental consistency, and effectively improve operation and maintenance efficiency overall.

[0003] However, existing container management technologies mainly focus on scheduling and resource allocation of the same application (the same type of application) on multiple containers. They require high homogeneity between containers and are difficult to apply to complex situations. At the same time, a single container can only be used for a specific application, and further system division cannot be performed within the container, which cannot meet the needs of multiple applications to share some application resources.

[0004] In actual applications, since each application in the system needs to run independently of each other, and each application will call some common cache data and configuration files, it is inevitable to configure each container independently under the existing container management method, and public data cannot be shared, wasting resources. Summary of the invention

[0005] To address the deficiencies in the prior art, the present invention proposes a multi-application container management method and system that supports custom resource sharing. By setting container internal policies, a resource synchronization mechanism and a scheduling mechanism are added on the basis of the basic container, and a registration mechanism is provided for applications that need to share resources to meet the controllable sharing of resources between applications. A unified external interface and scheduling strategy are provided for all applications belonging to the system to better utilize various system resources, and to match global asynchronous tasks to process high-resource-consuming asynchronous tasks and scheduled tasks in a more flexible and efficient manner, to meet the control requirements of relatively independent and partially synchronized control between applications.

[0006] To achieve the above objectives, the technical solutions adopted by the present invention include:

[0007] A multi-application container management method supporting custom resource sharing, characterized by comprising:

[0008] Create one or more containers on the application server and create corresponding processes for the containers;

[0009] Configure the only external interface of the application on the application server;

[0010] Registering an application to a container, including registering the same application to multiple different containers and / or registering multiple different applications to the same container;

[0011] Save the application registration information to the database;

[0012] Receive transaction requests and match corresponding applications according to the transaction requests;

[0013] Retrieve the registration information of the corresponding application from the database;

[0014] Query the load status of the corresponding container according to the registration information, and allocate the transaction request to the container with the lower load status;

[0015] The corresponding application registered on the container with a lower load status receives the transaction request through the only external interface, outputs the processing result of the transaction request through the only external interface, and generates a data bus corresponding to the transaction request in the container at the same time;

[0016] Feedback the processing result of the transaction request to the transaction initiator.

[0017] Furthermore, the method further comprises:

[0018] After assigning the transaction request to a container with a lower load status, the time required for executing the transaction request, the amount of resources occupied, and the real-time feedback requirements are estimated, and the transaction request that meets the preset standards is generated as a global asynchronous task and a unique identifier is attached, wherein the unique identifier includes the necessary information required to execute the global asynchronous task;

[0019] The container suspends execution of the generated global asynchronous tasks.

[0020] Furthermore, the method further comprises:

[0021] Any container in the system scans the unique identifier of the global asynchronous task. When a container matches the necessary information included in the unique identifier and the current load status of the container is low, the global asynchronous task is assigned to the container for execution.

[0022] Furthermore, the method further comprises:

[0023] When multiple different containers simultaneously match the necessary information included in the unique identifier and the current load status of the container is low, the container that generates the global asynchronous task is preferentially allocated.

[0024] Furthermore, the method further comprises:

[0025] When the system includes multiple different application servers, one or more containers are established on each application server, including establishing different containers on the same application server and / or establishing the same container on different application servers, and establishing corresponding processes for the containers;

[0026] Configure the application's unique external interface on each application server;

[0027] Registering an application to a container includes registering the same application to multiple different containers on the same application server, and / or registering the same application to multiple different containers on different application servers, and / or registering multiple different applications to the same container on the same application server.

[0028] Furthermore, the method further comprises:

[0029] The load status of the corresponding application server and container is queried according to the registration information, and the transaction request is allocated to the application server and container with lower load status.

[0030] Furthermore, querying the load status of the corresponding application server and container includes querying the thread pool status, memory and CPU usage, handle usage and database connection pool occupancy of the corresponding application server and container.

[0031] Furthermore, the method further comprises:

[0032] All applications registered to the same container share cache resources in the container, which include configuration files, public data, and dependent packages.

[0033] The present invention also relates to a multi-application container management system supporting custom resource sharing, which is characterized by comprising:

[0034] The front-end server layer includes a front-end dispatching server for receiving transaction requests and distributing the transaction requests to application servers and containers with lower load status;

[0035] The application server layer includes one or more application servers and is connected to the front-end server layer;

[0036] The container layer built within the application server includes one or more containers;

[0037] The application layer registered in the container includes one or more applications;

[0038] The database layer is used to store application registration information.

[0039] The present invention also relates to an electronic device, characterized in that it comprises a processor and a memory;

[0040] The memory is used to store registration information of the application;

[0041] The processor is used to execute the above method by calling the registration information of the application.

[0042] The beneficial effects of the present invention are:

[0043] The multi-application container management method and system supporting customized resource sharing described in the present invention are adopted. By setting the internal policy of the container, a resource synchronization mechanism and a scheduling mechanism are added on the basis of the basic container, and a registration mechanism is provided for applications that need to share resources to meet the controllable sharing of resources between applications, and a unified external interface and scheduling strategy are provided for all applications belonging to the system to better utilize various system resources, match global asynchronous tasks, and process high-resource-consuming asynchronous tasks and timed execution tasks in a more flexible and efficient manner, so as to meet the control requirements of relatively independent and partially synchronized control between applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 The present invention is a flowchart of a multi-application container management method that supports sharing of custom resources.

[0045] Figure 2 This is a schematic diagram of the structure of a multi-application container management system that supports custom resource sharing in the present invention. DETAILED DESCRIPTION

[0046] In order to more clearly understand the content of the present invention, it will be described in detail with reference to the drawings and embodiments.

[0047] like Figure 1 The figure is a flow chart of a multi-application container management method supporting custom resource sharing according to the present invention, which includes the following steps:

[0048] Create one or more containers on each application server in the system and create corresponding processes for the containers;

[0049] Configure the application's unique external interface on each application server;

[0050] Registering the application to the container includes registering the same application to multiple different containers on the same application server, and / or, registering the same application to multiple different containers on different application servers, and / or, registering multiple different applications to the same container on the same application server;

[0051] Save the application registration information to the database;

[0052] Receive transaction requests and match corresponding applications according to the transaction requests;

[0053] Retrieve the registration information of the corresponding application from the database;

[0054] Query the load status of the corresponding application server and container according to the registration information, and distribute the transaction request to the application server and container with lower load status; the querying of the load status of the corresponding application server and container includes querying the thread pool status, memory and CPU usage, handle usage and database connection pool occupancy of the corresponding application server and container;

[0055] Estimate the time required for the execution of the transaction request, the amount of resources occupied, and the real-time feedback requirements, and generate the transaction request that meets the preset standards as a global asynchronous task and attach a unique identifier, wherein the unique identifier includes the necessary information required to execute the global asynchronous task; at the same time, the container suspends the execution of the generated global asynchronous task;

[0056] The corresponding application registered on the container with a lower load status receives the transaction request through the only external interface, outputs the processing result of the transaction request through the only external interface, and generates a data bus corresponding to the transaction request in the container at the same time;

[0057] Any container in the system scans the unique identifier of the global asynchronous task. When a container matches the necessary information included in the unique identifier and the current load status of the container is low, the global asynchronous task is assigned to the container for execution; in particular, the container that generates the global asynchronous task will be assigned preferentially;

[0058] Feedback the processing result of the transaction request to the transaction initiator.

[0059] Through the above method, each application can be registered on any number of containers, and a container can also register any number of applications (the specific number of registrations can be adjusted and optimized according to the system resources required by the application), and each application occupies a unique external interface on the same server. Each container has a corresponding process on the server, so all applications in the same container can share cache resources. In order to make the applications in the container run relatively independently, each application will generate a corresponding data bus each time it completes the corresponding transaction. The buses between transactions are independent of each other and will not affect the data of other transactions. Therefore, for the resources in the cache, such as configuration files, public data, dependency packages, etc., each application can share them, and some cached data can also be modified while meeting business needs.

[0060] When a transaction needs to execute a task that takes a long time and occupies a lot of resources, but does not require real-time feedback, it can be converted into a global asynchronous task in the entire system. A global asynchronous task has a unique identifier and carries all the key information required to execute the task. It can be executed by any server in the system. Each container of each server in the system will scan these global asynchronous tasks regularly. If the current container is relatively idle, it will preempt the task and execute it. Preferably, the asynchronous task will be preempted and executed by the container that generated the task.

[0061] like Figure 2 The figure shows a schematic diagram of the structure of a multi-application container management system supporting custom resource sharing according to the present invention, including:

[0062] The front-end server layer is used to receive transaction requests and distribute them to application servers and containers with lower load status;

[0063] The application server layer includes one or more application servers and is connected to the front-end server layer;

[0064] The container layer built within the application server includes one or more containers;

[0065] The application layer registered in the container includes one or more applications;

[0066] The database layer is used to store application registration information.

[0067] In the specific application process, all application servers and containers have a unified front-end dispatch server. The outside world will not interact directly with the backend application, but will be transmitted through the front-end dispatch server. The front-end dispatch server will synchronize the registration information of the application, and when receiving a transaction request, it will dynamically adjust the forwarding to the backend server and the corresponding application port based on the load status of each server and container of the application corresponding to the transaction, combined with the preset threshold configuration. After the transaction is completed, the return information will also be returned from the application to the initiator through the front-end dispatch server to prevent attack requests from directly requesting the backend, thereby improving the security of the system.

[0068] like Figure 2As shown, when transaction 1 initiates a request to the front-end scheduling server, the front-end scheduling server will obtain the application server and container information (container I on server 1 and server 2 and container II on server 2) that can execute the transaction based on the application registration information (obtained from the database and stored in the cache), and select a container of a relatively idle server according to the running status of each qualified server container in Redis, and forward the transaction request to the port of the corresponding application of the server. Application A will determine the specific transaction to be executed based on the necessary information in the forwarded request, return it to the front-end scheduling server after execution, and finally return it to the service initiator. During this period, there will be no direct interaction between the server initiator and the service executor, and all communications will pass through the front-end scheduling server.

[0069] When a transaction generates a corresponding global asynchronous task, the corresponding task execution key information will be inserted into the database. Each container has a dedicated thread to periodically query the database for global asynchronous tasks (or scheduled tasks) waiting to be executed. When searching for tasks that need to be executed, it will make a judgment based on the resource status of its own server. If it meets the idle conditions, it will try to preempt the global asynchronous task (modify the flag of the global asynchronous task). After the preemption is successful, the detailed information of the global asynchronous task will be obtained and the corresponding task will be executed. After successful execution, the execution result will be recorded in the database and the flag of the global asynchronous task will be modified.

[0070] The above is only a preferred specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A multi-application container management method supporting custom resource sharing, characterized in that: include: Create one or more containers on the application server and create corresponding processes for the containers; Configure the only external interface of the application on the application server; Registering an application to a container, including registering the same application to multiple different containers and / or registering multiple different applications to the same container; Save the application registration information to the database; Receive transaction requests and match corresponding applications according to the transaction requests; Retrieve the registration information of the corresponding application from the database; Query the load status of the corresponding container according to the registration information, and allocate the transaction request to the container with the lower load status; The corresponding application registered on the container with a lower load status receives the transaction request through the only external interface, outputs the processing result of the transaction request through the only external interface, and generates a data bus corresponding to the transaction request in the container at the same time; Feedback the processing result of the transaction request to the transaction initiator; The method further comprises: After assigning the transaction request to a container with a lower load status, the time required for executing the transaction request, the amount of resources occupied, and the real-time feedback requirements are estimated, and the transaction request that meets the preset standards is generated as a global asynchronous task and a unique identifier is attached, wherein the unique identifier includes the necessary information required to execute the global asynchronous task; The container suspends execution of the generated global asynchronous tasks.

2. The method according to claim 1, characterized in that The method further comprises: Any container in the system scans the unique identifier of the global asynchronous task. When a container matches the necessary information included in the unique identifier and the current load status of the container is low, the global asynchronous task is assigned to the container for execution.

3. The method according to claim 2, characterized in that The method further comprises: When multiple different containers simultaneously match the necessary information included in the unique identifier and the current load status of the container is low, the container that generates the global asynchronous task is preferentially allocated.

4. The method according to claim 1, characterized in that The method further comprises: When the system includes multiple different application servers, one or more containers are established on each application server, including establishing different containers on the same application server and / or establishing the same container on different application servers, and establishing corresponding processes for the containers; Configure the application's unique external interface on each application server; Registering an application to a container includes registering the same application to multiple different containers on the same application server, and / or registering the same application to multiple different containers on different application servers, and / or registering multiple different applications to the same container on the same application server.

5. The method according to claim 4, characterized in that The method further comprises: The load status of the corresponding application server and container is queried according to the registration information, and the transaction request is allocated to the application server and container with lower load status.

6. The method according to claim 5, characterized in that The querying of the load status of the corresponding application server and container includes querying the thread pool status, memory and CPU usage, handle usage and database connection pool occupancy of the corresponding application server and container.

7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: All applications registered to the same container share cache resources in the container, which include configuration files, public data, and dependent packages.

8. A multi-application container management system supporting custom resource sharing, characterized in that: include: The front-end server layer includes a front-end dispatching server for receiving transaction requests and distributing the transaction requests to application servers and containers with lower load status; The application server layer includes one or more application servers and is connected to the front-end server layer; The container layer built within the application server includes one or more containers; The application layer registered in the container includes one or more applications; Database layer, used to store application registration information; The system further includes: after allocating the transaction request to the container with a lower load status, estimating the time required for executing the transaction request, the amount of resources occupied, and the real-time feedback requirements, and generating the transaction request that meets the preset standard as a global asynchronous task and attaching a unique identifier, wherein the unique identifier includes necessary information required for executing the global asynchronous task; The container suspends execution of the generated global asynchronous tasks.

9. An electronic device, characterized in that: including a processor and a memory; The memory is used to store registration information of the application; The processor is used to execute the method according to any one of claims 1 to 7 by calling the registration information of the application.

Images