Function configuration methods in serverless architecture, computing device, storage medium and program product

Abstract

Provided in the embodiments of the present disclosure are function configuration methods in serverless architecture, a computing device, a storage medium and a program product. A method comprises: determining at least one target execution unit in a target container instance corresponding to a function; determining a label corresponding to the target container instance, the label being determined on the basis of the function; and configuring the label for the at least one target execution unit, the label being used for instructing to schedule execution units configured with the same label to virtual cores generated by means of emulation of the same physical core. The technical solution provided in the embodiments of the present disclosure improves performance stability.

Description

[0001] Function configuration method in serverless architecture, computing device, storage medium and program product The present disclosure claims priority to Chinese Patent Application No. 202410813322.1, filed on June 21, 2024 with the Chinese Patent Office, entitled "Function configuration method in serverless architecture, computing device, storage medium and program product", the entire contents of which are incorporated herein by reference. TECHNICAL FIELD Embodiments of the present disclosure relate to the technical field of computer technology, and in particular to a function configuration method in serverless architecture, a computing device, a storage medium and a program product. BACKGROUND In some cloud computing systems that provide Serverless (serverless) services, users only need to write functions, and the cloud computing system allocates computing resources for them and charges resources according to the actual execution time of the functions. Function execution usually needs to create a corresponding container instance in the host machine, and execute in the form of one or more execution units in the container instance. In order to improve processing performance and resource utilization, etc., the current host machine usually starts the hyper-threading technology. Hyper-threading technology refers to simulating the generation of multiple virtual cores in a physical core. These virtual cores are also known as hyper-threads. Through hyper-threading technology, multiple execution units can be allowed to alternate execution in the same physical core, thereby improving parallel processing capability. However, due to the start of the hyper-threading technology, multiple virtual cores will share the same physical core resources, so there will be hyper-threading interference problems, which will greatly affect the function execution time and cause performance fluctuations. SUMMARY Embodiments of the present disclosure provide a function configuration method in serverless architecture, a computing device, a storage medium and a program product to solve the technical problem of easy performance fluctuations in the prior art. In a first aspect, a function configuration method in serverless architecture is provided in embodiments of the present disclosure, comprising: determining at least one target execution unit in a target container instance corresponding to a function; determining a label corresponding to the target container instance, the label being determined according to the function; configuring the label for the at least one target execution unit; wherein the label is used to indicate that execution units configured with the same label are scheduled into a virtual core simulated by the same physical core. In a second aspect, a function configuration method in serverless architecture is provided in embodiments of the present disclosure, comprising: in response to a function invocation request, determining a label corresponding to the function; determining a target host machine; sending the label to the target host machine, so that the target host machine configures the label for at least one target execution unit in a target container instance corresponding to the function; wherein the label is used to indicate that execution units configured with the same label are scheduled into a virtual core simulated by the same physical core.In a third aspect, the embodiments of the present disclosure provide a computing device, comprising a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be invoked and executed by the processing component, so as to implement the function configuration method in the serverless architecture according to the first aspect or the function configuration method in the serverless architecture according to the second aspect. In a fourth aspect, the embodiments of the present disclosure provide a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processing component, the function configuration method in the serverless architecture according to the first aspect or the function configuration method in the serverless architecture according to the second aspect is implemented. In a fifth aspect, the embodiments of the present disclosure provide a computer program product, comprising computer programs / instructions, and when the computer programs / instructions are executed by a processing component, the function configuration method in the serverless architecture according to the first aspect or the function configuration method in the serverless architecture according to the second aspect is implemented. According to the embodiments of the present disclosure, according to the label corresponding to the function, at least one target execution unit of the function in the corresponding target container instance is configured with the label, so that the execution units configured with the same label can be scheduled to the same physical core simulated virtual core, so that different target execution units of the function can run in the same physical core. Since the resource competitiveness of different target execution units of the function is equivalent, the execution time of different target execution units of the function under different conditions is close and relatively stable, so that the performance stability can be improved, and the user experience can be improved. These aspects or other aspects of the present disclosure will be more apparent in the following description of the embodiments. BRIEF DESCRIPTION OF DRAWINGS In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure or the prior art, the drawings needed in the description of the embodiments or the prior art will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present disclosure, and those skilled in the art can also obtain other drawings according to these drawings without creative effort.FIG. 1 shows a flowchart of one embodiment of a function configuration method in a serverless architecture provided by the present disclosure; FIG. 2 shows a scheduling schematic diagram in an actual application of an embodiment of the present disclosure; FIG. 3 shows a label configuration schematic diagram in an actual application of an embodiment of the present disclosure; FIG. 4 shows a flowchart of another embodiment of a function configuration method in a serverless architecture provided by the present disclosure; FIG. 5 shows a scene interaction schematic diagram in an actual application of an embodiment of the present disclosure; FIG. 6 shows a structural schematic diagram of one embodiment of a function configuration apparatus in a serverless architecture provided by the present disclosure; FIG. 7 shows a structural schematic diagram of another embodiment of a function configuration apparatus in a serverless architecture provided by the present disclosure; and FIG. 8 shows a structural schematic diagram of one embodiment of a computing device provided by the present disclosure. DETAILED DESCRIPTION In order to make the person skilled in the art better understand the present disclosure scheme, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present disclosure. In some processes described in the specification and claims of the present disclosure and the above-described accompanying drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that these operations can be executed or performed in parallel without the order in which they appear in the present text, and the serial numbers of the operations, such as 101, 102, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and the operations can be executed in sequence or in parallel. It should be noted that the "first", "second", etc. in the present text are used to distinguish different messages, devices, modules, etc., and do not represent the order, nor do "first" and "second" represent different types. The technical solutions of the present disclosure can be applied to a cloud computing system of a serverless architecture, which is a cloud computing mode, also known as functions-as-a-service (FaaS). This serverless computing environment can be charged based on the execution time of each function and the amount of resources allocated for the execution of the function. Users only need to write functions, and the cloud computing system allocates computing resources for them, and charges resources according to the actual execution time of the function. As described in the background art, the host usually starts the hyper-threading technology, and each virtual core can allocate a thread, and the physical core allocates computing resources between the multiple virtual cores simulated by it, so as to improve the parallel processing capability of the physical core, but the hyper-threading technology will have hyper-threading interference, and the same virtual core will occupy resources.The inventors find that the execution units corresponding to a function can be randomly scheduled to different virtual cores, resulting in unstable execution duration of different execution units, ultimately affecting the function execution duration and causing performance fluctuations. To improve performance stability, the inventors propose the technical solutions of the embodiments of the present disclosure after a series of researches. In the embodiments of the present disclosure, a label corresponding to a function is configured for at least one target execution unit of the function in a target container instance corresponding to the function, so that execution units configured with the same label can be scheduled to the same virtual core simulated by a physical core, so that different target execution units of the function can run in the same physical core. Since the resource competitiveness of different target execution units of the function is comparable, the execution duration of different target execution units of the function under different conditions is close and relatively stable, so that the performance stability can be improved and the user experience can be improved. The technical solutions in the embodiments of the present disclosure will be described clearly and completely in combination with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present disclosure. The technical solutions of the embodiments of the present disclosure can be applied to a system architecture composed of a user end, a service end and a host. In one practical application, the system architecture can be a cloud computing system. The cloud computing system can provide a serverless service. The serverless is a cloud computing mode, also known as functions-as-a-service (FaaS), which allows the use of short-term running, usually stateless functions triggered by events. The term "serverless" does not mean that there is no use of computer servers in the computing environment. On the contrary, the term means that users of the serverless computing environment do not need to provide or manage physical computer servers, virtual machines, containers, etc. used by the platform when executing user instructions. In the serverless computing environment, resource allocation is managed by a cloud service provider, allowing the development of functions without considering the implementation, adjustment or expansion of servers. The serverless computing environment provides a method to achieve the purpose of serverless, allowing developers to execute code to respond to events without building or maintaining complex infrastructure. A service can be split into a series of functions that can be automatically and independently scaled to handle potential loads, rather than by expanding monolithic hardware devices. The end user of such a serverless computing environment can be charged based on the execution time of the function and the amount of resources allocated for the execution of the function.The server can be implemented as a distributed server cluster composed of multiple servers, or as a single server. The server can be a server of a distributed system, or a server combined with a blockchain. The server can be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, cloud communication, network services, middleware services, domain name services, security services, content distribution networks (CDN), big data, and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. In one implementation, the server can be a cloud computing node provided by a cloud computing system, which can include a physical server, a bus, and other system components coupled to the processing component, including a storage component. Among them, the user end is a browser, APP (Application, application), or a web application such as H5 (HyperText Markup Language, HyperText Markup Language 5th edition) application, or light application (also known as small program, a lightweight application) or cloud application or SDK (Software Development Kit, Software Development Kit), etc. The user end can be deployed in the user's local electronic device, such as a personal mobile terminal such as a mobile phone, a tablet computer, a personal computer, etc. Various other types of applications can also be configured in the electronic device, such as human-computer dialogue applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc. The electronic device can be a device used by the user, which has the functions of computing, networking, and communication required by the user, such as a mobile phone, a tablet computer, a personal computer, a wearable device, etc. The electronic device can generally include at least one processing component and at least one storage component. The electronic device can also include a network card chip, a 10 bus, audio and video components, etc. The present disclosure does not limit this. Optionally, according to the implementation form of the electronic device, some peripheral devices such as a keyboard, a mouse, a stylus, a printer, etc. can also be included, and the present disclosure does not limit this. The user end can call the corresponding API (Application Programming Interface, Application Programming Interface) to initiate a related request, etc., which is responded by the server to perform corresponding processing, etc. The host machine can be a physical machine that actually executes functions.It should be noted that the embodiments of the present disclosure can involve the use of user data. In actual application, user-specific personal data can be used in the schemes described herein within the scope permitted by applicable laws and regulations (for example, user explicit consent, user actual notification, etc.) in the case of meeting the requirements of applicable laws and regulations of the country. It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present disclosure are information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose authorization or not. It should be noted that the technical solutions of the embodiments of the present disclosure are applicable to a network virtual environment, and the users described are generally "virtual users". Real users can register user accounts in the server through registration to obtain user identities in the network environment. The implementation details of the technical solutions of the embodiments of the present disclosure are described in detail below. FIG. 1 is a flowchart of one embodiment of a function configuration method in a serverless architecture provided by the present disclosure. The technical solutions of the present embodiment can be executed by a host computer. The method comprises the following steps.

[0002] 101 : determine at least one target execution unit in a target container instance corresponding to a function. In the Server less architecture, a function is the most basic computing unit, composed of a code snippet written and deployed by a developer, usually used to perform a specific task or respond to a specific event. In actual application, a function usually runs in a container instance, and one function can correspond to the creation of multiple container instances, each container instance can represent a function instance, that is, the runtime environment of a function, which exists in the form of one or more execution units created in the container instance. In the embodiments of the present disclosure, the execution unit can refer to a process or a thread, which is not limited in the present disclosure. The target container instance can refer to any container instance corresponding to the function, and at least one target execution unit is created in the target container instance to execute the specific task corresponding to the function. The target container instance is generated by the host machine, and in actual application, a virtual machine can be created first, the target container instance is created in the virtual machine, and at least one target execution unit is created in the target container instance. Alternatively, the host machine can create the target container instance in response to a container creation request, and the container creation request can be sent by the server. The server can determine whether there is a target container instance corresponding to the function based on the function call request, if not, it can send a container creation request to the host machine to request the creation of a target container instance; and if there is a target container instance corresponding to the function, it can directly send a function call request. The function call request can be generated by the user or in response to a specific event. Therefore, the determination of the target container instance corresponding to the function and the execution unit in the target container instance can include: creating a target container instance corresponding to the function and at least one target execution unit in the target container instance in response to a container creation request

[0003] 102: Determine the label corresponding to the target container instance. The label can be used to uniquely identify the function according to the function; of course, as an optional manner, since the execution units of the same task type are generally considered to have similar execution time, the label can be used to uniquely identify the task type to which the function belongs. In addition, since the function can correspond to the creation of multiple container instances, each container instance also has a corresponding relationship with the label corresponding to the function. Wherein, the label corresponding to the function can be determined by the server and sent to the host, which can be sent independently or contained in the container creation request and sent to the host. The present disclosure does not limit this, and the host can determine the label corresponding to the target container instance according to the label sent by the server. The host can save the label corresponding to the target container instance to the local database, etc. In the case of using the label to identify the task type, the server can first determine the task type of the function, and determine the label used to identify the task type for it. Wherein, the determination manner of the task type will be described in detail in the corresponding embodiments below.

[0004] 103: Configure the tag for at least one target execution unit. After determining the tag corresponding to the target container instance, the tag can be configured for the target execution unit in the target container instance. Optionally, configuring the tag for at least one target execution unit can be implemented by configuring the tag for the target container instance, so that the tags of all execution units in the same container instance are the same. The tag can be used to indicate that the execution units configured with the same tag are scheduled to the virtual cores generated by the same physical core, so as to ensure that the execution units with the same tag run in different virtual cores of the same physical core. In the case of using the tag to identify the function, the execution units of the same function run in different virtual cores of the same physical core. In the case of using the tag to identify the task type, since the task types of different functions can be the same, the execution units of different functions can run in different programs of the same physical core. For ease of understanding, referring to the execution unit scheduling diagram shown in FIG. 2, it is assumed that the physical cores Core0, Core1 and Core2 in FIG. 2 generate two virtual cores, and there are two tags in FIG. 2. The black circle represents an execution unit configured with the tag A, and the white circle represents an execution unit configured with the tag B. Since one physical core corresponds to two virtual cores, the two execution units can be scheduled as a group to one physical core. As shown in FIG. 2, the currently running execution units in Core0 and Core1 are execution units configured with the tag B, and the currently running execution unit in Core2 is an execution unit configured with the tag A. The next group of execution units to be scheduled in each physical core are also execution units with the same tag. The ellipse in FIG. 2 represents a group of execution units. In this embodiment, the execution units configured with the same tag are scheduled to the virtual cores generated by the same physical core, so that different target execution units of the function can run in the same physical core. Since the resource competition of different target execution units of the function is equivalent, the execution time of different target execution units of the function under different conditions is close and relatively stable, thereby improving the performance stability and user experience. In some embodiments, for a target execution unit, there can be no execution unit with the same tag that is not scheduled. In order to ensure the performance stability, the method can further include: for any target execution unit, if there is no execution unit with the same tag, scheduling the target execution unit to a first virtual core generated by a first physical core, and controlling the opposite virtual core in the first physical core to be in an idle state; and controlling the running of the target execution unit according to the target resource constraint parameter corresponding to the function. The target resource constraint parameter can constrain the calculation resources allocated to the target execution unit.The peer virtual core can be the remaining virtual core after the first virtual core in the first physical core, the first physical core can be any physical core, and the first virtual core can be any virtual core. By forcing the peer virtual core to be idle and using the resource constraint parameter to constrain the computing resources available to the target execution unit, the execution time of the target execution unit is stabilized, thereby ensuring the function performance stability and improving the user experience. The computing resources can be CPU, memory, and other hardware resources, and can also be operating system and other software resources. In an actual application, the computing resources can be CPU resources, i.e., CPU computing power, which can be interpreted as the number of instructions that the CPU can execute per second. In theory, if the peer virtual core is in an idle state, the target execution unit can obtain 100% (percent) of the CPU computing power, but this will cause the execution time of the target execution unit to change and thus cause performance fluctuations. Because in the case where the peer virtual core is not idle, due to resource competition, the target execution unit can only obtain part of the CPU computing power. Therefore, in order to ensure performance stability, the target execution unit can obtain the same or similar CPU computing power in the case where the peer virtual core is idle or not idle by constraining the resource usage range when the peer virtual core is idle, thereby ensuring performance stability. The target resource constraint parameter can be determined in advance, for example, it can be 60%, and it can be set in combination with the resource usage of the execution unit running the same label in the case where the peer is not idle. Alternatively, the target resource constraint parameter can be determined by the server and sent to the host, and the host configures the resource constraint parameter for the target execution unit, so that the target execution unit can run according to the resource constraint parameter when it is scheduled. In addition to the above resource constraint parameter, other resource control parameters can also be configured for the target execution unit in order to improve resource utilization and computing power stability. Therefore, in some embodiments, the method can further include: determining a target resource control parameter corresponding to the target container instance; wherein the target resource control parameter is determined according to the function; configuring the target resource control parameter for at least one target execution unit; and the target resource control parameter is used to control the computing resources allocated by the target execution unit. The target resource control parameter can include a target resource scheduling parameter and / or the above target resource constraint parameter. The target resource scheduling parameter can include a target allocation period and a target resource usage time. The target resource usage time is used to limit the resource usage time of at least one target execution unit in the target allocation period. The allocation period refers to the time interval for reevaluating and allocating computing resources.The resource usage time can include a total amount of time allowed to use the computing resource and / or a maximum continuous execution time allowed to use the computing resource. For example, if the allocation period is 100 ms (milliseconds) and the total amount of time is 10 ms, then 10 ms of the computing resource is allocated to the target execution unit in each 100 ms allocation period, that is, the maximum time that the target execution unit can use the computing resource in 100 ms is 10 ms. For another example, if the allocation period is 100 ms and the maximum continuous execution time is 5 ms, then the target execution unit can execute the CPU time for a maximum of 5 ms continuously in each 100 ms. In actual applications, the allocation period can refer to CFS BWC periods (CFS BWC periods) in CFS BWC (Completely Fair Scheduler Bandwidth Control, a technology provided by an operating system for limiting, recording, and isolating physical resources used by a process group), where the CFS BWC can be implemented based on Cgroup (Control Group, a technology provided by an operating system for limiting, recording, and isolating physical resources used by a process group), and the resource usage time can refer to CFS BWC slices (CFS BWC slices) in CFS, which can be implemented based on Cgroup. The target resource control parameter can be determined by the server and sent to the host, and configured by the host to the target execution unit in the target container instance. The target execution unit can use the computing resource according to the resource constraint parameter in each target resource usage. The target resource usage time and the target allocation period can be determined based on the function configuration information provided by the user, and of course, can be determined in combination with the real-time performance of the function to ensure the stable performance of the function. The corresponding embodiments will be described below. In some embodiments, the method can further include: in response to a function call request, scheduling any target execution unit and an execution unit with the same label as the target execution unit to run in a virtual core simulated by the same physical core to execute the function call request. The function call request can be sent by the server to the host, and the function call request can be triggered by the user or generated in response to a specific event, and the present disclosure does not limit this. The host can schedule and run execution units with the same label in a virtual core simulated by the same physical core according to the labels configured by the execution units.As can be known from the above description, the target container instance can also be configured with target resource control parameters, and therefore, in some embodiments, in response to the function call request, scheduling any target execution unit and the execution unit with the same label as the target execution unit to the same physical core to simulate a virtual core to run, to execute the function call request can include: in response to the function call request, scheduling any target execution unit and the execution unit with the same label as the target execution unit to the same physical core to simulate a virtual core, and controlling the target execution unit to run according to the target resource control parameters, to execute the function call request. In some embodiments, the method can further include: collecting running data of the at least one target execution unit to determine resource index data corresponding to the function call request; and sending the resource index data to the server; wherein the label is determined by the server according to the task type of the function; the task type is determined according to the portrait data of the function; and the portrait data is obtained by statistically processing historical resource index data corresponding to the function. In some embodiments, the host machine can periodically collect running data of the at least one target execution unit, and can periodically report resource index data to the server, wherein the collection period and the reporting period can be the same or different. In some embodiments, the running data can include, for example, unit execution time, unit consumption data, and unit configuration data. In some embodiments, collecting running data of the at least one target execution unit to determine resource index data corresponding to the function call request can include: collecting running data of the at least one target execution unit; and processing the running data of the at least one target execution unit to determine resource index data of the function call request. In some embodiments, the resource index data can include, for example, one or more of request execution time, request frequency, resource consumption data, and resource configuration data. The request execution time can be, for example, the longest unit execution time or the average unit execution time corresponding to the at least one target execution unit; the resource consumption data can be the average of the unit consumption data of the at least one target execution unit or the unit consumption data of the target execution unit with the longest unit execution time; the resource configuration data is the unit configuration data; and the request frequency can be determined according to the request period of the function call request.The unit consumption data can include unit consumption, such as 60% of CPU computing power, and the like. Optionally, the unit consumption data can include a first type of unit consumption in a virtual core idle state of the opposite end and a second type of unit consumption in a virtual core non-idle state of the object. The obtained resource consumption data also includes a first type of resource consumption in a virtual core idle state of the opposite end (which can be an average of the first type of unit consumption of at least one target execution unit or the first type of unit consumption of the target execution unit with the longest unit execution time) and a second type of resource consumption in a virtual core non-idle state of the object (which can be an average of the second type of unit consumption of at least one target execution unit or the second type of unit consumption of the target execution unit with the longest unit execution time). After the resource index data is reported to the server, it can be saved as historical resource index data in the server. The server can analyze the historical resource index data corresponding to the function to determine the portrait data of the function. The portrait data can be the historical resource index data corresponding to the latest function call request, or can be obtained by aggregating multiple historical resource index data. For example, the portrait data can include one or more of function execution time, function execution frequency, historical consumption data, and historical configuration data. The function execution time can be the request execution time in the latest historical resource index data or the maximum or average request execution time corresponding to multiple historical resource index data. The function execution frequency can be the request frequency in the latest historical resource index data or the minimum or average request frequency corresponding to multiple historical resource index data. The historical consumption data can be the resource consumption data in the latest historical resource index data or the average or maximum resource consumption data corresponding to multiple historical resource index data. The historical configuration data is the resource configuration data. The server can determine the task type corresponding to the function based on the portrait data. For example, the function execution time can be used to determine whether the function is a delay-sensitive task. If the function execution time is less than a certain time length, it can be considered a delay-sensitive task, otherwise it is a non-delay-sensitive task. The function execution frequency can be used to determine whether the function is a high-frequency task. If the function execution frequency is greater than a certain frequency threshold, it can be considered a high-frequency task, otherwise it is a low-frequency task. The historical resource consumption data can be used to determine whether the function is a compute-intensive task or an input / output-intensive task. For example, if the historical resource consumption data is greater than a certain value, it can be considered a compute-intensive task, otherwise it is an input / output-intensive task.By determining the label based on the task type, the execution units running the same task type in the same physical core can be made, wherein the execution units corresponding to the same function have the same task type, and the execution units of the same task type have similar resource competition capability, because the execution duration can be ensured to be stable, the stability of the function is improved, the execution duration of the corresponding function of each function call request is ensured to be the same or similar, because the cloud computing system is charged based on the function execution duration, the stable function execution duration will not cause the cost to be high or low, and the user experience can be improved. As described in the foregoing, the host computer can also determine the target resource control parameter corresponding to the function. Optionally, the resource control parameter can also be determined by the server based on the portrait data of the function. For example, in the case that the target resource control parameter includes the target resource constraint parameter, the historical resource consumption data can be used for determination; optionally, the historical resource consumption data can include the first type of resource consumption and the second type of resource consumption, and the target resource constraint parameter can be determined based on the weighted average of the first type of resource consumption and the second type of resource consumption, for example, the first type of resource consumption is 100% CPU computing power, and the second type of resource consumption is 40% CPU computing power, and the target resource constraint parameter can be 70% CPU computing power. Of course, the target resource constraint parameter can also be pre-configured in combination with the actual situation or determined according to the resource consumption test data of the execution unit running the same task type or the same function in the same physical core in the simulation environment or the simulation environment, and the present disclosure does not limit this. In the case that the target resource control parameter includes the target resource scheduling parameter, for example, the target resource usage time and the target resource allocation period can be obtained by combining the function execution duration, adjusting the historical resource usage time and the historical allocation period. For example, one or more of the following implementation manners can be included: in one implementation manner, in the case that the function execution duration is greater than the predetermined execution duration, the historical allocation period can be reduced to obtain the target allocation period; the reduction time or the reduction multiple of the historical allocation period can be determined according to the difference between the function execution duration and the predetermined duration, and usually if the allocation period is long, the execution unit still needs to wait for a long time after consuming the resource usage time in one allocation period to continue running in the next allocation period, resulting in resource waste, therefore, the function execution duration can be shortened by reducing the historical allocation period, and the resource utilization rate is improved.In another implementation, the historical resource usage time can be calibrated according to a ratio of the function execution duration to the predetermined execution duration, and the ratio can be used as a calibration coefficient. Optionally, it can be further determined whether the ratio is greater than a coefficient threshold value. If yes, the coefficient threshold value can be used as the calibration coefficient. Otherwise, the ratio can be used as the calibration coefficient. The coefficient threshold value can be preconfigured according to the resource utilization rate in the host machine. For example, when the resource utilization rate of the computing resource is 20%, the corresponding coefficient threshold value can be 112%. When the resource utilization rate is 30%, the corresponding coefficient threshold value can be 123%. When the resource utilization rate is 40%, the corresponding coefficient threshold value can be 130%, and so on. Generally, the higher the resource utilization rate, the higher the coefficient threshold value. However, as the resource utilization rate is higher, the load is also higher. At this time, the host machine needs to be expanded as soon as possible to reduce the load of the host machine, rather than increasing the calibration coefficient. Therefore, the coefficient threshold value can be determined according to the performance inflection point of the host machine. For example, the 130% corresponding to the resource utilization rate of 40%. By setting the coefficient threshold value, that is, the maximum calibration coefficient, the rationality of the resource quota adjustment can be improved on the basis of improving the accuracy of the resource usage time adjustment, and excessive adjustment can be avoided. In another implementation, the target allocation period can be set to a first period when the historical resource usage time is less than a first predetermined value, and the target allocation period can be set to a second period when the historical resource usage time is greater than the first predetermined value. The second period is greater than the first period. For example, the second period can be 100 ms, and the first period can be 20 ms. It can be understood that for functions with small historical resource usage time, the resource usage time can be used up, but the execution unit can be suspended because the execution has not been completed. Therefore, the next allocation period needs to be waited for. At this time, if the allocation period is long, a long delay can be caused, thereby causing performance glitches. Therefore, when the historical resource usage time is less than the first predetermined value, the second period can be selected as the target allocation period. When the historical resource usage time is greater than the first predetermined value, the first period can be selected as the target allocation period. The first predetermined value can be set according to actual needs.In addition, in the case of CPU quota for resource usage time, the target resource scheduling parameter can further include whether to start a resource burst mechanism, which can be started in the case that the historical CPU quota is less than a second predetermined value. The resource burst mechanism is used to indicate that the target execution unit accumulates the unused time of the target CPU quota until the accumulated time threshold is reached, and in any target allocation period, when the resource usage time reaches the target CPU quota, the resource continues to be used within the accumulated time range of the unused time. By configuring the target resource control parameter, the resource utilization can be further improved, and the function performance stability can be ensured. In some embodiments, the server can periodically perform portrait analysis and determine the corresponding label for the function, and the server can determine the label and send it to the host, which can be saved to the local database by the host. Therefore, the above-mentioned determination of the target container instance corresponding to the label according to the corresponding label of the function can include: obtaining the label corresponding to the function sent by the server, and determining that the target container instance corresponds to the label; storing the corresponding relationship between the function description information and the label; wherein the function description information can be determined based on the task type or the function identifier, etc., to identify the task type or the function, etc. The above-mentioned configuration of the label for at least one target execution unit includes: for any target execution unit in the target container instance, querying the storage data based on the function description information corresponding to the target execution unit to determine the corresponding label; and configuring the target execution unit with the label. The host can also save the mapping relationship between the label and different execution units. In order to facilitate understanding, FIG. 3 shows a label configuration diagram, which includes process 1, process 2, process 3, and process 4 in the host 300, process 1 has been configured with the label cookie 1, process 2 has been configured with the label cookie 1, process 3 has been configured with the label cookie 2. o The label sent by the server 200 can be saved to the local database 302 by the parameter configuration module 301 deployed by the host 300, and the local database 302 stores the corresponding relationship between the function description information and the label, for example, the function description information functionresource1 corresponds to cookie 1, the function description information functionresource2 corresponds to cookie 2, and the function description information functionresource3 corresponds to cookie 3 oAssuming that the function description information corresponding to the process 4 to be configured is functionresource1, the parameter configuration module 301 can first query the tag cookiel mapped by functionresource1 from the local database 302, and then configure the tag cookiel for the process 4. It can be known that the process 1, the process 2 and the process 4 have the same tag, which is used to schedule the multiple virtual cores of the same physical core in subsequent kernel scheduling. In actual application, the host machine can realize the tag configuration operation and the execution unit scheduling operation by means of core scheduling technology. On the basis of the core scheduling technology, a tag configuration interface, a tag binding interface and a tag release interface can be added; wherein, the tag configuration interface can create a new tag but not bind any execution unit; the tag binding interface can configure a tag for a specified execution unit; and the tag release interface is used to delete a tag. The tag corresponding to the function configured for the at least one target execution unit can be to query the tag by calling the tag configuration interface, and to configure the tag by calling the tag binding interface. In addition, in the case of tag invalidation, the tag release interface can be called to delete the tag. FIG. 4 is a flowchart of another embodiment of a function configuration method in a serverless architecture provided by the present disclosure. The technical scheme of the present embodiment can be executed by a server, and the method can include the following steps:

[0005] 401: In response to a function call request, a tag corresponding to a function is determined. The function refers to the most basic computing unit in the Serverless architecture, which is composed of a code fragment written and deployed by a developer, and is usually used to execute a specific task or respond to a specific event. The function call request can be generated by a user trigger or in response to a specific event. In actual application, a container instance corresponding to the function is created by a host machine, and a specific task is executed by an execution unit in the container instance. The multiple execution units in the container instance constitute a function instance. The tag can be used to uniquely identify the function. Of course, as an alternative, since the execution units of the same task type are usually considered to have similar execution time, the tag can be used to uniquely identify the task type to which the function belongs. The task type of the function can be determined, and a tag used to identify the task type can be determined.

[0006] 402: determining a target host machine. The target host machine can be a host machine running a target container instance. After the function execution is completed, the container instance can be destroyed or kept for a certain period of time. Therefore, optionally, determining the target host machine can include: judging whether there is a target container instance corresponding to the function; if yes, determining that a host machine where the target container instance is located is the target host machine; if not, selecting the target host machine, wherein the target host machine can be any host machine or a host machine meeting load requirements through load balancing, and the present disclosure does not limit this. In addition, if there is no target container instance corresponding to the function, a container creation request can also be sent to the target host machine to create a target container instance in the target host machine; and if there is a target container instance corresponding to the function, the function invocation request can also be forwarded to the target host machine.

[0007] 403: send the label to the target host, so that the target host configures the label for at least one target execution unit in the function corresponding target container instance. Wherein, the label is used to indicate that the execution units configured with the same label are scheduled into the same physical core simulated generated virtual core. Optionally, since if there is a function corresponding target container instance, the target container instance corresponds to the label, therefore, step 403 can be that when there is no function corresponding target container instance, the function corresponding label is sent to the target host at the same time of sending the container creation request to the target host. Of course, the label can also be carried in the container creation request and sent to the target host. The target host can create the target container instance and set the label for the target container instance, so as to achieve the purpose of setting the label for all execution units in the target container instance. The target host can schedule any target execution unit and the execution unit with the same label to the same physical core simulated generated virtual core to run, so as to execute the function call request. Wherein, the label can be included in the container creation request or the function call request and sent to the target host. Of course, since the label may change dynamically, the label of the function can be sent to the target host independently after updating. In the embodiment, the execution units configured with the same label are scheduled into the same physical core simulated generated virtual core, so that different target execution units of the function can run in the same physical core. Since the resource competition of different target execution units of the function is equivalent, the execution time of different target execution units of the function under different conditions is close and relatively stable, so that the performance stability can be improved and the user experience can be improved. In some embodiments, the method can further include: determining the corresponding target resource control parameter for the function; sending the target resource control parameter to the target host, so that the target host configures the target resource control parameter for at least one target execution unit in the target container instance. Wherein, the target resource control parameter can include target resource scheduling parameter and / or target resource constraint parameter. The target resource scheduling parameter can include target allocation period and target resource use time. Wherein, the target resource use time is used to limit the resource use time of at least one target execution unit in the target allocation period. The target resource constraint parameter is used to constrain the computing resources allocated by the target execution unit. Optionally, the target resource constraint parameter can be specifically used to indicate that the computing resources allocated by the target execution unit are constrained when the opposite virtual core of the target execution unit is in an idle state.Optionally, since the target container instance corresponds to the target resource control parameter if the function corresponds to the target container instance, the target resource control parameter can be sent to the target host machine at the same time as the container creation request is sent to the target host machine if the function does not correspond to the target container instance. Of course, the target resource control parameter can also be sent to the target host machine in the container creation request. The target host machine can set the target resource control parameter for the target container instance after creating the target container instance, so as to achieve the purpose of setting the target resource control parameter for all execution units in the target container instance. In some embodiments, the above determining the corresponding label for the function can include: performing statistical processing on historical resource indicator data corresponding to the function to determine portrait data of the function; determining a task type of the function according to the portrait data; and determining a label for the function to identify the task type. Optionally, the target resource control parameter can also be determined according to the portrait data, so the method can further include: determining a resource control parameter of the function according to the portrait data. The historical resource indicator data can be obtained by the host machine, so in some embodiments, the method can further include: sending a function call request to the target host machine, so that the target host machine runs at least one target execution unit in the target container instance to execute the function call request; obtaining resource indicator data corresponding to the function call request uploaded by the target host machine; and the resource indicator data is obtained by aggregating processing of running data of the at least one target execution unit. The specific obtaining manner of the resource indicator data can be found in the foregoing embodiments, which will not be described here. After the resource indicator data is reported to the server, it can be saved in the server as historical resource indicator data. The server can perform portrait analysis on the historical resource indicator data corresponding to the function to determine the portrait data of the function. The portrait data can be historical resource indicator data corresponding to the last function call request, or can be obtained by aggregating processing of multiple historical resource indicator data. The historical resource indicator data can include one or more of request execution time, request frequency, resource consumption data, and resource configuration data; and the resource configuration data can include resource usage time and resource allocation period. The portrait data can include one or more of function execution time, function execution frequency, historical consumption data, and historical configuration data.In some embodiments, the determining the profiling data of the function based on the statistical processing of the historical resource usage data corresponding to the function can include: determining at least one historical resource index data corresponding to the function; and performing statistical processing on the at least one historical resource index data to determine a function execution duration, a function execution frequency, historical consumption data, historical resource usage time, and historical resource allocation period of the function. The function execution duration can be a request execution duration in the last historical resource index data or a maximum request execution duration or an average request execution duration corresponding to a plurality of historical resource index data; the function execution frequency can be a request frequency in the last historical resource index data or a minimum request frequency or an average request frequency corresponding to a plurality of historical resource index data; the historical consumption data can be resource consumption data in the last historical resource index data or average resource consumption data or maximum resource consumption data corresponding to a plurality of historical resource index data; and the historical configuration data is resource configuration data. In some embodiments, the determining the target resource control parameter of the function based on the profiling data can include: adjusting the historical resource usage time and the historical resource allocation period based on the function execution duration to obtain a target resource usage time and a target resource allocation period; and determining a target resource constraint parameter based on the historical resource consumption data. The adjusting the historical resource usage time and the historical resource allocation period based on the function execution duration to obtain the target resource usage time and the target resource allocation period can include one or more of the following implementation manners: in one implementation manner, the historical allocation period can be reduced to obtain a target allocation period when the function execution duration is greater than a predetermined execution duration; the reduction time or reduction multiple of the historical allocation period can be determined according to the difference between the function execution duration and the predetermined duration. In another implementation manner, a ratio of the function execution duration to the predetermined execution duration can be used as a calibration coefficient to calibrate the historical resource usage time to obtain the target resource usage time; optionally, it can be further determined whether the ratio is greater than a coefficient threshold value, and if so, the coefficient threshold value is used as the calibration coefficient, otherwise the ratio is used as the calibration coefficient. The coefficient threshold value can be obtained by pre-configuring in combination with the resource utilization rate in the host machine. In yet another implementation manner, the historical resource usage time can be used to set the target allocation period as a first period if it is less than a first predetermined value, and as a second period if it is greater than the first predetermined value, the second period being greater than the first period. The determining the target resource constraint parameter based on the historical resource consumption data can include: determining the target resource constraint parameter based on a weighted average of the first type of resource consumption and the second type of resource consumption.In some embodiments, the task type of the function determined according to the profiling data can include: determining the function as a delay-sensitive task or a non-delay-sensitive task in combination with the function execution duration, such as considering the function as a delay-sensitive task when the function execution duration is less than a certain duration, or considering the function as a non-delay-sensitive task otherwise; determining the function as a high-frequency task or a low-frequency task in combination with the function execution frequency, such as considering the function as a high-frequency task when the function execution frequency is greater than a certain frequency threshold, or considering the function as a low-frequency task otherwise; determining the function as a compute-intensive task or an input / output (I / O)-intensive task in combination with the historical resource consumption data, such as considering the function as a compute-intensive task when the historical resource consumption data is greater than a certain value, or considering the function as an I / O-intensive task otherwise, and the like. By setting the label based on the task type, the execution units running the same task type in the same physical core can be obtained, wherein the execution units corresponding to the same function have the same task type, and the execution units of the same task type have similar resource competition capabilities, because the execution duration can be ensured to be stable, the stability of the function is improved, the function execution duration corresponding to each function call request is ensured to be the same or similar, since the cloud computing system is charged based on the function execution duration, the stable function execution duration will not cause the cost to be high at one time and low at another time, and the user experience can be improved. In actual applications, the server can be implemented as a single server or multiple servers, and multiple modules can be deployed in the target host to perform corresponding operations in combination with the actual situation. For example, the server includes multiple servers, and the technical solutions of the embodiments of the present disclosure are introduced in combination with the interaction diagram shown in FIG. 5. The multiple servers can include a scheduling server 501, a profiling server 502, and a storage server 503, and the like. The storage server 503 is used to store the resource indicator data uploaded by the target host; the profiling server 502 can periodically obtain the historical resource indicator data from the storage server and perform profiling analysis to determine the profiling data. The scheduling server 501 can obtain the profiling data of the function from the profiling server 502 in response to the function call request, determine the task type and the target resource control parameter of the function according to the profiling data, and determine the label indicating the task type and the target resource control parameter for the function. The storage server can use external storage services such as SLS, OSS, and the like to store the resource indicator data. The scheduling server 501 can send the label and the target resource control parameter corresponding to the function to the target host, and send a container creation request to the target host when it is determined that there is no target container instance corresponding to the function.The execution engine module 504 in the target host machine can be a server less agent node running on the host machine to invoke the container engine 505 to create a virtual machine 506 in the target host machine and create a target container instance 507 in the virtual machine 506. oThe parameter configuration module 508 can take the label transmitted by the execution engine module 504 and the target resource control parameter as inputs, and configure the label and the target resource control parameter for the target execution unit in the target container instance. The target resource scheduling parameter in the target resource control parameter can include a Cgroup parameter, the target resource scheduling parameter can be configured for the Cgroup module 509 by the kernel parameter configuration module, and the target execution unit can be controlled to run by the target resource scheduling parameter of the Cgroup module. The target resource constraint parameter in the target resource control parameter can be configured to the target container instance by the parameter configuration module. The target host machine can also be deployed with an index collection module 510 to collect running data of at least one target execution unit in the target container instance, and generate resource index data. The resource index data can be a five-tuple data, for example, can include: function ID (identification), resource configuration data, resource consumption data, request execution duration, and request frequency. The index collection module 510 can periodically report the five-tuple data to the storage server 503, and the storage server 503 can perform persistent storage. In addition, the target container instance can be deleted after a period of time or after ending running, so the execution engine module 504 can also update the content in the local database in the kernel parameter configuration module 508 in response to the container deletion event, delete the related record of the target container instance; then, the execution engine module 504 can call the container engine 505 to delete the target execution unit in the target container instance, and the target container instance is deleted. In the embodiment of the present disclosure, the resource utilization rate can be ensured by starting the hyper-threading technology, and the hyper-threading interference can be avoided by label configuration. In addition, combined with the resource constraint parameter, the same CPU computing power can be ensured when the peer virtual core is in an idle state or a non-idle state. In addition, the resource scheduling parameter is configured based on the function image data, further improving the resource utilization rate and ensuring the performance stability. FIG. 6 is a structural diagram of one embodiment of a function configuration device in a serverless architecture provided by an embodiment of the present disclosure. The device can include: an execution engine module 601, configured to determine at least one target execution unit in a target container instance corresponding to a function, and determine a label corresponding to the target container instance; the label is determined according to the function; a parameter configuration module 602, configured to configure the label for the at least one target execution unit; wherein the label is used to indicate that the execution units configured with the same label are scheduled to the same physical core simulated virtual core.In some embodiments, the execution engine module is further configured to determine a target resource control parameter corresponding to the target container instance; and the parameter configuration module is further configured to configure the target resource control parameter for the at least one target execution unit; and the target resource control parameter is used to control the computing resources allocated to the at least one target execution unit. In some embodiments, the apparatus can further comprise a core scheduling module configured to, in response to the function call request, schedule any target execution unit and an execution unit having the same label as the target execution unit to run in a same physical core simulated generated virtual core, so as to execute the function call request. In some embodiments, the apparatus can further comprise an index collection module configured to collect running data of the at least one target execution unit, so as to determine resource index data corresponding to the function call request; and send the resource index data to the server; wherein the label is determined by the server according to a task type of the function; the task type is determined according to profile data of the function; and the profile data is obtained by statistics on historical resource index data corresponding to the function. In some embodiments, the parameter configuration module determining the label corresponding to the target container instance comprises: obtaining the label corresponding to the function sent by the server; and storing a correspondence between function description information and the label; and the parameter configuration module configuring the label for the at least one target execution unit comprises: for any target execution unit, querying the stored data based on function description information corresponding to the target execution unit to determine the corresponding label; and configuring the label for the target execution unit. In some embodiments, the execution engine module is further configured to determine a resource control parameter corresponding to the target container instance; wherein the resource control parameter is determined according to profile data of the function; and the parameter configuration module is further configured to configure the target resource control parameter for the at least one target execution unit; and the core call module can be specifically configured to schedule any target execution unit and an execution unit having the same label as the target execution unit to a same physical core simulated generated virtual core, and control the target execution unit to run according to the target resource control parameter, so as to execute the function call request. In some embodiments, the target resource control parameter comprises a resource constraint parameter, and the core scheduling module is further configured to, for any target execution unit, if there is no execution unit having the same label as the target execution unit, schedule the target execution unit to a first virtual core simulated generated by a first physical core, and control a peer virtual core in the first physical core to be in an idle state; and control the target execution unit to run according to the target resource constraint parameter corresponding to the function; wherein the target resource constraint parameter is used to constrain the computing resources allocated to the at least one target execution unit. In some embodiments, the execution engine module can be specifically configured to, in response to a container creation request sent by the server, create the target container instance corresponding to the function and the at least one target execution unit in the target container instance.The configuration apparatus described in FIG. 6 can perform the configuration method described in the embodiment shown in FIG. 1, and the implementation principle and technical effects thereof will not be repeated. The specific manner in which each module or unit in the configuration apparatus in the above embodiments performs operations has been described in detail in the embodiments related to the method, and will not be described in detail here. FIG. 7 is a structural schematic diagram of another embodiment of a function configuration apparatus in a serverless architecture provided by the embodiments of the present disclosure. The apparatus can include: a configuration module 701 configured to determine a corresponding label for a function in response to a function call request; a determination module 702 configured to determine a target host; and a notification module 703 configured to send the label to the target host, so that the target host configures the label for at least one target execution unit in a target container instance corresponding to the function; wherein the label is used to indicate that execution units configured with the same label are scheduled into a same physical core simulated virtual core. In some embodiments, the configuration module is further configured to determine a corresponding target resource control parameter for the function; and the notification module is further configured to send the target resource control parameter to the target host, so that the target host configures the target resource control parameter for at least one target execution unit in the target container instance. In some embodiments, the configuration module determining the corresponding label for the function includes: performing statistical processing on historical resource indicator data corresponding to the function to determine portrait data of the function; determining a task type of the function according to the portrait data; and determining a label for the function to identify the task type. In some embodiments, the notification module is further configured to send the function call request to the target host, so that the target host runs at least one target execution unit in the target container instance to execute the function call request; and obtain resource indicator data corresponding to the function call request uploaded by the target host; the resource indicator data is obtained by performing summary processing on running data of the at least one target execution unit. In some embodiments, the configuration module is further configured to determine a resource control parameter of the function according to the portrait data. In some embodiments, the historical resource indicator data includes one or more of request execution duration, request frequency, resource consumption data, and resource configuration data; and the resource configuration data includes resource usage time and resource allocation period.The configuration module performs statistical processing on historical resource usage data corresponding to the function, and the portrait data of the function can include: determining at least one historical resource index data corresponding to the function; performing statistical processing on the at least one historical resource index data to determine function execution duration, function execution frequency, historical consumption data, historical resource usage time, and historical resource allocation period of the function; and the resource control parameter of the function determined by the configuration module according to the portrait data can include: based on the function execution duration, adjusting the historical resource usage time and the historical resource allocation period to obtain a target resource usage time and a target resource allocation period; the target resource usage time is used to limit the resource usage time of the at least one target execution unit in the target allocation period; and based on the historical resource consumption data, determining a target resource constraint parameter. In some embodiments, the determination module determines the target host machine can include: in response to a function call request, determining whether there is a target container instance corresponding to the function; if yes, determining a target host machine where the target container instance is located; and if no, selecting a target host machine and sending a container instance creation request to the target host machine to create a target container instance in the target host machine. The configuration apparatus described in FIG. 7 can perform the configuration method described in the embodiment shown in FIG. 4, and the implementation principle and technical effects will not be repeated. For the specific manner in which each module, unit of the configuration apparatus in the above embodiments performs operations, it has been described in detail in the embodiments related to the method, and will not be described in detail here. The embodiments of the present disclosure also provide a computing device, as shown in FIG. 8, which can include a storage component 801 and a processing component 802; the storage component 801 stores one or more computer instructions, wherein the one or more computer instructions are called and executed by the processing component 802 to implement the configuration method described in the embodiment shown in FIG. 1 or the configuration method described in the embodiment shown in FIG. 4. Of course, the computing device can also include other components, such as an input / output interface, a display component, a communication component, etc. The input / output interface provides an interface between the processing component and the peripheral interface module, and the above peripheral interface module can be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the computing device and other devices, etc. The processing component can include one or more processors to execute computer instructions to complete all or part of the steps in the above method.The processing component can also be implemented with one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors or other electronic components, for performing the above methods. The storage component is configured to store various types of data to support the operation of the terminal. The storage component can be implemented by any type of volatile or nonvolatile storage devices 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 display component can be an electroluminescent (EL) element, a liquid crystal display or a micro display with a similar structure, or a retina directly displayable or similar laser scanning display. It should be noted that the above computing device can be a physical device or an elastic computing host provided by a cloud computing platform. It can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or a single terminal device. The embodiments of the present disclosure further provide a computer readable storage medium storing a computer program, and the computer program can implement the configuration method of the embodiment shown in FIG. 1 or the configuration method of the embodiment shown in FIG. 4 when executed by a computer. The computer readable medium can be included in the electronic device described in the above embodiments; or it can exist separately and not be assembled into the electronic device. The embodiments of the present disclosure further provide a computer program product comprising a computer program carried on a computer readable storage medium, and the computer program can implement the configuration method of the embodiment shown in FIG. 1 or the configuration method of the embodiment shown in FIG. 4 when executed by a computer. In such embodiments, the computer program can be downloaded and installed from a network, and / or installed from a detachable medium. When the computer program is executed by a processor, various functions defined in the system of the present disclosure are executed. Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described systems, devices and units can refer to the corresponding processes in the foregoing method embodiments, which will not be described herein. The above-described device embodiments are only schematic, and the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., they can be located in one place or distributed on multiple network units.Part or all of the modules can be selected according to actual needs to achieve the purposes of the embodiments. Those skilled in the art can understand and implement without creative labor. Through the above description of the embodiments, those skilled in the art can clearly understand that the embodiments can be realized by software and necessary universal hardware platforms, and of course can be realized by hardware. Based on such understanding, the above technical solutions can be embodied in the form of software products, and the computer software product can be stored in a computer readable storage medium, such as ROM / RAM, magnetic disk, optical disc, etc., including a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute the methods described in each embodiment or some parts of the embodiment. Finally, it should be pointed out that: the above embodiments are only used to illustrate the technical solutions of the present disclosure, not to limit them; although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure.

Claims

Claims 1. A function configuration method in a serverless architecture, wherein, include: Determine at least one target execution unit in the target container instance corresponding to the function; The tag corresponding to the target container instance is determined, and the tag is determined according to the function; Configure the tag for the at least one target execution unit; wherein the tag is used to indicate that execution units configured with the same tag are scheduled to virtual cores generated by the same physical core simulation.

2. The method according to claim 1, wherein, It also includes: determining target resource control parameters corresponding to the target container instance; the target resource control parameters being determined according to the function; configuring the target resource control parameters for the at least one target execution unit; the target resource control parameters being used to control the computing resources allocated to the at least one target execution unit.

3. The method according to claim 1 or 2, wherein, It also includes: in response to a function call request, scheduling any target execution unit and execution units with the same label to run in a virtual core generated by the same physical core, so as to execute the function call request.

4. The method according to claim 3, wherein, Also includes: Collect runtime data from the at least one target execution unit to determine the resource metrics data corresponding to the function call request; The resource indicator data is sent to the server; wherein, the tag is determined by the server based on the task type of the function; the task type is determined based on the profile data of the function; the profile data is obtained by statistically analyzing the historical resource indicator data corresponding to the function.

5. The method according to claim 4, wherein, The step of determining the tag corresponding to the target container instance includes: obtaining the tag corresponding to the function sent by the server, and determining that the target container instance corresponds to the tag; The storage function describes the correspondence between the information and the tags; Configuring the tag for the at least one target execution unit includes: for any target execution unit in the target container instance, querying stored data based on the function description information corresponding to the target container instance to determine the corresponding tag; Configure the label for the target execution unit.

6. The method according to claim 4 or 5, wherein, It also includes: determining the target resource control parameters corresponding to the target container instance; wherein the target resource control parameters are determined based on the function's profile data; configuring the target resource control parameters for the at least one target execution unit; and scheduling any target execution unit and execution units with the same label to run in a virtual core generated by the same physical core to execute the function call request, which includes: scheduling any target execution unit and execution units with the same label to a virtual core generated by the same physical core, and controlling the target execution unit to run according to the target resource control parameters to execute the function call request.

7. The method according to claim 6, wherein, The target resource control parameters include resource constraint parameters, and the method further includes: for any target execution unit, if there is no execution unit with the same label, then the target execution unit... The execution unit is scheduled to the first virtual core simulated by the first physical core, and the counterpart virtual core in the first physical core is kept in an idle state; the target execution unit is controlled to run according to the resource constraint parameters; wherein, the target resource constraint parameters are used to constrain the computing resources allocated to the at least one target execution unit.

8. The method according to any one of claims 1 to 7, wherein, The determination of at least one target execution unit in the target container instance corresponding to the function includes: in response to a container creation request sent by the server, creating the target container instance corresponding to the function and at least one target execution unit in the target container instance.

9. A function configuration method in a serverless architecture, wherein, include: In response to a function call request, a corresponding tag is determined for the function; Identify the target host machine; The tag is sent to the target host machine so that the target host machine can configure the tag for at least one target execution unit in the target container instance corresponding to the function; wherein the tag is used to indicate that execution units configured with the same tag are scheduled to virtual cores generated by the same physical core.

10. The method according to claim 9, wherein, Also includes: Determine the corresponding target resource control parameters for the function; The target resource control parameters are sent to the target host machine so that the target host machine can configure the target resource control parameters for at least one target execution unit in the target container instance.

1. The method according to claim 9 or 10, wherein, The step of determining the corresponding tag for the function includes: performing statistical processing on the historical resource indicator data corresponding to the function to determine the profile data of the function; The task type of the function is determined based on the profile data; The function is assigned a label to the application to identify the task type.

12. The method according to claim 11, wherein, It also includes: sending the function call request to the target host machine so that the target host machine can run at least one target execution unit in the target container instance to execute the function call request; obtaining resource indicator data corresponding to the function call request uploaded by the target host machine; the resource indicator data is obtained by summarizing and processing the running data of the at least one target execution unit.

13. The method according to claim 11, wherein, Also includes: The target resource control parameters of the function are determined based on the profile data.

14. The method according to claim 13, wherein, The historical resource indicator data includes one or more of request execution duration, request frequency, resource consumption data, and resource configuration data; the resource configuration data includes resource usage time and resource allocation cycle; the step of statistically processing the historical resource usage data corresponding to the function to determine the profile data of the function includes: determining at least one historical resource indicator data corresponding to the function; performing statistical analysis on the at least one historical resource indicator data to determine the function execution duration, function execution frequency, historical consumption data, historical resource usage time, and historical resource allocation cycle of the function; the step of determining the target resource control parameters of the function based on the profile data includes: adjusting the historical resource usage time and the historical resource allocation cycle based on the function execution duration to obtain the target resource usage time and the target resource allocation cycle; the target resource usage time is used to limit the resource usage time of the at least one target execution unit in the target allocation cycle; and determining the target resource constraint parameters based on the historical resource consumption data.

15. The method according to any one of claims 9 to 14, wherein, The determination of the target host includes: in response to a function call request, determining whether a target container instance corresponding to the function exists; if yes, determining the host where the target container instance is located as the target host; if no, selecting a target host and sending a container creation request to the target host to create the target container instance in the target host.

16. A computing device, wherein, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement the function configuration method in a serverless architecture as described in any one of claims 1 to 8 or the function configuration method in a serverless architecture as described in any one of claims 9 to 15.

17. A computer-readable storage medium, wherein, It stores a computer program, which, when executed by a processing component, implements the function configuration method in a serverless architecture as described in any one of claims 1 to 8 or the function configuration method in a serverless architecture as described in any one of claims 9 to 15.

18. A computer program product, wherein, Includes a computer program / instruction, which, when executed by a processing component, implements the function configuration method in a serverless architecture as described in any one of claims 1 to 8 or the function configuration method in a serverless architecture as described in any one of claims 9 to 15. 18

Images