Disclosure of Invention
The embodiment of the application provides a workload capacity expansion method and system, which are used for at least solving the problem that resources are occupied when the workload capacity expansion is carried out in the related technology.
In a first aspect, an embodiment of the present application provides a workload capacity expansion method, where the method includes:
when monitoring that a kubernets cluster deploys a new workload and a target SDK is deployed in a service process of the workload, a monitoring process determines to expand the workload, wherein the target SDK is used for running concurrent tasks;
the monitoring process injects a sidecar mode container into the pod corresponding to the business process and runs an expansion process in the container, wherein the expansion process and the business process share a memory;
the service process calls an interface of the target SDK and appoints a code to be executed to the target SDK; the target SDK determines whether the resources of the pod are sufficient, if not, the target SDK sends the codes and the corresponding memory data to the shared memory, and sends a request for running the codes to the expansion process;
the expansion process generates at least one wasm file according to the data in the shared memory and communicates with the kubernets cluster to generate at least one execution process; and the expansion process sends the wasm file to the execution process.
In some embodiments, the process of generating the wasm file by the extension process according to the data in the shared memory includes:
the expanding process encapsulates the codes and the memory data in the shared memory to obtain a function of the wasm; and the expansion process adds a network communication address in the encapsulation result, compiles all codes and generates the wasm file.
In some embodiments, after the extension process sends the wasm file to the execution process, the method includes:
the execution process processes the wasm file and sends a processing result to the network communication address;
and the expansion process receives the processing result, writes the processing result into the shared memory, and informs the target SDK to read the processing result.
In some embodiments, after the generating at least one executing process, the method comprises:
the expanding process monitors whether the number of the executing processes is sufficient;
if not, the expansion process is communicated with the kubernets cluster to add an execution process, and the expansion process brings the added execution process into management.
In a second aspect, an embodiment of the present application provides a workload capacity expansion system, where the system includes a monitoring process, a service process, an expansion process, and an execution process, where the expansion process includes a compiling module and a scheduling module;
when the monitoring process monitors that a kubernets cluster deploys a new workload and a target SDK is deployed in the service process of the workload, determining to expand the workload, wherein the target SDK is used for running concurrent tasks;
the monitoring process injects a sidecar mode container into the pod corresponding to the business process and runs the expansion process in the container, wherein the expansion process and the business process share a memory;
the service process calls an interface of the target SDK and appoints a code to be executed to the target SDK; the target SDK determines whether the resources of the pod are sufficient, if not, the target SDK sends the code and the corresponding memory data to the shared memory, and sends a request for running the code to the compiling module;
the compiling module generates at least one wasm file according to data in the shared memory, the scheduling module is communicated with the kubernets cluster to generate at least one execution process, and the scheduling module sends the wasm file to the execution process.
In some embodiments, the process of generating the wasm file by the compiling module according to the data in the shared memory includes:
the compiling module encapsulates the codes and the memory data in the shared memory to obtain a function of the wasm; and the compiling module adds a network communication address in the packaging result, compiles all codes and generates the wasm file.
In some embodiments, the development process further comprises a result processing module;
after the scheduling module sends the wasm file to the execution process, the execution process processes the wasm file and sends a processing result to the network communication address;
and the result processing module receives the processing result, writes the processing result into the shared memory, and informs the target SDK to read the processing result.
In some of these embodiments, after the generating at least one executing process:
the scheduling module monitors whether the number of the execution processes is sufficient;
if not, the scheduling module is communicated with the kubernets cluster to add an execution process, and the scheduling module brings the added execution process into management.
In a third aspect, an embodiment of the present application provides an electronic apparatus, including a memory and a processor, where the memory stores a computer program, and the processor is configured to execute the computer program to perform the workload capacity expansion method.
In a fourth aspect, an embodiment of the present application provides a storage medium, where a computer program is stored in the storage medium, where the computer program is configured to execute the workload capacity expansion method when running.
Compared with the related art, the workload capacity expansion method provided by the embodiment of the application determines to expand the workload when the monitoring process monitors that the kubernets cluster deploys the new workload and the service process of the workload deploys the target SDK, wherein the target SDK is used for running concurrent tasks; the monitoring process injects a sidecar mode container into a pod corresponding to the business process, and runs an expansion process in the container, wherein the expansion process and the business process share a memory; the service process calls an interface of the target SDK and appoints a code to be executed to the target SDK; the target SDK determines whether the resources of the pod are sufficient, if not, the target SDK sends the codes and the corresponding memory data to the shared memory and sends a request for running the codes to an expansion process; the expansion process generates at least one wasm file according to data in the shared memory and communicates with the kubernets cluster to generate at least one execution process; the expansion process sends the wasm file to the execution process, the problem that resources are occupied when the workload is expanded in the related technology is solved, and the effect of saving system resources is achieved.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application.
It is obvious that the drawings in the following description are only examples or embodiments of the present application, and that it is also possible for a person skilled in the art to apply the present application to other similar contexts on the basis of these drawings without inventive effort. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of ordinary skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments without conflict.
Unless defined otherwise, technical or scientific terms referred to herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. Reference to "a," "an," "the," and similar words throughout this application are not to be construed as limiting in number, and may refer to the singular or the plural. The present application is directed to the use of the terms "including," "comprising," "having," and any variations thereof, which are intended to cover non-exclusive inclusions; for example, a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to the listed steps or elements, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Reference to "connected," "coupled," and the like in this application is not intended to be limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The term "plurality" as referred to herein means two or more. "and/or" describes an association relationship of associated objects, meaning that three relationships may exist, for example, "A and/or B" may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. Reference herein to the terms "first," "second," "third," and the like, are merely to distinguish similar objects and do not denote a particular ordering for the objects.
The workload capacity expansion method is based on kubernets and a wasm technology, wherein the wasm is a brand new format which is portable, small in size, fast in loading and web-compatible, is used for solving the problem of high-performance processing of a browser at first, is small in size and has strong portability, and can also run under a non-web environment. The invention creatively combines the kubernets and the wasm technology to solve the problem that the resource is occupied when the workload in the kubernets cluster is expanded.
The workload capacity expansion method provided by the present application may be applied to an application environment shown in fig. 2, where fig. 2 is an application environment schematic diagram of the workload capacity expansion method according to an embodiment of the present application, and as shown in fig. 2, the workload capacity expansion method is applied to a kubernets system, where the kubernets system includes a plurality of NODEs (NODEs), and each NODE runs one or more PODs, where a POD is a smallest management element in the kubernets; each POD includes one or more containers within it, each container having processes running therein, the processes including: the system comprises a monitoring process 201, a business process 202, an expansion process 203 and an execution process 204, wherein the business process 202 can exist in a POD independently or coexist with the expansion process 203 in the POD, and the business process 202 and the expansion process 203 communicate through a shared memory under the condition that the two processes coexist in the POD.
Fig. 3 is a flowchart of a workload capacity expansion method according to a first embodiment of the present application, where as shown in fig. 3, the flowchart includes the following steps:
step S301, when monitoring that a kubernets cluster deploys a new workload and a target SDK is deployed in a service process 202 of the workload, the monitoring process 201 determines to expand the workload, where the service process 202 is a process that really processes service logic and includes a service code, and the target SDK is used to run a concurrent task;
in step S301, the determination as to whether or not the capacity is expanded is performed because: only if the concurrent execution method is registered in the target SDK in advance and the target SDK is deployed in the service process 202, the application program can execute the concurrent task based on the target SDK and can smoothly complete the capacity expansion operation;
of course, in this embodiment, how the monitoring process 201 determines that the target SDK is deployed in the service process 202 of the workload is not limited in a specific manner, for example, in some embodiments, a user may configure in advance whether the application supports capacity expansion according to a deployment situation of the target SDK, so that the monitoring process 201 may determine whether the target SDK is deployed in the service process 202 of the workload by checking configuration information, and determine whether to expand the workload of the application;
step S302, when the monitoring process 201 determines to expand the workload, the monitoring process 201 injects a sidecar-mode container into the pod corresponding to the service process 202, and runs the extension process 203 in the container, where the service process 202 and the extension process 203 communicate with each other through a shared memory;
step S303, the service process 202 calls an interface of the target SDK and designates a code to be executed to the target SDK; the target SDK determines whether the resources of the pod are sufficient: if yes, the target SDK directly executes the code; if not, the target SDK sends the code and the corresponding memory data to the shared memory, and sends a request for running the code to the expansion process 203;
step S304, the expansion process 203 receives the request of running the code, and generates at least one wasm file according to the data in the shared memory; for example, the development process 203 encapsulates codes and memory data in the shared memory to obtain a function of the wasm, adds a network communication address in an encapsulation result to specify an execution result to be written into an IP (Internet protocol) PORT (PORT) monitored by the development process 203, and finally compiles all codes to generate a wasm file;
step S305, the expansion process 203 communicates with the kubernets cluster to generate at least one execution process 204; the development process 203 sends the wasm file to the execution process 204.
Through steps S301 to S305, since there are many memory overheads in the related art when increasing the number of copies for capacity expansion, the operation of one springboot program includes: in the embodiment, when capacity expansion is performed, codes to be executed and corresponding memory data are compiled into a wap file, and the wap file is sent to the execution processes 204 in the remaining Pod for processing.
Consider the case where, in some of the embodiments, there are concurrent requests, in which case:
for each request needing to be executed, the extension process 203 generates a wasm file corresponding to the request, for example, if there are 3 concurrent requests, the extension process 203 correspondingly generates 3 wasm files;
under the condition that the expansion process 203 generates a plurality of wasm files, the expansion process 203 communicates with the kubernets cluster, and correspondingly generates the execution processes 204 with the same number;
for new requests generated thereafter, the extension process 203 continuously monitors whether the number of execution processes 204 is sufficient; if not, the expansion process 203 communicates with the kubernets cluster, so that an execution process 204 is newly added, and the newly added execution process 204 correspondingly processes the new request.
In some embodiments, fig. 4 is a flowchart of a workload capacity expansion method according to a second embodiment of the present application, and as shown in fig. 4, after an extension process 203 sends a wasm file to an execution process 204, the flowchart includes the following steps:
step S401, the execution process 204 processes the wasm file, and sends the processing result to the corresponding network communication address, for example, the execution process 204 executes a code in the wasm file, where the code already includes a process of sending the execution result to the extension process 203;
step S402, the expansion process 203 receives the processing result, writes the processing result into the shared memory, and notifies the target SDK to read the processing result;
in step S403, the target SDK reads the result from the shared memory, and returns the execution result to the service code.
Through steps S401 to S403, since the expansion is realized by increasing the number of copies in the related art, and each copy independently solves a complete task, the method is only applicable to such requests for concurrent access by the user; in practical situations, there are requests that multiple concurrent processes need to be implemented inside a program, and all results are finally summarized and returned, and the capacity expansion problem of the requests cannot be solved by increasing the number of copies to implement capacity expansion in the related art; in this embodiment, after each execution process 204 finishes processing the corresponding wap file, it sends the execution result to the extension process 203, and the extension process 203 receives the processing result, writes the processing result into the shared memory, and notifies the target SDK to read the processing result, which involves returning the processing result, so that it is possible to process such requests that multiple concurrent processes need to be implemented inside the program, and finally summarize all results and return.
An embodiment of the present application further provides a workload capacity expansion system, fig. 5 is a schematic diagram of a workload capacity expansion system according to a third embodiment of the present application, and as shown in fig. 5, the system includes a monitoring process, a service process, an expansion process, and an execution process, where:
the monitoring process 201 determines whether the new workload meets the framework through the apiServer, if so, the monitoring process 201 injects a sidecar-mode container into the pod corresponding to the business process 202, and runs an expansion process 203 in the container;
the service process 202 calls an interface of the target SDK and specifies a code to be executed to the target SDK; the target SDK determines whether the resources of the pod are sufficient: if yes, the target SDK directly executes the code; if not, the target SDK sends the code and the corresponding memory data to the shared memory, and sends a request for running the code to the expansion process 203;
expanding a process to acquire data in the shared memory, packaging codes, adding a network communication address to the packaged codes, and compiling the file into a wasm format to obtain a wasm file;
the development process 203 communicates with the kubernets cluster to apply for a plurality of pod running on different hosts, and an execution process runs in the pod (or in other embodiments, the pod of the plurality of execution processes can also run on the same host under the condition that the memory resources of the host are sufficient), so as to obtain at least one execution process 204; the development process 203 sends the wasm file to the execution processes 204;
the execution process 204 processes the codes in the wasm file and sends the processing result to the expansion process 203; the development process 203 receives the processing result, writes the processing result into the shared memory, and notifies the target SDK to read the processing result; and the target SDK reads the result from the shared memory and returns the execution result to the service code.
In addition, in combination with the workload capacity expansion method in the foregoing embodiment, the embodiment of the present application may provide a storage medium to implement. The storage medium having stored thereon a computer program; the computer program, when executed by a processor, implements any of the workload expansion methods in the above embodiments.
In one embodiment, a computer device is provided, which may be a terminal. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a workload capacity expansion method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.
In an embodiment, fig. 6 is a schematic internal structure diagram of an electronic device according to an embodiment of the present application, and as shown in fig. 6, there is provided an electronic device, which may be a server, and its internal structure diagram may be as shown in fig. 6. The electronic device comprises a processor, a network interface, an internal memory and a non-volatile memory connected by an internal bus, wherein the non-volatile memory stores an operating system, a computer program and a database. The processor is used for providing calculation and control capability, the network interface is used for communicating with an external terminal through network connection, the internal memory is used for providing an environment for an operating system and the running of a computer program, the computer program is executed by the processor to realize a workload capacity expansion method, and the database is used for storing data.
Those skilled in the art will appreciate that the configuration shown in fig. 6 is a block diagram of only a portion of the configuration associated with the present application, and does not constitute a limitation on the electronic device to which the present application is applied, and a particular electronic device may include more or less components than those shown in the drawings, or may combine certain components, or have a different arrangement of components.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
It should be understood by those skilled in the art that various features of the above-described embodiments can be combined in any combination, and for the sake of brevity, all possible combinations of features in the above-described embodiments are not described in detail, but rather, all combinations of features which are not inconsistent with each other should be construed as being within the scope of the present disclosure.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.