A container-unperceived startup method and system

Abstract

The present invention discloses a serverless platform-based container startup method and system. The method includes the following steps: using an interpreter to analyze user requests and sending them to a cold standby or hot standby queue; a processor to perform security authentication on user request instructions in the cold standby and hot standby queues, clustering and analyzing user requests that pass security authentication, and forwarding the user request instructions after cluster analysis to a container manager; the container manager is responsible for creating containers, calling trigger functions, and scheduling containers; and a resource monitor is responsible for creating, updating, and shutting down containers in the hot standby pool, including merging containers, decomposing containers whose memory or CPU usage exceeds thresholds, and periodically starting and stopping containers. Compared with existing technologies, the present invention accelerates container initialization and dependent package loading, while effectively conserving resources.

Description

Technical Field

[0001] The present invention relates to a container non-perception startup method and system, belonging to the technical field of cloud computing. Background Art

[0002] With the continuous development of cloud computing technology, serverless technology has become an inevitable trend in the development of cloud computing. Enterprises only need to pay cloud providers for renting resources, and they can use resources to call services when user requests arrive. When there are no user requests, no resources are used, and billing is based on the number and duration of calls. Compared with traditional online service models, serverless computing greatly reduces user costs, allowing users to completely avoid server configuration issues, thereby simplifying development and providing better scalability than traditional online services. However, serverless uses an on-demand structure and deletes idle function instances at runtime. Therefore, when the function is called again, the platform will restart a new instance and redeploy the operating environment and software code. This results in significant function startup delays during service calls, seriously affecting the serverless model's responsiveness.

[0003] Therefore, many researchers have proposed optimizations for the serverless cold start problem. For example, Oakes et al. attempted to reduce cloud function startup time by caching the required function packages on worker nodes. They proposed a shared package cache. When a cloud function is assigned to a worker node, the cache checks whether the required packages are cached. However, the drawback is that a large number of cached packages consumes service resources. Mohan et al. adopted a container pool strategy to reduce cold start latency. They pre-run empty containers so that when a function is triggered, new containers can be directly obtained from the container pool without restarting them. However, this method uses a static container pool capacity, which can lead to resource waste when function user requests are low. Harter et al. studied the software packages installed when starting a function instance, prioritizing necessary packages for rapid software deployment and delaying the loading of non-essential packages. Although this method can effectively reduce instance startup latency, it still cannot prevent cold starts and is difficult to meet the requirements of fast-response functions. Summary of the Invention

[0004] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a container-aware startup method and system that can reduce the latency of serverless computing calls.

[0005] To achieve the above object, the present invention is implemented by adopting the following technical solutions:

[0006] In a first aspect, the present invention provides a method for starting a container without any perception, the method comprising:

[0007] Receive and parse user requests to obtain the software packages required by the user requests;

[0008] The software package name is used as a keyword to match container information with the local database. Based on the matching result, the user request is placed in the cold standby queue or hot standby queue.

[0009] Perform security authentication on user requests from cold and hot standby queues, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user requests;

[0010] If the instruction requested by the user comes from the hot standby queue, a running container with the highest similarity is selected in the hot standby pool as the target container to execute the function event requested by the user;

[0011] If the user's requested instruction comes from the cold standby queue, a new container is created in the cold standby pool and scheduled to the hot standby pool.

[0012] In combination with the first aspect, further, a method of inserting a user request into a cold standby queue or a hot standby queue according to a matching result includes:

[0013] If the container information matching result is empty, a label with an attribute value of 0 is attached to the user request and the user request is placed in the cold standby queue;

[0014] If the container information matches n containers, the user request is labeled with the attribute value of the information list of n containers and the user request is placed in the hot standby queue;

[0015] Where n = 1, 2, 3, ...; the container information list includes: container CPU information, memory information, disk space information, number of software packages, and the size of each software package.

[0016] In combination with the first aspect, further, the method of performing cluster analysis on user requests that pass security authentication includes:

[0017] User requests with a label attribute value of 0 are classified into one category, which has the lowest priority;

[0018] When the attribute value of the label attached to the user request is non-zero, secondary clustering is performed, and two user requests with non-zero attribute values ​​are randomly selected. a 、r b , calculate r a 、r b The intersection of dependent environments:

[0019] r a ∩r b ={s1…,s m},

[0020] Among them, r a 、rb Indicates user request; s m represents the intersection of dependent environments;

[0021] When the value of the intersection of dependent environments accounts for 50% or more of the total dependent environments, the user request r a , r b Classified into one category, this type of user request has a higher priority than user requests whose dependency environment intersection value accounts for less than 50% of the total dependency environments.

[0022] In combination with the first aspect, further, the similarity of the containers is calculated using the following formula:

[0023]

[0024] Among them, Z i Indicates the similarity of container i; w1+w2+w3=1, c i 、m i They represent the CPU usage and memory usage of container i, respectively. si Indicates the number of software packages that container i hits user requests, M d T si The size of each software package in the hot standby pool, t represents the total number of containers in the hot standby pool, and T and M are the number and total size of the software packages that the user requests depend on, respectively.

[0025] In combination with the first aspect, further, the security authentication includes authenticating the source, authority and function of the user request.

[0026] In combination with the first aspect, the method further includes dynamically monitoring the hot standby pool, including merging containers, decomposing containers and / or periodically starting and stopping containers.

[0027] In combination with the first aspect, further, the method for merging containers includes:

[0028] Calculate the similarity between two containers in the local database container information table;

[0029] If the similarity is less than the set threshold, the two containers are merged to form a new container and added to the local database container information table;

[0030] The two merged containers meet the following requirements: the container functions are inactive before the merger; after the merger, the CPU, memory, and disk space usage of the new container do not exceed the corresponding set thresholds.

[0031] In combination with the first aspect, further, before calculating the similarity between two containers in the container information table of the local database, the attribute values ​​of the two containers are standardized and normalized.

[0032] In combination with the first aspect, further, the method for decomposing the container includes:

[0033] Query the container's software package information from the local database to obtain software package attribute values ​​including at least the number of times the software package has been installed in different containers.

[0034] Sort the software packages by the number of times they are installed in different containers, and select the software packages whose number of times they are installed in different containers is not less than the set threshold.

[0035] Start a new container in the hot standby pool, schedule the removed software package to the new container, update the local database container information table, and the container decomposition is completed.

[0036] In combination with the first aspect, further, the method for periodically starting and stopping a container includes:

[0037] Query the container in the hot standby pool, according to the container at time T set The number of times it is called within a period predicts the time period for the next start and stop;

[0038] If the predicted stop time of a container is less than or equal to the current time, if the container is in the running state, the container is stopped and the next start time of the container is predicted. If the predicted start time of a container is less than or equal to the current time, if the container is in the stopped state, the container is started immediately and the next stop time of the container is predicted.

[0039] The container is not in the predicted start and stop time period. Query the container at time T set The number of internal cold starts and the total number of starts. The number of cold starts indicates the number of times the container is passively started due to predicted failures.

[0040] In the event of a container prediction failure, the prediction function is re-optimized and the updated prediction function is used to predict the next start and stop time period of the container.

[0041] In a second aspect, the present invention provides a container non-perception startup system, the system comprising:

[0042] Interpreter: Receives and parses user requests to obtain the software packages required by the user requests. It uses the software package name as a keyword to match container information with the local database and places the user request into the cold standby queue or hot standby queue based on the matching result.

[0043] Processor: Used to perform security authentication on user requests from cold standby queues and hot standby queues, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user request;

[0044] Container Manager: When the user-requested instruction comes from the hot standby queue, it selects a running container with the highest similarity in the hot standby pool as the target container to execute the function event requested by the user; and when the user-requested instruction comes from the cold standby queue, it creates a new container in the cold standby pool and schedules the new container to the hot standby pool.

[0045] In combination with the second aspect, the system further includes a resource monitor: used to dynamically monitor the hot standby pool, including merging containers, decomposing containers and / or periodically starting and stopping containers.

[0046] Compared with the prior art, the present invention has the following beneficial effects:

[0047] 1. This invention addresses the performance bottleneck caused by resource competition due to frequent container creation in serverless computing scenarios. It introduces a container confidence matching strategy. The container with the highest similarity in the hot standby pool is used as the target container trigger function, reducing the dependency package loading time and container initialization time, thereby improving the overall performance of the platform.

[0048] 2. To address the problem of existing serverless computing platforms immediately destroying containers after executing serverless instances, this paper designs a hot standby pool caching container strategy. This strategy prevents containers from being immediately destroyed after executing serverless instances. This reduces the overhead of container startup and software package preparation, and improves overall system resource utilization.

[0049] 3. This paper addresses the problem of multiple containers with the same environment occupying platform resources in existing serverless computing platforms. By merging containers with similar dependency environments, this paper increases the probability of a container hitting the next user request, reducing container cold start time and resource waste.

[0050] 4. In view of the need of existing serverless computing platforms to force inactive function containers to be kept in an active state, the present invention designs a container periodic start and stop strategy. By predicting the next startup time period of the container, the container is kept in a stopped state during the non-startup time period, reducing the system's memory, CPU and other resource overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 A schematic diagram of the structure of a serverless container startup system based on a serverless platform provided in an embodiment of the present invention;

[0052] Figure 2 A flow chart of a container matching method based on a serverless platform provided in an embodiment of the present invention;

[0053] Figure 3 A schematic diagram of the structure of container merging based on a serverless platform provided in an embodiment of the present invention;

[0054] Figure 4 A schematic diagram of the structure of container decomposition based on a serverless platform provided by an embodiment of the present invention;

[0055] Figure 5 This is a flow chart of a method for periodically inspecting and starting and stopping containers based on a serverless platform, provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0056] The technical solution of the present invention is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present application and the specific features in the embodiments are detailed descriptions of the technical solution of the present application, rather than limitations on the technical solution of the present application. Unless there is a conflict, the embodiments of the present application and the technical features in the embodiments can be combined with each other.

[0057] The term "and / or" in this article is merely a description of the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0058] Example 1:

[0059] An embodiment of the present invention provides a method for starting a container without awareness, which is implemented based on a serverless platform and specifically includes the following steps:

[0060] Step 1: The service access gateway receives a user request, which includes function dependencies and function source code, to obtain the software package required by the user request. The software package is the software package installed when the function instance is started.

[0061] Step 2: Use the software package name as a keyword to match container information with the local database. Based on the matching result, the user request is placed in the cold standby queue or hot standby queue.

[0062] This embodiment of the present invention uses a tree structure to store container information and dependent software packages. After parsing the dependent software package required by the user request, the container information is matched against the local database using the software package name as a key. If no matching information is found, the user request is labeled with an attribute value of 0 and placed in a cold standby queue, awaiting call forwarding.

[0063] If n containers are matched, the user request is labeled with an attribute value that contains a list of n containers, and the user request is placed in the hot standby queue.

[0064] Where n = 1, 2, 3, etc. The container information list includes: container CPU information, memory information, disk space information, number of software packages, and the size of each software package.

[0065] Step 3: Perform security authentication on user requests from the cold standby queue and the hot standby queue, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user requests. This includes:

[0066] After the processor reads the request from the cold standby queue and the hot standby queue, it first performs a security check on the user request, including verifying the source, permissions, and functions of the information. If the user request information is abnormal, the user request is filtered and an alarm is issued;

[0067] Once the user request passes the security check, cluster analysis of the user request begins:

[0068] User requests with a label attribute value of 0 are classified into one category and have the lowest priority;

[0069] When the attribute value of the label attached to the user request is non-zero, secondary clustering is performed. Specifically, assuming that the non-zero user request is r a , r b , then r a , r b The intersection of the dependent environments is: r a ∩r b ={s1…,s m}; where r a Indicates, r b Indicates user request, s m represents the intersection of dependent environments;

[0070] When the value of the intersection of dependent environments accounts for 50% or more of the total dependent environments, the user request r a , r b Classified into the first category, this type of user request has a higher priority than user requests whose dependency environment intersection value accounts for less than 50% of the total dependency environment;

[0071] The embodiment of the present invention prioritizes user requests through cluster analysis, which has the advantage that user requests of the same type can share the same container with a high probability, reducing the loading and initialization of dependent packages in the container.

[0072] Step 4: If the instruction requested by the user comes from the hot standby queue, a running container with the highest similarity is selected in the hot standby pool as the target container to execute the function event requested by the user. The similarity of the containers can be calculated using the following formula:

[0073]

[0074] Among them, w is used to represent the weight, then w1+w2+w3=1, c i 、m iRespectively represent the CPU usage and memory usage of container i; T si Indicates the number of software packages that container i hits user requests, M d T si The size of each software package in the hot standby pool, t represents the total number of containers in the hot standby pool, and T and M are the number and total size of software packages that the user requests depend on, respectively.

[0075] Step 5: If the user request instruction comes from the cold standby queue, a new container is created in the cold standby pool and scheduled to the hot standby pool.

[0076] like Figure 2 FIG. 1 is a method for quickly matching containers provided by an embodiment of the present invention, comprising the following steps:

[0077] Step 201: Use the software package name as a keyword to match container information with the local database, and insert the user request into the cold standby queue or the hot standby queue according to the matching result. The user request of the hot standby queue has a higher priority than the cold standby queue.

[0078] Step 202: After receiving the user request instruction from the hot standby queue, the container manager immediately executes the similarity matching algorithm to quickly match the running container with the highest similarity as the target container.

[0079] Step 203: After receiving the user request instruction from the cold standby queue, the container manager immediately starts a new container in the cold standby area as the target container.

[0080] Step 204: The container manager checks the dependency packages installed in the target container and compares them with the software packages required in the instruction user request. If the target container dependency environment is greater than or equal to the software packages required in the instruction user request, the process proceeds to step 209; otherwise, the process proceeds to step 205.

[0081] Step 205: This embodiment of the present invention supports local software package caching. The cached information is stored in local data via the structure of a software registration list. The processor confirms whether the software package has been cached by querying the software registration list.

[0082] Step 206: If no software information is found in the software registration list, the container manager initiates a user request to the image repository to pull the software into the local container.

[0083] Step 207: Update the software registration list and cache the software to the local node.

[0084] Step 208: When the software registration list can be queried for software information, the software is directly pulled from the local computer into the container.

[0085] Step 209: After the dependent environment in the target container is prepared, the function trigger is executed to complete the task requested by the user.

[0086] The serverless platform-based container startup method provided by an embodiment of the present invention also includes dynamic monitoring of the hot standby pool. The resource monitor is responsible for the creation, update and shutdown of containers in the hot standby pool, including merging containers, decomposing containers and / or periodically starting and stopping containers.

[0087] Merging containers refers to merging containers with the same attributes. The purpose is to reduce the number of running containers and avoid wasting platform resources. Secondly, after merging containers with the same attributes, the container contains more complete dependency environments, which increases the probability of user request hits and avoids container cold start processes.

[0088] The following explains the container merging method:

[0089] Assume that the local database query container information table is {d1,d2...,d n}, where container d i The attribute value is {l1,l2...,l m};

[0090] Calculation container d i , d j When Z is less than the set threshold, the container d is merged. i , d j Forming a new container d' ij , and added to the local database container information table; after the container is merged, the container frequency is increased by one, and the duplicate package dependency value is increased by one;

[0091] It should be noted that the two containers d are merged. i , d j Should satisfy: Container d before merging i , d j Functions are inactive; and, after merging, the new container d' ij The CPU usage, memory usage, and disk space usage do not exceed the corresponding set thresholds.

[0092] Container d i , d j The similarity Z can be calculated using Euclidean geometry detection, and the calculation formula is as follows:

[0093]

[0094] The smaller the Z value, the smaller the container d i and container d j The higher the similarity.

[0095] Large differences in container attribute values ​​will lead to errors in Z. To improve accuracy, the attribute values ​​of the container can be standardized before calculating the similarity. i The attribute value is {l1,l2...,l m}, the attribute value after standardization is in: represents the eigenvalue of the i-th attribute, m represents the mean, and S represents the variance;

[0096] At the same time, in order to remove the dimensional differences between different attribute values, the attribute values ​​of the container can be normalized, for example: container d i Attribute value

[0097] As an embodiment of the present invention, a specific method for decomposing a container may include the following steps:

[0098] Query the container's software package information from the local database and obtain the software package attribute values, which include: the number of times the software package is installed for different containers, the size of the software package {s1, s2..., s m}、CPU size {c1,c2...,c m}、Occupied memory size {m1,m2…,m m}wait;

[0099] In the embodiment of the present invention, the software packages are sorted according to the number of times they are installed in different containers, and the attribute values ​​of i software packages are taken out so that the attribute values ​​of the remaining software packages are less than a set threshold.

[0100] Start a new container in the hot standby pool, schedule i software packages into the new container, create a new local database container information table, and the container decomposition is complete.

[0101] The following further explains the method of merging and decomposing containers with reference to specific embodiments. Figure 3 、 Figure 4 As shown in the figure, assume that there are three containers: D1, D2, and D3. The weight of container D1 is 2, the weight of container D2 is 1, and the weight of container D3 is 3. The software package and dependency values ​​corresponding to D1 are {s1:3,s2:2,s3:1}, the software package and dependency values ​​corresponding to D2 are {s1:1,s2:1,s7:1}, and the software package and dependency values ​​corresponding to D3 are {s4:3,s5:2,s6:1}. Assume that container D3 is overloaded in the initial state, and there will be no overload after containers D1 and D2 are merged.

[0102] like Figure 3 As shown in the figure, the container merging method based on the serverless platform can be:

[0103] Step 301: The resource monitor detects that containers D1 and D2 have the same software environment and determines that the weight value of container D1 is greater than the weight value of container D2, and immediately stops the execution of software packages s1 and s2 in container D2.

[0104] Step 302: The status of the software in container D2 after it is stopped is fed back to the container management.

[0105] Step 303: The software in container D2 is stopped successfully without any abnormality, and the dependency values ​​of software packages s1 and s2 in container D1 are updated.

[0106] Step 304: Schedule software package s7 of container D2 to container D1, and synchronously update the weight of container D1.

[0107] Step 305: Destroy container D2 to reduce system overhead.

[0108] In response to the problem that existing serverless computing platforms immediately destroy containers after executing serverless instances, an embodiment of the present invention designs a hot standby pool cache container strategy. The container is not immediately destroyed after the serverless instance is executed, which reduces the overhead of container startup and software package preparation and improves the overall resource utilization of the system.

[0109] like Figure 4 As shown in the figure, the container decomposition process based on the serverless platform is as follows:

[0110] Step 320: Query the local library for package information about container D3, including package dependency values, package size, CPU usage, and memory usage. The lower the package dependency value, the weaker the relationship between the software and the container. Software with the smallest dependency value is preferentially selected as the decomposition target, ensuring that the remaining software after decomposition occupies less than a set threshold.

[0111] Step 321: After receiving the decomposition instruction, the container manager quickly starts a new container Dn, schedules the s6 software in D3 to Dn, stops the s6 software in D3, and updates the container information table.

[0112] The periodic start and stop of the container is based on the container function call frequency, container CPU, and memory usage as characteristic values, and a multivariate linear regression model is constructed to predict the container start and stop time; assuming that a set of containers {d1, d2…, d n}, at time T set In the call {f1,f2…,f n} times, the regression model predicts d i The time when it is called again is t i , in (0,t i ) within the time d i In closed state, ti Then start the container again to reduce resource waste.

[0113] like Figure 5 As shown, the method for periodically inspecting and starting and stopping a container includes the following steps:

[0114] Step 401: The resource monitor queries the containers in the hot standby pool and predicts the next start / stop time period based on the number of times the container is called within time T.

[0115] Step 402: If the predicted stop time of the container is less than or equal to the current time, and the container is in the running state, the container is stopped and the next start time of the container is predicted; if the predicted start time of the container is less than or equal to the current time, and the container is in the stopped state, the container is started immediately and the next stop time of the container is predicted.

[0116] Step 403: If the container is not within the predicted start / stop time period, query the number of cold starts and the total number of starts of the container within time T, where the number of cold starts represents the number of passive starts of the container due to predicted failures.

[0117] Step 404: In the case of a container prediction failure, the resource monitor may choose to re-optimize the prediction function.

[0118] Step 405: Use the updated prediction function to predict the next start / stop time period of the container.

[0119] Example 2:

[0120] like Figure 1 As shown, an embodiment of the present invention provides a serverless platform-based container-unaware startup system, which can be used to implement the container-unaware startup method described in Example 1, including an interpreter, a processor, and a container manager;

[0121] Interpreter: Receives and parses user requests to obtain the software packages required by the user requests. It uses the software package name as a keyword to match container information with the local database and places the user request into the cold standby queue or hot standby queue based on the matching result.

[0122] Processor: Used to perform security authentication on user requests from cold standby queues and hot standby queues, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user request;

[0123] Container Manager: When the user-requested instruction comes from the hot standby queue, it selects a running container with the highest similarity in the hot standby pool as the target container to execute the function event requested by the user; and when the user-requested instruction comes from the cold standby queue, it creates a new container in the cold standby pool and schedules the new container to the hot standby pool.

[0124] The container non-perception startup method provided in this embodiment can be implemented as follows: Figure 1 The system implementation shown includes an interpreter, a processor, a container manager, and a resource manager; specifically, the following steps are included:

[0125] Step 101: The interpreter serves as the unified entrance for external access to the system. It is responsible for receiving and parsing HTTP user requests or other user requests in response to events. It then compares the user requests with local structured container instances and decides whether to send the user requests to the cold standby or hot standby queue.

[0126] Step 102: The cold standby or hot standby queue is responsible for receiving the task user request initiated by the user and caching it in the message queue to prevent the user request from being lost. It also supports multi-process push and improves system throughput.

[0127] Step 103: The processor processes user requests pushed from the cold or hot standby queues. When the processor is idle, it automatically steals user requests from the most loaded queue. Within the entire system, the processor is the core component responsible for efficient platform operation. It tags and clusters user requests based on the user request information pushed from the queues. It also employs a priority scheduling strategy to prioritize user requests based on tag attribute values.

[0128] Step 104: The container manager is the main worker in the system. It is responsible for managing resources in the platform and operating the underlying containers. It uses the container similarity strategy to find the most suitable container for instance deployment. When no function container is matched, it reads the user's requested function information and creates the corresponding resources with the function code and its dependency management, and finally creates a container with resources.

[0129] Step 105: Each time the container manager creates a new container, it tracks the running status of the container function in real time. When the function is triggered, in order to reduce the cold start delay caused by each container creation, the container manager chooses to schedule the container to the hot standby pool.

[0130] Step 106: The container manager matches a suitable function container through the similarity strategy and schedules the user request instruction to be executed in the container.

[0131] The serverless platform-based container non-perceiving startup system provided by an embodiment of the present invention also includes a resource monitor, which is used to dynamically monitor the hot standby pool, including merging containers, decomposing containers and / or periodically starting and stopping containers.

[0132] When the resource monitor detects containers with the same attribute values ​​in the hot standby pool, it first determines the running status of the containers and whether there is an overload after the merger. If the judgment is passed, the resource monitor performs the container merger operation.

[0133] When the resource monitor detects that the container resources in the hot standby pool exceed the threshold, the container is decomposed according to the relationship between the container and the software dependency value.

[0134] The specific method and steps of the resource monitor for merging containers, decomposing containers, and periodically starting and stopping containers can be found in Example 1 and will not be described in detail here.

[0135] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A method for starting a container without any perception, characterized in that: The method comprises: Receive and parse user requests to obtain the software packages required by the user requests; The software package name is used as a keyword to match container information with the local database. Based on the matching result, the user request is placed in the cold standby queue or hot standby queue. Perform security authentication on user requests from cold and hot standby queues, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user requests; If the instruction requested by the user comes from the hot standby queue, a running container with the highest similarity is selected in the hot standby pool as the target container to execute the function event requested by the user; If the user's request comes from the cold standby queue, a new container is created in the cold standby pool and scheduled to the hot standby pool. It also includes dynamic monitoring of the hot standby pool, including the decomposition vessel; The decomposition container comprises: Query the container's software package information from the local database to obtain software package attribute values ​​including at least the number of times the software package has been installed in different containers. Sort the software packages by the number of times they are installed in different containers, and select the software packages whose number of times they are installed in different containers is not less than the set threshold. Start a new container in the hot standby pool, schedule the removed software package to the new container, update the local database container information table, and the container decomposition is completed.

2. The method for starting a container without any perception according to claim 1, characterized in that: Methods for placing user requests into the cold standby queue or hot standby queue based on matching results include: If the container information matching result is empty, a label with an attribute value of 0 is attached to the user request and the user request is placed in the cold standby queue; If the container information matches n containers, the user request is labeled with the attribute value of the information list of n containers and the user request is placed in the hot standby queue; Where n = 1, 2, 3, ...; the container information list includes: container CPU information, memory information, disk space information, number of software packages, and the size of each software package.

3. The method for starting a container without any perception according to claim 2, characterized in that: Methods for clustering analysis of user requests that have passed security authentication include: User requests with a label attribute value of 0 are classified into one category, which has the lowest priority; When the attribute value of the label of the user request is not 0, secondary clustering is performed, and two user requests with non-zero attribute values ​​are selected. ,calculate The intersection of dependent environments: ， in, Indicates a user request; represents the intersection of dependent environments; When the value of the intersection of dependent environments accounts for 50% or more of the total dependent environments, the user request Classified into one category, this type of user request has a higher priority than user requests whose dependency environment intersection value accounts for less than 50% of the total dependency environments.

4. The method for starting a container without any perception according to claim 1, characterized in that: The similarity of the containers is calculated using the following formula: ； in, represents the similarity of container i; 、 Respectively represent the CPU usage and memory usage of container i, Indicates the number of software packages requested by the user that are matched by container i. for The size of each software package in the hot standby pool, t represents the total number of containers in the hot standby pool, and T and M are the number and total size of the software packages that the user requests depend on, respectively.

5. The method for starting a container without any perception according to claim 1, characterized in that: The security authentication includes authenticating the source, authority and function of the user request.

6. The method for starting a container without perception according to claim 1, characterized in that: The dynamic monitoring includes merging containers, decomposing containers and / or periodically starting and stopping containers.

7. The method for starting a container without perception according to claim 6, characterized in that: The method for merging containers comprises: Calculate the similarity between two containers in the local database container information table; If the similarity is less than the set threshold, the two containers are merged to form a new container and added to the local database container information table; The two merged containers meet the following requirements: the container functions are inactive before the merger; after the merger, the CPU, memory, and disk space usage of the new container do not exceed the corresponding set thresholds.

8. The method for starting a container without perception according to claim 7, characterized in that: Before calculating the similarity between two containers in the local database container information table, the attribute values ​​of the two containers are standardized and normalized.

9. The method for starting a container without perception according to claim 6, characterized in that: Methods for periodically starting and stopping containers include: Query the container in the hot standby pool, according to the container at time T set The number of times it is called within a period predicts the time period for the next start and stop; If the predicted stop time of a container is less than or equal to the current time, if the container is in the running state, the container is stopped and the next start time of the container is predicted. If the predicted start time of a container is less than or equal to the current time, if the container is in the stopped state, the container is started immediately and the next stop time of the container is predicted. The container is not in the predicted start and stop time period. Query the container at time T set The number of internal cold starts and the total number of starts. The number of cold starts indicates the number of times the container is passively started due to predicted failures. In the event of a container prediction failure, the prediction function is re-optimized and the updated prediction function is used to predict the next start and stop time period of the container.

10. A container non-perception startup system, characterized in that: The system comprises: Interpreter: Receives and parses user requests to obtain the software packages required by the user requests. It uses the software package name as a keyword to match container information with the local database and places the user request into the cold standby queue or hot standby queue based on the matching result. Processor: Used to perform security authentication on user requests from cold standby queues and hot standby queues, perform cluster analysis on user requests that pass security authentication, and obtain the instruction category of the user request; Container Manager: When a user-requested instruction comes from the hot standby queue, it selects a running container with the highest similarity in the hot standby pool as the target container to execute the user-requested function event. Also, when a user-requested instruction comes from the cold standby queue, it creates a new container in the cold standby pool and schedules the new container to the hot standby pool. It also includes dynamic monitoring of the hot standby pool, including the decomposition vessel; The decomposition container comprises: Query the container's software package information from the local database to obtain software package attribute values ​​including at least the number of times the software package has been installed in different containers. Sort the software packages by the number of times they are installed in different containers, and select the software packages whose number of times they are installed in different containers is not less than the set threshold. Start a new container in the hot standby pool, schedule the removed software package to the new container, update the local database container information table, and the container decomposition is completed.

11. The container non-perception starting system according to claim 10, characterized in that: It also includes a resource monitor: used to dynamically monitor the hot standby pool, including merging containers, decomposing containers, and / or periodically starting and stopping containers.

Images