Application starting acceleration method and related device

Abstract

The invention discloses an application starting acceleration method, which is applied to the process of starting an application program through a language virtual machine in an acceleration cloud native scene. According to the method, a second node obtains and caches data capable of accelerating starting of an application program from the started application program in a cloud native scene, and when a first node needs to start a first application program, the second node starts the first application program; and the first node requests an acceleration application program from the second node and informs the data type capable of supporting acceleration starting when the first application program is operated. Therefore, the second node can select the data meeting the condition from the cached data and send the data to the first node based on the data type of the first application program supporting the accelerated startup, so that the process of loading the corresponding data after the language virtual machine executes compiling is omitted; the process that the first node starts the first application program through the language virtual machine is accelerated.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular, to an application startup acceleration method and related devices. Background Art

[0002] In order to ensure that the execution platform is not restricted, many current high-level programming languages, such as Java, Kotlin, JavaScript, Python, C#, etc., usually use a language virtual machine to implement the operation of application programs. For the source code written in these high-level programming languages, usually the source code is first compiled into intermediate code, and then the language virtual machine interprets and executes the intermediate code to realize the operation of the application program.

[0003] The language virtual machine enables application programs to run across platforms, and also provides various advanced functions such as garbage collection and dynamic type checking for programming languages, promoting the ecological prosperity of programming languages. Currently, these languages that require a language virtual machine have gradually become the mainstream choice for industry development.

[0004] With the development of cloud computing, more and more application programs are deployed in cloud native scenarios. In cloud native scenarios, the processing resources that can be allocated to each application program are less, and due to the characteristics of elastic scaling in cloud native scenarios, application programs are often started frequently. Therefore, in cloud native scenarios, the phenomenon that application programs executed based on a language virtual machine take a long time to start has become an urgent problem to be solved. Summary of the Invention

[0005] This application provides an application startup acceleration method, which can accelerate the process of starting an application program through a language virtual machine.

[0006] In the first aspect of this application, an application startup acceleration method is provided, which is applied to accelerating the startup of an application program running based on a language virtual machine in a cloud native scenario. The method includes: First, when a first node needs to start a first application program, the first node sends a first request message to a second node. The first request message is used to request to accelerate the startup of the first application program, and the first request information is used to indicate the data type that the first application program supports for accelerated startup. And the first node and the second node are different nodes in the cloud native scenario, such as different servers in the cloud native scenario.

[0007] Then, the first node receives the first data sent by the second node, where the first data is the data required during the startup process of the first application. The first data is obtained and cached by the second node based on the already started application, and the first data belongs to the data type that supports accelerated startup of the first application. That is, the second node selects the first data that can accelerate the startup of the first application from the cached application data based on the data type that supports accelerated startup of the first application and sends it to the first node.

[0008] Finally, the first node starts the first application based on the first data. The first application is started through a language virtual machine in the cloud-native scenario. Among them, the first data may include one or more types of data. For different types of data, the way the first node uses the data to accelerate the startup of the first application may also be different.

[0009] In this solution, the second node obtains and caches the data that can accelerate the startup of the application from the already started application in the cloud-native scenario. And when the first node wants to start the first application, the first node requests to accelerate the application from the second node and informs the data type that can support accelerated startup when running the first application. In this way, the second node can select the data that meets the conditions from the cached data based on the data type that supports accelerated startup of the first application and send it to the first node, saving the process of the language virtual machine performing compilation and then loading the corresponding data, and realizing the process of accelerating the first node to start the first application through the language virtual machine.

[0010] Generally speaking, in this solution, due to the fact that the code of the application program executed by the language virtual machine often uses the same underlying framework and third-party libraries, the application data generated after the application program starts is cached on one node, and the cached application data is shared when other nodes newly start the application program, so as to achieve the acceleration of the application program startup process.

[0011] In a possible implementation, the data types that the first application supports accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the language virtual machine to run, custom data, or a snapshot of the application program. Among them, the compiled code refers to the binary code obtained after the language virtual machine compiles the bytecode. The code optimization data refers to various data related to code optimization generated during the running of the application program. The metadata required for the language virtual machine to run can be various data required by the language virtual machine when running the application program. The custom data refers to the data relatively related to the application program itself, such as the resource storage path or some other data related to the personalized code of the application program. The snapshot of the application program refers to the mirror of all the data generated in the memory at a certain time point during the running of the application program.

[0012] In this solution, by setting multiple data types that can be used to accelerate the startup of an application, the application can select one or more data types for startup acceleration based on its own situation, improving the generality of the data that can be shared on the second node and facilitating the second node to provide startup acceleration services for more applications.

[0013] In a possible implementation, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources. Among them, a class is a user-defined reference data type, and class data can be used to indicate the classes used by the application during operation. The constant pool is used to store constants such as integers, floating-point literals, and strings. The class loader is responsible for converting the bytecode in the JVM into classes that can be executed by the JVM.

[0014] In a possible implementation, after starting the first application, the first node sends second data to the second node. The second data is the data used during the operation of the first application. Moreover, the second data can be used to accelerate the startup of the application. In addition, the second data is data that the first node has screened and confirmed is not on the second node. That is, the first node collects the data used during the operation of the first application and screens the data that is not on the second node from the collected data to obtain the second data.

[0015] In this way, after receiving the second data, the second node can cache the second data, making the application data cached on the second node more abundant and ensuring that the second node can provide more comprehensive application acceleration services.

[0016] In a possible implementation, before the first node sends the second data to the second node, the first node sends a second request message to the second node. The second request message is used to indicate the data collected during the operation of the first application and is used to request confirmation of the data that the second node needs to cache. That is, the first node requests the second node to confirm the data that the second node actually needs to cache from the data collected by the first node.

[0017] Then, the first node receives a response message sent by the second node. The response message is used to indicate the data that the second node needs to cache. In this way, based on the response message, the first node can determine the second data from the collected data. Among them, the second data can be all the data collected by the first node or a part of the data collected by the first node.

[0018] In this solution, after the node responsible for running the application successfully starts and runs the application, it regularly collects the data generated during the running of the application and negotiates with the node responsible for caching the application data, so as to send some new data that can be used to accelerate the application to the node responsible for caching the application data, thereby enriching the application data cached on the node and ensuring that the node can provide a more comprehensive application acceleration service.

[0019] In a possible implementation, the second node is the central node in the cloud-native scenario, and the first data is obtained by the second node from other nodes that have started the application. For example, after any node in the cloud-native scenario completes the startup of the application, it can send the application data generated during the running of the application to the second node during or after the application runs, and this application data can be used to accelerate the startup process of the application.

[0020] In a possible implementation, the second node is a node that has started the second application in the cloud-native scenario, where the data required for the startup process of the second application overlaps with the data required for the startup process of the first application. During the running of the application, the second node can cache the data that can be used to accelerate the startup of the application, so as to share the cached data with other nodes that need to start a new application later.

[0021] In a possible implementation, the started application that provides the first data to the second node can include applications of different types from the first application. That is, the first application and the started application are different applications (i.e., applications started based on different codes), but the first application and the started application can share some data. Of course, the started application that provides the first data to the second node can also include applications of the same type as the first application, for example, the first application and the started application are the same application (i.e., applications started based on the same code).

[0022] The second aspect of this application provides an application startup acceleration method, including: the second node obtains and caches application data, where the application data is obtained based on a started application program and is used to accelerate the startup process of the application program; the second node receives a first request message sent by the first node, where the first request message is used to request acceleration of the startup of the first application program, and the first request information is used to indicate the data types supported for accelerated startup of the first application program, and the first application program is started through a language virtual machine in a cloud-native scenario; the second node sends the first data to the first node, where the first data is the data required during the startup process of the first application program, and the first data is determined by the second node from the data based on the data types supported for accelerated startup of the first application program.

[0023] In a possible implementation, the data types supported for accelerated startup of the first application program include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application program.

[0024] In a possible implementation, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources.

[0025] In a possible implementation, the method further includes: after the first node starts the first application program, the second node receives second data sent by the first node, where the second data is the data used during the operation of the first application program; the second node caches the second data.

[0026] In a possible implementation, before the second node receives the second data sent by the first node, the method further includes: the second node receives a second request message sent by the first node, where the second request message is used to indicate the data collected during the operation of the first application program, and the second request message is used to request confirmation of the data that the second node needs to cache; the second node sends a response message to the first node, where the response message is used to indicate the data that the second node needs to cache, and the data that the second node needs to cache is determined based on the collected data and the application data.

[0027] In a possible implementation, the second node is the central node in a cloud-native scenario, and the application data is obtained by the second node from other nodes that have started application programs.

[0028] In a possible implementation, the second node is a node that has started the second application program in a cloud-native scenario, the application data is obtained based on the second application program, and the data required during the startup process of the second application program overlaps with the data required during the startup process of the first application program.

[0029] In a possible implementation, the started application for providing the first data to the second node may include an application of a different type from the first application.

[0030] A third aspect of this application provides an application startup acceleration device, which is deployed on the first node, and the device includes: a sending module, configured to send a first request message to the second node, where the first request message is used to request to accelerate the startup of the first application, and the first request information is used to indicate the data type that the first application supports accelerated startup; a receiving module, configured to receive the first data sent by the second node, where the first data is the data required during the startup process of the first application, the first data is obtained and cached by the second node based on the started application, and the first data belongs to the data type that the first application supports accelerated startup; a processing module, configured to start the first application based on the first data, and the first application is started through a language virtual machine in the cloud native scenario.

[0031] In a possible implementation, the data types that the first application supports accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the language virtual machine to run, custom data, or a snapshot of the application.

[0032] In a possible implementation, the metadata required for the language virtual machine to run includes class data, constant pool, and class loader resources.

[0033] In a possible implementation, after starting the first application, the sending module is further configured to send second data to the second node, and the second data is the data used during the running process of the first application.

[0034] In a possible implementation, before the sending module sends the second data to the second node, the sending module is further configured to send a second request message to the second node, where the second request message is used to indicate the data collected during the running process of the first application, and the second request message is used to request to confirm the data that the second node needs to cache; the receiving module is further configured to receive the response message sent by the second node, where the response message is used to indicate the data that the second node needs to cache; the processing module is further configured to determine the second data from the collected data based on the response message at the first node.

[0035] A fourth aspect of the present application provides an application startup acceleration device, which is deployed on a second node. The device includes: a processing module, configured to obtain and cache application data, where the application data is obtained based on a started application program and is used to accelerate the startup process of the application program; a receiving module, configured to receive a first request message sent by a first node, where the first request message is used to request acceleration of the startup of a first application program, and the first request message is used to indicate the data types supported for accelerated startup by the first application program, and the first application program is started through a language virtual machine in a cloud native scenario; a sending module, configured to send first data to the first node, where the first data is the data required during the startup process of the first application program, and the first data is determined by the second node from the data based on the data types supported for accelerated startup by the first application program.

[0036] In a possible implementation manner, the data types supported for accelerated startup by the first application program include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application program.

[0037] In a possible implementation manner, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources.

[0038] In a possible implementation manner, after starting the first application program, the receiving module is further configured to receive second data sent by the first node, where the second data is the data used during the operation of the first application program; the processing module is further configured to cache the second data.

[0039] In a possible implementation manner, before receiving the second data sent by the first node, the receiving module is further configured to receive a second request message sent by the first node, where the second request message is used to indicate the data collected during the operation of the first application program, and the second request message is used to request confirmation of the data that the second node needs to cache; the sending module is further configured to send a response message to the first node, where the response message is used to indicate the data that the second node needs to cache, and the data that the second node needs to cache is determined based on the collected data and the application data.

[0040] A fifth aspect of the present application provides an application startup acceleration device, which may include a processor. The processor is coupled to a memory, and the memory stores program instructions. When the program instructions stored in the memory are executed by the processor, the method according to the first aspect or any implementation manner of the first aspect is implemented. For the steps executed by the processor in each possible implementation manner of the first aspect, reference may specifically be made to the first aspect, and details are not described herein again.

[0041] A sixth aspect of the present application provides a cloud computing system, including a device according to any implementation manner of the third aspect and a device according to any implementation manner of the fourth aspect.

[0042] The seventh aspect of the present application provides a computer-readable storage medium, in which a computer program is stored. When it runs on a computer, it enables the computer to execute the method according to any implementation manner of the first aspect above.

[0043] The eighth aspect of the present application provides a circuit system, which includes a processing circuit configured to execute the method according to any implementation manner of the first aspect above.

[0044] The ninth aspect of the present application provides a computer program product. When it runs on a computer, it enables the computer to execute the method according to any implementation manner of the first aspect above.

[0045] The tenth aspect of the present application provides a chip system, which includes a processor for supporting a server or a feature screening device to implement the functions involved in any implementation manner of the first aspect above. For example, it processes the data and / or information involved in the above method. In a possible design, the chip system further includes a memory for storing the necessary program instructions and data of the server or the feature screening device. The chip system can be composed of chips or include chips and other discrete devices.

[0046] For the beneficial effects of the second to tenth aspects above, reference can be made to the introduction of the first aspect above, and details will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a schematic architecture diagram of an application scenario provided by an embodiment of the present application;

[0048] Figure 2 It is a schematic architecture diagram of a VM acceleration service provided by an embodiment of the present application;

[0049] Figure 3 It is a schematic structural diagram of an electronic device 101 provided by an embodiment of the present application;

[0050] Figure 4 It is a schematic flowchart of an application startup acceleration method provided by an embodiment of the present application;

[0051] Figure 5 It is a schematic architecture diagram when the VM acceleration service is centrally deployed provided by an embodiment of the present application;

[0052] Figure 6 It is a schematic flowchart of VM cloud application acceleration startup and shared data provided by an embodiment of the present application;

[0053] Figure 7Schematic diagram of a process for a VM cloud application to interact with a VM acceleration service to achieve startup acceleration provided by an embodiment of the present application;

[0054] Figure 8 Schematic diagram of a process for a VM cloud application to share application data with a VM acceleration service provided by an embodiment of the present application;

[0055] Figure 9 Schematic diagram of an architecture during decentralized deployment of a VM acceleration service provided by an embodiment of the present application;

[0056] Figure 10 Schematic diagram of the structure of an application startup acceleration device provided by an embodiment of the present application;

[0057] Figure 11 Schematic diagram of the structure of another application startup acceleration device provided by an embodiment of the present application;

[0058] Figure 12 Schematic diagram of the structure of an execution device provided by an embodiment of the present application;

[0059] Figure 13 Schematic diagram of the structure of a computer-readable storage medium provided by an embodiment of the present application. Detailed implementation manners

[0060] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments.

[0061] The terms "first", "second", "third", "fourth", etc. (if any) in the specification, claims and accompanying drawings of the present application are used to distinguish similar objects, and do not necessarily need to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments described here can be implemented in an order other than that illustrated or described here.

[0062] In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0063] For ease of understanding, some technical terms related to the embodiments of the present application are introduced below.

[0064] (1) Cloud Native

[0065] Cloud native is a distributed cloud based on distributed deployment and unified operation and management, and a set of cloud technology product systems built on technologies such as containers and microservices. Cloud native applications are applications designed for the "cloud". After using cloud native technologies, developers do not need to consider the underlying technical implementation and can give full play to the elasticity and distributed advantages of the cloud platform to achieve functions such as rapid deployment and on-demand scaling.

[0066] Simply put, cloud native is a compound word. "Cloud" means that the application runs in a distributed cloud environment, and "native" means that the application fully considers the elasticity and distributed characteristics of the cloud platform at the beginning of design and is designed for the cloud.

[0067] It can be seen that cloud native is not simply using the cloud platform to run existing applications. It is an application architecture method that can make full use of the advantages of cloud computing for application design, implementation, deployment, delivery, and operation.

[0068] (2) Language Virtual Machine (VM)

[0069] The language virtual machine is an important tool in programming languages. Essentially, it is a software module that can convert high-level language code (such as bytecode) into low-level machine instructions, enabling the code to run on different operating systems and hardware platforms. For example, for the Java language, after compiling the Java source code into bytecode as intermediate code, the Java language virtual machine can convert the bytecode into machine instructions for execution.

[0070] (3) Java

[0071] Java is a programming language specifically designed for the distributed environment of the Internet. Java has a "form and feel" similar to the C++ language, but it is easier to use than the C++ language and completely adopts an "object-oriented" approach in programming. Applications written in Java can either run on a single computer or be distributed and run on the server side and client side of a network.

[0072] (4) Class

[0073] A class is the basis for implementing information encapsulation in object-oriented programming. A class is a user-defined reference data type, also known as a class type. Each class contains data descriptions and a set of functions that operate on the data or transmit messages. An instance of a class is usually called an object.

[0074] (5) Snapshot

[0075] A snapshot refers to an available copy of a specified data set, which includes the image of the corresponding data at a certain point in time (the time point when the copy starts). Specifically, a snapshot can be a copy of the data it represents or a replica of the data.

[0076] To ensure that the execution platform is not restricted, many current high-level programming languages, such as Java, Kotlin, JavaScript, Python, C#, etc., usually adopt a language virtual machine to implement the operation of applications. For the source code written in these high-level programming languages, usually the source code is first compiled into intermediate code, and then the language virtual machine interprets and executes the intermediate code to achieve the operation of the application.

[0077] In addition, various advanced features provided by the language virtual machine, such as security checks, memory management, reflection, etc., also bring additional performance consumption to the execution of applications. Currently, most language virtual machines have implemented Just-in-time Compilation (JIT) technology, which dynamically compiles the frequently executed bytecodes into machine instructions and caches them at runtime, and then directly executes the machine instructions, avoiding the process of repeated interpretation and execution, and can significantly improve the running speed.

[0078] Although the peak performance of these applications based on language virtual machines is already very high, their startup speed is still not satisfactory. With the development of cloud computing, more and more applications are deployed in cloud-native scenarios. In cloud scenarios, the startup performance problem of applications running based on language virtual machines becomes increasingly prominent. This is caused by two characteristics of cloud scenarios: (1) less processing resources are allocated to a single application on the cloud; (2) the elastic scaling feature of cloud scenarios may cause applications to start relatively frequently. Traditional language virtual machines, such as the Java language virtual machine, were initially designed for long-running applications, and the processes such as class loading, warm-up, compilation, and support for various dynamic features are time-consuming and resource-consuming.

[0079] Therefore, in cloud-native scenarios, the phenomenon that applications executed based on language virtual machines take a long time to start has become an urgent problem to be solved.

[0080] Based on this, the present application provides an application startup acceleration method, in which a second node obtains and caches data that can accelerate the startup of an application from an already started application in a cloud-native scenario, and when a first node wants to start a first application, the first node requests the second node to accelerate the application and informs the data types that can support accelerated startup when running the first application. In this way, the second node can select data that meets the conditions from the cached data based on the data types that support accelerated startup of the first application, and send it to the first node, eliminating the process of the language virtual machine performing compilation and then loading the corresponding data, and realizing the process of accelerating the first node to start the first application through the language virtual machine.

[0081] Exemplarily, please refer to Figure 1 , Figure 1 which is a schematic architecture diagram of an application scenario provided by an embodiment of the present application. As Figure 1 shown, the cloud-native environment includes a cloud-native environment hardware cluster, which may include one or more cloud computing nodes for deploying applications that run based on a language virtual machine (hereinafter referred to as VM cloud applications). Among them, the cloud computing node may refer to a physical server or a virtual machine deployed on a physical server. Here, the specific form of the cloud-native environment is not limited, as long as the ultimately deployed VM cloud applications can communicate with the VM acceleration service over the network.

[0082] The cloud-native environment also includes a software module: a container orchestration platform for managing various hardware in the cloud environment and automatically deploying various VM cloud applications. Among them, the VM cloud applications in the cloud-native environment can be deployed on cloud computing nodes, and the VM cloud applications can be elastically scaled as needed.

[0083] The cloud-native environment also includes a newly added VM acceleration service. The VM acceleration service provides acceleration services for all VM cloud applications, optimizes the container deployment speed, and saves container resources. The deployment method of the VM acceleration service is flexible and can be containerized like other VM cloud applications, or deployed on an independent server or decentralized on top of each VM cloud application.

[0084] Please refer to Figure 2 , Figure 2 which is a schematic architecture diagram of a VM acceleration service provided by an embodiment of the present application. As Figure 2 shown, the VM cloud application shares the data obtained during the running process with the VM acceleration service, including profiling data, compiled code, metadata required for the language virtual machine to run, custom data, and snapshots of the application, etc. The data types that can be shared are rich.

[0085] The VM acceleration service caches, aggregates, shares, and continuously iterates the data shared by multiple VM cloud applications, generates acceleration data packets (hereinafter referred to as acceleration packets), and distributes the acceleration packets to newly launched VM cloud applications on demand.

[0086] Since different types of VM cloud applications often use the same underlying frameworks and third-party libraries, the VM acceleration service can integrate the data shared by different VM cloud applications and generate more general acceleration packets.

[0087] For ease of understanding, the devices to which the application startup acceleration method provided in the embodiments of the present application is applied will be introduced below.

[0088] Reference may be made to Figure 3 , Figure 3 which is a schematic structural diagram of an electronic device 101 provided in an embodiment of the present application. As Figure 3 shown, the electronic device 101 to which the application startup acceleration method provided in the embodiments of the present application is applied is, for example, a computing node in a cloud-native scenario. For example, the electronic device 101 is a server. Specifically, the electronic device 101 includes a processor 103, and the processor 103 is coupled to a system bus 105. The processor 103 may be one or more processors, and each processor may include one or more processor cores. A display adapter 107, which can drive a display 109, and the display 109 is coupled to the system bus 105. The system bus 105 is coupled to an input / output (I / O) bus through a bus bridge 111. An I / O interface 115 is coupled to the I / O bus. The I / O interface 115 communicates with a variety of I / O devices, such as an input device 117 (such as a touch screen, etc.), an external memory 121 (for example, a hard disk, a floppy disk, an optical disc, or a USB flash drive), a multimedia interface, etc.). A transceiver 123 (which can send and / or receive radio communication signals), a camera 155 (which can capture static and dynamic digital video images), and an external USB port 125. Optionally, the interface connected to the I / O interface 115 may be a USB interface.

[0089] Among them, the processor 103 may be any conventional processor, including a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, or a combination of the above. Optionally, the processor may be a dedicated device such as an ASIC.

[0090] The electronic device 101 can communicate with the software deployment server 149 through the network interface 129. Exemplarily, the network interface 129 is a hardware network interface, such as a network card. The network 127 can be an external network, such as the Internet, or an internal network, such as Ethernet or a virtual private network (VPN). Optionally, the network 127 can also be a wireless network, such as a WiFi network, a cellular network, etc.

[0091] The hard disk drive interface 131 is coupled to the system bus 105. The hardware drive interface is connected to the hard disk drive 133. The internal memory 135 is coupled to the system bus 105. The data running in the internal memory 135 can include the operating system (OS) 137, application programs 143, and a schedule of the electronic device 101.

[0092] The operating system includes a Shell 139 and a kernel 141. The Shell 139 is an interface between the user and the kernel of the operating system. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system: waits for the user's input, interprets the user's input to the operating system, and processes various output results of the operating system.

[0093] The kernel 141 consists of those parts in the operating system that are used to manage memory, files, peripherals, and system resources. The kernel 141 directly interacts with the hardware. The operating system kernel usually runs processes and provides inter-process communication, provides CPU time slice management, interrupts, memory management, and IO management, etc.

[0094] Exemplarily, please refer to Figure 4 , Figure 4 which is a schematic flow diagram of an application startup acceleration method provided by an embodiment of the present application. As Figure 4 shown, the application startup acceleration method provided in this embodiment includes the following steps 401-404. The application startup acceleration method provided in this embodiment can be applied to a cloud native scenario to accelerate the startup of application programs running based on a language virtual machine in the cloud native scenario.

[0095] Step 401, the second node acquires and caches application data, where the application data is obtained based on a started application program and is used to accelerate the startup process of the application program.

[0096] In this embodiment, the second node is a node in the cloud native scenario, which can acquire the application data generated by the started application program and can cache the acquired application data for subsequent distribution to other nodes that need to start the application program.

[0097] In a possible example, the second node can be the central node in the cloud-native scenario, that is, the second node has established network connections with other nodes in the cloud-native scenario and can interact with any other node in the cloud-native scenario to exchange application data. In this way, after any node in the cloud-native scenario completes the startup of the application program, during the running of the application program or after the application program finishes running, it can send the application data generated during the running of the application program to the second node, and this application data can be used to accelerate the startup process of the application program.

[0098] In another possible example, the second node can be a node for running VM cloud applications in the cloud-native scenario. During the running of the application program, the second node can cache the data that can be used to accelerate the startup of the application program, so as to share the cached data with other nodes that need to newly start the application program later. Or, before starting the VM cloud application, the second node can obtain the application data that can be used to accelerate the startup of the VM cloud application from other nodes; in this way, the second node can cache the application data obtained from other nodes and the data generated during its own running of the VM cloud application.

[0099] Among them, the application data cached by the second node can be various types of data, for example, it can include compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or snapshots of the application program.

[0100] Specifically, the compiled code refers to the binary code obtained after the language virtual machine compiles the bytecode. For example, for the bytecode that often needs to be compiled and run during the running of the application program or the bytecode with a complex compilation process, these bytecodes can be compiled to obtain the compiled code. Then, the second node can obtain and cache these compiled codes, so as to send the cached compiled codes to other nodes that newly start the application program later, saving the process of compiling the bytecode when starting the application program.

[0101] Code optimization data may refer to various types of data related to code optimization generated during the runtime of an application. Exemplarily, code optimization data may be, for example, profiling data. Among them, profiling data is data obtained by analyzing the running process of an application based on a program performance analysis tool (such as the number of times various functions are called in the application, the running duration of various functions, etc.), and can be used to optimize the code of the application. For example, based on the profiling data, it is known that in the code of the application, function A is executed 1000 times, while function B is only executed once. Then, during the startup process of the application, the compilation process of function A can be optimized, and function B does not need to be compiled, thereby improving the startup speed of the application.

[0102] The metadata required for the operation of the language virtual machine may be various data required by the language virtual machine when running an application, and may specifically include class data (such as classes called during the running process of the application), constant pools, class loader resources (i.e., tools responsible for loading class data), operation parameters of the language virtual machine, and other data.

[0103] A class is a user-defined reference data type, and class data may be used to indicate the classes used during the running process of an application.

[0104] The constant pool is used to store constants such as integers, floating-point literals, and strings. By obtaining the constant pool, some constants required during the startup period of the application can be quickly obtained, eliminating the constant generation process.

[0105] The class loader is responsible for converting bytecodes in the JVM into classes that can be executed by the JVM. During the runtime of the JVM, classes will be dynamically created as needed. The bootstrap class loader will first load the core class library in the program, and then load dependent classes downward. Class loaders can be divided into three types: the bootstrap class loader, the extension class loader, and the application class loader. Therefore, the above-mentioned class loader resources may refer to the resources of the class loader required during the running process of an application.

[0106] Custom data may refer to data relatively related to the application itself, such as the resource storage path (classpath of the resource) or other data related to the personalized code of the application. In the case where the custom data is the resource storage path, by obtaining the resource storage path, a certain resource under the resource storage path can be quickly determined during the startup process of the application, and there is no need to traverse all possible storage paths to obtain the resource, thereby improving the startup speed of the application.

[0107] A snapshot of an application refers to an image of all the data generated in memory at a certain point in time during the running of the application. Based on the snapshot of the application, the application can be directly continued to run from a certain point in time during the running of the application, thus eliminating various loading processes during the startup process of the application.

[0108] It should be noted that among the application data introduced above, some application data can be shared by different types of applications, such as class data, constant pools, and class loader resources and other application data. For this application data that can be shared by different types of applications, the second node can obtain it from a certain application and distribute this shareable application data to other different types of applications for use, so as to accelerate different types of applications based on the same application data. For some other application data (such as compiled code, code optimization data, custom data, or snapshots of applications), this part of the application data can only be used to accelerate the same type of application. Therefore, the second node can obtain and cache the application data of a specific application from the node that has started a specific application, and distribute the cached application data when other nodes newly start the specific application.

[0109] Step 402, the first node sends a first request message to the second node. The first request message is used to request to accelerate the startup of the first application, and the first request message is used to indicate the data types supported by the first application for accelerated startup.

[0110] In this embodiment, the first node is a node in the cloud native scenario, and the first node currently needs to start the first application. Then, before the first node starts the first application, the first node can send a first request message to the second node to request to accelerate the startup of the first application.

[0111] Generally speaking, the first node and the second node are different nodes in the cloud native scenario. Among them, the nodes in the cloud native scenario can refer to servers, or containers deployed in servers and other environments where applications can run independently. That is, the first node and the second node can be, for example, different servers in the cloud native scenario, or different containers in the same server. This embodiment does not make specific limitations on this.

[0112] Specifically, in order to enable the second node to clarify the situation of the application that the first node needs to accelerate the startup of, the first node can carry information about the first application in the first request message, such as the name of the first application, the version number of the first application, and the running environment of the first application and other information.

[0113] In addition, since various types of application data may be cached on the second node, and the data that can support accelerating the first application when the first node starts the first application may be specific type of data, the first node may indicate the data types supported by the first application for accelerated startup in the first request message, so that the second node can send the corresponding data to the first node.

[0114] Exemplarily, the data types supported by the first application for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or snapshots of the application. Among them, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources.

[0115] In addition, while indicating the data types supported by the first application for accelerated startup in the first request message, it may also be the specific information of the data required under the data types supported by the first application for accelerated startup. For example, when the first request message indicates that the data type supported by the first application for accelerated startup is class data, it may also be a list of classes supported by the first application for accelerated startup, to indicate which classes the first application can be accelerated based on.

[0116] Generally speaking, the application data cached on the second node may have various types of data, so as to provide application acceleration services for other nodes from various perspectives. However, the applicable scopes of different types of application data may be different (for example, some application data can be applicable to most application programs, while some other application data can only be applicable to specific application programs), and the acceleration effects may also be different. For example, the applicable scope of class data is relatively wide, and application programs with different businesses but the same framework can often share the same class data to achieve accelerated startup. And the above profiling data is highly bound to the runtime of the application program, and the profiling data generated by different instances of the same application program may vary greatly.

[0117] Moreover, the sizes of different types of application data may also vary greatly (for example, the amount of the above custom data may be relatively low, while the amount of the snapshot of the application program is relatively high), and the requirements for changes to the business logic may also be different when different types of application data are applied to accelerate the startup of the application program (for example, applying the above custom data does not require developers to modify the running logic of the application program additionally, while applying the above snapshot of the application program requires developers to modify the running logic of the application program additionally).

[0118] Based on this, in this embodiment, when the first node requests to accelerate the first application from the second node, it is necessary to indicate the data types that the first application can support for accelerated startup, so that the second node can select the data that meets the conditions from various types of data.

[0119] Generally speaking, the data types that the first application can support for accelerated startup can be specified by the developer. For example, when the developer has made corresponding modifications to the running logic of the first application, the first application can use various types of data for acceleration; another example is that when the developer has not made any modifications to the running logic of the first application, the first application may only be able to use some specific types of data (such as custom data or class data, etc.) for acceleration.

[0120] Step 403, the second node sends the first data to the first node, where the first data is the data required during the startup process of the first application. The first data is obtained and cached by the second node based on the already started application, and the first data belongs to the data types that the first application supports for accelerated startup.

[0121] After obtaining the first request message, the second node can confirm the application on the first node that needs to be accelerated (i.e., the first application), and the data types that the first application can support for accelerated startup. In this way, the second node can select the first data that the first application supports for accelerated startup from the cached application data.

[0122] Specifically, if the data corresponding to the data types that the first application supports for accelerated startup can be shared by different types of applications, the second node can determine the first data provided for the first application to use from the application data obtained from various types of applications. For example, assume that the data type that the first application supports for accelerated startup is class data, and the first request message indicates the class list used by the first application. Since different types of applications may often use the same classes, the second node can determine the classes mentioned in the class list from the class data obtained from various types of applications, and then send the determined classes to the first node as the first data.

[0123] If the data corresponding to the data type that the first application supports for accelerated startup is data that can only be used by a specific application, the second node can determine the first data provided for the first application from the application data obtained from an application of the same type as the first application. For example, assume that the data type that the first application supports for accelerated startup is profiling data. Then, the second node can determine the profiling data therein as the first data provided for the first application from the application data obtained from other applications (usually the same type of applications that have been started by other nodes) with the same application name as the first application.

[0124] Exemplarily, when the second node is the central node in a cloud-native scenario, the first data sent by the second node can be obtained by the second node from other nodes that have started applications. That is, the second node obtains the first data that can accelerate the startup of the first application from other nodes that have started applications and caches the first data so that the first data can be sent to the first node subsequently. Among them, the applications started by other nodes that have started applications and the first application can be applications of the same type, then the first data is data that can be shared by different types of applications. The applications started by other nodes that have started applications and the first application can also be applications of different types, then the first data can include data that can be shared by different types of applications and / or data that can only be used by the first application.

[0125] Exemplarily, when the second node is a node for running VM cloud applications in a cloud-native scenario, the second node can be, for example, a node that has started the second application in a cloud-native scenario. Among them, the data required for the startup process of the second application overlaps with the data required for the startup process of the first application, that is, some or all of the data required during the startup process of the second application is the same as the data required during the startup process of the first application. For example, the second application and the first application are applications of different types, but the class data required during the startup process of the second application is the same as the class data required during the startup process of the first application. Therefore, the second node can send the data shared by the first application and the second application to the first node. Another example is that the second application and the first application are applications of the same type (for example, the first application and the second application are actually applications started based on the same code on different nodes). In this way, the data required during the startup process of the second application is basically the same as the data required during the startup process of the first application. Therefore, the second node can send all the data generated during the running process of the second application to the first application.

[0126] Step 404, the first node starts the first application based on the first data, and the first application is started through a language virtual machine in the cloud native scenario.

[0127] After the first node obtains the first data, the first data can be used to accelerate the startup process of the first application. Among them, the first data may include one or more types of data. For different types of data, the way the first node uses the data to accelerate the startup of the first application may also be different.

[0128] For example, when the first data includes compiled code, when the first node starts the first application based on the language virtual machine, it can directly run the compiled code, thus skipping the process of compiling the intermediate code of the first application and improving the startup speed of the application.

[0129] For another example, when the first data includes metadata such as class data, the first node can directly map the class data to memory, thus skipping the lengthy loading process. Among them, when the first application follows the conventional startup process, class loading often has multiple steps such as traversing resources to find class files, generating objects based on class files, and performing verification on objects. By directly mapping the class data to memory, the above-mentioned cumbersome multiple steps can be avoided, and the startup speed of the application can be improved.

[0130] For another example, when the first data includes custom data indicating the resource storage path, the first node can quickly locate the resources required in the process of starting the first application based on the resource storage path in the first data, thus avoiding the process of traversing the required resources in all resources and improving the startup speed of the application.

[0131] Optionally, in order to continue to enrich the application data cached on the second node, after starting the first application, the first node can send the second data to the second node. The second data is the data used in the running process of the first application, and the second data can be used to accelerate the startup of the application. In this way, after receiving the second data, the second node can cache the second data, so that the application data cached on the second node is more abundant, ensuring that the second node can provide a more comprehensive application acceleration service.

[0132] Optionally, before the first node sends the second data to the second node, the first node first sends a second request message to the second node. The second request message is used to indicate the data collected by the first node during the running process of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache. That is, the first node requests the second node to confirm the data that the second node actually needs to cache from the data collected by the first node.

[0133] Then, the first node receives a response message sent by the second node, and the response message is used to indicate the data that the second node needs to cache. In this way, based on the response message, the first node can determine the second data from the collected data. The second data may be all the data collected by the first node, or a part of the data collected by the first node, and this embodiment does not make specific limitations on this.

[0134] That is to say, during the process of the first node running the first application, the first node can regularly collect the data generated during the running of the first application, and the data collected by the first node can be used to accelerate the startup of the application. For example, the data collected by the first node may be compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application. Since there may be some overlap between the application data cached on the second node and the data collected by the first node, the first node can negotiate with the second node after collecting the running data of the first application to confirm the data that the second node needs to obtain and cache from the first node.

[0135] In this solution, after the node responsible for running the application successfully starts and runs the application, by regularly collecting the data generated during the running of the application and negotiating with the node responsible for caching the application data, some new data that can be used to accelerate the application is sent to the node responsible for caching the application data, thereby enriching the application data cached on the node and ensuring that the node can provide a more comprehensive application acceleration service.

[0136] For ease of understanding, the following will introduce in detail the execution process of the application startup acceleration method provided in the embodiments of the present application with specific examples. To achieve application startup acceleration, this embodiment provides a VM acceleration service, which can be specifically implemented by program code deployed on a node (such as the above-mentioned second node) in a cloud-native scenario. That is, the above-mentioned second node is used to provide a VM acceleration service for other nodes. Specifically, when the node is a server, the program code of the VM acceleration service can run in the memory of the server, communicate with the VM cloud applications on other nodes through the network, and use the external memory (such as a hard disk) on the server to store the application data obtained from other already started application programs.

[0137] Among them, the deployment method of the VM acceleration service is relatively flexible, and it can be centralized deployment or decentralized deployment. The following will introduce the specific methods of centralized deployment and decentralized deployment of the VM acceleration service respectively.

[0138] Exemplarily, please refer to Figure 5 , Figure 5The figure is a schematic diagram of the architecture when the VM acceleration service is centrally deployed according to an embodiment of the present application. As Figure 5 shown, when the VM acceleration service is centrally deployed, the program code of the VM acceleration service is deployed on the server in the cloud in the form of an independent application. In this way, by specifying the access address of the VM acceleration service, the VM cloud application in the cloud-native scenario can directly communicate with the VM acceleration service through the network to share runtime data and cached data. It should be noted that when deploying the VM acceleration service, ensure that the VM cloud application can access the VM acceleration service in the form of a domain name or network address. Moreover, after the VM acceleration service is started, it will not be shut down again, and the listening port is always ready to receive acceleration requests sent by each VM cloud application.

[0139] For the VM cloud application in the cloud-native scenario, in addition to the cloud application business logic itself, the VM cloud application can also include a data sharing module, which is used to collect the application data generated during the operation of the VM cloud application and share the generated application data to the VM acceleration service through the network for caching. In this way, the VM acceleration service can continuously receive application data from other nodes through the network and integrate the application data into a cache file for accelerating the startup of the application program, so that when a new node starts an application program later, the cache file can be sent to the node that starts the new application program.

[0140] Among them, the VM acceleration service mainly involves two modules: network communication management and client data management. The client data management module is used to organize and manage the application data of each client (i.e., each VM cloud application) in memory, including updating data, merging data, deleting expired data, etc. And various acceleration packages generated based on the runtime data of each VM cloud application will be stored in the hard disk in the form of files. When generating the acceleration package, it may involve intensive CPU calculations such as compilation. The network communication module is responsible for interacting with each VM cloud application and is responsible for serializing and deserializing various types of data.

[0141] Exemplarily, please refer to Figure 6 , Figure 6 The figure is a schematic diagram of the process for accelerating the startup and sharing data of a VM cloud application according to an embodiment of the present application. As Figure 6 shown, in the cloud-native scenario, if a VM cloud application starts to use the startup acceleration service, the node responsible for starting the VM cloud application (such as the first node that starts the first application program in the above embodiment) will automatically request to accelerate the startup of the VM cloud application from the node that deploys the VM acceleration service (such as the second node in the above embodiment) before starting the VM cloud application.

[0142] Moreover, the node responsible for starting the VM cloud application will inform the VM acceleration service of the data types acceptable for accelerated startup this time and the relevant information of the currently to-be-started VM cloud application (such as the name, version number, and running environment of the VM cloud application, etc.).

[0143] After receiving the acceleration request from the node responsible for starting the VM cloud application, the VM acceleration service will search for available data in the cached application data based on the acceleration request and send the found data to the node responsible for starting the VM cloud application.

[0144] In addition, after the node starts and runs the VM cloud application based on the data fed back by the VM acceleration service, it can collect the application data generated during the running of the VM cloud application and send the application data missing or needing to be updated on the VM acceleration service to the VM acceleration service. In this way, the VM acceleration service can further complement, merge, or update the cached application data based on the application data sent by the node when running the VM cloud application, so as to maximize the applicable scope of the cache, continuously optimize the performance of the cached data, and save storage resources.

[0145] Since each VM cloud application will send the application data collected during the running process to the VM acceleration service for caching after startup, as the number of started VM cloud applications increases, the application data cached on the VM acceleration service will also increase. Then, the application data that the VM acceleration service can provide to the node for accelerating the startup of the VM cloud application before the startup of the VM cloud application will also increase, so that the startup speed of subsequent VM cloud applications will become faster and faster.

[0146] As Figure 6 shown, when the VM cloud application 1 starts, since there is no cached application data on the VM acceleration service yet, the VM cloud application 1 cannot obtain the application data for accelerated startup and can only start based on the traditional startup method. Therefore, the startup speed of the VM cloud application 1 is the slowest. After the VM cloud application 1 starts and runs, it sends the application data collected during the running process to the VM acceleration service so that the VM acceleration service can cache the obtained application data.

[0147] When the VM cloud application 2 starts, the VM acceleration service can send the cached application data to the VM cloud application 2, thereby improving the startup speed of the VM cloud application 2. Similarly, after the VM cloud application 1 starts and runs, it will also send the application data collected during the running process to the VM acceleration service, so that the VM acceleration service can cache the obtained application data. And so on, each subsequent VM cloud application can obtain the cached application data from the VM acceleration service when starting up, achieving startup acceleration; and each VM cloud application can send the application data collected during the running process to the VM acceleration service, thereby enriching the data cached on the VM acceleration service, enabling the VM acceleration service to provide more and more application data to accelerate the startup of the VM cloud application, and ultimately making the acceleration effect of the VM cloud application better and better.

[0148] Among them, there can be various types of application data cached on the VM acceleration service, such as compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or snapshots of application programs. For example, for the compiled code, the VM acceleration service replaces the compilation process in the subsequent startup phase of the VM cloud application by caching the compiled code. For the code optimization data, the VM acceleration service can enable compilation optimization based on runtime profiling data (Profile-guided Optimization, PGO), collect and merge the profiling data, so as to optimize the compilation process in the subsequent startup phase of the VM cloud application. That is, when the VM cloud application compiles the code, it can be optimized based on various known runtime data. The more known data there is, the more optimizations can be done. Therefore, a relatively common data can be merged from the relatively personalized runtime data sent by multiple started VM cloud applications on the VM acceleration service to compile better-quality and more general code.

[0149] However, for the application data cached on the VM acceleration service, the applicable ranges of different types of application data may be different (for example, some application data can be applicable to most application programs, while some other application data can only be applicable to specific application programs), the acceleration effects may be different, the sizes of different types of application data may vary greatly, and the requirements for changes to the business logic when applying different types of application data to accelerate the startup of the application program may also be different. Therefore, in this embodiment, the cached application data is stratified according to the complexity of making cached data and the data transmission volume on the VM acceleration service. The following is an example of a possible stratification method:

[0150] Level 1: Custom data.

[0151] Level 2: Custom data and metadata.

[0152] Level 3: Custom data, metadata, and compiled code.

[0153] Level 4: Custom data, metadata, compiled code, and code optimization data (such as Profiling data).

[0154] Level 5: Snapshots of the application.

[0155] Generally speaking, the higher the level corresponding to the application data, the more obvious the speedup, but the larger the cache file (i.e., the higher the requirement for network transmission speed), the more stringent the matching conditions, and the more application-side logic support is required (i.e., the more implementation logic the developer needs to modify). In addition, after the VM acceleration service hierarchically classifies the cached application data, the node only needs to inform the VM acceleration service of the acceleration level that the currently started VM cloud application can accept before starting the VM cloud application, and the VM acceleration service can determine the corresponding application data from the above classified levels and send it to the node.

[0156] In addition, many different application programs use the same framework and third-party libraries. Therefore, in order to expand the scope of application of the cache, reduce duplicate cache generation, and save hard disk space, this embodiment classifies the cache according to the hierarchical structure of the modules or classes of the application program, and the caches of the same module of different application programs can be merged. For example, for a typical Java cloud application, it first uses the Java class library, then applies the application development framework (such as Spring Boot), and finally its personalized business logic code. Therefore, the VM acceleration service can divide the cached application data into three layers: jdk cache, spring cache, and application cache.

[0157] Exemplarily, please refer to Figure 7 , Figure 7 which is a schematic diagram of the process for a VM cloud application to interact with a VM acceleration service to achieve startup acceleration provided by an embodiment of the present application. As Figure 7 shown, before starting, the VM cloud application can configure the address of the VM acceleration service to be accessed in the command line or configuration file. In the initial stage of starting the VM cloud application, that is, during the VM initialization period, the node where the VM cloud application is located interacts with the VM acceleration service and automatically negotiates whether there is an applicable acceleration package available. That is, the node where the VM cloud application is located sends the data type that the currently started VM cloud application can support for accelerated startup to the VM acceleration service; then, the VM acceleration service searches for available acceleration packages that meet the conditions in the cached application data.

[0158] If there is an available acceleration package on the VM acceleration service, the acceleration package is transmitted to the node where the VM cloud application is located and acceleration is enabled. If there is no available acceleration package on the VM acceleration service, the VM cloud application is started based on the traditional method. When the VM acceleration service is unavailable (such as a program crash), the VM cloud application will automatically fallback to start through the traditional method instead of crashing together. Also, if there is additional runtime data that can be shared during the operation of the VM cloud application, it will be collected into the memory.

[0159] Please refer to Figure 8 , Figure 8 which is a schematic flowchart of a process for a VM cloud application to share application data with a VM acceleration service provided by an embodiment of this application. As Figure 8 shown, after the VM cloud application is started, it continuously collects the runtime data of the VM cloud application (i.e., the application data generated during the operation of the VM cloud application). Also, the VM cloud application will perform preprocessing on the collected runtime data after reaching a specified time node, such as sorting and merging the runtime data or organizing the format of the runtime data, etc. Among them, the specified time node can refer to the time node when the VM cloud application starts successfully, a specific time node during the operation of the VM cloud application, the time node when the VM cloud application collects a certain amount of runtime data, or the time node when the VM cloud application ends its operation. Then, based on the collected runtime data, the VM cloud application asks the VM acceleration service for the required data, and after the VM acceleration service responds, it sends the data required by the VM acceleration service (such as the data missing or needing to be updated on the VM acceleration service), thereby reducing duplicate data transmission.

[0160] Exemplarily, please refer to Figure 9 , Figure 9 which is a schematic architecture diagram when the VM acceleration service is decentralized. As Figure 9 shown, when the VM acceleration service is decentralized, the program code of the VM acceleration service can be integrated into a regular VM cloud application. That is, in addition to the regular business logic, the VM cloud application can also provide the VM acceleration service, thereby providing startup-accelerating application data for other newly started VM cloud applications.

[0161] In Figure 9Among them, the VM cloud application includes cloud application business logic (i.e., the business logic of the VM cloud application itself) and VM acceleration services. Based on the VM acceleration services, the VM cloud application can share the runtime data generated during its own operation with other newly started VM cloud applications, thereby accelerating the startup of other VM cloud applications. Specifically, in the scenario of decentralized deployment of VM acceleration services, the VM acceleration services can be deployed on each VM cloud application, and the runtime data and cached application data are shared among different VM cloud applications. At this time, the acceleration package for accelerating startup can be generated by each VM cloud application automatically negotiating to select the VM cloud application with a lower current load.

[0162] The method provided by the embodiments of the present application has been introduced in detail above. Next, the device for executing the above method provided by the embodiments of the present application will be introduced.

[0163] Please refer to Figure 10 , Figure 10 which is a schematic structural diagram of an application startup acceleration device provided by an embodiment of the present application. As Figure 10 shown, the application startup acceleration device is deployed on the first node, and the application startup acceleration device includes: a sending module 1001, configured to send a first request message to the second node, the first request message being used to request to accelerate the startup of the first application program, and the first request information being used to indicate the data types supported by the first application program for accelerated startup; a receiving module 1002, configured to receive the first data sent by the second node, where the first data is the data required during the startup process of the first application program, the first data is obtained and cached by the second node based on the already started application program, and the first data belongs to the data types supported by the first application program for accelerated startup; a processing module 1003, configured to start the first application program based on the first data, and the first application program is started through a language virtual machine in the cloud native scenario.

[0164] In a possible implementation manner, the data types supported by the first application program for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application program.

[0165] In a possible implementation manner, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources.

[0166] In a possible implementation manner, after starting the first application program, the sending module 1001 is further configured to send second data to the second node, and the second data is the data used during the operation of the first application program.

[0167] In a possible implementation, before the sending module 1001 sends the second data to the second node, the sending module 1001 is further configured to send a second request message to the second node, where the second request message is used to indicate the data collected during the running of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache; the receiving module 1002 is further configured to receive a response message sent by the second node, where the response message is used to indicate the data that the second node needs to cache; the processing module 1003 is further configured to determine the second data from the collected data based on the response message at the first node.

[0168] Please refer to Figure 11 , Figure 11 which is a schematic structural diagram of another application startup acceleration device provided by an embodiment of this application. As Figure 10 shown, the application startup acceleration device is deployed on the second node, and the application startup acceleration device includes: a processing module 1101, configured to obtain and cache application data, where the application data is obtained based on the started application program, and the application data is used to accelerate the startup process of the application program; a receiving module 1102, configured to receive a first request message sent by the first node, where the first request message is used to request acceleration of the startup of the first application, and the first request message is used to indicate the data type supported by the first application for accelerated startup, and the first application is started through a language virtual machine in a cloud native scenario; a sending module 1103, configured to send the first data to the first node, where the first data is the data required during the startup process of the first application, and the first data is determined by the second node from the data based on the data type supported by the first application for accelerated startup.

[0169] In a possible implementation, the data types supported by the first application for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application program.

[0170] In a possible implementation, the metadata required for the operation of the language virtual machine includes class data, constant pool, and class loader resources.

[0171] In a possible implementation, after starting the first application, the receiving module 1102 is further configured to receive second data sent by the first node, where the second data is the data used during the running of the first application; the processing module 1101 is further configured to cache the second data.

[0172] In a possible implementation, before receiving the second data sent by the first node, the receiving module 1102 is further configured to receive a second request message sent by the first node, where the second request message is used to indicate the data collected during the operation of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache; the sending module 1103 is further configured to send a response message to the first node, where the response message is used to indicate the data that the second node needs to cache, and the data that the second node needs to cache is determined based on the collected data and the application data.

[0173] Please refer to Figure 12 , Figure 12 FIG. is a schematic structural diagram of an execution device provided by an embodiment of the present application. As Figure 12 shown, the execution device 1200 may specifically be embodied as a server, which is not limited herein. Specifically, the execution device 1200 includes: a receiver 1201, a transmitter 1202, a processor 1203, and a memory 1204 (where the number of processors 1203 in the execution device 1200 may be one or more, Figure 12 and one processor is taken as an example here), where the processor 1203 may include an application processor 12031 and a communication processor 12032. In some embodiments of the present application, the receiver 1201, the transmitter 1202, the processor 1203, and the memory 1204 may be connected through a bus or other means.

[0174] The memory 1204 may include a read-only memory and a random access memory, and provide instructions and data to the processor 1203. A part of the memory 1204 may further include a non-volatile random access memory (NVRAM). The memory 1204 stores processor and operation instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, where the operation instructions may include various operation instructions for implementing various operations.

[0175] The processor 1203 controls the operation of the execution device. In a specific application, the various components of the execution device are coupled together through a bus system, where the bus system may include a power bus, a control bus, a status signal bus, etc. in addition to a data bus. However, for the sake of clarity, all buses are referred to as a bus system in the figure.

[0176] The method disclosed in the embodiments of the present application can be applied to or implemented by the processor 1203. The processor 1203 can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor 1203 or instructions in the form of software. The above-mentioned processor 1203 can be a general-purpose processor, a digital signal processor (DSP), a microprocessor or a microcontroller, and can further include an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0177] The processor 1203 can implement or execute each method, step and logic block diagram disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly reflected as being completed by the hardware decoding processor, or completed by a combination of the hardware and software modules in the decoding processor. The software module can be located in a mature storage medium in the art such as random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. This storage medium is located in the memory 1204, and the processor 1203 reads the information in the memory 1204 and combines its hardware to complete the steps of the above method.

[0178] The receiver 1201 can be used to receive input digital or character information, and generate signal inputs related to the relevant settings and function controls of the execution device. The transmitter 1202 can be used to output digital or character information through the first interface; the transmitter 1202 can also be used to send instructions to the disk group through the first interface to modify the data in the disk group; the transmitter 1202 can also include a display device such as a display screen.

[0179] The execution device provided by the embodiments of the present application may specifically be a chip, and the chip includes a processing unit and a communication unit. The processing unit may be a processor, for example, and the communication unit may be an input / output interface, a pin, a circuit, or the like. The processing unit may execute the computer-executable instructions stored in the storage unit to cause the chip in the execution device to execute the method described in the above embodiments. Optionally, the storage unit is a storage unit within the chip, such as a register, a cache, etc. The storage unit may also be a storage unit located outside the chip within the wireless access device, such as a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM), etc.

[0180] Reference may be made to Figure 13 , Figure 13 which is a schematic structural view of a computer-readable storage medium provided by the embodiments of the present application. The present application also provides a computer-readable storage medium. In some embodiments, the above Figure 3 disclosed method may be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or encoded on other non-transitory media or articles.

[0181] Figure 13 Schematically shown is a conceptual partial view of an example computer-readable storage medium arranged according to at least some of the embodiments presented herein. The example computer-readable storage medium includes a computer program for executing a computer process on a computing device.

[0182] In one embodiment, the computer-readable storage medium 1300 is provided using a signal-bearing medium 1301. The signal-bearing medium 1301 may include one or more program instructions 1302, which when run by one or more processors may provide the functions or partial functions described above for Figure 3 description.

[0183] In some examples, the signal-bearing medium 1301 may include a computer-readable medium 1303, such as but not limited to, a hard disk drive, a compact disc (CD), a digital video disc (DVD), a digital tape, a memory, a ROM, or a RAM, and so on.

[0184] In some embodiments, the signal-bearing medium 1301 may include a computer-readable medium 1304, such as, but not limited to, a memory, a read / write (R / W) CD, an R / W DVD, and the like. In some embodiments, the signal-bearing medium 1301 may include a communication medium 1305, such as, but not limited to, digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.). Thus, for example, the signal-bearing medium 1301 may be conveyed by a wireless form of the communication medium 1305 (e.g., a wireless communication medium compliant with the IEEE 802.X standard or other transmission protocols).

[0185] One or more program instructions 1302 may be, for example, computer-executable instructions or logic-implemented instructions. In some examples, a computing device of the computing device may be configured to provide various operations, functions, or actions in response to the program instructions 1302 communicated to the computing device via one or more of the computer-readable medium 1303, the computer-readable medium 1304, and / or the communication medium 1305.

[0186] It should be further noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place or distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationships between the modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines.

[0187] Through the description of the above embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware. Of course, it can also be implemented by dedicated hardware, including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. Generally, functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits, or dedicated circuits. However, for this application, in more cases, software program implementation is a better embodiment. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a floppy disk, a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disc of a computer, and includes several instructions to enable a computer device (which may be a personal computer, a training device, or a network device, etc.) to execute the methods of the various embodiments of this application.

[0188] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.

[0189] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that the computer can store or a data storage device such as a training device or data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)), etc.

Claims

1. A method for accelerating application startup, characterized in that The method is applied to the process of starting a first application on a language virtual machine based on a cloud-native scenario. The method includes: A first node sends a first request message to a second node. The first request message is used to request accelerating the start of the first application, and the first request message is used to indicate the data types supported by the first application for accelerated start-up. The first node receives first data sent by the second node. The first data is data required during the start-up process of the first application. The first data is obtained and cached by the second node based on a started application, and the first data belongs to the data types supported by the first application for accelerated start-up. The first node starts the first application based on the first data.

2. The method according to claim 1, characterized in that, The data types supported by the first application for accelerated start-up include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application.

3. The method according to claim 2, wherein The metadata required for the operation of the language virtual machine includes class data, constant pools, and class loader resources.

4. The method according to any one of claims 1 to 3, characterized in that The method further includes: After starting the first application, the first node sends second data to the second node. The second data is data used during the operation of the first application, and the second data is data that has been screened and confirmed not to exist on the second node.

5. The method according to claim 4, characterized in that, Before the first node sends the second data to the second node, the method further includes: The first node sends a second request message to the second node. The second request message is used to indicate the data collected during the operation of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache. The first node receives a response message sent by the second node. The response message is used to indicate the data that the second node needs to cache. Based on the response message, the first node determines the second data from the collected data.

6. The method according to any one of claims 1-5, characterized in that The second node is the central node in the cloud-native scenario. The first data is obtained by the second node from other nodes that have started applications.

7. The method according to any one of claims 1-5, characterized in that, The second node is a node on which a second application has been started in the cloud-native scenario. The data required during the start-up process of the second application overlaps with the data required during the start-up process of the first application.

8. The method according to any one of claims 1-6, characterized in that, The started applications include applications of different types from the first application.

9. A method for accelerating application startup, characterized in that, The method is applied to the process of starting a first application on a language virtual machine based on a cloud-native scenario. The method includes: The second node obtains and caches application data. The application data is obtained based on a started application, and the application data is used to accelerate the start-up process of the application. The second node receives a first request message sent by the first node. The first request message is used to request to accelerate the startup of the first application, and the first request information is used to indicate the data types supported by the first application for accelerated startup. The first application is started through a language virtual machine in a cloud-native scenario; The second node sends first data to the first node, where the first data is the data required during the startup process of the first application, and the first data is determined by the second node from the data based on the data types supported by the first application for accelerated startup.

10. The method according to claim 9, wherein The data types supported by the first application for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the language virtual machine to run, custom data, or a snapshot of the application.

11. The method according to claim 10, wherein The metadata required for the language virtual machine to run includes class data, constant pools, and class loader resources.

12. The method according to any one of claims 9-11, characterized in that, The method further includes: After the first node starts the first application, the second node receives second data sent by the first node. The second data is the data used during the running process of the first application; The second node caches the second data.

13. The method according to claim 12, wherein Before the second node receives the second data sent by the first node, the method further includes: The second node receives a second request message sent by the first node. The second request message is used to indicate the data collected during the running process of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache; The second node sends a response message to the first node. The response message is used to indicate the data that the second node needs to cache, and the data that the second node needs to cache is determined based on the collected data and the application data.

14. The method according to any one of claims 9-13, characterized in that, The second node is the central node in the cloud-native scenario, and the application data is obtained by the second node from other nodes that have started the application.

15. The method according to any one of claims 9 - 13, characterized in that The second node is a node that has started the second application in the cloud-native scenario. The application data is based on the second application, and the data required during the startup process of the second application overlaps with the data required during the startup process of the first application.

16. The method according to any one of claims 9-15, characterized in that, The started applications include applications of different types from the first application.

17. An application startup acceleration device, characterized in that, The device is deployed on the first node, and the device includes: A sending module, configured to send a first request message to the second node. The first request message is used to request to accelerate the startup of the first application, and the first request information is used to indicate the data types supported by the first application for accelerated startup; A receiving module, configured to receive the first data sent by the second node. The first data is the data required during the startup process of the first application, and the first data is obtained and cached by the second node based on the started applications, and the first data belongs to the data types supported by the first application for accelerated startup; A processing module, configured to start the first application based on the first data, where the first application is started through a language virtual machine in a cloud-native scenario.

18. The device according to claim 17, wherein, The data types supported by the first application for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application.

19. The device according to claim 18, characterized in that, The metadata required for the operation of the language virtual machine includes class data, constant pools, and class loader resources.

20. The apparatus according to any one of claims 17-19, characterized in that After starting the first application, the sending module is further configured to send second data to the second node, where the second data is data used during the operation of the first application.

21. The device according to claim 20, characterized in that, Before the sending module sends the second data to the second node, the sending module is further configured to send a second request message to the second node, where the second request message is used to indicate data collected during the operation of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache; The receiving module is further configured to receive a response message sent by the second node, where the response message is used to indicate the data that the second node needs to cache; The processing module is further configured to determine the second data from the collected data on the first node based on the response message.

22. An application startup acceleration device, characterized in that, The apparatus is deployed on a second node, and the apparatus includes: A processing module, configured to obtain and cache application data, where the application data is obtained based on a started application, and the application data is used to accelerate the startup process of the application; A receiving module, configured to receive a first request message sent by a first node, where the first request message is used to request acceleration of the startup of a first application, and the first request message is used to indicate the data types supported by the first application for accelerated startup, and the first application is started through a language virtual machine in a cloud-native scenario; A sending module, configured to send first data to the first node, where the first data is data required during the startup process of the first application, and the first data is determined by the second node from the data based on the data types supported by the first application for accelerated startup.

23. The device according to claim 22, characterized in that, The data types supported by the first application for accelerated startup include one or more of the following: compiled code, code optimization data, metadata required for the operation of the language virtual machine, custom data, or a snapshot of the application.

24. The device according to claim 23, characterized in that, The metadata required for the operation of the language virtual machine includes class data, constant pools, and class loader resources.

25. The apparatus according to any one of claims 22-23, characterized in that After starting the first application, the receiving module is further configured to receive second data sent by the first node, where the second data is data used during the operation of the first application; The processing module is further configured to cache the second data.

26. The device according to claim 25, wherein Before receiving the second data sent by the first node, the receiving module is further configured to receive a second request message sent by the first node, where the second request message is used to indicate data collected during the operation of the first application, and the second request message is used to request confirmation of the data that the second node needs to cache; The sending module is further configured to send a response message to the first node, where the response message is used to indicate the data that the second node needs to cache, and the data that the second node needs to cache is determined based on the collected data and the application data.

27. An application startup acceleration device, characterized in that, It includes a memory and a processor; the memory stores code, and the processor is configured to execute the code. When the code is executed, the device performs the method according to any one of claims 1 to 16.

28. A cloud computing system, characterized in that, It includes the device according to any one of claims 17-21 and the device according to any one of claims 22-26.

29. A computer storage medium, characterized in that, The computer storage medium stores instructions, and when the instructions are executed by a computer, the computer implements the method according to any one of claims 1 to 16.

30. A computer program product, characterized in that, The computer program product stores instructions, and when the instructions are executed by a computer, the computer implements the method according to any one of claims 1 to 16.

Images