Container processing method and device and electronic equipment

Abstract

The embodiment of the invention provides a container processing method and device and electronic equipment. The method comprises the steps of determining a target load index of a target container deployed on a physical machine, and determining the number of copy containers needing to be newly added according to task information of a to-be-processed task, available resource information of the physical machine and a resource upper limit parameter of the target container; and according to the micro-service boundary of the target container and the target load index, deploying the replica container of the target container with the replica container number on the physical machine. Wherein the target load index is a load index that the target container has a resource bottleneck. The method is used for achieving the technical effects of improving the accuracy of the data processing process and improving the import processing efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a container processing method, apparatus, and electronic device. Background Technology

[0002] The next generation of Enterprise Resource Planning (ERP) products increasingly adopts a service-oriented architecture, breaking down the previously single physical or virtual application node into multiple smaller containerized nodes. This results in limited resource quotas (multi-core central processing unit (CPU), memory, etc.) for each node, making it difficult for a single containerized node to handle large-scale data import tasks as in the traditional way.

[0003] In traditional solutions, to avoid system risks caused by importing too much data at once, operators usually need to adopt a manual preprocessing strategy, which involves manually splitting the huge source data file into several smaller sub-files and then completing the import in batches through multiple independent import operations.

[0004] Therefore, existing methods for batch data import processing in containerized ERP systems suffer from technical problems such as low accuracy and low efficiency in data processing. Summary of the Invention

[0005] This application provides a container processing method, apparatus, and electronic device to achieve the technical effect of improving the accuracy of data processing and import processing efficiency.

[0006] In a first aspect, embodiments of this application provide a container processing method, including:

[0007] Determine the target load metric for the target container deployed on the physical machine, wherein the target load metric is the load metric for which the target container has a resource bottleneck;

[0008] Based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container, determine the number of new replica containers that need to be added;

[0009] Based on the microservice boundary of the target container and the target load metric, deploy the specified number of replica containers of the target container on the physical machine.

[0010] In one possible implementation, the available resource information of the physical machine includes the remaining allocable resources of the physical machine on the target load index; the resource limit parameter of the target container includes the maximum amount of resources that the target container is allowed to use on the target load index; and the task information includes the current amount of data to be processed.

[0011] In one possible implementation, determining the number of new replica containers to be added based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container includes:

[0012] Calculate the number of first replica containers based on the maximum resource amount and the remaining allocable resource amount;

[0013] Based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead of processing a unit of data on the target load index, calculate the number of second replica containers;

[0014] The number of replica containers is determined based on the number of the first replica containers and the number of the second replica containers.

[0015] In one possible implementation, deploying the number of replica containers of the target container on the physical machine based on the microservice boundary of the target container and the target load metric includes:

[0016] Determine the service splitting boundary of the target container based on the microservice boundary of the target container;

[0017] Configure resource parameters for each replica container based on the target load metric and the target container's resource limit parameter;

[0018] Based on the configured resource parameters and the service split boundary, instantiate the number of replica containers of the specified number.

[0019] In one possible implementation, the method further includes:

[0020] When the target container meets the preset shrinkage trigger condition, determine the number of replica containers of the target container to be destroyed;

[0021] From the replica containers corresponding to the target container, determine the target number of replica containers to be destroyed;

[0022] Destroy the target copy container.

[0023] In one possible implementation, the preset reduction trigger condition includes at least one of the following:

[0024] The average value of any load metric of the target container and its corresponding replica container is less than a preset low load threshold.

[0025] In the target container and its corresponding replica container, the number of containers whose values ​​of any load index are less than a preset low load threshold is greater than a preset number threshold.

[0026] The current time is within the preset off-peak business period;

[0027] The system receives user input requesting a destruction operation for the target container.

[0028] In one possible implementation, destroying the target copy container includes:

[0029] Remove the target replica container from the load balancer and start timing to obtain the cumulative duration;

[0030] Wait for the target replica container to complete the currently processed request;

[0031] When the target replica container finishes processing the currently processed request or the cumulative duration exceeds a preset duration, the computing resources, memory resources, and network resources occupied by the target replica container are released.

[0032] In one possible implementation, determining the number of replica containers based on the number of the first replica containers and the number of the second replica containers includes:

[0033] Based on the historical load data of the target container, predict the load trend of the target container in the future time period;

[0034] The number of standby containers is determined based on the load trend and the resource limit parameter of the target container;

[0035] The number of replica containers is determined based on the number of the first replica containers, the number of the second replica containers, and the number of spare containers.

[0036] Secondly, embodiments of this application provide a container processing apparatus, comprising:

[0037] The first determining module includes determining the target load index of the target container deployed on the physical machine, wherein the target load index is the load index of the target container where there is a resource bottleneck;

[0038] The second determining module includes determining the number of new replica containers to be added based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container.

[0039] The deployment module includes deploying the number of replica containers of the target container on the physical machine based on the microservice boundary of the target container and the target load metric.

[0040] In one possible implementation, the available resource information of the physical machine includes the remaining allocable resources of the physical machine on the target load index; the resource limit parameter of the target container includes the maximum amount of resources that the target container is allowed to use on the target load index; and the task information includes the current amount of data to be processed.

[0041] In one possible implementation, the second determining module is specifically used for:

[0042] Calculate the number of first replica containers based on the maximum resource amount and the remaining allocable resource amount;

[0043] Based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead of processing a unit of data on the target load index, calculate the number of second replica containers;

[0044] The number of replica containers is determined based on the number of the first replica containers and the number of the second replica containers.

[0045] In one possible implementation, the deployment module specifically includes:

[0046] Determine the service splitting boundary of the target container based on the microservice boundary of the target container;

[0047] Configure resource parameters for each replica container based on the target load metric and the target container's resource limit parameter;

[0048] Based on the configured resource parameters and the service split boundary, instantiate the number of replica containers of the specified number.

[0049] In one possible implementation, the container processing device further includes a destruction module for:

[0050] When the target container meets the preset shrinkage trigger condition, determine the number of replica containers of the target container to be destroyed;

[0051] From the replica containers corresponding to the target container, determine the target number of replica containers to be destroyed;

[0052] Destroy the target copy container.

[0053] In one possible implementation, the preset reduction trigger condition includes at least one of the following:

[0054] The average value of any load metric of the target container and its corresponding replica container is less than a preset low load threshold.

[0055] In the target container and its corresponding replica container, the number of containers whose values ​​of any load index are less than a preset low load threshold is greater than a preset number threshold.

[0056] The current time is within the preset off-peak business period;

[0057] The system receives user input requesting a destruction operation for the target container.

[0058] In one possible implementation, the destruction module is specifically used for:

[0059] Remove the target replica container from the load balancer and start timing to obtain the cumulative duration;

[0060] Wait for the target replica container to complete the currently processed request;

[0061] When the target replica container finishes processing the currently processed request or the cumulative duration exceeds a preset duration, the computing resources, memory resources, and network resources occupied by the target replica container are released.

[0062] In one possible implementation, the second determining module is specifically used for:

[0063] Based on the historical load data of the target container, predict the load trend of the target container in the future time period;

[0064] The number of standby containers is determined based on the load trend and the resource limit parameter of the target container;

[0065] The number of replica containers is determined based on the number of the first replica containers, the number of the second replica containers, and the number of spare containers.

[0066] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0067] The memory stores computer-executed instructions;

[0068] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0069] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0070] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0071] The container processing method, apparatus, and electronic device provided in this application automatically identify resource bottlenecks by determining the target load index of the target container deployed on the physical machine, thereby replacing the traditional operation mode of manual judgment and manual data partitioning. Furthermore, based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameters of the target container, the number of replica containers to be added is determined, realizing automated and precise calculation of the scaling scale and providing resource guarantees for parallel processing. Finally, replica containers are deployed according to the microservice boundary and target load index of the target container, ensuring that the added processing capacity can be immediately and effectively invested in the bottleneck task. The entire method eliminates the error risks introduced by human operation through automated and precise scaling, and significantly improves the throughput and overall efficiency of batch data import through parallel processing. Attached Figure Description

[0072] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0073] Figure 1 Flowchart of the container processing method provided in this application Figure 1 ;

[0074] Figure 2 Flowchart of the container processing method provided in this application Figure 2 ;

[0075] Figure 3 Flowchart of the container processing method provided in this application Figure 3 ;

[0076] Figure 4 A schematic diagram of the container handling apparatus provided in this application;

[0077] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0078] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0079] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0080] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0081] First, the application scenarios involved in this application will be explained:

[0082] In ERP application practice, batch data import is a core function supporting business data initialization and periodic synchronization. Its processing performance and reliability directly affect the overall operational efficiency of the system. Faced with large enterprises with millions or even more data records, traditional monolithic deployment architectures are usually implemented based on physical servers or virtual machines with complete resource isolation. Because they can provide ample and dedicated computing resources (such as CPU, large-capacity memory, etc.) for a single application instance, they can usually handle such high-load, continuous data processing tasks relatively easily.

[0083] However, with the widespread adoption of microservices and containerization technologies, the architectural paradigm of next-generation ERP systems is undergoing a profound transformation. Service-oriented architecture decouples previously single, bloated application nodes into a set of lightweight service units with clearly defined responsibilities and independent deployments, running in container environments with strictly limited resource quotas. While this evolution improves the system's agility, maintainability, and elastic scalability, it also leads to a significant reduction in the underlying hardware resources available to each service instance.

[0084] Therefore, a single containerized node often struggles to independently handle large-scale data import operations comparable to those of a traditional monolithic architecture, and the original data processing model faces adaptation challenges.

[0085] In traditional solutions, to avoid system risks caused by importing too much data at once, operators usually need to adopt a manual preprocessing strategy, which involves manually splitting the huge source data file into several smaller sub-files and then completing the import in batches through multiple independent import operations.

[0086] While this method can alleviate the pressure of single-processing to some extent, it still has the following problems:

[0087] 1. It significantly increases the complexity and workload of manual intervention, requiring implementers to have corresponding document handling skills and experience.

[0088] 2. Because the import process needs to be started repeatedly, the total time of the entire data loading task is often greatly extended due to the overhead of process initialization and waiting between batches, which affects the overall timeliness of data readiness.

[0089] 3. Operators primarily rely on personal experience to make rough judgments about data volume, failing to accurately quantify the system's actual capacity limits under multiple uncertainties such as real-time workloads, concurrent request contention, and dynamic resource allocation. This problem is further amplified in containerized ERP systems: resource quotas for containerized service instances are dynamically scheduled, and operators' experience-based judgments cannot match the real-time resource status of containers. As a result, splitting strategies often face a dilemma: if the file units are too large, one or more import processes may exceed the resource limits provided by their runtime environment, leading to severe performance degradation or even node overload or unexpected restarts, jeopardizing the continuity and stability of system services; conversely, if the partitioning is too fragmented, while the success rate of individual import tasks may increase, the resulting surge in the number of import batches further amplifies manual operation costs and management overhead, causing unnecessary consumption of time and human resources, and ultimately reducing overall import efficiency due to excessive fragmentation.

[0090] Therefore, existing methods for batch data import processing in containerized ERP systems suffer from technical problems such as low accuracy and low efficiency in data processing.

[0091] Based on the aforementioned technical problems, the technical concept of this application is as follows: During the research of containerized ERP batch data import processing solutions, the inventors discovered that the core issue hindering a single containerized node from handling large-scale data imports lies in the lack of automated logic for matching container resource status with task volume. Simultaneously, they found that the load status of the target container deployed on the physical machine, the available resources of the physical machine, and the information on tasks to be processed are all directly collectable and effective data, and the microservice boundary of the target container can serve as a reasonable basis for container deployment. Therefore, the inventors considered first determining the target load index where the target container has resource bottlenecks, grasping the core of resource constraints. Then, combining task information, available physical machine resources, and the resource limit parameters of the target container, the number of replica containers to be added is automatically determined. Finally, replicas are deployed based on the microservice boundary and target load index, dynamically adjusting the containers in real time. This effectively improves the accuracy and efficiency of the data processing process without the need for manual data file splitting.

[0092] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0093] Figure 1 Flowchart of the container processing method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0094] S11. Determine the target load metric for the target container deployed on the physical machine.

[0095] In this step, we consider that in a containerized deployment environment, multiple container instances run on physical machines or virtual nodes, jointly supporting business applications. As the business load dynamically changes, some container instances may experience performance bottlenecks due to insufficient resources, affecting the overall service quality. To maintain system stability and responsiveness, it is necessary to promptly identify container instances with resource constraints and take appropriate scaling measures based on their specific bottleneck types.

[0096] In this context, a physical machine refers to the actual computing device that hosts the containers, possessing independent computing, storage, and network resources. In a cloud computing environment, a physical machine may manifest as a server or a virtualized host with dedicated resource allocation. Physical machines can register their resource specifications with the control plane through agent components and continuously report resource utilization status, providing fundamental resource data for container scheduling.

[0097] The target load metric refers to the load metric indicating that the target container has a resource bottleneck. In practical applications, a resource bottleneck refers to a situation where, during the operation of the target container, the usage of a certain type of resource reaches or exceeds a preset threshold, making that resource a key constraint limiting task processing efficiency. In other words, the resource supply capacity cannot meet the current task's demand for that resource, which may lead to problems such as task backlog and processing delays.

[0098] For example, target load metrics could be queries per second (QPS), CPU utilization, memory pressure, etc.

[0099] In one possible implementation, the monitoring system continuously tracks various load metrics of the target container. When a certain load metric is found to continuously exceed a preset threshold for a specified duration, such as CPU utilization continuously >80% for a preset duration, the load metric is determined to be the target load metric of the target container.

[0100] In another possible implementation, machine learning algorithms can be used to identify and predict the values ​​of various load indicators, and compare the predicted values ​​with preset thresholds. When it is found that the predicted value of a certain load indicator continuously exceeds the preset threshold for a specified period of time, the load indicator is determined to be the target load indicator of the target container.

[0101] In another possible implementation, the electronic device pre-configures a dedicated Application Programming Interface (API) for triggering container splitting. This API allows authorized users (such as system administrators) to initiate calls via protocols such as Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Secure Protocol (HTTPS). During the call, the user can select a container through a user-defined graphical interface. The electronic device then responds by designating the selected container as the target container. Subsequently, a monitoring system quickly collects various load metrics of the target container to determine the target load metric. Alternatively, it may respond to the user's load metric selection via the user-defined graphical interface, designating the user-defined load metric as the target load metric.

[0102] S12. Based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container, determine the number of new replica containers that need to be added.

[0103] In this step, after identifying the target load metrics of the target container, it is necessary to quantitatively assess the scaling requirements and determine the number of new container replicas to be added. In determining the number of container replicas, it is necessary to comprehensively consider the current amount of tasks to be processed, the remaining available resources of the physical machine, and the resource limitations of the container itself, ensuring that the scaling plan meets business processing needs without exceeding the physical resource capacity, thereby achieving optimal resource utilization.

[0104] The task information of the pending tasks refers to the workload-related information waiting for the target container and its copies to process, including the current amount of data to be processed, as well as the task queue length, expected processing time requirements, and the characteristics of the computing, memory, and network resources required for task processing.

[0105] The available resources information of a physical machine refers to the current available resources on the physical machine where the target container is located, including the amount of remaining allocable resources in the dimension of the target load metric.

[0106] For example, if the target load metric is CPU utilization, then available resource information includes the remaining CPU computing power of the physical machine. If it's memory utilization, then it includes the remaining physical memory capacity. This information is collected and reported in real time by node agents to ensure that decisions are based on the latest resource status.

[0107] The target container's resource cap parameter refers to the maximum limit allowed for each container instance in the use of various resources, including the maximum amount of resources allowed to be used on the target load metric.

[0108] For example, the resource limit parameters of the target container may specifically include the single import volume of the target container, the maximum number of worker threads, the maximum memory usage limit, and the maximum CPU usage limit.

[0109] In this context, a replica container refers to an additional container instance that has the same functionality and service interfaces as the target container. These replica containers share the same microservice boundary but run as independent processes with their own resource allocation and runtime environment. The number of replica containers required refers to the number of additional container instances that need to be created to alleviate the resource bottleneck of the target container.

[0110] In one possible implementation, the number of first replica containers can be calculated based on the maximum resource amount and remaining allocable resources corresponding to the resource limit parameter. Then, the number of second replica containers is calculated based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead per unit of data processed on the target load metric. Finally, the total number of replica containers is determined based on the number of first and second replica containers.

[0111] It should be understood that the specific implementation process and principles of this step will be explained later. Figure 2 The embodiments shown are described in detail here, and will not be repeated here.

[0112] S13. Based on the microservice boundary of the target container and the target load metric, deploy the target number of replica containers on the physical machine.

[0113] In this step, after determining the number of new replica containers needed, these container instances need to be actually created and deployed. The deployment process not only needs to ensure the new containers can start and run normally, but also needs to consider the design principles of the microservice architecture and the specific types of resource bottlenecks. Through reasonable configuration and scheduling optimization, the new containers can effectively share the load while maintaining the maintainability and scalability of the system.

[0114] In microservice architecture, the microservice boundary of the target container refers to the functional scope and service contract of the service to which the target container belongs. Essentially, the microservice boundary defines the service's responsibilities, external interfaces, data boundaries, and dependencies; it is the basic unit for service decomposition and composition. When deploying replica containers, it is crucial to strictly adhere to the microservice boundary to ensure that the replica containers belong to the same service as the target container and provide the same functionality and quality of service.

[0115] In one possible implementation, this step can be achieved through the following steps a-c:

[0116] Step a: Determine the service splitting boundary of the target container based on the microservice boundary of the target container.

[0117] The service split boundary refers to the specific technical definition within the microservice boundary when replicating instances. It determines which software components, configurations, code, and resource definitions need to be fully replicated when creating a replica container. The service split boundary includes the complete application package, runtime environment, dependent libraries, environment variables, configuration files, and the ports and protocols used for external services.

[0118] Specifically, the service registry or configuration management repository is queried to obtain the service identifier corresponding to the target container. Then, based on the service identifier, the complete deployment descriptor of the service (such as Docker image address, environment variable configuration, health check endpoint, service discovery tag, etc.) is retrieved. This information together constitutes the service split boundary.

[0119] Step b: Configure resource parameters for each replica container based on the target load metric and the target container's resource limit parameters.

[0120] Resource parameters refer to the specific resource allocation values ​​set for each replica container when it is instantiated. These parameters are concrete instances of resource limit parameters and typically include CPU share or number of cores, memory limits, disk quotas, network bandwidth limits, etc.

[0121] For example, if the target load metric is CPU, then the replica container is configured with a higher priority CPU scheduling weight or allocated more virtual CPU cores. If the target load metric is memory pressure, then the replica container is allocated a larger memory limit.

[0122] Furthermore, more granular configurations can be made based on the resource usage patterns of the target container in historical load data. For example, for applications with fluctuating memory usage, a higher memory limit can be set in conjunction with an elastic memory management strategy.

[0123] Understandably, the configuration must strictly adhere to the globally defined resource limit parameters, and the calculated resource values ​​are usually rounded up or buffered to cope with load fluctuations.

[0124] Step c: Instantiate the number of replica containers based on the configured resource parameters and service split boundaries.

[0125] Specifically, firstly, based on the service partitioning boundary, a creation command is sent to the node agent on the specified physical machine. This command includes information such as the container image address, environment variables, and command parameters. Simultaneously, resource parameters for each replica container are appended to the creation command. Upon receiving the creation command, the node agent, while driving the local container runtime, requests resources according to the resource parameters and instantiates the required number of replica container processes based on the image. After the replica containers start, the node agent performs a pre-defined health check and automatically registers successfully running container instances with the service registry and load balancer, enabling them to be discovered by other services and begin receiving traffic.

[0126] In this implementation, the service splitting boundary is determined based on the microservice boundary of the target container, ensuring that the newly created replica containers are fully aligned with the original services in terms of business functions, interface contracts, and data dependencies, thus maintaining the clarity and integrity of the microservice architecture. Resource parameters are configured for each replica container based on the target load metric and the target container's resource cap, enabling differentiated resource provisioning and fine-grained cost control for identified bottlenecks. Based on this instantiated replica container, it can be seamlessly integrated into existing systems and immediately assume load, achieving rapid, reliable, and architecturally compliant service capability enhancement.

[0127] This application provides a container processing method that determines the target load index of a target container deployed on a physical machine. Based on the task information of the task to be processed, the available resources of the physical machine, and the resource limit parameters of the target container, the method determines the number of replica containers that need to be added. Based on the microservice boundary of the target container and the target load index, the method deploys the target container's replica containers on the physical machine. The target load index is the load index of the target container where resource bottlenecks exist. In this technical solution, by determining the target load index of the target container deployed on the physical machine, the system can automatically identify resource bottlenecks, thus replacing the traditional operation mode of manual judgment and manual data partitioning. Furthermore, by determining the number of replica containers that need to be added based on the task information of the task to be processed, the available resources of the physical machine, and the resource limit parameters of the target container, the method achieves automated and precise calculation of the scaling scale, providing resource guarantees for parallel processing. Finally, by deploying replica containers based on the microservice boundary of the target container and the target load index, the method ensures that the added processing capacity can be immediately and effectively invested in bottleneck tasks. The entire method eliminates the error risks introduced by human operation through automated and precise scaling, and significantly improves the throughput and overall efficiency of batch data import through parallel processing.

[0128] Figure 2 Flowchart of the container processing method provided in this application Figure 2 ,like Figure 2 As shown, S12 includes:

[0129] S21. Calculate the number of first replica containers based on the maximum resource quantity and the remaining allocable resource quantity.

[0130] In this technical solution, after determining the target load index, in order to evaluate the upper limit of the feasibility of expansion from the perspective of physical resource supply capacity, it is necessary to calculate the maximum number of target container replicas that can be created on the current physical machine based on resource constraints, i.e., the number of first replica containers.

[0131] The maximum resource limit refers to the maximum amount of resources that the target container is allowed to use under the target load metric; it is a preset upper limit for the resource consumption of the target container instance. For example, if the target load metric is CPU utilization, the maximum resource limit might mean that the target container can use the computing power of up to 2 CPU cores. If it is memory, it might mean that the target container can use up to 4GB of physical memory.

[0132] The remaining allocable resources refer to the total amount of resources available for the new container to use on the physical machine hosting the target container at the current moment, based on the resource dimension corresponding to the target load metric. The remaining allocable resources reflect the real-time resource availability of the physical machine, which is continuously collected and reported by the node agent, such as the remaining computing power of the CPU, the remaining free capacity of memory, or the remaining bandwidth of the network.

[0133] In one possible implementation, the remaining allocable resources are divided by the maximum resources, and the quotient is rounded down. The rounded result is then used to determine the number of the first replica containers.

[0134] In another possible implementation, the remaining allocable resources are divided by the maximum resources, and the quotient is rounded down. The rounded result is used to determine the initial number of first replica containers. Then, the initial number of first replica containers is multiplied by a safety factor less than 1, and the resulting value is used to determine the number of first replica containers.

[0135] In this implementation, the degree of resource fragmentation, the resource buffer reserved for system daemons or other containers, and the security overhead required for resource isolation between containers are taken into account. Therefore, a safety factor of less than 1 is multiplied by the initial number of first replica containers to ensure that the final number of first replica containers will not lead to the exhaustion of physical machine resources.

[0136] S22. Calculate the number of second replica containers based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead of processing a unit of data on the target load index.

[0137] In this step, after calculating the expansion limit from the perspective of resource supply, it is necessary to assess the number of container replicas required to digest the current workload from the perspective of business processing needs, i.e., the number of second replica containers.

[0138] The current amount of data to be processed refers to the total size of the task queue waiting for the target container and its replicas to process, which may include the number of messages to be processed, the total data size of the transaction, or the number of requests.

[0139] The data processing capacity of the target container refers to the amount of data or tasks that a single replica container can process per unit of time. It is usually based on historical performance data or benchmark tests, such as being able to process 1,000 requests per second.

[0140] The expected resource overhead per unit of data processed on the target load metric refers to the amount of resources expected to be consumed by the target container per unit of data or task processed, based on the target load metric. For example, the expected CPU time consumed in processing a database query operation, or the expected memory size for processing an image.

[0141] In one possible implementation, the current amount of data to be processed is divided by the data processing capacity of the target container to obtain the total number of processing time units required. Then, based on the expected completion time of the tasks to be processed, the maximum duration for completing the tasks is determined. Finally, the value obtained by dividing the maximum duration for completing the tasks to be processed by the total number of processing time units is rounded up, and this rounded value is used to determine the number of second replica containers.

[0142] In another possible implementation, the total target resource amount required to process all the current pending data is evaluated, and the processing capacity that the target container can handle under its maximum resource limit is calculated. Then, the total target resource amount is divided by the processing capacity that the target container can handle under its maximum resource limit, and the resulting value is rounded up. The rounded value is then used to determine the number of second replica containers.

[0143] S23. Determine the number of replica containers based on the number of first replica containers and the number of second replica containers.

[0144] In this step, after obtaining quantitative results from two independent dimensions—resource supply constraints (number of first replica containers) and business demand constraints (number of second replica containers)—it is necessary to combine these two results to make a final, executable decision to determine the actual number of replica containers that need to be created.

[0145] In one possible implementation, the smaller of the number of first replica containers and the number of second replica containers is determined as the number of replica containers. This ensures that newly added replica containers will not fail to be deployed due to exceeding the remaining physical machine resources, nor will they cause task backlog due to insufficient quantity.

[0146] In another possible implementation, the load trend of the target container in the future is predicted based on its historical load data. The number of standby containers is determined according to the load trend and the resource limit parameters of the target container. The total number of replica containers is then determined based on the number of first replica containers, the number of second replica containers, and the number of standby containers.

[0147] The historical load data of the target container refers to time-series data continuously collected and stored by the monitoring system, reflecting the target container's operating status and resource consumption over different time periods in the past. This data typically includes specific load metrics such as CPU utilization, memory usage, queries per second, and network I / O traffic at various historical moments.

[0148] The future time period refers to one or more consecutive time intervals that the prediction model targets in the near future. The length and granularity of this time period can be configured according to business cycle and decision-making needs, such as the next 5 minutes, the next 1 hour, or the next business peak period.

[0149] Among them, load trend refers to the direction of change, fluctuation pattern and magnitude of change of the target load index of the target container in the future time period, which is inferred based on the analysis of historical load data.

[0150] Specifically, time series forecasting algorithms can be used to fit the historical load index data sequence of the target container to determine its predicted value sequence for future periods, thereby identifying the load trend. Alternatively, machine learning algorithms can be combined to learn patterns from the historical load data itself while incorporating external features that may influence the load for joint training. These external features could include holiday markers, marketing campaign plans, system event logs, etc. The trained model can then be used to process the historical load index data sequence of the target container to obtain the load trend.

[0151] Furthermore, the expected incremental demand for the target load metric in the future time period compared to the current time can be quantified from the predicted load trend. Then, this expected incremental resource demand is divided by the maximum resource capacity, and the quotient is rounded up to obtain an estimate of the number of standby containers. Alternatively, a reinforcement learning optimization algorithm can be used to comprehensively evaluate and iteratively learn multiple factors, such as expected incremental demand, resource utilization targets, the cost of scaling up operations, and the sensitivity to scaling down, within a long-term benefit framework, thereby dynamically calculating the optimal number of standby containers that balances cost and performance.

[0152] Furthermore, the number of replica containers can be compared with the number of spare containers to obtain the number of replica containers in the second set, and the smaller value can be determined as the total number of replica containers. Dynamic weights can also be assigned to the number of replica containers in the first set, the second set, and the number of spare containers to construct a decision function, and the output of this decision function can be used to determine the final number of replica containers. The decision function must ensure that its final output number of replica containers does not exceed the number of replica containers in the first set.

[0153] In the above implementation, by predicting the load trend of the target container over a future time period based on its historical load data, the system can gain insight into the cyclical changes and growth trends of business volume, achieving a shift from passive response to proactive planning. Furthermore, based on this load trend and the resource limit parameters of the target container, the number of backup containers is determined, enabling the system to prepare resource buffers in advance for foreseeable load growth, effectively shortening the response latency for future expansion.

[0154] In the above embodiments, by calculating the number of first replica containers based on the maximum resource volume and the remaining allocable resources, a hard upper limit is clearly defined on the current physical node resource supply capacity, preventing node resource exhaustion and system instability caused by over-deployment. Simultaneously, by calculating the number of second replica containers based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead per unit of data processed on the target load metric, the minimum capacity required to handle the current workload is precisely quantified. Combining these two factors to determine the final number ensures that the expansion scale is strictly limited between resource feasibility and business necessity, achieving the optimization goal of maximizing resource utilization while ensuring service capacity.

[0155] In practical applications, the aforementioned embodiments address the issue of ensuring service capacity through capacity expansion when the load increases. Correspondingly, to ensure that excess resources are automatically and safely released when the load decreases to improve utilization and control costs, this application further proposes a container scaling-down and destruction mechanism. This mechanism, together with the expansion mechanism, constitutes a complete elastic scaling closed loop, enabling fine-grained management of computing resources throughout their entire lifecycle. Specific implementation details are as follows... Figure 3 As shown.

[0156] Figure 3 Flowchart of the container processing method provided in this application Figure 3 ,like Figure 3 As shown, the method includes:

[0157] S31. When the target container meets the preset shrinkage trigger condition, determine the number of copy containers of the target container to be destroyed.

[0158] In this step, after the container cluster has completed its capacity expansion for peak business periods and is running stably, there is excess container processing capacity as the business load naturally decreases or is proactively adjusted based on resource optimization. In order to improve resource utilization efficiency and reduce operating costs while ensuring service quality, it is necessary to reclaim redundant container resources.

[0159] The preset scaling-down trigger condition refers to a series of pre-configured rules or logical criteria used to determine whether the container destruction process should be initiated. In practical applications, the preset scaling-down trigger condition may include at least one of the following:

[0160] The average of any load metric for the target container and its corresponding replica container is less than a preset low load threshold.

[0161] The number of containers in the target container and its corresponding replica containers whose value of any load metric is less than the preset low load threshold is greater than the preset number threshold.

[0162] The current time is during the preset off-peak business period.

[0163] Received user input requesting a destruction operation for the target container.

[0164] Based on the resource pricing model, the resource price of the target container is determined to be higher than the preset price.

[0165] The number of replica containers to be destroyed corresponding to the target container refers to the number of replica containers that should be removed from the currently running replica containers after evaluation.

[0166] In one practical approach, the monitoring system collects load metrics of the target container and all its replica containers in real time. When the monitoring system detects that the average value of any load metric (such as CPU utilization, memory utilization, or queries per second) is consistently below a preset low-load threshold for a certain period of time, it determines that the preset scaling-down trigger condition has been met. Then, based on the current total number of instances, the historical load baseline, and the preset minimum safe number of instances, an algorithm calculates the number of instances that can be safely removed, i.e., the number of replica containers to be destroyed.

[0167] In another practical approach, a scaling-down assessment process is automatically triggered during pre-defined off-peak business hours.

[0168] In another practical approach, a user-initiated scaling-down command is received via a dedicated API. In this case, the number of replica containers to be destroyed can be directly specified by the user or calculated by an algorithm based on the current total number of instances, historical load baseline, and preset minimum safe instance count.

[0169] Specifically, based on the current total number of instances, historical load baseline, and preset minimum number of secure instances, the algorithm calculates the number of replica containers to be destroyed as follows: Determine the reasonable number of instances required under the current business load based on the historical load baseline; then subtract the reasonable number of instances from the current total number of instances and round up to obtain the theoretically redundant number of instances. Further, the larger of the preset minimum number of secure instances and the theoretically redundant number of instances is determined as the number of replica containers to be destroyed.

[0170] S32. Determine the target replica container number of replica containers to be destroyed from the replica containers corresponding to the target container.

[0171] In this step, after determining the number of container instances that need to be destroyed, it is necessary to specifically select which container instances will be the targets of this scaling-down operation from the replica containers corresponding to the currently running target container.

[0172] In one possible implementation, based on the historical load data and current connection count of the replica containers, the replica containers are arranged in ascending order of current processing requests or resource utilization, and the number of replica containers at the top of the list to be destroyed is determined as the target replica containers.

[0173] In another possible implementation, replica containers located on the same node as the physical machine to be maintained, or replica containers that have anti-affinity deployment constraints with other specific service containers, are identified as candidate replica containers. Then, the target replica container is randomly selected from the candidate replica containers or determined according to a preset selection criterion.

[0174] The preset selection criteria can be to arrange the candidate replica containers in ascending order of current processing requests or resource utilization, and determine the number of candidate replica containers to be destroyed at the top of the list as the target replica containers.

[0175] In the above implementation methods, the real-time status and historical indicators of all replica containers can be obtained by querying the service registry and monitoring data, and the specific target replica container can be determined based on the built-in or configurable selection algorithm.

[0176] S33. Destroy the target copy container.

[0177] In this step, after identifying the target replica container, an actual destruction operation needs to be performed to release the system resources it occupies. This ensures that removing the target replica container does not affect ongoing business requests and completely cleans up the runtime environment to avoid resource leaks.

[0178] In one possible implementation, the target replica container is removed from the load balancer, and a timer is started to accumulate duration. The system waits for the target replica container to complete the currently processed request. Once the target replica container has finished processing the currently processed request or the accumulated duration exceeds a preset time, the computing, memory, and network resources occupied by the target replica container are released.

[0179] Specifically, the target replica container is removed from the load balancer's backend server list to ensure that new business requests are no longer routed to it, and a timer is started to control the overall process duration. Next, a termination signal is sent to the target replica container, allowing it to continue processing the currently handling request and achieving natural business termination. The process will wait for the container to terminate itself or until a preset graceful shutdown timeout. If the container process does not stop after the timeout, it will be forcibly terminated. After the container process terminates, resource cleanup and reclamation are performed, including releasing the network configuration bound to the container (such as Internet Protocol (IP) addresses and port mapping rules), cleaning up its unique temporary storage volumes and cached data, and updating the resource manager's records to reflect the increase in available resources.

[0180] In this implementation, business continuity is ensured through traffic isolation, and the final completion of operations and the cleanliness of the system state are ensured through forced termination and resource cleanup, thereby achieving secure scaling down with no business loss and complete resource recovery.

[0181] In the above embodiments, by determining the number of replica containers to be destroyed when the target container meets the preset scaling-down trigger conditions, the system can automatically trigger resource reclamation decisions when the business load decreases or based on optimization strategies. This mechanism enables the total system resources to dynamically track actual changes in business load, effectively solving the problem of long-term resource idleness and cost waste caused by continuously maintaining peak capacity.

[0182] Furthermore, the following will provide a practical explanation of the above container processing method through a specific embodiment.

[0183] In this embodiment, the container processing method can be implemented through the following steps:

[0184] Step 1: Collect basic information about the physical machine and container in real time.

[0185] Deploy a lightweight agent (Node Agent) on each physical or virtual node. Through this agent, collect physical machine information in real time (including total resource capacity, number of currently running containers, resource utilization in various dimensions), as well as pre-set container resource limit parameters (such as single import volume, maximum number of worker threads, maximum memory usage limit, maximum CPU usage limit, etc.).

[0186] Step 2: Deploy the initial container based on task requirements.

[0187] Based on business needs, physical machine information, and pre-defined container resource limits, deploy and run containers that carry core services on physical machines.

[0188] Step 3: Register the container and update service discovery.

[0189] After a new container is deployed, its instance information (such as CPU, memory, storage, network, and other resource specifications) is registered with the control plane and service registry through a node agent, making it accessible. Simultaneously, the agent establishes a heartbeat mechanism to report the health status and resource utilization of each container in real time.

[0190] Step 4: Build and maintain container topology relationships.

[0191] Based on the container's registration information, service type, and dependencies, construct a topology graph between containers.

[0192] Step 5: Run the container and connect it to business traffic.

[0193] After the container starts, the load balancer distributes external business traffic to the container based on information from the service registry.

[0194] Step 6: Monitor the running status and collect performance data.

[0195] The monitoring system continuously collects runtime load metrics of the container, such as QPS, CPU utilization, and memory pressure.

[0196] Step 7: Trigger elastic scaling based on monitoring data and policies.

[0197] When the monitoring data from step 6 indicates that a container (i.e., the "target container") has reached the expansion condition, the elastic scaling process is initiated:

[0198] Step 7-1, Trigger Condition Monitoring and Evaluation: The monitoring system triggers an evaluation based on real-time collected application load metrics (such as CPU utilization consistently exceeding 80% for a preset duration) or manual API calls. It determines the adjustment dimensions based on the current resource bottleneck and intelligently segments the application architecture based on microservice boundaries. Combining task information of the pending tasks, available resources of the physical machine, and the resource limit parameters of the target container, it calculates the number of new replica containers that need to be added.

[0199] Step 7-2: Deploy replica containers: Using the target container as a template, create a specified number of replica containers and enable them to register, update the topology graph, and connect to traffic.

[0200] Step 7-3: Dynamically Reserve Backup Containers: Based on the workload characteristics, historical operation data, and potential pending tasks of each container, dynamically reserve backup containers. Specifically, this involves analyzing time-series data and combining it with parameters such as performance, resource utilization, and cost to predict future load trends. The number of reserved containers can be optimized using reinforcement learning algorithms.

[0201] Step 8: Destroy and recycle the resources of the copy container.

[0202] Step 8-1, Trigger Destruction: Destruction is triggered based on continuous low-load monitoring data, resource pricing models, non-peak business periods, or management instructions.

[0203] Step 8-2, Selection and Destruction: Determine the target replica container based on the topology diagram and perform destruction: 1) Remove it from the load balancer and stop new traffic from entering. 2) Send a termination signal to allow it to complete the currently processed request, and set a graceful shutdown timeout. After the timeout, the process will be forcibly terminated.

[0204] Step 8-3, Resource Cleanup and Reclamation: Release the network configuration bound to the container (such as IP address and port mapping), clean up temporary storage volumes and cached data, persist important data to shared storage, feed back the released resource information to the cluster resource pool, and remove the target replica container from the topology graph.

[0205] Figure 4 A schematic diagram of the container processing apparatus provided in this application is shown below. Figure 4 As shown, the container processing device 40 provided in this embodiment includes:

[0206] The first determining module 401 includes determining the target load index of the target container deployed on the physical machine, wherein the target load index is the load index of the target container where there is a resource bottleneck.

[0207] The second determining module 402 includes determining the number of new replica containers to be added based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container.

[0208] Deployment module 403 includes a number of replica containers of the target container that are deployed on a physical machine based on the microservice boundary of the target container and the target load metric.

[0209] In one possible implementation, the available resource information for the physical machine includes the amount of remaining allocable resources for the physical machine at the target load metric. The resource cap parameter for the target container includes the maximum amount of resources allowed for the target container at the target load metric. The task information includes the current amount of data to be processed.

[0210] In one possible implementation, the second determining module 402 is specifically used for:

[0211] Calculate the number of first replica containers based on the maximum resource quantity and the remaining allocable resources.

[0212] Calculate the number of second replica containers based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead per unit of data processed on the target load metric.

[0213] The number of replica containers is determined based on the number of first replica containers and the number of second replica containers.

[0214] In one possible implementation, deployment module 403 specifically includes:

[0215] Determine the service splitting boundaries of the target container based on the microservice boundaries of the target container.

[0216] Configure resource parameters for each replica container based on the target load metric and the target container's resource limit parameters.

[0217] The number of replica containers is instantiated based on the configured resource parameters and service split boundaries.

[0218] In one possible implementation, the container handling device 40 further includes a destruction module for:

[0219] When the target container meets the preset shrinkage trigger condition, determine the number of replica containers of the target container to be destroyed.

[0220] From the corresponding replica containers of the target container, determine the number of target replica containers to be destroyed.

[0221] Destroy the target copy container.

[0222] In one possible implementation, the preset shrinkage trigger condition includes at least one of the following:

[0223] The average of any load metric for the target container and its corresponding replica container is less than a preset low load threshold.

[0224] The number of containers in the target container and its corresponding replica containers whose value of any load metric is less than the preset low load threshold is greater than the preset number threshold.

[0225] The current time is during the preset off-peak business period.

[0226] Received user input requesting a destruction operation for the target container.

[0227] In one possible implementation, the destruction module is specifically used for:

[0228] Remove the target replica container from the load balancer and start timing to obtain the cumulative duration.

[0229] Waiting for the target replica container to complete the currently processed request.

[0230] When the target replica container finishes processing the currently being processed request or the cumulative time exceeds the preset time, the computing resources, memory resources, and network resources occupied by the target replica container are released.

[0231] In one possible implementation, the second determining module 402 is specifically used for:

[0232] Based on the historical load data of the target container, predict the load trend of the target container in the future time period.

[0233] The number of standby containers is determined based on the load trend and the resource limit parameter of the target container;

[0234] The number of replica containers is determined based on the number of the first replica containers, the number of the second replica containers, and the number of spare containers.

[0235] The container processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0236] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0237] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0238] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0239] In the above embodiments, it should be understood that the processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0240] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0241] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0242] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0243] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0244] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0245] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0246] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0247] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0248] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0249] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0250] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0251] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A container processing method, characterized in that, include: Determine the target load metric for the target container deployed on the physical machine, wherein the target load metric is the load metric for which the target container has a resource bottleneck; Based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container, determine the number of new replica containers that need to be added; Based on the microservice boundary of the target container and the target load metric, deploy the specified number of replica containers of the target container on the physical machine.

2. The method according to claim 1, characterized in that, The available resource information of the physical machine includes the remaining allocable resources of the physical machine on the target load index; the resource limit parameter of the target container includes the maximum amount of resources that the target container is allowed to use on the target load index; The task information includes the current amount of data to be processed.

3. The method according to claim 2, characterized in that, The step of determining the number of new replica containers to be added based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container includes: Calculate the number of first replica containers based on the maximum resource amount and the remaining allocable resource amount; Based on the current amount of data to be processed, the data processing capacity of the target container, and the expected resource overhead of processing a unit of data on the target load index, calculate the number of second replica containers; The number of replica containers is determined based on the number of the first replica containers and the number of the second replica containers.

4. The method according to any one of claims 1-3, characterized in that, The step of deploying the number of replica containers of the target container on the physical machine based on the microservice boundary of the target container and the target load metric includes: Determine the service splitting boundary of the target container based on the microservice boundary of the target container; Configure resource parameters for each replica container based on the target load metric and the target container's resource limit parameter; Based on the configured resource parameters and the service split boundary, instantiate the number of replica containers of the specified number.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: When the target container meets the preset shrinkage trigger condition, determine the number of replica containers of the target container to be destroyed; From the replica containers corresponding to the target container, determine the target number of replica containers to be destroyed; Destroy the target copy container.

6. The method according to claim 5, characterized in that, The preset shrinkage trigger condition includes at least one of the following: The average value of any load metric of the target container and its corresponding replica container is less than a preset low load threshold. In the target container and its corresponding replica container, the number of containers whose values ​​of any load index are less than a preset low load threshold is greater than a preset number threshold. The current time is within the preset off-peak business period; The system receives user input requesting a destruction operation for the target container.

7. The method according to claim 5, characterized in that, The destruction of the target copy container includes: Remove the target replica container from the load balancer and start timing to obtain the cumulative duration; Wait for the target replica container to complete the currently processed request; When the target replica container finishes processing the currently processed request or the cumulative duration exceeds a preset duration, the computing resources, memory resources, and network resources occupied by the target replica container are released.

8. The method according to any one of claims 3, 6 or 7, characterized in that, Determining the number of replica containers based on the number of the first replica containers and the number of the second replica containers includes: Based on the historical load data of the target container, predict the load trend of the target container in the future time period; The number of standby containers is determined based on the load trend and the resource limit parameter of the target container; The number of replica containers is determined based on the number of the first replica containers, the number of the second replica containers, and the number of spare containers.

9. A container handling apparatus, characterized in that, include: The first determining module includes determining the target load index of the target container deployed on the physical machine, wherein the target load index is the load index of the target container where there is a resource bottleneck; The second determining module includes determining the number of new replica containers to be added based on the task information of the task to be processed, the available resource information of the physical machine, and the resource limit parameter of the target container. The deployment module includes deploying the number of replica containers of the target container on the physical machine based on the microservice boundary of the target container and the target load metric.

10. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

Images