Service configuration method and apparatus, electronic device, storage medium

Abstract

The application relates to a service configuration method and device, electronic equipment and a storage medium. The method comprises the following steps: creating a candidate executor under the condition that a target container runs, the target container encapsulating a target SDK used for constructing a target service, the candidate executor being an executor to be started, and the executor being a thread or a process in the target container; sampling a resource usage of the target container by an executor monitor to obtain a target sampling result; determining whether to start the candidate executor according to the target sampling result and a current instance quantity in the target container, so as to dynamically configure the executor in the target service, the candidate executor being used for obtaining a prototype class in the target SDK and being instantiated into a target instance when being started, the candidate executor being converted into a target executor after being started, and the target executor being used for processing a service request for calling the target service by the target instance. The application solves the technical problem of low resource utilization caused by the fact that a small number of instances are usually run in a service in the related art to avoid service collapse.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and in particular to a service configuration method and device, an electronic device, and a storage medium. BACKGROUND

[0002] With the rapid development of the field of artificial intelligence, more and more applications need AI algorithms to empower them. The form in which algorithms are ultimately implemented is usually to be encapsulated in services first, and then called through the external interface of the service. These services usually need a lot of physical resources (CPU, GPU, memory, video memory, etc.) support. In order to improve the utilization rate of physical machines, usually multiple instances are run inside a service, and multiple services are deployed on a physical machine. For a resource, system fixed physical machine, the demand for resources, environment, etc. of the services deployed on the physical machine usually differs greatly. If too many instances are running on the physical machine, resulting in insufficient resources such as OOM (Out of Memory, indicating memory overflow), etc., it will directly cause the service to crash and unable to complete the normal service process. If too few instances are running on the physical machine, it will also cause the processing efficiency of service requests to be low. In order to avoid service crashes, the number of instances running inside the service is usually much lower than the number of instances that can be supported by the available resources of the physical machine, and the resource utilization rate is low.

[0003] In view of the above problem that in order to avoid service crashes, the number of instances running inside the service is usually small, resulting in low resource utilization, no effective solution has been proposed so far. SUMMARY

[0004] The present application provides a service configuration method and device, an electronic device, and a storage medium, to at least solve the technical problem in the related art that in order to avoid service crashes, the number of instances running inside the service is usually small, resulting in low resource utilization.

[0005] According to an aspect of an embodiment of the present application, a service configuration method is provided, comprising: creating a candidate executor in the case of running a target container, wherein the target container encapsulates a target SDK used to build a target service, the candidate executor is an executor to be started, and the executor is a thread or process in the target container; sampling the resource usage of the target container through an executor monitor to obtain a target sampling result; determining whether to start the candidate executor to dynamically configure the executor in the target service according to the target sampling result and the current number of instances in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate it into a target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is used to process service requests calling the target service through the target instance.

[0006] According to another aspect of the embodiments of the present application, a service configuration apparatus is also provided, comprising: a creating module configured to create a candidate executor when a target container is running, wherein the target container encapsulates a target SDK used to build a target service, the candidate executor is an executor to be started, and the executor is a thread or a process in the target container; a sampling module configured to sample resource usage of the target container by an executor monitor to obtain a target sampling result; and a determining module configured to determine whether to start the candidate executor to dynamically configure the executor in the target service according to the target sampling result and a current instance number in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate the target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is used to process a service request invoking the target service by the target instance.

[0007] According to another aspect of the embodiments of the present application, a storage medium is also provided, comprising a stored program, wherein the program is executed to perform the method described above.

[0008] According to another aspect of the embodiments of the present application, an electronic device is also provided, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory is used to store a computer program; and the processor is used to execute the computer program to implement the method according to any one of the preceding aspects.

[0009] According to one aspect of the embodiments of the present application, a computer readable storage medium is provided, comprising a stored program, wherein the program is executed to perform the method according to any one of the preceding aspects.

[0010] In the embodiments of the present application, the method comprises the following steps: creating a candidate executor in the case that the target container runs, wherein the target container encapsulates a target SDK used for building a target service, the candidate executor is an executor to be started, and the executor is a thread or a process in the target container; sampling a resource usage of the target container by an executor monitor to obtain a target sampling result; and determining whether to start the candidate executor to dynamically configure the executor in the target service according to the target sampling result and a current instance quantity in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate the prototype class into a target instance when the candidate executor is started, the candidate executor is converted into a target executor after the candidate executor is started, and the target executor is used to process a service request of calling the target service by the target instance. In the embodiments of the present application, a thread or a process is created as an executor in the target container, and each executor is not started directly after the executor is created, but whether the executor can be started is determined according to a current resource usage of the target container and a current instance quantity in the target container. The executor has an instance used for processing a service request only after the executor is started. The instance quantity running in the target service is controlled according to the resource usage, and the dynamic configuration of the executor quantity in the target service is implemented when the target service is deployed on a physical machine, so that the instance running in the service is not increased in the case of insufficient resources, and the technical problem that the resource utilization rate is low because a small quantity of instances usually run in the service in the related art to avoid service collapse is solved. BRIEF DESCRIPTION OF DRAWINGS

[0011] The accompanying drawings, which are included to provide a further understanding of the present application and are incorporated in and constitute a part of this application, illustrate embodiments of the present application and serve to explain the present application. In the drawings:

[0012] Figure 1 FIG. 1 is a schematic diagram of a hardware environment of a service configuration method according to an embodiment of the present application;

[0013] Figure 2 FIG. 2 is a flowchart of an optional service configuration method according to an embodiment of the present application;

[0014] Figure 3 FIG. 3 is an optional task schematic diagram according to an embodiment of the present application;

[0015] Figure 4 FIG. 4 is a monitoring flowchart of an optional executor monitor according to an embodiment of the present application;

[0016] Figure 5 FIG. 5 is a schematic diagram of an overall idea of an optional service configuration scheme according to an embodiment of the present application;

[0017] Figure 6is a schematic diagram of an optional service configuration device according to an embodiment of the application; and

[0018] Figure 7 is a structural schematic diagram of an electronic device according to an embodiment of the application. DETAILED DESCRIPTION

[0019] In order to make the personnel in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor should be within the scope of protection of the present application.

[0020] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0021] First, some nouns or terms that appear in the description of the embodiments of the present application are applicable to the following explanations:

[0022] SDK: Software Development Kit, is a collection of development tools used by some software engineers when building application software for a specific software package, software framework, hardware platform, operating system, etc.

[0023] Class: a collection of objects that share the same attributes and methods. It defines the attributes and methods that are common to each object in the collection. When writing a class, we give it some general behavior, based on the class to create objects, we can let each object have these general behaviors, and then give each object a unique personality according to the needs. Objects are instances of classes, and an object is created according to a class, which is called instantiation.

[0024] Class inheritance: Inheritance is a way to create a new class, the new class can inherit one or more base classes, then the new class is called subclass or derived class, the base class is called parent class or superclass.

[0025] Abstract class: Often used to represent the abstract concept of the analysis and design of the problem domain, it is an abstraction of a series of specific concepts that look different but are essentially the same. Classes modified by "abstract" in programming statements are abstract classes. In C++, a class with pure virtual functions is called an abstract class, which cannot generate objects; in Java, a class with abstract methods is called an abstract class, which also cannot generate objects; Python also has the concept of abstract classes, which specifies a series of methods and specifies methods that must be implemented by inherited classes. Abstract classes are incomplete and can only be used as base classes. In object-oriented methods, abstract classes are mainly used for type hiding and as global variables.

[0026] Interface: An abstract type is a collection of abstract methods, and interfaces are usually declared with "interface". In some object-oriented languages, a class can implement multiple interfaces but can only inherit from one abstract (or any other type) class. A class that implements an interface must implement all the methods described in the interface, otherwise it must be declared as an abstract class. In Python, interfaces are implemented by abstract classes and abstract methods.

[0027] DSL: Domain Specific Language, a language designed for a specific context in a certain field. Here the field refers to a certain business context (such as banking, insurance, etc.), or a certain application context (such as web applications, databases, AI algorithms, etc.). Another concept compared to this is GPL (general-purpose language), which can be widely used in various business or application problems. Common GPLs include Java, Python, etc.

[0028] Concurrency: In a certain period of time, multiple tasks are executed alternately. For example, when multiple threads are operating, the CPU running time is divided into several time periods, and the time periods are allocated to each thread for execution, and when the thread code runs in a time period, other threads are in a suspended state.

[0029] Parallel: In a certain period of time, multiple tasks are truly executed at the same time. For multi-core CPU processing multiple tasks, the operating system will assign each core of the CPU a task to execute, and multiple cores are truly executing multiple tasks at the same time.

[0030] Process: It is the smallest unit of resource allocation. It is the basic unit for the operating system to allocate and schedule resources. Once a process is created, a certain amount of resources will be allocated to it.

[0031] Thread: The smallest unit of program execution. In fact, the process is only responsible for allocating resources, while the threads are the ones that use these resources to execute the program. In other words, the process is a container for threads. There must be at least one thread in a process to be responsible for executing the program. At the same time, the thread itself does not own system resources, it only needs a little bit of resources that are essential for running, but it can share all the resources owned by the process with other threads belonging to the same process.

[0032] Blocking and non-blocking refer to the states of the caller (program) while waiting for a result (or input). In blocking mode, the current thread is suspended until the result is returned, and returns after receiving the result. In non-blocking mode, if the result cannot be obtained immediately, the caller will not block the current thread. Therefore, in the non-blocking case, the caller needs to periodically poll to check the processing status.

[0033] According to one aspect of the embodiments of this application, a method embodiment for service configuration is provided.

[0034] Optionally, in this embodiment, the above-described service configuration method can be applied to, for example, Figure 1 The hardware environment shown consists of terminal 101 and server 103. Figure 1 As shown, server 103 is connected to terminal 101 via a network and can be used to provide services to the terminal or clients installed on the terminal. Database 105 can be set up on the server or independently of the server to provide data storage services to server 103. The aforementioned network includes, but is not limited to, wide area networks (WANs), metropolitan area networks (MANs), or local area networks (LANs). Terminal 101 is not limited to PCs, mobile phones, tablets, etc. The service configuration method of this application embodiment can be executed by server 103, by terminal 101, or by both server 103 and terminal 101. The service configuration method of this application embodiment can also be executed by a client installed on terminal 101.

[0035] Figure 2 This is a flowchart of an optional service configuration method according to an embodiment of this application, such as... Figure 2 As shown, the method may include the following steps:

[0036] Step S202: With the target container running, create a candidate executor, wherein the target container encapsulates the target SDK for building the target service, the candidate executor is the executor to be started, and the executor is a thread or process in the target container.

[0037] Step S204, sampling the resource usage of the target container by the executor monitor to obtain a target sampling result.

[0038] Step S206, determining whether to start a candidate executor to dynamically configure the executor in the target service according to the target sampling result and the current instance number in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate the target instance when starting, and the candidate executor is converted into the target executor after starting, and the target executor is used to process the service request of calling the target service through the target instance.

[0039] Through the above steps S202 to S206, by creating a thread or a process as an executor in the target container, each executor is not started directly after being created, but whether the executor needs to be started is determined according to the current resource usage of the target container and the current instance number in the target container, and the executor has an instance for processing a service request only after being started. The number of instances running in the target service is controlled according to the resource usage, and when the target service is deployed on a physical machine, the dynamic configuration of the number of executors in the target service is realized, thereby avoiding increasing the number of instances running in the service in the case of insufficient resources, and further solving the technical problem of low resource utilization in the related art that a small number of instances are usually running in the service to avoid service collapse.

[0040] The present application can be applied to the actual production process of intelligent content such as intelligent advertising and the like, and the robustness of an AI (artificial intelligence) service is improved through monitoring the resource usage and the corresponding processing mechanism.

[0041] In the technical solution provided in step S202, the candidate executor is created under the condition that the target container is running, wherein the target container encapsulates a target SDK used to build the target service, the candidate executor is a to-be-started executor, and the executor is a thread or a process in the target container.

[0042] The above target container is used to implement containerized deployment of the target service.

[0043] Optionally, a target image corresponding to the target service is constructed, and the target image is started as the target container in the form of a container instance. The target image can include a target SDK, a service framework, basic dependencies and the like used to build the target service.

[0044] Each executor is a thread or a process, and usually appears in a concurrent or parallel form.

[0045] Optionally, the candidate executor is created by an executor manager, the executor manager being a constructed executor management class object, and various methods and attributes can be defined in the executor management class, such as an executor creation method, an executor container attribute, an executor refreshing method, and an executor state obtaining and returning method.

[0046] In the technical solution provided in step S204, the resource usage of the target container is sampled by the executor monitor to obtain a target sampling result.

[0047] The executor monitor is a thread or process that can be used to monitor the resource usage of the target container. The monitoring mode of the executor monitor on the resource usage includes but is not limited to the following modes: (1) event triggering mode, such as triggering sampling of the resource usage of the target container when a new executor is completed; (2) polling mode, such as periodically sampling the resource usage of the target container.

[0048] In this embodiment, the resource usage of the target container is sampled by the executor monitor to obtain a target sampling result through the event triggering mode when the candidate executor is created.

[0049] The resource usage of the target container can be usage information including but not limited to the following information: (1) CPU usage information; (2) memory usage information; (3) GPU usage information; and (4) video memory usage information.

[0050] Optionally, the usage information of the CPU and the memory can be obtained through related parameters in the target container; and the usage information of the GPU and the video memory can be directly obtained by using a corresponding tool in a development kit.

[0051] The target sampling result can include the resource usage information obtained by sampling, or can include the amount of resources applied when the target container is deployed. The amount of resources applied when the target container is deployed can be directly obtained without sampling.

[0052] Optionally, the target sampling result is expressed by a resource usage rate, and the resource usage rate is obtained by comparing the resource usage information obtained by sampling with the amount of resources applied when the target container is deployed.

[0053] In the technical solution provided in step S206, whether to start the candidate executor to dynamically configure the executor in the target service is determined according to the target sampling result and the current instance number in the target container, the candidate executor is used to obtain a prototype class in the target SDK and instantiate the prototype class into a target instance when the candidate executor is started, the candidate executor is converted into a target executor after being started, and the target executor is used to process a service request for calling the target service by using the target instance.

[0054] The class implementing the function required by the target service in the target SDK is a prototype class, and the target SDK can have one or more prototype classes. The prototype class can be obtained by inheriting the target service class (i.e., the prototype class is a subclass of the target service class).

[0055] The current instance quantity is the number of instances currently existing in the target container. In the case where each executor has one instance after being started, the current instance quantity is equivalent to the number of started executors.

[0056] According to the current instance quantity and the target sampling result, it is determined whether there is sufficient resource to increase a new instance. If there is still sufficient resource, it is determined to start the candidate executor. If the resource is insufficient, it is determined not to start the candidate executor.

[0057] As an optional embodiment, the method further includes the following steps:

[0058] In step S102, the non-blocking method is called by the executor monitor to execute the monitoring task, wherein the monitoring task is to monitor the resource usage of the target container at a fixed time;

[0059] In step S104, when the resource usage of the target container monitored by the executor monitor reaches the early warning condition, the abnormal executor with abnormal resource usage in the target container is determined.

[0060] In step S106, the abnormal executor is closed.

[0061] In addition to triggering sampling when creating an executor, the executor monitor can also sample the resource usage of the target container at a fixed time according to a polling mode to realize monitoring of the resource usage of the target container.

[0062] The early warning condition can be set according to actual conditions. For example, the early warning condition is that the resource usage rate of the target container exceeds 90%. The resource usage rate can be the ratio between the current resource usage of the target container and the resource amount applied when the target container is deployed.

[0063] Since the resource usage can include the usage information of multiple resources such as CPU, GPU, memory, and video memory, whether the early warning condition is reached can be determined by comprehensively judging the usage information of multiple resources according to a preset strategy.

[0064] If the resource usage of the target container reaches the early warning condition, it means that there is currently an overflow risk, and part of the executors need to be closed to reduce the number of instances running in the target container, so as to avoid the target service from crashing due to insufficient resources.

[0065] The executor monitor is also configured to monitor the running state of each executor in the target container. In the case where the resource usage of the target container reaches a pre-warning condition, an abnormal executor is determined.

[0066] The abnormal executor can be an executor that excessively occupies resources, such as an executor whose resource occupation amount exceeds a preset boundary value, which can be set according to actual conditions.

[0067] Optionally, the termination interface of the abnormal executor is called by the executor monitor to shut down the abnormal executor.

[0068] After the abnormal executor containing the instance is shut down, the number of instances in the target container is reduced, and the computing power of the target service is reduced.

[0069] In order to maintain the stability of the computing power of the target service, as an optional embodiment, the method further includes the steps as follows:

[0070] Step 302, in the case where the number of instances in the target container is reduced, a specified executor in the target container is determined, wherein the specified executor is an executor that is currently in an unstarted state;

[0071] Step 304, at least one specified executor is attempted to be started according to a preset starting strategy to restore the number of instances in the target container.

[0072] Optionally, in this embodiment, in the case where the number of instances in the target container is reduced, before all specified executors are determined, the method further includes the steps as follows:

[0073] Step S301, in the case where there is no specified executor in the target container, a new candidate executor is created.

[0074] The preset starting strategy can be determined comprehensively according to the resource amount, the priority of the target service, and the number of service requests. The preset starting strategy can include a stop condition, for example, after the attempt to start the executor fails, if the retry reaches a preset number of times or the preset time length is reached and the starting is still not started, the attempt to start the executor is stopped.

[0075] In the case where the number of instances in the target container is reduced, if there is a specified executor that is not started in the target container, the specified executor is attempted to be started to restore the number of instances in the target container to the number before the reduction, so as to maintain the stable computing power. If all specified executors are started and the number of instances in the target container still cannot be restored to the number before the reduction, new candidate executors need to be created and attempted to be started in the manner of steps S202 to S206 until the number of instances in the target container is restored to the number before the reduction or the stop condition in the preset starting strategy is reached.

[0076] In the case that the number of instances in the target container is reduced, if there is no un-started specified executor in the target container, a new candidate executor can be created and attempted to start in the manner of steps S202 to S206 until the number of instances in the target container is restored to the number before the reduction or a stop condition in the preset starting strategy is reached.

[0077] As an optional embodiment, after step S204, the method further includes:

[0078] Step S41, in the case that the candidate executor is determined to be started, the candidate executor is converted into a target executor after obtaining a prototype class in the target SDK and being instantiated into a target instance, wherein the target executor is used to listen to a newly appeared task object;

[0079] Step S42, in the case that the target executor listens to the newly appeared target task object, the target task object is obtained, wherein the target task object is obtained after a target service request is converted according to a target task class, the target service request is a service request for calling a target service, the target task class is defined with a container attribute and a task method, and the task method includes a result backwriting method;

[0080] Step S43, the target task object is processed by the target executor to obtain a target processing result, wherein the target executor is used to call the result backwriting method in the target task object to write the target processing result into a result container of the target task object in the case that the target processing result is obtained.

[0081] Optionally, in the embodiment, after step S42, in the case that the target executor listens to the newly appeared target task object, the target task object is obtained, the method further includes:

[0082] Step S51, the target return result corresponding to the target service request is determined by blocking the result data from the result container of the target task object.

[0083] In the case that the target service request is received, the target service request can be converted into a target task object by a task submitter according to a target task class, in the case that any target executor listens to the target task object, the target executor can obtain the target task object, and the target task object is processed by a target instance in the target executor to obtain a return result corresponding to the target service request.

[0084] The result container attribute and the task method can be defined in the target task class. The target service request is converted into the target task object according to the target task class, and the target task object containing the target result container is obtained. Since the target task class defines the task method, the target task object also contains the task method.

[0085] The task object is an instantiation object of a data type class of the construction. The target task class can be a base class, and a specific implementation class is used to instantiate the task object.

[0086] The task submitter is a thread for calling the task submission method of the task manager to submit the task object to the task container.

[0087] The task manager is a task management class object of the construction, and the task management class defines a task submission method for submitting the task object to the task container.

[0088] The task management class also defines a task container attribute for storing the task object. The task container is a container for storing the task object in the task manager.

[0089] Optionally, after the target service request is converted into the target task object, the target task object can be placed in the task container, and the target executor is used to listen to the newly appeared task object in the task container.

[0090] Optionally, when the target task object is acquired by the target executor, the target task object starts to block the acquired result data from the result container of the target task object, and determines the target return result corresponding to the target service request according to the acquired result data.

[0091] Through the above steps S41 to S43 and the step S51, the submission and processing of the task are decoupled, and the production-consumption mode is realized.

[0092] Optionally, in this embodiment, after the abnormal executor using the resource abnormally in the target container is determined in step S104, the method further includes the following steps:

[0093] In step S31, when the abnormal executor is an executor in the task processing stage, the result write-back method is called by the executor monitor to write the target abnormal result into the result container of the target task object.

[0094] Optionally, in step S51, the target return result corresponding to the target service request is determined by blocking the acquired result data from the result container of the target task object, including the following steps:

[0095] In step S511, the target abnormal result is obtained by blocking the acquired result data from the result container of the target task object.

[0096] Step S512, determine the target exception result as the target return result corresponding to the target service request.

[0097] The exception executor is closed when it is in the task processing stage, and the target processing result after the target task object is completed cannot be obtained. The result writing method is called by the executor monitor to write the target exception result into the result container of the target task object, so that the target task object can obtain the target exception result when blocking the result data, and the target exception result is used as the target return result corresponding to the target service request, so that the service calling party sending the target service request can know the processing situation of the target service request.

[0098] Through the above steps S511 to S512, it is ensured that no matter whether the service request parameter is reasonable, the result can be returned within the reasonable resource utilization, and the stability of the service to the outside is improved.

[0099] As an optional embodiment, before step S202, the method further includes the following steps:

[0100] Step S11, starting the target image as a target container in the form of a container, wherein the target image includes a service framework and a target SDK;

[0101] Step S12, according to the running script indicated by the entry command in the target image, the permission of executing the command in the target container is limited to user permission, and the start command of the service supervision process is executed, wherein the service supervision process closes all executors in the target container when it is necessary to close the target service through the message mechanism of the receiving system;

[0102] Step S13, start the service framework through the service supervision process to start creating the executor monitor.

[0103] Optionally, the target image is an image file including an operating system, environment dependency, a service framework, a target SDK, a target DSL and its encapsulation code, etc.

[0104] The target DSL refers to a domain specific language taking a general language as a host language, and belongs to an embedded DSL (Embedded Domain Specific Language). The host language of the target DSL can be an object-oriented programming language including but not limited to Python, Java, C++, and the like. The target DSL can include one or more classes, including a target service class, the target service class can define interfaces and methods, can define an abstract interface that must be implemented by a subclass, and can define a general method or interface that can be inherited or overridden. The storage form of the target DSL is not limited, and can be stored in the form of a module, a library, a file, or the like. For example, the target DSL is an embedded DSL taking Python as a host language, and is packaged into a wheel package in the form of a wheel, that is, the wheel package can be downloaded and installed in any Python development environment by using a pip tool.

[0105] Through steps S11 to S13, in the entry script of the target image started as a container, the permission is first degraded to run the subsequent commands in the permission of a certain common user created, to ensure that the target service in the target container does not affect the related resource configuration of the host machine; and then the start command of the service supervision process is executed, so that the PID of the started process is 1, that is, the parent process, to ensure that the system message mechanism can be received, and the graceful exit of the process is completed. All target service related processes are child processes, and when the service supervision process exits, it can ensure that all processes and threads opened in the target service running process are closed, so as to prevent orphan or zombie processes from continuously occupying resources, and to avoid the problem of resource leakage.

[0106] Optionally, in step S202, the candidate executors are created in the case that the target container is running, and the step further includes the following steps:

[0107] In step S21, after starting to create the executor monitor, a preset number of candidate executors are created by an executor manager in the target container and placed in an executor container of the executor manager, wherein the executor manager is an object of an executor management class, and the executor management class defines an executor creation method and an executor container attribute.

[0108] Optionally, the executor monitor is created by using a non-blocking method, and a non-blocking method is called to start a task of monitoring the resource usage of the target container in a timely manner.

[0109] Since the above is a non-blocking method, the executor creation process can be entered almost simultaneously, and a predetermined number of executors are created by the executor manager and placed in the executor container.

[0110] The executor manager is an executor management class object constructed, and various methods and attributes can be defined in the executor management class, such as an executor creation method, an executor container attribute, an executor refreshing method, and an executor state acquisition and return method.

[0111] As an optional embodiment, the technical solutions of the present application are described below in conjunction with the specific embodiments:

[0112] With more and more applications requiring AI (artificial intelligence) to empower them, a large number of algorithms in various fields are landing in the form of service interfaces. These services usually require a large amount of physical resources (CPU, GPU, memory, video memory, etc.) support, and the cost of resources such as GPU is quite high. Therefore, in order to improve the utilization rate of physical machines, multiple inference instances are usually started within a service, and multiple services are deployed on a physical machine. For a resource and system fixed physical machine, the requirements of the services deployed thereon for resources, environment, and the like are usually quite different. Therefore, to ensure that each AI service running on a physical machine at the same time can fully utilize the physical resources to achieve stable computing power (the number of inference instances that can run simultaneously in a service), a mechanism for improving the robustness of each service needs to be designed.

[0113] Problems in the related art: ① Different services on the same physical machine have different requirements for system and environment dependencies. ② Different running stages of the same service have discontinuous resource usage. A service that provides AI empowerment usually has peak physical resource usage when performing inference calculation; resource usage is second when initializing the inference model; and resource usage is less when processing the request data and computing results. Therefore, it is necessary to dynamically balance resource utilization and service stability. ③ The number of services that can be carried on the same physical machine at different times is different. The deployment platform only judges whether the resource application at the moment can meet the requirements of deploying a certain service. Therefore, the number of services carried by the same physical machine at different times is also different. However, the loadable amount of services at a certain moment does not represent the loadable amount of services at each stage, so the computing power output of different services needs to be adjusted according to the actual use of resources at different times. ④ The resource usage caused by different request parameters of the same service is also different. For example, a small video with low code stream and a long video with high code stream may be the same input of the same service, resulting in a large difference in resource usage and occupation time of the service when facing different requests. Therefore, the stability of computing power in the face of different requests is also a problem to be solved. ⑤ Service crashes caused by resource shortage cannot be located. Resource shortage such as OOM (Out of Memory, here referring to memory or video memory overflow) will directly cause the service to crash and fail to complete the normal service process, resulting in no response to the request or the problem cannot be located.

[0114] The embodiment provides a service configuration scheme: ①containerization is used to encapsulate services, each container is made into a minimum independent system meeting service requirements, different containers can be simultaneously deployed on a physical machine to become host machines of the containers, and user permissions in the containers are controlled so that the services do not have administrator permissions of the host machines of the containers and cannot affect resource configuration of the host machines. ②a task object, a task manager, a task submitter, an executor, an executor manager, an executor monitor are designed, and a production and consumption mode is implemented to decouple tasks and reasoning. ③the executor monitor has two working modes of event triggering and polling. The event triggering is starting of the executor. Each time the executor starting process is entered, the monitor first triggers calculation of resource usage in the container, and determines whether there is enough resource to start a new executor according to the number of existing executors. The polling mode is that the monitor regularly collects resource usage in the container, and when the resource usage rate reaches a warning value, the executor with the resource usage exception is gracefully exited in the following mode: when the executor is not in the task execution stage, the executor does not need to return a result and can be directly terminated; when the executor is in the task execution stage, related information of the executor with the resource usage exception is returned as data of a result, and then the executor is terminated. After the executor is terminated, because of loss of computing power, a new executor creation process is entered, but whether the new executor can be successfully started and when the new executor is started are determined according to the event triggering mode of the monitor.

[0115] Overall idea of the scheme is as follows:

[0116] (1) basic concept introduction

[0117] 1. Task: represented by the graph shown in the figure. It is an instantiation object of a data type class, and the actual task class (i.e., the target task class in the application) is a base class, which has two specific implementation classes for instantiating synchronous and asynchronous task objects. An important attribute for decoupling with execution is the result container attribute. When the executor is in the form of multithreading, the attribute is a container object; when the executor is in the form of multiprocessing, the attribute is a container proxy object. Figure 3

[0118] 2. Task manager: a task management class object. It has a container attribute for storing task objects and a method for submitting the task objects to the container; a method for obtaining and returning the task execution state, and the like.

[0119] 3. Task submitter: a thread for calling the task manager to submit the task method and submitting the task to the task container.

[0120] 4. Executor: a thread / process for result calculation (mainly model reasoning), which usually appears in the form of concurrency or parallelism, and when the executor is successfully created and is in a state of being able to process tasks, it enters the role of a consumer.​

[0121] 5. Executor manager: The executor management class object is constructed. It has methods such as executor generation, refreshing, state acquisition and return, and attributes such as an executor container.

[0122] 6. Executor monitor: A thread or process that monitors the running state of the executor. It will implement corresponding measures such as writing back task results and restarting the executor according to different state definitions, such as timeout state for the running time of the executor being longer than the intended time of task execution, unhealthy state for the executor being in dead busy, zombie, etc., and excessive resource occupation, etc. Whether the resource usage rate reaches the warning is one of the many indicators monitored by the executor monitor. The overall schematic of the executor manager with the executor monitor is shown in Figure 4

[0123] (B) Overall thought process

[0124] As shown in Figure 5 , this scheme divides resource monitoring into two modes: time trigger and event trigger. On the one hand, the timing monitoring of resources is to ensure that at a certain moment, all inference instances of services running on the same host machine will not crash due to insufficient resources or abnormal use of resources, resulting in failure to return the execution result normally. On the other hand, the monitoring of resources will be triggered by the event of starting an executor. This event occurs in two cases. When a service is first deployed to a host machine, the host machine can definitely carry at least one inference instance of the service, and at this time, the resource evaluation of the monitor is equivalent to a second check. After starting an inference instance, in order to improve the utilization rate of resources and the output of computing power, the process of starting the next instance will be entered, which will trigger resource monitoring again. According to the existing instances and resource usage, it is judged whether it can be started; the other case is that the timing monitoring finds that the resource usage reaches the warning value, and the executor with abnormal resource usage needs to be terminated to ensure the stability of the service. However, for subsequent task requests, the service loses the computing power of one inference instance, so in order to maintain the stable computing power of the service as much as possible, there will be a process to try to restart the lost instance, which will continuously trigger resource monitoring until the resource evaluation is passed, and then the instance will be started, ensuring the computing power output under the premise of service stability.

[0125] The specific implementation steps of this scheme are as follows:

[0126] (1) Make an image file including operating system, environment dependency, service framework, SDK framework, algorithm SDK and its encapsulation code, etc.

[0127] ​(2) In the entry script of the mirror image started as a container, the permission is first degraded to run the subsequent commands under the permission of a certain ordinary user created to ensure that the services in the container will not affect the relevant resource configuration of the host machine; then the exec command is used to execute the start command of the service supervision process, so that the PID of the started process is 1, that is, the parent process, to ensure that it can receive the system message mechanism and complete the graceful exit of the process. When exiting, the service supervision process can ensure that all processes and threads opened during the running of the service are closed, avoiding the problem of resource leakage.

[0128] (3) The service supervision process starts the service framework, and before the server starts, an executor monitor is created.

[0129] (4) When the executor monitor is created, a non-blocking method is called to start a task for monitoring resources.

[0130] (5) Since the above is a non-blocking method, the main process can almost simultaneously enter the process of creating an executor, creating a certain number of executors and placing them in an executor container.

[0131] (6) Before the executor starts, the monitor triggers resource sampling and evaluation. CPU and memory usage information can be obtained through relevant parameters in the container, and by comparing with the amount of resources applied when the container is deployed, the resource usage rate can be obtained; GPU and video memory and other related resource usage can be directly obtained using the corresponding tools in the development kit.

[0132] (7) When the inference instance is the first in the service, the resource evaluation is a recheck, which is usually passed; whether the subsequent inference instance can be started is determined by the executor manager according to the number of existing instances and resource usage evaluation.

[0133] (8) The successfully started executor first dynamically imports all modules where the inference prototype classes are located, then obtains all inference prototype classes and instantiates them, and then converts to the role of a consumer to listen to whether there is a new task in the task manager in a blocking manner. If a new task arrives, perform inference calculation.

[0134] (9) In the process of (5)-(8), (4) periodically performs resource sampling and evaluation according to the timing configuration. When it is found that the resource usage reaches the warning, the task execution stage of the resource usage abnormal executor is judged. If the executor is not in task execution, the executor monitor calls the termination interface of the executor to close the executor; if the executor is in task execution, the executor monitor first calls the result backwriting method of the task object to write the resource usage abnormal error information to the result container of the task object in the form of result, which is obtained by the task object and returned as a service response, and then calls the termination interface of the executor to close the executor.

[0135] (10) In any case of (9), after the executor is closed, the executor manager finds that the inference instance is reduced, that is, the computing power is reduced, and it will try to start a new executor, and this event will enter step (6). The retry strategy can be customized according to resources, service priority and task quantity. After the computing power is restored or a certain strategy is met, the retry is stopped.

[0136] By the scheme, the following beneficial effects can be achieved:

[0137] 1. The supervision process is realized as a parent process, and all service related processes are child processes. The supervision process is taken as a parent process with PID 1, can accept a system signal mechanism, and is gracefully exited; the supervision process guarantees to close all child processes when exiting, so as to avoid orphan or zombie processes from continuously occupying resources.

[0138] 2. A monitor with two working modes of time and event triggering is designed and implemented. A closed loop of resource monitoring is formed, that is, evaluation at the moment of instance creation and monitoring of service running at different time periods on a host machine.

[0139] 3. The resource monitoring granularity is an executor object, which is decoupled from specific tasks. The resource monitoring strategy is directly reflected in different operations of the executor monitor, which can ensure that task results are returned within reasonable resource utilization regardless of whether the task request parameters are reasonable or not, and improve the stability of the service to the outside. The positioning of resource use abnormalities can reach the process granularity, that is, when the resources are abnormal, the monitor only closes the specific executor causing the abnormality, and does not make the entire container crash, thereby reducing the time of re-deployment due to container crash and improving the robustness of the service. The operation granularity of the monitor is an executor, that is, an inference instance. It directly evaluates the possibility of computing power output; when the computing power is lost due to an abnormality, it can have a "memory" to try to restore the computing power. Therefore, stable computing power can be output under the condition of reasonable resource utilization.

[0140] It should be noted that, for each of the foregoing method embodiments, in order to simply describe, it is expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the order of the described actions, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0141] Those skilled in the art can clearly understand that the method according to the above-mentioned embodiments can be realized by means of software on a general hardware platform as necessary, and of course, can also be realized by hardware, but in many cases, the former is a better implementation. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a plurality of instructions for causing a terminal device (which can be a mobile phone, a computer, a server, or a network device) to execute the method described in each embodiment of the present application.

[0142] According to another aspect of the embodiments of the present application, a service configuration apparatus for implementing the above-mentioned service configuration method is also provided. Figure 6 is a schematic diagram of an optional service configuration apparatus according to an embodiment of the present application, as shown in Figure 6 , the apparatus can include:

[0143] The creating module 22 is configured to create a candidate executor in a case where the target container is running, wherein the target container encapsulates a target SDK for building a target service, the candidate executor is an executor to be started, and the executor is a thread or a process in the target container.

[0144] The sampling module 24 is configured to sample a resource usage of the target container by an executor monitor to obtain a target sampling result.

[0145] The determining module 26 is configured to determine whether to start the candidate executor to dynamically configure the executor in the target service according to the target sampling result and a current instance number in the target container, wherein the candidate executor is configured to obtain a prototype class in the target SDK and instantiate as a target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is configured to process a service request for calling the target service by the target instance.

[0146] It should be noted that the creating module 22 in this embodiment can be configured to perform step S202 in the embodiments of the present application, the sampling module 24 in this embodiment can be configured to perform step S204 in the embodiments of the present application, and the determining module 26 in this embodiment can be configured to perform step S206 in the embodiments of the present application.

[0147] It should be noted that the above-mentioned modules and the examples and application scenarios realized by the corresponding steps are the same, but are not limited to the content disclosed in the above-mentioned embodiments. It should be noted that the above-mentioned modules as part of the apparatus can run in a hardware environment as shown in Figure 1 , and can be realized by software or hardware.

[0148] Through the above module, the technical problem of low resource utilization caused by the fact that a small number of instances are usually run in the service to avoid service collapse in the related art is solved.

[0149] As an optional embodiment, the apparatus further comprises a monitoring module configured to: call a non-blocking method to perform a monitoring task through the executor monitor, wherein the monitoring task is to monitor the resource usage of the target container at a fixed time; and determine an abnormal executor that uses resources abnormally in the target container when the executor monitor monitors that the resource usage of the target container reaches a pre-warning condition.

[0150] Optionally, the apparatus further comprises a starting module configured to: convert the candidate executor into a target executor after the candidate executor acquires a prototype class in the target SDK and instantiates the prototype class into a target instance, wherein the target executor is configured to listen to a newly appeared task object.

[0151] Optionally, the apparatus further comprises a processing module configured to: acquire the target task object when the target executor listens to the newly appeared target task object, wherein the target task object is obtained by converting a target service request according to a target task class, the target service request is a service request for calling a target service, the target task class is defined with a container attribute and a task method, and the task method comprises a result write-back method; and process the target task object through the target executor to obtain a target processing result, wherein the target executor is configured to write the target processing result into a result container of the target task object by calling the result write-back method in the target task object when the target processing result is obtained.

[0152] Optionally, the apparatus further comprises a returning module configured to: acquire the result data from the result container of the target task object to determine a target return result corresponding to the target service request.

[0153] Optionally, the monitoring module is further configured to: when the abnormal executor is an executor in a task processing stage, write a target abnormal result into a result container of a target task object by calling a result write-back method through the executor monitor.

[0154] Optionally, the returning module is further configured to: acquire the target abnormal result from the result container of the target task object to determine the target abnormal result as a target return result corresponding to the target service request.

[0155] Optionally, the apparatus further comprises a restarting module configured to: in the case that the number of instances in the target container decreases, determine a designated executor in the target container, wherein the designated executor is an executor currently in an unstarted state; and attempt to start at least one designated executor according to a preset starting strategy to restore the number of instances in the target container.

[0156] Optionally, the creating module 22 is further configured to: in the case that the designated executor does not exist in the target container, create a new candidate executor.

[0157] Optionally, the apparatus further comprises a preparing module configured to: start the target image in the form of a container as a target container, wherein the target image comprises a service framework and a target SDK; and execute a starting command of a service supervision process according to a running script indicated by an entry command in the target image, wherein the service supervision process closes all executors in the target container in the case that the target service needs to be closed through a message mechanism of a receiving system, and the service supervision process starts the service framework to begin creating an executor monitor.

[0158] Optionally, the creating module 22 is further configured to: after starting the executor monitor, create a preset number of candidate executors through an executor manager in the target container and place the candidate executors in an executor container of the executor manager, wherein the executor manager is an object of an executor management class, and the executor management class defines an executor creation method and an executor container attribute.

[0159] As another optional embodiment, the sampling module 24 comprises a triggering unit and a sampling unit, the triggering unit is configured to trigger the sampling unit after the candidate executor is created, so that the sampling unit samples the resource usage of the target container through the executor monitor to obtain a target sampling result.

[0160] Optionally, the triggering unit is further configured to trigger the sampling unit at a regular time, so that the sampling unit invokes a non-blocking method through the executor monitor to perform a monitoring task.

[0161] Optionally, the determining module 26 is further configured to: in the case that the resource usage of the target container monitored by the executor monitor reaches a warning condition, determine an abnormal executor in the target container that has an abnormal resource usage; and close the abnormal executor.

[0162] It should be noted that the above modules have the same examples and application scenarios as the corresponding steps, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules as part of the apparatus can run in the hardware environment as shown in Figure 1 , and can be implemented by software or hardware, wherein the hardware environment comprises a network environment.

[0163] According to another aspect of the embodiments of the present application, an electronic device is provided for implementing the above service configuration method, comprising: Figure 7 As shown in the figure, the electronic device can include a processor 1501, a communication interface 1502, a memory 1503 and a communication bus 1504, wherein the processor 1501, the communication interface 1502 and the memory 1503 complete mutual communication through the communication bus 1504.

[0164] The memory 1503 is used to store computer programs.

[0165] The processor 1501 is used to execute the programs stored in the memory 1503, and implement the steps of the above method embodiments.

[0166] The bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or only one type of bus.

[0167] The communication interface is used for communication between the above electronic device and other devices.

[0168] The memory can include a Random Access Memory (RAM) and can also include a Non-Volatile Memory (NVM), for example, at least one disk memory. Optionally, the memory can also be at least one storage device located away from the above processor.

[0169] The above processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0170] Those skilled in the art can understand that, Figure 7The structure shown is only schematic and does not limit the structure of the electronic device described above. For example, the electronic device can further include more or fewer components (such as a network interface, a display device, etc.) than those shown, or have a different configuration than that shown. Figure 7 The electronic device can further include more or fewer components (such as a network interface, a display device, etc.) than those shown in the middle, or have a different configuration than that shown. Figure 7 The electronic device can further include more or fewer components (such as a network interface, a display device, etc.) than those shown in the middle, or have a different configuration than that shown.

[0171] The embodiments of the present application also provide a computer readable storage medium, the storage medium includes a stored program, wherein the program runs to perform the method steps of the method embodiments described above.

[0172] Optionally, in the present embodiment, the storage medium can include but is not limited to: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0173] By adopting the embodiments of the present application, a service configuration scheme is provided. By creating a thread or process as an executor in the target container, each executor is not started directly after being created, but whether the executor needs to be started is determined according to the current resource usage of the target container and the current instance number in the target container. The executor has instances for processing service requests only after being started. The number of instances running in the target service is controlled according to the resource usage, the dynamic configuration of the target service is realized, and thus the instances running on the physical machine are not increased in the case of insufficient resources, and the technical problem of low resource utilization caused by the fact that a small number of instances are usually running in the service in the related art to avoid service collapse is solved.

[0174] Optionally, the specific examples in the present embodiment can refer to the examples described in the above embodiments, which will not be described herein again.

[0175] It should be noted that, in the present text, relationship terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement "including a" does not exclude the presence of another identical element in the process, method, article or device including the element.

[0176] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0177] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

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

[0179] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and 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 through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0180] 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.

[0181] Furthermore, the functional units in the various embodiments of this application 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0182] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A service configuration method, characterized by, The method comprises the following steps: In the case of running a target container, a candidate executor is created, wherein the target container encapsulates a target SDK for building a target service, the candidate executor is an executor to be started, and the executor is a thread or a process in the target container; A target sampling result is obtained by sampling resource usage of the target container through an executor monitor; It is determined whether to start the candidate executor to dynamically configure the executor in the target service according to the target sampling result and a current instance number in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate a target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is used to process a service request for calling the target service through the target instance; Before the step of creating the candidate executor in the case of running the target container, the method further comprises the following steps:

2. The method of claim 1, wherein, The target image is started in the form of a container to form the target container, the target image comprises a service framework and the target SDK, the permission of executing a command in the target container is limited to a user permission according to a running script indicated by an entry command in the target image, a start command of a service supervision process is executed, the service supervision process closes all executors in the target container when the target service needs to be closed through a message mechanism of a receiving system, and the service supervision process starts the service framework to create the executor monitor. The method further comprises the following steps: A non-blocking method is called by the executor monitor to execute a monitoring task, wherein the monitoring task is to monitor resource usage of the target container at a fixed time; When the executor monitor monitors that resource usage of the target container reaches a warning condition, an abnormal executor with abnormal resource usage in the target container is determined; 3. The method of claim 2, wherein, The abnormal executor is closed. After the step of determining whether to start the candidate executor according to the target sampling result and the current instance number in the target container, the method further comprises the following steps: When it is determined to start the candidate executor, the candidate executor is converted into a target executor after obtaining a prototype class in the target SDK and instantiating a target instance, wherein the target executor is used to listen to a newly appeared task object; When the target executor listens to a newly appeared target task object, the target task object is obtained, wherein the target task object is obtained by converting a target service request according to a target task class, the target service request is a service request for calling the target service, the target task class defines a container attribute and a task method, and the task method comprises a result backwriting method; The target task object is processed by the target executor to obtain a target processing result, wherein the target executor is used to call the result backwriting method in the target task object to write the target processing result into a result container of the target task object when the target processing result is obtained. The target return result corresponding to the target service request is determined by blocking the acquisition of result data from the result container of the target task object.

4. The method of claim 3, wherein, After the abnormal executor corresponding to the abnormal resource usage in the target container is determined, the method further comprises: In the case that the abnormal executor is an executor in a task processing stage, the result write-back method is called by the executor monitor to write the target abnormal result into the result container of the target task object; The target return result corresponding to the target service request is determined by blocking the acquisition of result data from the result container of the target task object. The target abnormal result is obtained by blocking the acquisition of result data from the result container of the target task object; The target abnormal result is determined as the target return result corresponding to the target service request.

5. The method of claim 1, wherein, The method further comprises: In the case that the number of instances in the target container is reduced, a specified executor in the target container is determined, wherein the specified executor is an executor currently in an unstarted state; At least one specified executor is attempted to be started according to a preset starting strategy to restore the number of instances in the target container; Before all the specified executors are determined, the method further comprises: in the case that the specified executor does not exist in the target container, a new candidate executor is created.

6. The method of claim 1, wherein, The candidate executor is created in the case that the target container is running, comprising: After the creation of the executor monitor is started, a preset number of candidate executors are created by an executor manager in the target container and placed in an executor container of the executor manager, wherein the executor manager is an object of an executor management class, and the executor management class defines an executor creation method and an executor container attribute.

7. A service configuration apparatus characterized by comprising: Comprise: A creation module is configured to create a candidate executor in the case that a target container is running, wherein the target container encapsulates a target SDK used to build a target service, the candidate executor is a to-be-started executor, and the executor is a thread or a process in the target container; A sampling module is configured to sample a resource usage of the target container by an executor monitor to obtain a target sampling result; A determination module is configured to determine whether to start the candidate executor to dynamically configure an executor in the target service according to the target sampling result and a current number of instances in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate a target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is used to process a service request for calling the target service by the target instance; A determination module is configured to determine whether to start the candidate executor to dynamically configure an executor in the target service according to the target sampling result and a current number of instances in the target container, wherein the candidate executor is used to obtain a prototype class in the target SDK and instantiate a target instance when started, the candidate executor is converted into a target executor after being started, and the target executor is used to process a service request for calling the target service by the target instance; The service configuration device further comprises a preparation module configured to: before creating the candidate executor, start the target image as the target container in the form of a container in the case that the target container is running, the target image comprising a service framework and the target SDK; execute a service supervision process start command by limiting the execution command in the target container to user permissions according to a running script indicated by an entry command in the target image, and closing all executors in the target container in the case that the target service needs to be closed through a message mechanism of a receiving system; and start the service framework through the service supervision process to begin creating an executor monitor.

8. An electronic device, comprising: Comprise: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory is used for storing a computer program; the processor is used for executing the computer program to implement the method in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The storage medium comprises a stored program, wherein the program executes the method in any one of the preceding claims 1 to 6 when running. The storage medium comprises a stored program, wherein the program executes the method in any one of the preceding claims 1 to 6 when running.

Images