Instance starting method and device of microservice, electronic equipment and storage medium

Abstract

The present disclosure provides an instance startup method and device of a microservice, electronic equipment and a storage medium, and relates to the technical field of microservices and distributed storage. The specific implementation scheme is as follows: a first instance startup phase checkpoint snapshot sent by a first device is acquired, the checkpoint snapshot is a snapshot when the running state of the first instance meets a set condition; a snapshot request of a second instance sent by a second device is received; according to the snapshot request, the checkpoint snapshot is sent to the second device, and the checkpoint snapshot includes related information required for the second instance to perform checkpoint coordinated recovery (CRaC) startup.

Description

Technical Field

[0001] This disclosure relates to the fields of microservices and distributed storage technology, and in particular to a method, apparatus, electronic device and storage medium for starting up microservice instances. Background Technology

[0002] Microservices, as a software architectural style, divide an application into a set of small, independently deployed services. These services can be developed, tested, deployed, and scaled independently. The Java community, an object-oriented programming language, provides a wealth of tools and frameworks for microservice development. However, Java microservices also face some controversies during the startup and runtime phases, including long startup times, high memory and CPU load during startup, and poor performance during the cold start phase. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for starting up microservice instances.

[0004] According to one aspect of this disclosure, a method for starting a microservice instance is provided, comprising: acquiring a checkpoint snapshot of a first instance startup phase sent by a first device, the checkpoint snapshot being a snapshot of the first instance's running state meeting set conditions; receiving a snapshot request for a second instance sent by a second device; and sending the checkpoint snapshot to the second device according to the snapshot request, the checkpoint snapshot including relevant information required for the second instance to perform checkpoint coordination recovery CRaC startup.

[0005] According to another aspect of this disclosure, another method for starting a microservice instance is provided, comprising: monitoring the running status of the first instance during the startup phase; in response to the running status meeting the set conditions, obtaining a checkpoint snapshot of the first instance when the running status meets the set conditions; and sending the checkpoint snapshot to a distributed storage system, the checkpoint snapshot including relevant information required for a second instance to perform CRaC startup.

[0006] According to another aspect of this disclosure, another method for starting a microservice instance is provided, comprising: obtaining a checkpoint snapshot corresponding to a first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup; and performing CRaC startup on the second instance based on the checkpoint snapshot.

[0007] According to another aspect of this disclosure, a microservice instance startup apparatus is provided, comprising: an acquisition module, configured to acquire a checkpoint snapshot of a first instance startup phase sent by a first device, the checkpoint snapshot being a snapshot of the first instance's running state meeting set conditions; a receiving module, configured to receive a snapshot request for a second instance sent by a second device; and a sending module, configured to send the checkpoint snapshot to the second device according to the snapshot request, the checkpoint snapshot including relevant information required for the second instance to perform checkpoint coordination recovery CRaC startup.

[0008] According to another aspect of this disclosure, another microservice instance startup apparatus is provided, comprising: a monitoring module for monitoring the running status of the first instance during the startup phase; an acquisition module for acquiring a checkpoint snapshot of the first instance when the running status meets the set conditions in response to the running status meeting the set conditions; and a sending module for sending the checkpoint snapshot to a distributed storage system, the checkpoint snapshot including relevant information required for a second instance to perform CRaC startup.

[0009] According to another aspect of this disclosure, another microservice instance startup apparatus is provided, comprising: an acquisition module for acquiring a checkpoint snapshot corresponding to a first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup; and a startup module for performing CRaC startup on the second instance based on the checkpoint snapshot.

[0010] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the microservice instance startup method described in one aspect of the above embodiment.

[0011] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein computer programs / instructions are stored thereon for causing the computer to execute the microservice instance startup method described in one aspect of the above-described embodiment.

[0012] According to another aspect of this disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the microservice instance startup method described in one aspect of the above-described embodiments.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0015] Figure 1 A flowchart illustrating a microservice instance startup method provided in this embodiment of the disclosure;

[0016] Figure 2 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0017] Figure 3 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0018] Figure 4 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0019] Figure 5 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0020] Figure 6 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0021] Figure 7 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0022] Figure 8 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0023] Figure 9 A flowchart illustrating another microservice instance startup method provided in this embodiment of the disclosure;

[0024] Figure 10 A schematic diagram illustrating the creation and distribution of checkpoint snapshots provided in embodiments of this disclosure;

[0025] Figure 11 A flowchart illustrating the process of creating checkpoints provided in this embodiment of the disclosure;

[0026] Figure 12 This is a schematic diagram illustrating the process of distributing checkpoint snapshots according to an embodiment of the present disclosure;

[0027] Figure 13A schematic diagram of the structure of a microservice instance startup device provided in this embodiment of the disclosure;

[0028] Figure 14 A schematic diagram of another microservice instance startup device provided in this embodiment of the disclosure;

[0029] Figure 15 A schematic diagram of another microservice instance startup device provided in this embodiment of the disclosure;

[0030] Figure 16 This is a block diagram of an electronic device used to implement the microservice instance startup method of the embodiments of this disclosure. Detailed Implementation

[0031] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0032] The following description, with reference to the accompanying drawings, outlines a method, apparatus, and electronic device for starting up microservice instances according to embodiments of the present disclosure.

[0033] Figure 1 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. This microservice instance startup method can be executed by a distributed storage system.

[0034] like Figure 1 As shown, the method for starting an instance of this microservice may include:

[0035] S101, Obtain a checkpoint snapshot of the first instance startup phase sent by the first device. The checkpoint snapshot is a snapshot when the running state of the first instance meets the set conditions.

[0036] It should be noted that the execution entity of the microservice instance startup method in this embodiment can be a hardware device with data processing capabilities and / or the necessary software to drive the hardware device. Optionally, the execution entity may include a server. Optionally, the server may be a server equipped with a distributed storage system. This embodiment does not impose specific limitations.

[0037] As is understandable, a checkpoint snapshot is a technique used in computer systems to save the complete state of a system or application at a specific point in time. Its main purpose is to enable quick restoration to the state of the most recent checkpoint in the event of a system failure or the need for recovery, thereby reducing data loss and recovery time.

[0038] In some implementations, the distributed storage system can receive and store a checkpoint snapshot of the first instance's startup phase sent by the first device. Optionally, the checkpoint snapshot is a snapshot taken when the running state of the first instance meets set conditions.

[0039] Optionally, the following conditions can be met: the CPU utilization rate of the instance is less than the utilization rate threshold, and the response speed is greater than the speed threshold. That is, when the first instance in the first device starts up, if the CPU utilization rate of the first instance is less than the utilization rate threshold and the response speed is greater than the speed threshold, then a checkpoint is created on the first instance, and a checkpoint snapshot is generated.

[0040] Furthermore, after the first instance completes the checkpoint creation, the distributed storage system can automatically receive the checkpoint snapshot synchronously sent by the first device where the first instance is located, and store the checkpoint snapshot in a distributed manner.

[0041] S102, Receive a snapshot request for the second instance sent by the second device.

[0042] In some implementations, when a distributed storage system receives a checkpoint snapshot, it can send the checkpoint snapshot to multiple instances on other devices so that the instances can quickly run to the running state of the first instance based on the checkpoint snapshot.

[0043] Optionally, the distributed storage system can send checkpoint snapshots to instances based on snapshot requests. In other words, the distributed storage system can receive snapshot requests for a second instance from a second device.

[0044] S103, based on the snapshot request, send a checkpoint snapshot to the second device. The checkpoint snapshot includes relevant information required for the second instance to perform checkpoint coordination to restore CRaC startup.

[0045] In some implementations, the stored checkpoint snapshot can be verified before being sent to the second device, and only after successful verification can the checkpoint snapshot be sent to the second device. Since the checkpoint snapshot contains relevant information required for the second instance to perform Coordinated Restore at Checkpoint (CRaC) startup, the integrity of this information can be verified, and only after the integrity verification is successful can the checkpoint snapshot be sent to the second device.

[0046] In other words, the distributed storage system can obtain a checkpoint snapshot based on a snapshot request, verify the integrity of the relevant information contained in the checkpoint snapshot that is required to start CRaC, and send the checkpoint snapshot to the second device after the verification is successful.

[0047] According to the microservice instance startup method provided in this disclosure, the distributed storage system receives a checkpoint snapshot of the first instance startup phase sent by a first device and stores the checkpoint snapshot. By receiving a snapshot request sent by a second device, the checkpoint snapshot can be sent to the second device, enabling the second instance in the second device to perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching the optimal operating state. The distributed storage system can also support the rapid deployment and startup of large-scale instances, thereby significantly saving the deployment time of microservices, ensuring that microservices reach the optimal operating state in the shortest possible time, and guaranteeing the consistency of instance operating logic.

[0048] Figure 2 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. This microservice instance startup method can be executed by a distributed storage system.

[0049] like Figure 2 As shown, the method for starting an instance of this microservice may include:

[0050] S201, Obtain a checkpoint snapshot of the first instance startup phase sent by the first device. The checkpoint snapshot is a snapshot of the first instance's running state when the set conditions are met.

[0051] S202, Receive a snapshot request for the second instance sent by the second device.

[0052] The details of steps S201-S202 can be found in the above embodiments and will not be repeated here.

[0053] S203, Verify the checkpoint snapshot based on the snapshot request.

[0054] In some implementations, to ensure the consistency of data in checkpoint snapshots and avoid data errors, checkpoint snapshots can be verified before being sent, thereby improving the reliability of distributed systems.

[0055] In some implementations, the task completion file corresponding to the checkpoint snapshot can be obtained based on the snapshot request, and the first verification information corresponding to the checkpoint snapshot can be retrieved from the task completion file. In other words, the task completion file contains status information, result data, verification information, etc., after the task execution is completed.

[0056] Further, a second verification information is determined based on the checkpoint snapshot. Optionally, the content, format, or encryption algorithm of the checkpoint snapshot can be extracted as the second verification information.

[0057] Furthermore, the checkpoint snapshot can be verified based on the first verification information and the second verification information. Optionally, the first verification information and the second verification information may include the checkpoint's process ID. By verifying whether the two process IDs are consistent, it can be determined whether the checkpoint snapshot has passed verification. Optionally, if the process IDs are consistent, the checkpoint snapshot is determined to have passed verification; otherwise, the checkpoint snapshot is determined to have failed verification.

[0058] S204, in response to sending a checkpoint snapshot to the second device after verification.

[0059] In some implementations, once the checkpoint snapshot is verified, the checkpoint snapshot stored in the distributed storage system can be sent to a second device.

[0060] In some implementations, when a checkpoint snapshot is determined to have failed verification, it can be re-verified based on the time interval between task completions to improve verification accuracy and reduce false positives.

[0061] Optionally, in response to a failed verification, the timestamp of the task completion file corresponding to the checkpoint snapshot is obtained, and the time interval between the timestamp and the current timestamp is determined based on the timestamp. Then, the time interval can be used to determine whether the checkpoint snapshot can be re-verified.

[0062] In some implementations, in response to the time interval between the timestamp and the current time not exceeding a set duration, the checkpoint snapshot is re-verified after the set duration is reached, until the number of verifications exceeds the set number.

[0063] For example, if the checkpoint snapshot fails verification, the time interval between the timestamp of the task completion file and the current time is obtained. If the time interval is less than 5 minutes, wait 6 seconds and re-verify the checkpoint snapshot. If it still fails verification, continue to verify until the number of verifications exceeds 10, then end the verification. If the checkpoint snapshot fails verification, then start the second instance normally.

[0064] According to the microservice instance startup method provided in this disclosure, the distributed storage system receives a checkpoint snapshot of the first instance startup phase sent by a first device and stores the checkpoint snapshot. By receiving a snapshot request sent by a second device and verifying the checkpoint snapshot according to the request, the system sends the checkpoint snapshot to the second device after successful verification, enabling the second instance on the second device to perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching its optimal operating state. Verifying the checkpoint snapshot ensures the consistency of the data in the checkpoint snapshot, avoids data errors, and improves the reliability of the distributed system.

[0065] Figure 3 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. This microservice instance startup method can be executed by a distributed storage system.

[0066] like Figure 3 As shown, the method for starting an instance of this microservice may include:

[0067] S301, Receive the read lock request sent by the first device.

[0068] S302, determine the lock information from the lock file, and in response to the lock information not being occupied, send the lock information to the first device.

[0069] In some implementations, before obtaining the checkpoint snapshot from the first instance of the first device, it is necessary to send lock information to the first device based on the first device's read lock request, so that the first device can create a checkpoint based on the lock information and then generate a checkpoint snapshot.

[0070] Optionally, the distributed storage system receives a read lock request from the first device, retrieves lock information from the lock file based on the read lock request, and determines whether the lock information is occupied, so as to determine whether it is necessary to send lock information to the first device based on the determination result.

[0071] It is understandable that if the lock information is occupied, it means that an instance has already created a checkpoint. If the instance is not the first instance, the first instance does not need to create a checkpoint and can directly execute CRaC startup. If the lock information is not occupied, it means that no instance has created a checkpoint, so the lock information can be sent to the first instance in the first device to avoid the duplicate creation of the checkpoint.

[0072] In other words, in response to the lock information not being occupied, the lock information is sent to the first device so that the first instance in the first device can create a checkpoint based on the lock information; in response to the lock information being occupied and the instance identifier corresponding to the lock information not being the instance identifier of the first instance, the lock read failure information is sent to the first device, and the lock read failure information instructs the first instance to execute CRaC startup.

[0073] In some implementations, when lock information is occupied and the instance identifier corresponding to the lock information is the instance identifier of the first instance, it can be determined whether there is a task completion file corresponding to the checkpoint snapshot, so as to monitor the timeliness of the lock information and improve the accuracy of lock information management.

[0074] In some implementations, if a corresponding task completion file exists for the checkpoint snapshot, it is determined that the first instance has already created a checkpoint, and the lock read process can be terminated; if no task completion file exists, the generation time of the lock information is determined, so as to monitor the timeliness of the lock information based on the generation time.

[0075] In some implementations, the timeliness of lock information can be determined based on the time interval between its generation time and the current time. If the time interval exceeds a set threshold, the lock information is deemed invalid. In response to detecting invalid lock information, the lock file is deleted, and the first instance is instructed to release the lock information so that it can be used by other instances for checkpoint creation.

[0076] In some implementations, before reading the lock information, it is necessary to determine whether the lock information exists in the lock file. If the lock information exists in the lock file, it is directly obtained from the lock file. If the lock information does not exist in the lock file, the lock generation function is called to generate the lock information and send the lock information to the first device to achieve secure access to the lock information.

[0077] S303, receive the instance identifier of the first instance sent by the first device, and write the instance identifier into the lock file.

[0078] In some implementations, to prevent instances in other devices from repeatedly creating checkpoints, the instance identifier of the first instance can be written into the lock file. This allows other instances to read the instance identifier of the first instance when they acquire the lock file, determine that the lock read has failed, and then execute CRaC startup.

[0079] S304, Obtain a checkpoint snapshot of the first instance startup phase sent by the first device. The checkpoint snapshot is a snapshot taken when the running state of the first instance meets the set conditions.

[0080] S305, Receive a snapshot request for the second instance sent by the second device.

[0081] S306, based on the snapshot request, send a checkpoint snapshot to the second device. The checkpoint snapshot includes relevant information required for the second instance to perform checkpoint coordination to resume CRaC startup.

[0082] The details of steps S304-S306 can be found in the above embodiments and will not be repeated here.

[0083] According to the microservice instance startup method provided in this disclosure, the distributed storage system receives a lock read request from a first device and sends lock information to the first device, enabling the first instance in the first device to create a checkpoint. The system then receives and stores a checkpoint snapshot of the first instance startup phase sent by the first device. By receiving a snapshot request from a second device, the system can send the checkpoint snapshot to the second device, enabling the second instance in the second device to perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching its optimal operating state. Before the first instance creates a checkpoint, obtaining lock information in the distributed storage system and creating the checkpoint based on that information avoids multiple instances repeatedly creating checkpoints, thus preventing resource waste.

[0084] Figure 4 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. This microservice instance startup method can be executed by a distributed storage system.

[0085] like Figure 4 As shown, the method for starting an instance of this microservice may include:

[0086] S401, Receive a process ID verification request sent by the first device. The process ID verification request includes the first process ID of the first instance that is creating a checkpoint.

[0087] S402, reads the second process number configured for creating checkpoints for the first instance from the CRaC file.

[0088] In some implementations, before obtaining the checkpoint snapshot from the first instance of the first device, it can be determined whether the checkpoint is created by the first instance based on the first process number of the first instance in the first device, thereby ensuring the legitimacy of the checkpoint creation.

[0089] In some implementations, since the checkpoint snapshot is stored in the distributed storage system after the instance creates the checkpoint, the distributed storage system can obtain the second process ID configured for the first instance to create the checkpoint based on the file associated with the checkpoint snapshot, such as the CRaC file.

[0090] In some implementations, a process ID verification request is received based on the first process ID of the first instance that is creating the checkpoint. The process ID verification request is parsed to obtain the first process ID. The first process ID and the second process ID are compared to determine whether the checkpoint was created by the first instance.

[0091] S403, in response to the first process number and the second process number being the same, sends a creation instruction for creating a checkpoint to the first device.

[0092] In some implementations, when the first process ID and the second process ID are determined to match, it can be determined that the first instance should create the checkpoint. By generating a creation instruction for the checkpoint and sending the creation instruction to the first device, the first instance in the first device can create the checkpoint. Allowing checkpoint creation only when the process IDs match avoids unnecessary resource consumption and waste.

[0093] In some implementations, when the first process ID and the second process ID are determined to be inconsistent, it can be determined that the first instance does not need to create a checkpoint and can start the instance. A third process ID is obtained from the recovery startup file, and its consistency with the first process ID is used to determine the startup type of the first instance. The startup type includes: recovery startup and normal startup. Optionally, a startup instruction can be sent directly to the first instance of the first device, eliminating the need for checkpoint creation, reducing microservice waiting time and resource consumption, and improving microservice response speed.

[0094] In other words, in response to a discrepancy between the first and second process IDs, the system reads the recovery startup file and determines whether the recovery startup file exists in order to obtain the third process ID from it. If the recovery startup file exists, the system identifies the third process ID recorded within it.

[0095] Further, it is determined whether the first process ID is consistent with the third process ID. If the first process ID and the third process ID are consistent, a recovery startup instruction is sent to the first device. If the recovery startup file does not exist or the first process ID and the third process ID are inconsistent, a normal startup instruction is sent to the first device.

[0096] S404, Obtain a checkpoint snapshot of the first instance startup phase sent by the first device. The checkpoint snapshot is a snapshot taken when the running state of the first instance meets the set conditions.

[0097] S405, Receive a snapshot request for the second instance sent by the second device.

[0098] S406, based on the snapshot request, send a checkpoint snapshot to the second device. The checkpoint snapshot includes relevant information required for the second instance to perform checkpoint coordination to restore CRaC startup.

[0099] The details of steps S404-S406 can be found in the above embodiments and will not be repeated here.

[0100] In some implementations, the distributed storage system can send a regular startup instruction or a CRaC startup instruction to a first or second device based on whether it stores the CRaC file. Optionally, by receiving a CRaC file read request sent by the first or second device when initiating CRaC startup, and responding to the absence of a CRaC file, a regular startup instruction is sent to the first or second device. When the CRaC file does not exist, the instance can perform a regular startup to ensure that the instance can start and run normally.

[0101] In some implementations, distributed storage systems can also store device startup information. Optionally, this can be done by receiving the CRaC startup process number sent by the first or second device after startup and writing it to a CRaC file. Alternatively, it can be done by receiving the CRaC recovery process number sent by the first or second device after recovery and writing it to a CRaC recovery file, thereby storing both the CRaC file and the CRaC recovery file. By recording the process numbers for CRaC startup and recovery, the state of each process can be accurately tracked and managed, ensuring that microservices operate more orderly and stably.

[0102] According to the microservice instance startup method provided in this disclosure, the distributed storage system can determine whether the first process ID of the first instance is consistent with the second process ID in the CRaC file before creating a checkpoint for the first instance. If they are consistent, the system sends a checkpoint creation instruction to the first device. Further, the system can receive and store a checkpoint snapshot of the first instance startup phase sent by the first device. By receiving a snapshot request from the second device, the system can send the checkpoint snapshot to the second device, enabling the second instance in the second device to perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching its optimal operating state. By determining whether the process IDs are consistent and only allowing checkpoint creation when the process IDs are consistent, unnecessary resource consumption and waste can be avoided.

[0103] Figure 5 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. The microservice instance startup method can be executed by a first device.

[0104] like Figure 5 As shown, the method for starting an instance of this microservice may include:

[0105] S501 monitors the running status of the first instance during the startup phase.

[0106] It should be noted that the execution entity of the microservice instance startup method in this embodiment can be a hardware device with data processing capabilities and / or the necessary software to drive the hardware device. Optionally, the execution entity may include a user terminal and other smart devices. Optionally, the user terminal includes, but is not limited to, mobile phones, computers, smart voice interaction devices, etc. This embodiment does not impose specific limitations. In this embodiment, the first device runs the first instance of the microservice.

[0107] In some implementations, during the creation of a checkpoint for the first instance, the first device can monitor the running status of the first instance during its startup phase and create a checkpoint when the running status reaches an optimal state. Optionally, reaching an optimal running status can mean that the running status meets set conditions.

[0108] Optionally, the first device can monitor the CPU utilization and response speed of the first instance to monitor the running status of the first instance.

[0109] In some implementations, before monitoring the running status of the first instance of a microservice during startup, the first device can also confirm whether the first instance has CRaC functionality. If it does have CRaC functionality, it can perform operations such as creating checkpoints on the first instance to save the checkpoint creation process and improve the efficiency of checkpoint creation.

[0110] Optionally, the first instance can be determined to have CRaC functionality by identifying the microservice's attribute information and then using that information. If the attribute information contains an identifier for CRaC functionality, the first instance is determined to have CRaC functionality; otherwise, the first instance does not have CRaC functionality.

[0111] S502, in response to the running state meeting the set conditions, obtain a checkpoint snapshot of the first instance when the running state meets the set conditions.

[0112] Optionally, the CPU utilization rate being less than the utilization rate threshold and the response speed being greater than the speed threshold can be used as the conditions for meeting the set conditions. That is, if the first device monitors that the CPU utilization rate of the first instance is less than the utilization rate threshold and the response speed is greater than the speed threshold, it determines that the running status of the first instance meets the set conditions. When the set conditions are met, the first instance creates a checkpoint and generates a checkpoint snapshot.

[0113] As is understandable, a checkpoint snapshot is a technique used in computer systems to save the complete state of a system or application at a specific point in time. Its main purpose is to enable quick restoration to the state of the most recent checkpoint in the event of a system failure or the need for recovery, thereby reducing data loss and recovery time.

[0114] In this embodiment of the disclosure, the checkpoint snapshot can save the optimal running state of the first instance so that the second instance can run directly to the optimal running state, thereby reducing the instance startup time.

[0115] S503, send a checkpoint snapshot to the distributed storage system. The checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0116] In some implementations, once the first device obtains a checkpoint snapshot of the first instance, it can send the checkpoint snapshot to the distributed storage system. Alternatively, a checkpoint snapshot can be generated based on the relevant information required to perform CRaC startup, and then sent to the distributed storage system.

[0117] According to the microservice instance startup method provided in this disclosure embodiment, the first device monitors the running status of the first instance and obtains a checkpoint snapshot of the first instance when the running status meets the set conditions, so as to send the checkpoint snapshot to the distributed storage system, so that the second instance in the second device can obtain the checkpoint snapshot from the distributed storage system and execute CRaC startup, thereby improving the startup speed of the second instance and quickly reaching the optimal running status.

[0118] Figure 6 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. The microservice instance startup method can be executed by a first device.

[0119] like Figure 6 As shown, the method for starting an instance of this microservice may include:

[0120] S601 monitors the running status of the first instance during the startup phase.

[0121] The details of step S601 can be found in the above embodiments and will not be repeated here.

[0122] S602, in response to the running state meeting the set conditions, obtain the running parameters of the first instance when the running state meets the set conditions.

[0123] In some implementations, when the running state of the first instance meets the set conditions, the memory usage information, configuration information, etc. of the first instance can be obtained as running parameters of the first instance when the running state meets the set conditions.

[0124] S603 determines checkpoint snapshots based on running parameters and JIT information.

[0125] In some implementations, when the first instance is in the startup phase, an encoding service can be used to warm up the first instance and obtain its compilation results. Optionally, the first instance can be warmed up when it is determined to start up, in order to improve its response speed.

[0126] In other words, in response to the startup operation of the first instance, the key classes and resources of the first instance are preloaded and initialized based on the object-oriented programming language virtual machine (Java Virtual Machine, JVM) so that the first instance can find and load the required key classes and resources more quickly when it starts up, thereby reducing the time required for class loading.

[0127] Furthermore, after the first instance starts up, it is compiled using Just-In-Time (JIT) to obtain its JIT information. JIT compilation allows frequently accessed code to be compiled into efficient machine code at runtime, significantly reducing the overhead of interpreted execution and improving program execution speed.

[0128] In some implementations, the JIT information of the first instance can be obtained through the above steps, and the runtime parameters and JIT information can be used as a checkpoint snapshot of the first instance. This ensures that the checkpoint snapshot can preserve the optimal running state of the first instance. Optionally, after obtaining the checkpoint snapshot of the first instance, it can be saved in the instance container. When the first instance fails or needs to be rolled back to a specific state, it can be directly restored from the checkpoint snapshot, greatly shortening the recovery time.

[0129] S604, send a checkpoint snapshot to the distributed storage system. The checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0130] The details of step S604 can be found in the above embodiments and will not be repeated here.

[0131] According to the microservice instance startup method provided in this disclosure embodiment, the first device monitors the running status of the first instance and obtains the running parameters and JIT information of the first instance as a checkpoint snapshot when the running status meets the set conditions, so as to send the checkpoint snapshot to the distributed storage system, so that the second instance in the second device can obtain the checkpoint snapshot from the distributed storage system and execute CRaC startup, thereby improving the startup speed of the second instance and quickly reaching the optimal running status.

[0132] Figure 7 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. The microservice instance startup method can be executed by a first device.

[0133] like Figure 7 As shown, the method for starting an instance of this microservice may include:

[0134] S701 monitors the running status of the first instance during the startup phase.

[0135] The details of step S701 can be found in the above embodiments and will not be repeated here.

[0136] S702, in response to the operating state meeting the set conditions, sends a read lock request to the distributed storage system.

[0137] In some implementations, when the running state of the first instance meets the set conditions, it is necessary to obtain lock information from the distributed storage system and create a checkpoint based on the lock information to avoid multiple instances repeatedly creating checkpoints, thus avoiding waste of resources.

[0138] In some implementations, a read lock request can be sent to the distributed storage system only after the first instance has completed its warm-up process. Once the first instance has warmed up, its internal resources have been fully initialized and optimized, making the use of these resources more efficient and improving the efficiency of checkpoint creation.

[0139] Optionally, JVM preloading and JIT execution can be used to warm up the first instance. The warm-up duration is obtained to determine whether warm-up is complete; that is, by obtaining the cumulative time of JVM and JIT execution on the first instance, a read lock request is sent to the distributed storage system if the cumulative duration does not exceed a set time.

[0140] Optionally, in response to the cumulative duration exceeding a set duration, CRaC startup is performed on the first instance. That is, if the first instance has not completed warm-up, and it is determined that an instance has completed checkpoint creation, the first instance can directly perform CRaC startup.

[0141] In some implementations, before the first device obtains lock information from the distributed storage system, it can also determine whether it can obtain lock information from the distributed storage system based on the process ID of the first instance. If the process IDs are consistent, it can indicate that a checkpoint can be created, thereby obtaining lock information from the distributed storage system. This avoids wasting resources by creating checkpoints due to inconsistent process IDs.

[0142] Optionally, a process ID verification request can be sent to the distributed storage system. The process ID verification request includes the first process ID of the first instance that is creating the checkpoint, and the distributed storage system verifies the first process ID. The verification process can be referred to the above embodiments, and will not be repeated here.

[0143] Furthermore, the first device can receive a creation instruction for creating a checkpoint sent by the distributed storage system. The creation instruction is sent when the first process ID and the second process ID are verified to be consistent, so as to create a checkpoint according to the creation instruction.

[0144] Optionally, a checkpoint is created when the first process ID and the second process ID are the same; when the first process ID and the second process ID are different, the first instance is restarted or started normally without the need for checkpoint creation, which reduces the waiting time and resource consumption of microservices and improves the response speed of microservices.

[0145] In other words, the first device can receive a recovery startup instruction or a normal startup instruction sent by the distributed storage system. The recovery startup instruction or the normal startup instruction is sent when it is verified that the first process ID and the second process ID are inconsistent.

[0146] S703 receives lock information sent by the distributed storage system and sends the instance identifier of the first instance to the distributed storage system.

[0147] In some implementations, the first device receives lock information from the distributed storage system, and the first instance can create a checkpoint based on the lock information. After the first instance completes the checkpoint creation, it sends the instance identifier of the first instance to the distributed storage system to prevent instances in other devices from creating checkpoints repeatedly.

[0148] In some implementations, when the first device sends a read lock request to the distributed storage system, if the lock information in the distributed storage system is already occupied and the instance identifier corresponding to the lock information is not the instance identifier of the first instance, it can receive a read lock failure message sent by the distributed storage system. The read lock failure message instructs the first instance to execute CRaC startup, thereby avoiding the first instance from repeatedly creating checkpoints.

[0149] In some implementations, after the first device sends a read lock request to the distributed storage system, the distributed storage system can also determine the timeliness of the lock information. The process of determining the timeliness of the lock information can be found in the above embodiments and will not be repeated here. When the distributed storage system determines that the lock information is invalid, the first device can receive the invalid lock information indication sent by the distributed storage system and release the lock information so that the lock information can be used by other instances to create checkpoints.

[0150] S704, Obtain a checkpoint snapshot of the first instance when the running status meets the set conditions.

[0151] S705 sends a checkpoint snapshot to the distributed storage system. The checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0152] The details of steps S704-S705 can be found in the above embodiments and will not be repeated here.

[0153] According to the microservice instance startup method provided in this disclosure embodiment, the first device monitors the running status of the first instance and, when the running status meets the set conditions, obtains lock information from the distributed storage system to create a checkpoint based on the lock information, and obtains a checkpoint snapshot of the first instance to send the checkpoint snapshot to the distributed storage system, so that the second instance in the second device can obtain the checkpoint snapshot from the distributed storage system and execute CRaC startup, thereby improving the startup speed of the second instance and quickly reaching the optimal running state.

[0154] Figure 8 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. The microservice instance startup method can be executed by a first device.

[0155] like Figure 8 As shown, the method for starting an instance of this microservice may include:

[0156] S801 monitors the running status of the first instance during the startup phase.

[0157] The details of step S801 can be found in the above embodiments and will not be repeated here.

[0158] S802, in response to the running state meeting the set conditions, determines the consumption that is in progress when the checkpoint is created, and terminates the ongoing consumption.

[0159] In some implementations, ongoing consumption on the first instance can be terminated before a checkpoint is created to prevent duplicate consumption after the first instance recovers. Optionally, probes can be used to monitor consumption to determine what is in progress when the checkpoint is created. Optionally, requests can also be monitored, and detected requests can be used as ongoing consumption.

[0160] In other words, a probe can be used to intercept and monitor the thread's execution function to obtain the runnable tasks of the first instance, where the runnable tasks are those currently being consumed. Furthermore, the runnable tasks can be terminated in the callback function before the checkpoint is created via the target interface.

[0161] Alternatively, a probe can be used to enhance the target interface so that the target interface terminates the runnable task in the callback function to avoid duplicate consumption after the first instance recovers.

[0162] In some implementations, web requests can be listened to, and the listening for web requests can be stopped before a checkpoint is created. The response message corresponding to the web request is returned, where the listened web request is being consumed in progress to prevent the request from being processed repeatedly after recovery from the checkpoint snapshot.

[0163] In some implementations, the file or connection pointed to by the file descriptor may change before a checkpoint snapshot is created. To avoid unexpected situations caused by changes or heterogeneity in the content of resources such as files or connections, resulting in the resource not existing on the instance, the resource pointed to by the file descriptor can be closed.

[0164] Optionally, by obtaining the file descriptor of the current process of the microservice and determining the resource path pointed to by the file descriptor, the relevant resources of the current process of the microservice can be closed according to the resource path.

[0165] S803, obtain the checkpoint snapshot of the first instance when the running status meets the set conditions.

[0166] S804, send a checkpoint snapshot to the distributed storage system. The checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0167] The relevant content of steps S803-S804 can be found in the above embodiments, and will not be repeated here.

[0168] According to the microservice instance startup method provided in this disclosure, the first device monitors the running status of the first instance and terminates ongoing consumption on the first instance before obtaining a checkpoint snapshot of the first instance, in order to avoid duplicate consumption after service recovery. Then, after consumption is terminated, the checkpoint snapshot is sent to the distributed storage system, so that the second instance in the second device can obtain the checkpoint snapshot from the distributed storage system and perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching its optimal running state.

[0169] Figure 9 This is a flowchart illustrating a microservice instance startup method provided in an embodiment of the present disclosure. This microservice instance startup method can be executed by a second device.

[0170] like Figure 9 As shown, the method for starting an instance of this microservice may include:

[0171] S901, Obtain the checkpoint snapshot corresponding to the first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0172] It should be noted that the execution entity of the microservice instance startup method in this embodiment can be a hardware device with data processing capabilities and / or the necessary software to drive the hardware device. Optionally, the execution entity may include a user terminal and other smart devices. Optionally, the user terminal includes, but is not limited to, mobile phones, computers, smart voice interaction devices, etc. This embodiment does not impose specific limitations. In this embodiment, the second device runs a second instance of the microservice.

[0173] In some implementations, in order to allow the second instance to directly enter the optimal operating state and save startup time, the second device can obtain the checkpoint snapshot corresponding to the first instance from the distributed storage system and determine the relevant information required for the second instance to perform CRaC startup from the checkpoint snapshot.

[0174] In some implementations, before retrieving the checkpoint snapshot from the distributed storage system, it can be determined whether a checkpoint snapshot exists within the instance container. In response to the existence of a checkpoint snapshot within the instance container, the checkpoint snapshot is read from the instance container, thus saving time in retrieving the checkpoint snapshot and reducing unnecessary network transmission.

[0175] Optionally, in response to the absence of a checkpoint snapshot within the instance container, a snapshot request is sent to the distributed storage system, and a checkpoint snapshot is received from the distributed storage system.

[0176] S902, based on the checkpoint snapshot, performs CRaC startup on the second instance.

[0177] In some implementations, once the second device obtains the checkpoint snapshot, it can perform CRaC startup on the second instance, so that the second instance can directly run to the running state when the first instance created the checkpoint snapshot, saving the running time of the second instance and thus saving the startup time of the microservice.

[0178] In some implementations, in order to accurately track and manage the process status of each instance and ensure that the microservices run more orderly and stably, CRaC can be started or resumed on a second instance, and the process ID can be sent to the distributed storage system.

[0179] In other words, the CRaC startup process ID can be sent to the distributed storage system and written to the CRaC file. Alternatively, the CRaC recovery process ID can be sent to the distributed storage system and written to the CRaC recovery file.

[0180] In some implementations, the first device can also confirm whether the second instance has CRaC functionality, and if it does, perform operations such as obtaining checkpoint snapshots on the second instance to save the checkpoint snapshot acquisition process and improve the efficiency of obtaining checkpoint snapshots.

[0181] Optionally, the system can determine whether a microservice has CRaC functionality based on its attribute information. If the attribute information contains an identifier for CRaC functionality, the second instance is determined to have CRaC functionality; otherwise, the second instance does not have CRaC functionality.

[0182] In some implementations, in order to adapt instance information when starting microservices using checkpoint snapshots, support the recovery of microservices on heterogeneous instances based on the same checkpoint snapshot, and ensure the consistency of microservice operation logic after recovery while implementing multi-instance distribution, CRaC startup can be performed based on the environment information of the second instance.

[0183] Optionally, the environment information of the second instance can be obtained through a startup script. Further, the environment information is written to environment variables via middleware, and CRaC startup is performed based on the environment variables and checkpoint snapshot. The environment information includes, but is not limited to: Internet Protocol (IP), service port, instance name, etc.

[0184] In some implementations, once CRaC has finished starting or recovering, the relevant resources of the second instance can be written into the resource path of the second instance to ensure that the second instance can access the correct resource path after startup or recovery, thereby maintaining data consistency.

[0185] Optionally, after CRaC startup or recovery is complete, it is determined whether a resource path exists for the second instance. If a resource path exists, the relevant resources of the second instance are appended and written to the resource path; if a resource path does not exist, a new file is created based on the resource path, and the relevant resources of the second instance are written to the new file.

[0186] In other words, when using checkpoint snapshots to restore the process, relevant resources are written. For log files in append-only mode, the existence of the source path is first checked. If it exists, writing is done in append mode; if it does not exist, a new file is created in the same path and writing begins from the beginning. For other file types, to avoid unexpected situations caused by changes in file content, read and write operations are only performed if the file exists; if the file does not exist, an exception is thrown. For remote connections, such as Hypertext Transfer Protocol (HTTP) connections and database connections, the middleware can be modified to rebuild the connection after recovery.

[0187] According to the microservice instance startup method provided in this disclosure embodiment, the second device obtains the checkpoint snapshot corresponding to the first instance, and performs CRaC startup on the second instance of the microservice running on the second device based on the checkpoint snapshot, so that the second instance directly runs to the running state when the first instance created the checkpoint snapshot, saving the running time of the second instance, thereby saving the startup time of the microservice.

[0188] Exemplary illustration, such as Figure 10 The diagram illustrates the creation and distribution of checkpoint snapshots. Figure 10 In this example, instance 1 is the first instance, and instances 2 through n are the second instances. Instance 1 creates a checkpoint snapshot when its running state meets set conditions and synchronizes the checkpoint snapshot to the distributed storage system. Further, instances 2 through n send snapshot requests to the distributed storage system to obtain the checkpoint snapshot corresponding to instance 1, thus enabling instances to pull the checkpoint snapshot from the distributed storage system and perform CRaC startup based on the checkpoint snapshot.

[0189] Figure 11 This diagram illustrates the process of creating a checkpoint. Taking the first instance as an example, it checks whether the first instance has CRaC functionality. If it does not, the first instance proceeds with a normal startup. If it does have CRaC functionality, it reads the second process ID configured for creating the checkpoint from the CRaC file. If the second process ID does not exist in the CRaC file, the first instance proceeds with a normal startup. Otherwise, it checks whether the first process ID and the second process ID of the first instance are consistent. If they are inconsistent, it reads the recovery startup file and, if the recovery startup file exists, determines the third process ID recorded in it. Further, it checks whether the first process ID and the third process ID are consistent. If they are consistent, the first instance proceeds with a recovery startup. If the recovery startup file does not contain the third process ID, or if the first process ID and the third process ID are inconsistent, the first instance proceeds with a normal startup.

[0190] Furthermore, the warm-up time of the first instance is obtained, and if the warm-up time does not exceed the set time (120 seconds), it is determined that the first instance has completed warm-up and a read lock request is sent to the distributed storage system. If the warm-up time exceeds 120 seconds, it is determined that the first instance executes CRaC startup.

[0191] Furthermore, the first instance can send a read lock request to the distributed storage system to obtain lock information from the lock file. If the lock information does not exist in the lock file, the lock generation function is called to generate lock information and send it to the first instance, further writing the instance identifier of the first instance into the lock file. If the lock information exists in the lock file, but the instance identifier corresponding to the lock information is not the instance identifier of the first instance, then it is determined that the first instance executes CRaC startup. If the lock information exists in the lock file, and the instance identifier corresponding to the lock information is the instance identifier of the first instance, it continues to determine whether there is a task completion file corresponding to the checkpoint snapshot. If there is no task completion file, the generation time of the lock information is determined, and the timeliness of the lock information is monitored based on the generation time. The timeliness of the lock information is determined based on the time interval between the generation time of the lock information and the current time. If the time interval is greater than the set interval threshold, the lock information is determined to be invalid, and then the lock file is deleted and the first instance is instructed to release the lock information so that the lock information can be used by other instances to create checkpoints.

[0192] Furthermore, after writing the instance identifier of the first instance into the lock file, operations such as graceful shutdown can be performed on the first instance to terminate the ongoing consumption of the first instance, thereby completing the creation of the checkpoint snapshot, storing the completed task completion file, and ending the checkpoint creation process.

[0193] like Figure 12 The diagram illustrates the process of distributing checkpoint snapshots. Taking the second instance as an example, it determines whether the second instance has CRaC functionality. If it does not, the second instance proceeds with a normal startup. If it does have CRaC functionality, it checks if a task completion file exists in the distributed storage server. If not, it checks if the second instance has a probe enabled. If the probe is enabled, the second instance proceeds with a CRaC startup and checks if the CRaC startup was successful. If the startup is successful, the second instance's process is written to the CRaC file. If the second instance does not have a probe enabled, or if the CRaC startup fails, the second instance proceeds with a normal startup.

[0194] If a task completion file exists in the distributed storage server, the first verification information corresponding to the checkpoint snapshot is obtained from the task completion file, and the second verification information is determined. The checkpoint snapshot can then be verified based on the first and second verification information. If verification fails, the time interval between the timestamp of the task completion file and the current timestamp is used to determine whether the checkpoint snapshot can be re-verified.

[0195] If the time interval is less than 5 minutes, wait 6 seconds and re-verify the checkpoint snapshot. If it still fails verification, continue to verify until the number of verifications exceeds 10. Then, end the verification process. If the checkpoint snapshot fails verification, start the second instance normally.

[0196] After the checkpoint snapshot passes verification, the second instance is determined to perform CRaC startup, and it is determined whether the CRaC startup is successful. If the startup is successful, the process of the second instance is written to the CRaC file; otherwise, the second instance is determined to perform normal startup.

[0197] Corresponding to the microservice instance startup methods provided in the above embodiments, one embodiment of this disclosure also provides a microservice instance startup device. Since the microservice instance startup device provided in this disclosure corresponds to the microservice instance startup methods provided in the above embodiments, the implementation methods of the above microservice instance startup methods are also applicable to the microservice instance startup device provided in this disclosure, and will not be described in detail in the following embodiments.

[0198] Figure 13 This is a schematic diagram of the structure of a microservice instance startup device provided in an embodiment of this disclosure.

[0199] like Figure 13 As shown, the microservice instance launch device 1300 of this disclosure includes an acquisition module 1301, a receiving module 1302 and a sending module 1303.

[0200] The acquisition module 1301 is used to acquire a checkpoint snapshot of the first instance startup phase sent by the first device. The checkpoint snapshot is a snapshot when the running state of the first instance meets the set conditions.

[0201] The receiving module 1302 is used to receive a snapshot request for the second instance sent by the second device;

[0202] The sending module 1303 is used to send a checkpoint snapshot to the second device according to the snapshot request. The checkpoint snapshot includes relevant information required by the second instance to perform checkpoint coordination to restore CRaC startup.

[0203] In one embodiment of this disclosure, the sending module 1303 is further configured to: verify the checkpoint snapshot according to the snapshot request; send the checkpoint snapshot to the second device in response to passing the verification; obtain the timestamp of the task completion file corresponding to the checkpoint snapshot in response to failing the verification; and wait for the set time period in response to the time interval between the timestamp and the current time not exceeding the set time period, and then re-verify the checkpoint snapshot until the number of verifications exceeds the set number of times.

[0204] In one embodiment of this disclosure, the sending module 1303 is further configured to: obtain a task completion file corresponding to the checkpoint snapshot, and obtain first verification information corresponding to the checkpoint snapshot from the task completion file; determine second verification information based on the checkpoint snapshot; and verify the checkpoint snapshot based on the first verification information and the second verification information.

[0205] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: receive a read lock request sent by a first device; determine lock information from a lock file; send lock information to the first device in response to the lock information not being occupied; receive an instance identifier of a first instance sent by the first device and write the instance identifier into the lock file; and send read lock failure information to the first device in response to the lock information being occupied and the instance identifier corresponding to the lock information not being the instance identifier of the first instance, wherein the read lock failure information instructs the first instance to execute CRa.

[0206] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: in response to the absence of lock information in the lock file, call the lock generation function to generate lock information and send the lock information to the first device.

[0207] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: determine whether a task completion file corresponding to a checkpoint snapshot exists; in response to the absence of a task completion file, determine the generation time of the lock information; monitor the timeliness of the lock information based on the generation time; and in response to the detection that the lock information is invalid, delete the lock file and instruct the first instance to release the lock information.

[0208] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: receive a process ID verification request sent by a first device, the process ID verification request including a first process ID of the first instance creating a checkpoint; read a second process ID configured for creating a checkpoint for the first instance from a CRaC file; and, in response to the first process ID and the second process ID being consistent, send a creation instruction for creating a checkpoint to the first device.

[0209] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: read a recovery startup file in response to a discrepancy between the first process ID and the second process ID; determine a third process ID recorded in the recovery startup file in response to the existence of the recovery startup file; send a recovery startup instruction to the first device in response to a discrepancy between the first process ID and the third process ID; and send a regular startup instruction to the first device in response to at least one of a lack of a recovery startup file or a discrepancy between the first process ID and the third process ID.

[0210] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: receive a CRaC file read request sent by the first device or the second device when enabling CRaC startup, and send a normal startup instruction to the first device or the second device in response to the absence of a CRaC file.

[0211] In one embodiment of this disclosure, the acquisition module 1301 is further configured to: receive the CRaC startup process number sent by the first device or the second device after startup is completed, and write it into the CRaC file; or, receive the CRaC recovery process number sent by the first device or the second device after recovery is completed, and write it into the CRaC recovery file.

[0212] According to the microservice instance startup apparatus provided in this disclosure, the distributed storage system receives a checkpoint snapshot of the first instance startup phase sent by a first device and stores the checkpoint snapshot. By receiving a snapshot request sent by a second device, the checkpoint snapshot can be sent to the second device, enabling the second instance in the second device to perform CRaC startup, thereby improving the startup speed of the second instance and quickly reaching its optimal operating state. The distributed storage system can also support the rapid deployment and startup of large-scale instances, thereby significantly saving the deployment time of microservices, ensuring that microservices reach their optimal operating state in the shortest possible time, and guaranteeing the consistency of instance operating logic.

[0213] Figure 14 This is a schematic diagram of the structure of a microservice instance startup device provided in an embodiment of this disclosure.

[0214] like Figure 14 As shown, the microservice instance startup device 1400 of this embodiment includes a monitoring module 1401, an acquisition module 1402, and a sending module 1403.

[0215] The monitoring module 1401 is used to monitor the running status of the first instance during the startup phase;

[0216] The acquisition module 1402 is used to acquire a checkpoint snapshot of the first instance when the running state meets the set conditions in response to the running state meeting the set conditions.

[0217] Sending module 1403 is used to send a checkpoint snapshot to the distributed storage system. The checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

[0218] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: in response to the startup operation of the first instance, preload and initialize the key classes and resources of the first instance based on the object-oriented programming language virtual machine JVM; and after the first instance is started, perform just-in-time (JIT) compilation on the first instance to obtain the JIT information of the first instance.

[0219] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: acquire the running parameters of the first instance when the running state meets the set conditions; and determine the checkpoint snapshot based on the running parameters and JIT information.

[0220] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: send a read lock request to the distributed storage system; receive lock information sent by the distributed storage system and send an instance identifier of the first instance to the distributed storage system; receive read lock failure information sent by the distributed storage system, wherein the read lock failure information instructs the first instance to execute CRaC startup; receive an invalidation indication of the lock information sent by the distributed storage system and release the lock information.

[0221] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: acquire the cumulative execution time of the first instance's JVM and JIT; in response to the cumulative execution time not exceeding a set time, send a read lock request to the distributed storage system; and in response to the cumulative execution time exceeding the set time, execute CRaC startup on the first instance.

[0222] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: send a process ID verification request to the distributed storage system, the process ID verification request including the first process ID of the first instance creating a checkpoint; and receive a creation instruction for creating a checkpoint sent by the distributed storage system, the creation instruction being sent when the first process ID and the second process ID are verified to be consistent.

[0223] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: receive a recovery startup instruction or a normal startup instruction sent by the distributed storage system, wherein the recovery startup instruction or the normal startup instruction is sent when it is verified that the first process ID and the second process ID are inconsistent.

[0224] In one embodiment of this disclosure, the monitoring module 1401 is further configured to: determine the attribute information of the microservice, and determine whether the first instance has CRaC functionality based on the attribute information.

[0225] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: determine the consumption in progress when the checkpoint is created, and terminate the ongoing consumption.

[0226] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: intercept and listen to the thread running function through a probe to acquire the runnable task of the first instance, wherein the runnable task is the ongoing consumption; and terminate the runnable task in a callback function before the creation of the checkpoint through the target interface.

[0227] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: listen for web requests; terminate the listening for web requests before creating a checkpoint, and return a response message corresponding to the web request, wherein the listened web request is an ongoing consumption.

[0228] In one embodiment of this disclosure, the acquisition module 1402 is further configured to: acquire the file descriptor of the current process of the microservice and determine the resource path pointed to by the file descriptor; and close the relevant resources of the current process of the microservice according to the resource path.

[0229] According to the microservice instance startup apparatus provided in this disclosure embodiment, the first device monitors the running status of the first instance and obtains a checkpoint snapshot of the first instance when the running status meets the set conditions, so as to send the checkpoint snapshot to the distributed storage system, so that the second instance in the second device can obtain the checkpoint snapshot from the distributed storage system and execute CRaC startup, thereby improving the startup speed of the second instance and quickly reaching the optimal running status.

[0230] Figure 15 This is a schematic diagram of the structure of a microservice instance startup device provided in an embodiment of this disclosure.

[0231] like Figure 15 As shown, the microservice instance startup device 1500 of this disclosure includes an acquisition module 1501 and a startup module 1502.

[0232] The acquisition module 1501 is used to acquire the checkpoint snapshot corresponding to the first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup;

[0233] Startup module 1502 is used to perform CRaC startup on the second instance based on checkpoint snapshots.

[0234] In one embodiment of this disclosure, the acquisition module 1501 is further configured to: determine whether a checkpoint snapshot exists in the instance container; in response to the existence of a checkpoint snapshot in the instance container, read the checkpoint snapshot from the instance container; in response to the absence of a checkpoint snapshot in the instance container, send a snapshot acquisition request to the distributed storage system and receive the checkpoint snapshot sent by the distributed storage system.

[0235] In one embodiment of this disclosure, the apparatus further includes: sending a CRaC startup process number to the distributed storage system and writing it into a CRaC file; or sending a CRaC recovery process number to the distributed storage system and writing it into a CRaC recovery file.

[0236] In one embodiment of this disclosure, the apparatus further includes: determining attribute information of the microservice, and determining whether it has CRaC functionality based on the attribute information.

[0237] In one embodiment of this disclosure, the apparatus further includes: a startup script to obtain environment information of the second instance; writing the environment information into environment variables through middleware; and performing CRaC startup based on the environment variables and checkpoint snapshots.

[0238] In one embodiment of this disclosure, the apparatus further includes: determining whether a resource path exists for the second instance after CRaC startup or recovery is complete; in response to the existence of a resource path, appending and writing relevant resources of the second instance to the resource path; and in response to the absence of a resource path, creating a new file based on the resource path and writing relevant resources of the second instance into the new file.

[0239] According to the microservice instance startup apparatus provided in this disclosure embodiment, the second device obtains the checkpoint snapshot corresponding to the first instance, and performs CRaC startup on the second instance of the microservice running on the second device based on the checkpoint snapshot, so that the second instance directly runs to the running state when the first instance created the checkpoint snapshot, saving the running time of the second instance, thereby saving the startup time of the microservice.

[0240] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0241] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0242] Figure 16 A schematic block diagram of an example electronic device 1600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0243] like Figure 16As shown, device 1600 includes a computing unit 1601, which can perform various appropriate actions and processes based on computer programs / instructions stored in read-only memory (ROM) 1602 or loaded from storage unit 1606 into random access memory (RAM) 1603. RAM 1603 may also store various programs and data required for the operation of device 1600. The computing unit 1601, ROM 1602, and RAM 1603 are interconnected via bus 1604. Input / output (I / O) interface 1605 is also connected to bus 1604.

[0244] Multiple components in device 1600 are connected to I / O interface 1605, including: input units 1606 such as keyboard, mouse, etc.; output units 1607 such as various types of displays, speakers, etc.; storage units 1608 such as disks, optical disks, etc.; and communication units 1609 such as network cards, modems, wireless transceivers, etc. Communication unit 1609 allows device 1600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0245] The computing unit 1601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1601 performs the various methods and processes described above, such as the microservice instance startup method. For example, in some embodiments, the microservice instance startup method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1606. In some embodiments, part or all of the computer program / instructions can be loaded and / or installed on device 1600 via ROM 1602 and / or communication unit 1609. When the computer program / instructions are loaded into RAM 1603 and executed by the computing unit 1601, one or more steps of the microservice instance startup method described above can be performed. Alternatively, in other embodiments, computing unit 1601 may be configured to execute microservice instance startup methods by any other suitable means (e.g., by means of firmware).

[0246] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include: implementations in one or more computer programs / instructions that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0247] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0248] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0249] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0250] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0251] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. The client-server relationship is created by computer programs / instructions running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0252] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in the disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this document does not impose any restrictions.

[0253] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method of starting an instance of a microservice, wherein, The method is executed by a distributed storage system, and the method comprises: receiving a read lock request sent by a first device, determining lock information from a lock file; in response to the lock information not being occupied, sending the lock information to the first device; receiving an instance identifier of a first instance sent by the first device, and writing the instance identifier into the lock file; in response to the lock information being occupied and the instance identifier corresponding to the lock information being different from an instance identifier of the first instance, sending read lock failure information to the first device, the read lock failure information indicating that the first instance performs CRaC starting; obtaining a checkpoint snapshot of a starting stage of the first instance sent by the first device, the checkpoint snapshot being a snapshot when a running state of the first instance meets a set condition; receiving a snapshot request of a second instance sent by a second device; in accordance with the snapshot request, sending the checkpoint snapshot to the second device, the checkpoint snapshot comprising relevant information required for the second instance to perform checkpoint coordinated recovery (CRaC) starting.

2. The method of claim 1, wherein, The method further comprises: verifying the checkpoint snapshot in accordance with the snapshot request; in response to passing the verification, sending the checkpoint snapshot to the second device; in response to failing the verification, obtaining a timestamp of a task completion file corresponding to the checkpoint snapshot; in response to a time interval between the timestamp and a current time not exceeding a set time length, waiting for a set time length, and then re-verifying the checkpoint snapshot until a verification number exceeds a set number.

3. The method of claim 2, wherein, The verifying the checkpoint snapshot in accordance with the snapshot request comprises: obtaining a task completion file corresponding to the checkpoint snapshot, and obtaining first verification information corresponding to the checkpoint snapshot from the task completion file; determining second verification information in accordance with the checkpoint snapshot; verifying the checkpoint snapshot in accordance with the first verification information and the second verification information.

4. The method of claim 1, wherein, The method further comprises: in response to the lock information not existing in the lock file, calling a lock generation function to generate the lock information, and sending the lock information to the first device.

5. The method of claim 1, wherein, The method further comprises: determining whether a task completion file corresponding to the checkpoint snapshot exists; in response to the task completion file not existing, determining a generation time of the lock information; monitoring the timeliness of the lock information based on the generation time; in response to monitoring that the lock information is invalid, deleting the lock file and instructing the first instance to release the lock information.

6. The method of any one of claims 1-5, wherein, Before the obtaining the checkpoint snapshot of the starting stage of the first instance sent by the first device, the method further comprises: receiving a process number verification request sent by the first device, the process number verification request comprising a first process number of the first instance creating a checkpoint; reading a second process number configured for the first instance to create a checkpoint from a CRaC file; in response to the first process number being consistent with the second process number, sending a creation instruction of creating a checkpoint to the first device.

7. The method of claim 6, wherein, The method further comprises: in response to the first process number being inconsistent with the second process number, reading a recovery starting file; in response to the existence of the recovery start file, determining a third process number recorded in the recovery start file; in response to the first process number and the third process number being consistent, sending a recovery start instruction to the first device; in response to at least one of the non-existence of the recovery start file and the inconsistency between the first process number and the third process number, sending a normal start instruction to the first device.

8. The method of any one of claims 1-5, wherein, The method further comprises: receiving a CRaC file reading request sent by the first device or the second device when starting the CRaC start, and in response to the non-existence of the CRaC file, sending a normal start instruction to the first device or the second device.

9. The method of any one of claims 1-5, wherein, The method further comprises: receiving a CRaC start process number sent by the first device or the second device after the start is completed, and writing the CRaC start process number into a CRaC file; or receiving a CRaC recovery process number sent by the first device or the second device after the recovery is completed, and writing the CRaC recovery process number into a CRaC recovery file.

10. A method of starting an instance of a microservice, wherein, The method is performed by a first device running a first instance of a microservice, and the method comprises: monitoring a running state of a start phase of the first instance; in response to the running state satisfying a set condition, sending a read lock request to a distributed storage system; receiving lock information sent by the distributed storage system, and sending an instance identifier of the first instance to the distributed storage system; receiving read lock failure information sent by the distributed storage system, the read lock failure information indicating that the first instance performs a CRaC start; receiving an invalid indication of the lock information sent by the distributed storage system, and releasing the lock information; obtaining a checkpoint snapshot of the first instance when the running state satisfies the set condition; sending the checkpoint snapshot to a distributed storage system, the checkpoint snapshot comprising relevant information required for a second instance to perform a CRaC start.

11. The method of claim 10, wherein, Before the checkpoint snapshot of the first instance when the running state satisfies the set condition is obtained, the method comprises: in response to a start operation of the first instance, preloading and initializing key classes and resources of the first instance based on a Java virtual machine (JVM) of an object-oriented programming language; after the start of the first instance is completed, performing just-in-time (JIT) compilation on the first instance to obtain JIT information of the first instance.

12. The method of claim 10, wherein, The checkpoint snapshot of the first instance when the running state satisfies the set condition is obtained by: obtaining running parameters of the first instance when the running state satisfies the set condition; determining the checkpoint snapshot according to the running parameters and the JIT information.

13. The method of claim 10, wherein, The read lock request sent to the distributed storage system comprises: obtaining a cumulative duration of the execution of the JVM and the JIT by the first instance, and in response to the cumulative duration being less than a set duration, sending a read lock request to the distributed storage system; in response to the cumulative duration being greater than the set duration, performing a CRaC start on the first instance.

14. The method of any one of claims 10-13, wherein, The method further comprises: sending a process number verification request to the distributed storage system, the process number verification request comprising a first process number of the first instance that is creating a checkpoint; receiving a creation instruction of creating a checkpoint sent by the distributed storage system, the creation instruction being sent when it is verified that the first process number and the second process number are consistent.

15. The method of claim 14, wherein, The method further comprises: receiving a recovery start instruction or a regular start instruction sent by the distributed storage system, the recovery start instruction or the regular start instruction being sent when it is verified that the first process number and the second process number are inconsistent.

16. The method of any one of claims 10-13, wherein, Before the monitoring of the running state of the first instance start phase, the method further comprises: determining attribute information of the microservice, and determining whether the first instance has a CRaC function according to the attribute information.

17. The method of any one of claims 10-13, wherein, Before the obtaining of the checkpoint snapshot of the first instance when the running state meets a set condition, the method further comprises: determining an ongoing consumption when a checkpoint is created, and terminating the ongoing consumption.

18. The method of claim 17, wherein, The determining of the ongoing consumption when a checkpoint is created, and the terminating of the ongoing consumption, comprises: intercepting and monitoring a thread running function through a probe to obtain a runnable task of the first instance, wherein the runnable task is the ongoing consumption; terminating the runnable task in a callback function before a checkpoint is created through a target interface.

19. The method of claim 17, wherein, The determining of the ongoing consumption when a checkpoint is created, and the terminating of the ongoing consumption, comprises: monitoring a web request of a webpage; terminating the monitored web request before a checkpoint is created, and returning a response message corresponding to the web request, wherein the monitored web request is the ongoing consumption.

20. The method of any one of claims 10-13, wherein, Before the obtaining of the checkpoint snapshot of the first instance when the running state meets a set condition, the method further comprises: obtaining a file descriptor of a current process of the microservice, and determining a resource path pointed by the file descriptor; closing related resources of the current process of the microservice according to the resource path.

21. A method of starting an instance of a microservice, wherein, The method is performed by a second device running a second instance of a microservice, and the method comprises: sending a read lock request to a distributed storage system; receiving lock information sent by the distributed storage system, and sending an instance identifier of the first instance to the distributed storage system; receiving read lock failure information sent by the distributed storage system, the read lock failure information indicating that the first instance performs a CRaC start; receiving an invalid instruction of the lock information sent by the distributed storage system, and releasing the lock information; obtaining a checkpoint snapshot corresponding to the first instance, wherein the checkpoint snapshot comprises related information required for the second instance to perform a CRaC start; performing a CRaC start on the second instance based on the checkpoint snapshot.

22. The method of claim 21, wherein, The obtaining of the checkpoint snapshot corresponding to the first instance comprises: determining whether the checkpoint snapshot exists in an instance container; in response to the checkpoint snapshot existing in the instance container, reading the checkpoint snapshot from the instance container; in response to the checkpoint snapshot not existing in the instance container, sending a snapshot obtaining request to the distributed storage system, and receiving the checkpoint snapshot sent by the distributed storage system.

23. The method of claim 21, wherein, The method further comprises: sending a CRaC start process number to the distributed storage system and writing in a CRaC file; or sending a CRaC recovery process number to the distributed storage system and writing in a CRaC recovery file.

24. The method of claim 21, wherein, The method further comprises: determining attribute information of the microservice, and determining whether to have a CRaC function according to the attribute information.

25. The method of any one of claims 21-24, wherein, The method further comprises: an environment information of the second instance is obtained by a start script; the environment information is written into an environment variable by a middleware, and the CRaC start is executed based on the environment variable and the checkpoint snapshot.

26. The method of claim 21, wherein, The method further comprises: after the CRaC start is completed or the CRaC recovery is completed, it is judged whether a resource path of the second instance exists; in response to the resource path existing, related resources of the second instance are written under the resource path; in response to the resource path not existing, a file is newly created based on the resource path, and related resources of the second instance are written in the newly created file.

27. An instance startup apparatus of a microservice, wherein, The device is suitable for a distributed storage system, and the device comprises: an obtaining module, configured to receive a read lock request sent by a first device, determine lock information from a lock file, and send the lock information to the first device in response to the lock information not being occupied; receive an instance identifier of a first instance sent by the first device, and write the instance identifier into the lock file; send a read lock failure information to the first device in response to the lock information being occupied and the instance identifier corresponding to the lock information being different from the instance identifier of the first instance, the read lock failure information indicating that the first instance performs a CRaC start; and obtain a checkpoint snapshot of a start stage of the first instance sent by the first device, the checkpoint snapshot being a snapshot when a running state of the first instance meets a set condition; a receiving module, configured to receive a snapshot request of a second instance sent by a second device; a sending module, configured to send the checkpoint snapshot to the second device according to the snapshot request, the checkpoint snapshot comprising related information required for the second instance to perform a CRaC start.

28. An instance startup apparatus of a microservice, wherein, The device is suitable for a first device running a first instance of a microservice, and the device comprises: a monitoring module, configured to monitor a running state of a start stage of the first instance; an obtaining module, configured to send a read lock request to a distributed storage system in response to the running state meeting a set condition, receive lock information sent by the distributed storage system, and send an instance identifier of the first instance to the distributed storage system; receive a read lock failure information sent by the distributed storage system, the read lock failure information indicating that the first instance performs a CRaC start; receive an invalid indication of the lock information sent by the distributed storage system, and release the lock information; and obtain a checkpoint snapshot of the first instance when the running state meets the set condition; a sending module, configured to send the checkpoint snapshot to the distributed storage system, the checkpoint snapshot comprising related information required for a second instance to perform a CRaC start.

29. An instance startup apparatus of a microservice, wherein, Suitable for a second device running a second instance of a microservice, the apparatus comprising: an obtaining module configured to send a read lock request to a distributed storage system, receive lock information sent by the distributed storage system, and send an instance identifier of the first instance to the distributed storage system, receive read lock failure information sent by the distributed storage system, the read lock failure information indicating that the first instance performs CRaC startup, receive an invalid indication of the lock information sent by the distributed storage system, and release the lock information, and obtain a checkpoint snapshot corresponding to the first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup; a starting module configured to perform CRaC startup on the second instance based on the checkpoint snapshot. 30.An electronic device comprising: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-26.

31. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to make the computer execute the method according to any one of claims 1-26.

32. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions are executed by the processor to implement the method of any one of claims 1-26.

Images