Microservice instance starting method and device, electronic equipment and storage medium

Abstract

The invention provides a micro-service instance starting method and device, electronic equipment and a storage medium, and relates to the technical field of micro-service and distributed storage. According to the specific implementation scheme, the method comprises the steps that a check point snapshot of a first instance starting stage sent by first equipment is obtained, wherein the check point snapshot is a snapshot when the running state of a first instance meets a set condition; receiving a snapshot request of a second instance sent by a second device; according to the snapshot request, a checkpoint snapshot is sent to the second device, and the checkpoint snapshot comprises related information needed by the second instance for executing checkpoint coordination recovery CRaC starting.

Description

Technical Field

[0001] The present disclosure relates to the fields of microservices and distributed storage technology, and in particular to a method, device, electronic device, and storage medium for starting an instance of a microservice. Background Art

[0002] Microservices, as a software architecture style, divides an application into a set of small, independently deployable services. These services can be independently developed, tested, deployed, and scaled. The object-oriented programming language Java community provides a wealth of tools and frameworks for microservice development. However, Java microservices also face some controversy during the startup and operation phases, including long startup time, high memory and central processing unit (CPU) load during startup, and poor performance during the cold start phase. Summary of the invention

[0003] The present disclosure provides a method, device, electronic device and storage medium for starting an instance of a microservice.

[0004] According to one aspect of the present disclosure, a method for starting an instance of a microservice is provided, comprising: obtaining a checkpoint snapshot of a first instance startup phase sent by a first device, the checkpoint snapshot being a snapshot when the running state of the first instance meets a set condition; receiving a snapshot request of 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 coordinated recovery (CRaC) startup.

[0005] According to another aspect of the present disclosure, another method for starting an instance of a microservice is provided, comprising: monitoring the running status of the first instance during the startup phase; in response to the running status satisfying a set condition, obtaining a checkpoint snapshot of the first instance when the running status satisfies the set condition; 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 the present disclosure, another method for starting an instance of a microservice 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 the present disclosure, a device for starting an instance of a microservice is provided, including: an acquisition module, used to acquire a checkpoint snapshot of a first instance startup phase sent by a first device, the checkpoint snapshot being a snapshot when the running state of the first instance meets a set condition; a receiving module, used to receive a snapshot request of a second instance sent by a second device; and a sending module, used 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 coordinated recovery CRaC startup.

[0008] According to another aspect of the present disclosure, another microservice instance startup device is provided, including: a monitoring module, used to monitor the running status of the first instance during the startup phase; an acquisition module, used to obtain a checkpoint snapshot of the first instance when the running status meets the set condition in response to the running status meeting the set condition; a sending module, used to send the checkpoint snapshot to a distributed storage system, the checkpoint snapshot including relevant information required for the second instance to perform CRaC startup.

[0009] According to another aspect of the present disclosure, another microservice instance startup device is provided, including: an acquisition module, used to obtain a checkpoint snapshot corresponding to a first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup; a startup module, used to perform CRaC startup on the second instance based on the checkpoint snapshot.

[0010] According to another aspect of the present 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, and the instructions are executed by the at least one processor so that the at least one processor can execute the instance startup method of the microservice described in the above-mentioned first embodiment.

[0011] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, on which a computer program / instructions are stored, and the computer instructions are used to enable the computer to execute the instance startup method of the microservice described in the above-mentioned embodiment.

[0012] According to another aspect of the present disclosure, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the method for starting an instance of a microservice described in the above-mentioned embodiment.

[0013] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0015] Figure 1 A schematic diagram of a process for starting a microservice instance provided in an embodiment of the present disclosure;

[0016] Figure 2 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0017] Figure 3 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0018] Figure 4 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0019] Figure 5 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0020] Figure 6 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0021] Figure 7 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0022] Figure 8 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0023] Fig. 9 A flowchart of another method for starting an instance of a microservice provided in an embodiment of the present disclosure;

[0024] Fig.10 A schematic diagram of checkpoint snapshot creation and distribution provided for an embodiment of the present disclosure;

[0025] Fig.11 A schematic diagram of a process for creating a checkpoint provided by an embodiment of the present disclosure;

[0026] Fig.12 A schematic diagram of a process for distributing checkpoint snapshots provided in an embodiment of the present disclosure;

[0027] Fig.13A schematic diagram of the structure of a microservice instance startup device provided in an embodiment of the present disclosure;

[0028] Fig.14 A schematic diagram of the structure of another microservice instance startup device provided in an embodiment of the present disclosure;

[0029] Fig.15 A schematic diagram of the structure of another microservice instance startup device provided in an embodiment of the present disclosure;

[0030] Fig.16 The present invention is a block diagram of an electronic device for implementing a method for starting a microservice instance according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0031] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0032] The following describes a method, device, and electronic device for starting a microservice example according to an embodiment of the present disclosure with reference to the accompanying drawings.

[0033] Figure 1 A schematic diagram of a flow chart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure. The method for starting an instance of a microservice can be executed by a distributed storage system.

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

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

[0036] It should be noted that the execution subject of the instance startup method of the microservice in the embodiment of the present disclosure may be a hardware device with data processing capabilities and / or the necessary software required to drive the hardware device to work. Optionally, the execution subject may include a server. Optionally, the server may be a server equipped with a distributed storage system. The embodiment of the present disclosure is not specifically limited.

[0037] It is understood that a checkpoint snapshot is a technology used in a computer system to save the complete state of a system or application at a certain moment. Its main purpose is to quickly restore to the state of the most recent checkpoint when the system fails or needs to be restored, thereby reducing data loss and recovery time.

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

[0039] Optionally, the CPU occupancy rate when the instance is running can be less than the occupancy rate threshold, and the response speed can be greater than the speed threshold, as satisfying the set condition. That is, when the first instance in the first device is started, the CPU occupancy rate of the first instance is less than the occupancy rate threshold, and the response speed is greater than the speed threshold, 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 perform distributed storage on the checkpoint snapshot.

[0041] S102: Receive a snapshot request of a second instance sent by a second device.

[0042] In some implementations, after receiving the checkpoint snapshot, the distributed storage system may send the checkpoint snapshot to multiple instances of other devices so that the instances can quickly run to the running state of the first instance according to the checkpoint snapshot.

[0043] Optionally, the distributed storage system may send a checkpoint snapshot to the instance based on the snapshot request. That is, the distributed storage system may receive a snapshot request for the second instance sent by the second device.

[0044] S103: Send a checkpoint snapshot to the second device according to the snapshot request, where the checkpoint snapshot includes relevant information required for the second instance to start executing the checkpoint coordinated recovery CRaC.

[0045] In some implementations, before sending the checkpoint snapshot to the second device, the stored checkpoint snapshot may be verified, and after the verification is passed, the checkpoint snapshot may be sent to the second device. Since the checkpoint snapshot contains relevant information required for the second instance to start performing a coordinated restore at checkpoint (CRaC), the integrity of the relevant information may be verified, and after the integrity is verified, the checkpoint snapshot may be sent to the second device.

[0046] That is, the distributed storage system can obtain the checkpoint snapshot according to the snapshot request, verify the integrity of the relevant information required for executing CRaC startup contained in the checkpoint snapshot, and send the checkpoint snapshot to the second device after the verification passes.

[0047] According to the instance startup method of a microservice provided by an embodiment of the present disclosure, a 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 so that the second instance in the second device performs CRaC startup, thereby improving the startup speed of the second instance to quickly reach 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 the microservices reach the optimal operating state in the shortest time, and at the same time ensuring the consistency of the instance operation logic.

[0048] Figure 2 A schematic diagram of a flow chart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure. The method for starting an instance of a microservice can be executed by a distributed storage system.

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

[0050] S201, obtaining a checkpoint snapshot of a first instance startup phase sent by a first device, where the checkpoint snapshot is a snapshot when the running state of the first instance meets a set condition.

[0051] S202: Receive a snapshot request of a second instance sent by a second device.

[0052] The relevant contents of steps S201 - S202 can be found in the above embodiment and will not be described again here.

[0053] S203: Verify the checkpoint snapshot according to the snapshot request.

[0054] In some implementations, in order to ensure the consistency of data in the checkpoint snapshot and avoid data errors, the checkpoint snapshot can be verified before sending the checkpoint snapshot to improve the reliability of the distributed system.

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

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

[0057] Further, the checkpoint snapshot may be verified according to the first verification information and the second verification information. Optionally, the first verification information and the second verification information may include a process number of the checkpoint, and whether the checkpoint snapshot has passed the verification is determined by verifying whether the two process numbers are consistent. Optionally, if the process numbers are consistent, it is determined that the checkpoint snapshot has passed the verification, otherwise, it is determined that the checkpoint snapshot has not passed the verification.

[0058] S204: In response to passing the verification, sending the checkpoint snapshot to the second device.

[0059] In some implementations, when it is determined that the checkpoint snapshot passes verification, the checkpoint snapshot stored in the distributed storage system can be sent to the second device.

[0060] In some implementations, when it is determined that a checkpoint snapshot has not passed verification, the checkpoint snapshot may be re-verified based on a time interval for task completion to improve the accuracy of verification and reduce misjudgment.

[0061] Optionally, in response to failure of verification, the timestamp of the task completion file corresponding to the checkpoint snapshot is obtained, and based on the timestamp, the time interval between the timestamp and the timestamp of the current moment is determined, and then it can be determined whether the checkpoint snapshot can be re-verified based on the time interval.

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

[0063] An exemplary description is given, in which it is determined that the checkpoint snapshot has not passed the verification, the time interval between the timestamp of the task completion file and the current moment is obtained, if the time interval is less than 5 minutes, wait for 6 seconds and re-verify the checkpoint snapshot, if it still fails the verification, continue to verify until the number of verifications exceeds 10 times, end the verification, determine that the checkpoint snapshot has not passed the verification, and then start the second instance normally.

[0064] According to the instance startup method of the microservice provided by the embodiment of the present disclosure, the distributed storage system receives a checkpoint snapshot of the first instance startup phase sent by the first device, and stores the checkpoint snapshot. By receiving a snapshot request sent by the second device, and verifying the checkpoint snapshot according to the snapshot request, and sending the checkpoint snapshot to the second device after the verification is passed, so that the second instance in the second device performs CRaC startup, the startup speed of the second instance is improved to quickly reach the optimal operating state. By verifying the checkpoint snapshot, the consistency of the data in the checkpoint snapshot is ensured, and data errors are avoided, so as to improve the reliability of the distributed system.

[0065] Figure 3 A schematic diagram of a flow chart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure. The method for starting an instance of a microservice can be executed by a distributed storage system.

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

[0067] S301, receiving a read lock request sent by a first device.

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

[0069] In some implementations, before obtaining a checkpoint snapshot from the first instance of the first device, lock information must be sent to the first device based on a read lock request from the first device, so that the first device creates a checkpoint based on the lock information and generates a checkpoint snapshot.

[0070] Optionally, the distributed storage system receives a read lock request from the first device, obtains lock information from the lock file according to the read lock request, and determines whether the lock information is occupied, so as to determine whether the lock information needs to be sent to the first device according to the determination result.

[0071] It can be understood that if the lock information is occupied, it means that an instance has 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, then the lock information can be sent to the first instance in the first device, avoiding repeated creation of checkpoints.

[0072] That is to say, in response to the lock information being not occupied, the lock information is sent to the first device so that the first instance in the first device creates a checkpoint based on the lock information; in response to the lock information being occupied and the instance identifier corresponding to the lock information is not the instance identifier of the first instance, a read lock failure information is sent to the first device, and the read lock failure information indicates that the first instance executes CRaC startup.

[0073] In some implementations, when the 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 to monitor the timeliness of the lock information and improve the accuracy of lock information management.

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

[0075] In some implementations, the timeliness of the lock information can be 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 a set interval threshold, the lock information is determined to be invalid. In response to monitoring that the lock information is invalid, the lock file is deleted and the first instance is instructed to release the lock information, so that the lock information can be used for other instances to create checkpoints.

[0076] In some implementations, before reading the lock information, it is necessary to determine whether the lock information exists in the lock file. In response to the existence of lock information in the lock file, the lock information is directly obtained from the lock file; in response to the absence of lock information in the lock file, the lock generation function is called to generate lock information, and the lock information is sent to the first device to achieve secure access to the lock information.

[0077] S303: Receive an instance identifier of the first instance sent by the first device, and write the instance identifier into a lock file.

[0078] In some implementations, in order to avoid repeated creation of checkpoints by instances in other devices, the instance identifier of the first instance can be written into the lock file so that other instances can read the instance identifier of the first instance when obtaining the lock file, determine that the read lock has failed, and execute CRaC startup.

[0079] S304, obtaining a checkpoint snapshot of the first instance startup phase sent by the first device, where the checkpoint snapshot is a snapshot when the running state of the first instance meets a set condition.

[0080] S305: Receive a snapshot request of the second instance sent by the second device.

[0081] S306: Send a checkpoint snapshot to the second device according to the snapshot request, where the checkpoint snapshot includes relevant information required for the second instance to start the checkpoint coordinated recovery CRaC.

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

[0083] According to the instance startup method of a microservice provided by an embodiment of the present disclosure, the distributed storage system receives a read lock request from the first device and sends lock information to the first device, so that the first instance in the first device creates a checkpoint, receives a checkpoint snapshot of the first instance startup phase sent by the first device, and stores the checkpoint snapshot. By receiving a snapshot request sent by the second device, the checkpoint snapshot can be sent to the second device, so that the second instance in the second device performs CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal operating state. Before the first instance creates a checkpoint, by obtaining lock information in the distributed storage system and creating a checkpoint based on the lock information, it is avoided that multiple instances repeatedly create checkpoints, resulting in a waste of resources.

[0084] Figure 4 A schematic diagram of a flow chart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure. The method for starting an instance of a microservice can be executed by a distributed storage system.

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

[0086] S401, receiving a process number verification request sent by a first device, where the process number verification request includes a first process number of a first instance that is creating a checkpoint.

[0087] S402: Read from the CRaC file a second process number configured for the first instance and used to create a checkpoint.

[0088] In some implementations, before obtaining a checkpoint snapshot from the first instance of the first device, it is also possible to determine 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 number configured for the first instance for creating the checkpoint based on files related to the checkpoint snapshot, such as the CRaC file.

[0090] In some implementations, a process number verification request generated based on a first process number of a first instance that is creating a checkpoint is received, the process number verification request is parsed, the first process number is obtained therefrom, and the first process number is compared with the second process number to determine whether the checkpoint is created by the first instance.

[0091] S403: In response to the first process number and the second process number being consistent, sending a creation indication of creating a checkpoint to the first device.

[0092] In some implementations, when it is determined that the first process number and the second process number are consistent, it can be determined that the checkpoint is created by the first instance. By generating a creation instruction for creating a checkpoint and sending the creation instruction to the first device, so that the first instance in the first device creates a checkpoint, the checkpoint is allowed to be created only when the process numbers are consistent, thereby avoiding unnecessary resource consumption and waste.

[0093] In some implementations, when it is determined that the first process number and the second process number are inconsistent, it can be determined that the first instance does not need to create a checkpoint, and the instance can be started. The third process number is obtained from the recovery startup file, and the startup type of the first instance is determined according to the consistency between the third process number and the first process number. The startup type includes: recovery startup and regular startup. Optionally, a startup instruction is directly sent to the first instance of the first device without the need to perform a checkpoint creation operation, thereby reducing the waiting time and resource consumption of the microservice and improving the response speed of the microservice.

[0094] That is, in response to the inconsistency between the first process number and the second process number, the recovery startup file is read and it is determined whether the recovery startup file exists to obtain the third process number from the recovery startup file. In response to the existence of the recovery startup file, the third process number recorded in the recovery startup file is determined.

[0095] Further, determine whether the first process number is consistent with the third process number, and in response to the first process number and the third process number being consistent, send a recovery startup indication to the first device; in response to at least one of the recovery startup file not existing and the first process number and the third process number being inconsistent, send a regular startup indication to the first device.

[0096] S404, obtaining a checkpoint snapshot of the first instance startup phase sent by the first device, where the checkpoint snapshot is a snapshot when the running state of the first instance meets a set condition.

[0097] S405: Receive a snapshot request of the second instance sent by the second device.

[0098] S406: Send a checkpoint snapshot to the second device according to the snapshot request, where the checkpoint snapshot includes relevant information required for the second instance to start the checkpoint coordinated recovery CRaC.

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

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

[0101] In some implementations, the distributed storage system can also store the startup information of the device, optionally by receiving the CRaC startup process number sent by the first device or the second device after the startup is completed, and writing it into the CRaC file. Alternatively, the CRaC recovery process number sent by the first device or the second device after the recovery is completed is received and written into the CRaC recovery file, and then the CRaC file and the CRaC recovery file are stored. By recording the process numbers of CRaC startup and CRaC recovery, the status of each process can be accurately tracked and managed, ensuring that the operation of microservices is more orderly and stable.

[0102] According to the instance startup method of the microservice provided by the embodiment of the present disclosure, the distributed storage system can determine whether the first process number of the first instance is consistent with the second process number in the CRaC file before the first instance creates a checkpoint, and send a checkpoint creation instruction to the first device when they are consistent. Further, a checkpoint snapshot of the first instance startup phase sent by the first device can be received, and the checkpoint snapshot can be stored. By receiving a snapshot request sent by the second device, the checkpoint snapshot can be sent to the second device so that the second instance in the second device performs CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal operating state. By determining whether the process numbers are consistent and allowing the creation of checkpoints only when the process numbers are consistent, unnecessary resource consumption and waste can be avoided.

[0103] Figure 5 A flowchart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure, wherein the method for starting an instance of a microservice can be executed by a first device.

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

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

[0106] It should be noted that the execution subject of the instance startup method of the microservice in the embodiment of the present disclosure may be a hardware device with data processing capabilities and / or the necessary software required to drive the hardware device to work. Optionally, the execution subject may include a user terminal and other smart devices. Optionally, the user terminal includes but is not limited to a mobile phone, a computer, an intelligent voice interaction device, etc. The embodiment of the present disclosure is not specifically limited. In the embodiment of the present disclosure, the first device runs the first instance of the microservice.

[0107] In some implementations, when the first instance is creating a checkpoint, the first device may monitor the running state of the first instance during the startup phase and create a checkpoint when the running state reaches an optimal state. Optionally, the running state reaching an optimal state may be that the running state meets a set condition.

[0108] Optionally, the first device may monitor the CPU occupancy rate of the first instance and the response speed of the first instance to monitor the running status of the first instance.

[0109] In some implementations, before monitoring the operating status of the first instance of the microservice during the startup phase, the first device may also confirm whether the first instance has the CRaC function, and if it has the CRaC function, perform operations such as checkpoint creation on the first instance to save the checkpoint creation process and improve the efficiency of checkpoint creation.

[0110] Optionally, the attribute information of the microservice may be determined, and whether the first instance has the CRaC function may be determined based on the attribute information. If the attribute information includes an identifier of the CRaC function, it is determined that the first instance has the CRaC function, otherwise the first instance does not have the CRaC function.

[0111] S502: In response to the running state satisfying a set condition, obtaining a checkpoint snapshot of the first instance when the running state satisfies the set condition.

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

[0113] It is understood that a checkpoint snapshot is a technology used in a computer system to save the complete state of a system or application at a certain moment. Its main purpose is to quickly restore to the state of the most recent checkpoint when the system fails or needs to be restored, thereby reducing data loss and recovery time.

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

[0115] S503: Send a checkpoint snapshot to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to execute CRaC startup.

[0116] In some implementations, after the first device obtains the checkpoint snapshot of the first instance, the checkpoint snapshot may be sent to the distributed storage system. Optionally, a checkpoint snapshot may be generated based on relevant information required to perform CRaC startup, and the checkpoint snapshot may be sent to the distributed storage system.

[0117] According to the instance startup method of a microservice provided in an embodiment of the present disclosure, 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, and sends 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 perform CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal running state.

[0118] Figure 6 A flowchart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure, wherein the method for starting an instance of a microservice can be executed by a first device.

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

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

[0121] The relevant contents of step S601 can be found in the above embodiment and will not be repeated here.

[0122] S602: In response to the running state satisfying the set condition, obtaining the running parameters of the first instance when the running state satisfies the set condition.

[0123] In some implementations, when the running state of the first instance meets the set conditions, 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, determining a checkpoint snapshot according to the operating parameters and JIT information.

[0125] In some implementations, when the first instance is in the startup phase, the encoding service can be used to preheat the first instance and obtain the compilation result of the first instance. Optionally, when it is determined that the first instance is to perform a startup operation, the first instance can be preheated to improve the response speed of the first instance.

[0126] That is, in response to the startup operation of the first instance, the key classes and resources of the first instance are pre-loaded and initialized based on the object-oriented programming language virtual machine (Java Virtual Machine, JVM), so that the required key classes and resources can be found and loaded more quickly when the first instance starts, thereby reducing the time required for class loading.

[0127] Furthermore, after the first instance is started, the first instance is compiled in real time (Just-In-Time, JIT) to obtain JIT information of the first instance. By performing JIT, the hot code can be compiled into efficient machine code when the program is running, thereby significantly reducing the overhead of interpretation and execution and improving the execution speed of the program.

[0128] In some implementations, the JIT information of the first instance can be obtained through the above steps, and the operating parameters and JIT information can be used as the checkpoint snapshot of the first instance, which can ensure that the checkpoint snapshot can save the best operating state of the first instance. Optionally, after obtaining the checkpoint snapshot of the first instance, the checkpoint snapshot 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, which greatly shortens the recovery time.

[0129] S604: Send a checkpoint snapshot to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to execute CRaC startup.

[0130] The relevant contents of step S604 can be found in the above embodiment and will not be described again here.

[0131] According to the instance startup method of a microservice provided in an embodiment of the present disclosure, 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, and sends 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 perform CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal running state.

[0132] Figure 7 A flowchart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure, wherein the method for starting an instance of a microservice can be executed by a first device.

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

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

[0135] The relevant contents of step S701 can be found in the above embodiment and will not be described again here.

[0136] S702: In response to the running status satisfying the set condition, a read lock request is sent to the distributed storage system.

[0137] In some implementations, when the running status 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 repeated creation of checkpoints by multiple instances, resulting in a waste of resources.

[0138] In some implementations, it is possible to determine whether the first instance has completed preheating and send a read lock request to the distributed storage system after preheating is completed. After the first instance has completed preheating, its internal resources have been fully initialized and optimized. At this time, sending a read lock request can more effectively utilize these resources and improve the efficiency of checkpoint creation.

[0139] Optionally, the execution of JVM preloading and JIT can be used as preheating the first instance. The preheating duration is obtained to determine whether the preheating is completed according to the preheating duration, that is, by obtaining the cumulative duration of the execution of JVM and JIT by the first instance, in response to the cumulative duration being not greater than the set duration, a read lock request is sent to the distributed storage system.

[0140] Optionally, in response to the accumulated duration being greater than the set duration, CRaC startup is performed on the first instance. That is, when the first instance has not completed preheating, it is determined that an existing instance has completed the creation of a checkpoint, and the first instance can be directly CRaC started.

[0141] In some implementations, before obtaining the lock information from the distributed storage system, the first device may also determine whether the lock information can be obtained from the distributed storage system based on the process number of the first instance, and when the process numbers are consistent, indicate that a checkpoint can be created, thereby obtaining the lock information from the distributed storage system, so as to avoid creating a checkpoint when the process numbers are inconsistent, which causes a waste of resources.

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

[0143] Furthermore, the first device may receive a creation instruction for creating a checkpoint sent by the distributed storage system, where the creation instruction is sent when it is verified that the first process number and the second process number are consistent, so as to create a checkpoint according to the creation instruction.

[0144] Optionally, when the first process number and the second process number are consistent, a checkpoint is created; when the first process number and the second process number are inconsistent, the first instance is recovered or normally started without the need to perform a checkpoint creation operation, thereby reducing the waiting time and resource consumption of the microservice and improving the response speed of the microservice.

[0145] That is, the first device may receive a recovery start indication or a regular start indication sent by the distributed storage system, where the recovery start indication or the regular start indication is sent when it is verified that the first process number and the second process number are inconsistent.

[0146] S703: Receive lock information sent by the distributed storage system, and send the instance identifier of the first instance to the distributed storage system.

[0147] In some implementations, the first device receives lock information sent by 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, the instance identifier of the first instance is sent to the distributed storage system to avoid repeated creation of checkpoints for instances in other devices.

[0148] In some implementations, after the first device sends a read lock request to the distributed storage system, if the lock information in the distributed storage system is occupied and the instance identifier corresponding to the lock information is not the instance identifier of the first instance, the distributed storage system may receive a read lock failure message, and 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 may also determine the timeliness of the lock information. The process of determining the timeliness of the lock information can refer to the above embodiment and will not be repeated here. When the distributed storage system determines that the lock information is invalid, the first device may receive an invalid indication of the lock information 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, obtaining a checkpoint snapshot of the first instance when the running status meets the set condition.

[0151] S705: Send a checkpoint snapshot to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to execute CRaC startup.

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

[0153] According to the instance startup method of a microservice provided in an embodiment of the present disclosure, 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, creates a checkpoint according to the lock information, and obtains a checkpoint snapshot of the first instance, and sends 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 perform CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal running state.

[0154] Figure 8 A flowchart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure, wherein the method for starting an instance of a microservice can be executed by a first device.

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

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

[0157] The relevant contents of step S801 can be found in the above embodiment and will not be described again here.

[0158] S802: In response to the running state satisfying the set condition, determining the ongoing consumption when the checkpoint is created, and terminating the ongoing consumption.

[0159] In some implementations, before creating a checkpoint, the ongoing consumption on the first instance can be terminated to avoid repeated consumption after the first instance is restored. Optionally, a probe can be used to monitor consumption to determine the ongoing consumption when the checkpoint is created. Optionally, requests can also be monitored and the monitored requests can be used as ongoing consumption.

[0160] That is, the thread running function can be intercepted and monitored by the probe to obtain the executable task of the first instance, wherein the executable task is the ongoing consumption. Further, the executable task is terminated in the callback function before the checkpoint is created through the target interface.

[0161] Optionally, the target interface may be enhanced using a probe so that the target interface terminates the runnable task in the callback function to avoid duplicate consumption after the first instance is restored.

[0162] In some implementations, web page requests can also be monitored, and the monitored Web requests can be terminated before creating a checkpoint, and a response message corresponding to the Web request can be returned, where the monitored Web request is an ongoing consumption to prevent the request from being processed repeatedly after restoring from the checkpoint snapshot.

[0163] In some implementations, the file or connection pointed to by the file descriptor may change before the checkpoint snapshot is created. In order to avoid unexpected situations caused by the non-existence of resources on the instance due to changes or heterogeneity in the content of resources such as files or connections, the resources pointed to by the file descriptor can be closed.

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

[0165] S803, obtaining a checkpoint snapshot of the first instance when the running status meets the set condition.

[0166] S804: Send a checkpoint snapshot to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to execute CRaC startup.

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

[0168] According to the instance startup method of a microservice provided by an embodiment of the present disclosure, the first device monitors the running status of the first instance and terminates the ongoing consumption on the first instance before obtaining the checkpoint snapshot of the first instance to avoid repeated consumption caused by service recovery. After the 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 to quickly reach the optimal running state.

[0169] Fig. 9 A flowchart of a method for starting an instance of a microservice provided in an embodiment of the present disclosure, wherein the method for starting an instance of a microservice can be executed by a second device.

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

[0171] S901, obtaining a checkpoint snapshot corresponding to a first instance, where the checkpoint snapshot includes relevant information required for a second instance to execute CRaC startup.

[0172] It should be noted that the execution subject of the instance startup method of the microservice in the embodiment of the present disclosure may be a hardware device with data processing capabilities and / or the necessary software required to drive the hardware device to work. Optionally, the execution subject may include a user terminal and other smart devices. Optionally, the user terminal includes but is not limited to a mobile phone, a computer, an intelligent voice interaction device, etc. The present embodiment of the present disclosure is not specifically limited. In the embodiment of the present disclosure, the second device runs the second instance of the microservice.

[0173] In some implementations, in order to enable 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 obtaining a checkpoint snapshot from a distributed storage system, it is also possible to determine whether a checkpoint snapshot exists in an instance container. In response to the existence of a checkpoint snapshot in the instance container, the checkpoint snapshot is read from the instance container to save time in obtaining the checkpoint snapshot and reduce unnecessary network transmission.

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

[0176] S902: Based on the checkpoint snapshot, perform CRaC startup on the second instance.

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

[0178] In some implementations, in order to accurately track and manage the status of the process of each instance and ensure that the operation of the microservice is more orderly and stable, CRaC startup or CRaC recovery can be performed on the second instance to send the process number to the distributed storage system.

[0179] That is, the CRaC startup process number may be sent to the distributed storage system and written into the CRaC file. Alternatively, the CRaC recovery process number may be sent to the distributed storage system and written into the CRaC recovery file.

[0180] In some implementations, the first device may also confirm whether the second instance has the CRaC function, and if so, perform operations such as obtaining a checkpoint snapshot on the second instance to save the checkpoint snapshot obtaining process and improve the efficiency of obtaining the checkpoint snapshot.

[0181] Optionally, the attribute information of the microservice may be determined, and whether the microservice has the CRaC function may be determined based on the attribute information. If the attribute information includes an identifier of the CRaC function, it is determined that the second instance has the CRaC function, otherwise the second instance does not have the CRaC function.

[0182] In some implementations, in order to complete the adaptation of instance information when starting microservices with checkpoint snapshots, support the recovery of microservices based on the same checkpoint snapshot on heterogeneous instances, and ensure the consistency of the 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 the startup script. Further, the environment information is written into the environment variables through the middleware, and the CRaC startup is performed based on the environment variables and the checkpoint snapshot. The environment information includes but is not limited to: Internet Protocol (IP), service port, instance name, etc.

[0184] In some implementations, when CRaC startup is complete or CRaC recovery is complete, the relevant resources of the second instance can be written to 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 is completed or CRaC recovery is completed, it is determined whether a resource path exists for the second instance. In response to the existence of the resource path, the relevant resources of the second instance are appended to the resource path; in response to the absence of the resource path, a new file is created based on the resource path and the relevant resources of the second instance are written into the new file.

[0186] That is, when the checkpoint snapshot is used to restore the process, the relevant resources are written. For log files in append write mode, you can first determine whether the source path exists. If it exists, it is written in append mode; if it does not exist, a new file is created in the same path and written from the beginning. For other types of files, in order to avoid unexpected situations caused by changes in file content, read and write operations are performed only when the file exists, and an exception is thrown if the file does not exist. For remote connections, such as Hypertext Transfer Protocol (HTTP) connections and database connections, the middleware can be modified to complete the reconstruction of the connection after recovery.

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

[0188] For example, Fig.10 Schematic diagram of checkpoint snapshot creation and distribution shown. Fig.10 In the example, instance 1 is the first instance, and instances 2 to n are the second instances. Instance 1 creates a checkpoint snapshot when the running state meets the set conditions, and synchronizes the checkpoint snapshot to the distributed storage system. Furthermore, instances 2 to n send snapshot requests to the distributed storage system to obtain the checkpoint snapshot corresponding to instance 1, so that the instance pulls the checkpoint snapshot from the distributed storage system and executes CRaC startup according to the checkpoint snapshot.

[0189] Fig.11 The flowchart of the checkpoint creation process is shown. Taking the first instance as an example, by determining whether the first instance has the CRaC function, if it does not have the CRaC function, it is determined that the first instance performs a regular startup. If it has the CRaC function, the second process number configured for the first instance to create a checkpoint is read from the CRaC file. If the second process number does not exist in the CRaC file, it is determined that the first instance performs a regular startup. Otherwise, it is determined whether the first process number of the first instance is consistent with the second process number. If not, the recovery startup file is read, and when the recovery startup file exists, the third process number recorded in the recovery startup file is determined. Further, it is determined whether the first process number and the third process number are consistent. If they are consistent, it is determined that the first instance performs a recovery startup. If the third process number does not exist in the recovery startup file, or the first process number and the third process number are inconsistent, it is determined that the first instance performs a regular startup.

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

[0191] Further, the first instance can send a read lock request to the distributed storage system to obtain the lock information in the lock file. If the lock information does not exist in the lock file, call the lock generation function to generate the lock information, send the lock information to the first instance, and further write 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, it is determined that the first instance performs 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, continue to determine whether there is a task completion file corresponding to the checkpoint snapshot. If there is no task completion file, determine the generation time of the lock information, and monitor the timeliness of the lock information according to the generation time. Determine the timeliness of the lock information 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, it is determined that the lock information is invalid, and then delete the lock file and instruct the first instance to release the lock information so that the lock information can be used for other instances to create checkpoints.

[0192] Furthermore, after the instance identifier of the first instance is written 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, and storing the created task completion file, thereby ending the checkpoint creation process.

[0193] like Fig.12 Schematic diagram of the process of distributing checkpoint snapshots shown in FIG. Taking the second instance as an example, determine whether the second instance has the CRaC function. If it does not have the CRaC function, determine that the second instance performs regular startup. If it has the CRaC function, determine whether there is a task completion file in the distributed storage server. If not, determine whether the second instance has a probe turned on. If the probe is turned on, determine that the second instance performs CRaC startup, and determine whether the CRaC startup is successful. After the startup is successful, write the process of the second instance into the CRaC file. If the second instance does not have a probe turned on, or the CRaC startup fails, determine that the second instance performs regular startup.

[0194] If there is a task completion file 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, so that the checkpoint snapshot can be verified according to the first verification information and the second verification information. If the verification fails, it is determined whether the checkpoint snapshot can be re-verified according to the time interval between the timestamp of the task completion file and the timestamp of the current moment.

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

[0196] After the checkpoint snapshot passes verification, it is determined that the second instance performs CRaC startup, and whether the CRaC startup is successful is determined. After the startup is successful, the process of the second instance is written into the CRaC file, otherwise it is determined that the second instance performs regular startup.

[0197] Corresponding to the instance startup methods of microservices provided in the above-mentioned embodiments, an embodiment of the present disclosure further provides an instance startup device for a microservice. Since the instance startup device for a microservice provided in the embodiment of the present disclosure corresponds to the instance startup methods for microservices provided in the above-mentioned embodiments, the implementation methods of the instance startup methods for the above-mentioned microservices are also applicable to the instance startup device for a microservice provided in the embodiment of the present disclosure, and will not be described in detail in the following embodiments.

[0198] Fig.13 A schematic diagram of the structure of a device for starting an instance of a microservice provided in an embodiment of the present disclosure.

[0199] like Fig.13 As shown, the microservice instance startup device 1300 of the embodiment of the present disclosure includes an acquisition module 1301, a receiving module 1302 and a sending module 1303.

[0200] An acquisition module 1301 is used to acquire a checkpoint snapshot of a first instance startup phase sent by a first device, where the checkpoint snapshot is a snapshot when the running state of the first instance meets a set condition;

[0201] The receiving module 1302 is configured to receive a snapshot request of a second instance sent by a second device;

[0202] The sending module 1303 is used to send a checkpoint snapshot to the second device according to the snapshot request, where the checkpoint snapshot includes relevant information required for the second instance to execute the checkpoint coordinated recovery CRaC startup.

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

[0204] In one embodiment of the present disclosure, the sending module 1303 is also used to: obtain the task completion file corresponding to the checkpoint snapshot, and obtain the first verification information corresponding to the checkpoint snapshot from the task completion file; determine the 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 the present disclosure, the acquisition module 1301 is also used to: receive a read lock request sent by the first device; determine lock information from the lock file; in response to the lock information being not occupied, send lock information to the first device; receive the instance identifier of the first instance sent by the first device, and write the instance identifier into the lock file; in response to the lock information being occupied and the instance identifier corresponding to the lock information is not the instance identifier of the first instance, send read lock failure information to the first device, and the read lock failure information indicates that the first instance executes CRa.

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

[0207] In one embodiment of the present disclosure, the acquisition module 1301 is also used to: determine whether there is a task completion file corresponding to the checkpoint snapshot; in response to the absence of the task completion file, determine the generation time of the lock information; monitor the timeliness of the lock information based on the generation time; in response to monitoring 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 the present disclosure, the acquisition module 1301 is also used to: receive a process number verification request sent by the first device, the process number verification request includes a first process number of the first instance that is creating a checkpoint; read a second process number configured for the first instance to create a checkpoint from the CRaC file; and in response to the first process number and the second process number being consistent, send a creation indication of creating a checkpoint to the first device.

[0209] In one embodiment of the present disclosure, the acquisition module 1301 is also used to: in response to the inconsistency between the first process number and the second process number, read the recovery startup file; in response to the existence of the recovery startup file, determine the third process number recorded in the recovery startup file; in response to the consistency between the first process number and the third process number, send a recovery startup indication to the first device; in response to at least one of the non-existence of the recovery startup file and the inconsistency between the first process number and the third process number, send a regular startup indication to the first device.

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

[0211] In one embodiment of the present disclosure, the acquisition module 1301 is further used to: receive a 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 a 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 instance startup device of the microservice provided by the embodiment of the present disclosure, the distributed storage system receives the checkpoint snapshot of the first instance startup phase sent by the first device, and stores the checkpoint snapshot. By receiving the snapshot request sent by the second device, the checkpoint snapshot can be sent to the second device, so that the second instance in the second device performs CRaC startup, thereby improving the startup speed of the second instance to quickly reach 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 the microservices reach the optimal operating state in the shortest time, and ensuring the consistency of the instance operation logic.

[0213] Fig.14 A schematic diagram of the structure of a device for starting an instance of a microservice provided in an embodiment of the present disclosure.

[0214] like Fig.14 As shown, the microservice instance startup device 1400 of the embodiment of the present disclosure 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] An acquisition module 1402 is configured to acquire, in response to the running state satisfying a set condition, a checkpoint snapshot of the first instance when the running state satisfies the set condition;

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

[0218] In one embodiment of the present disclosure, the acquisition module 1402 is also used 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; after the startup of the first instance is completed, perform just-in-time compilation JIT on the first instance to obtain the JIT information of the first instance.

[0219] In one embodiment of the present disclosure, the acquisition module 1402 is further used to: acquire the operating parameters of the first instance when the operating state meets the set conditions; and determine the checkpoint snapshot according to the operating parameters and JIT information.

[0220] In one embodiment of the present disclosure, the acquisition module 1402 is also used 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 a 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 executes CRaC startup; receive an invalid indication of the lock information sent by the distributed storage system, and release the lock information.

[0221] In one embodiment of the present disclosure, the acquisition module 1402 is also used to: obtain the cumulative time of the first instance executing JVM and JIT, and in response to the cumulative time being not greater than the set time, send a read lock request to the distributed storage system; in response to the cumulative time being greater than the set time, execute CRaC startup on the first instance.

[0222] In one embodiment of the present disclosure, the acquisition module 1402 is also used to: send a process number verification request to the distributed storage system, the process number verification request includes the first process number of the first instance that is creating a checkpoint; receive a creation instruction for creating a checkpoint sent by the distributed storage system, the creation instruction is sent when it is verified that the first process number and the second process number are consistent.

[0223] In one embodiment of the present disclosure, the acquisition module 1402 is further used to: receive a recovery start indication or a regular start indication sent by the distributed storage system, and the recovery start indication or the regular start indication is sent when it is verified that the first process number and the second process number are inconsistent.

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

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

[0226] In one embodiment of the present disclosure, the acquisition module 1402 is also used to: intercept and monitor the thread running function through a probe to obtain the executable task of the first instance, where the executable task is an ongoing consumption; and terminate the executable task in the callback function before creating a checkpoint through the target interface.

[0227] In one embodiment of the present disclosure, the acquisition module 1402 is further used to: monitor web page Web requests; terminate the monitoring of the Web requests before creating a checkpoint, and return a response message corresponding to the Web request, wherein the monitored Web request is an ongoing consumption.

[0228] In one embodiment of the present disclosure, the acquisition module 1402 is further used to: obtain 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 instance startup device of a microservice provided by an embodiment of the present disclosure, 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, and sends 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 perform CRaC startup, thereby improving the startup speed of the second instance to quickly reach the optimal running state.

[0230] Fig.15 A schematic diagram of the structure of a device for starting an instance of a microservice provided in an embodiment of the present disclosure.

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

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

[0233] The startup module 1502 is configured to execute CRaC startup on the second instance based on the checkpoint snapshot.

[0234] In one embodiment of the present disclosure, the acquisition module 1501 is also used to: determine whether there is a checkpoint snapshot 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 the present disclosure, the device further includes: sending a CRaC startup process number to a distributed storage system and writing it into a CRaC file; or sending a CRaC recovery process number to a distributed storage system and writing it into a CRaC recovery file.

[0236] In one embodiment of the present disclosure, the device further includes: determining attribute information of the microservice, and determining whether the microservice has the CRaC function based on the attribute information.

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

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

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

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

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

[0242] Fig.16 A schematic block diagram of an example electronic device 1600 that can be used to implement an embodiment 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 can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0243] like Fig.16As shown, the device 1600 includes a computing unit 1601, which can perform various appropriate actions and processes according to a computer program / instruction stored in a read-only memory (ROM) 1602 or a computer program / instruction loaded from a storage unit 1606 to a random access memory (RAM) 1603. In the RAM 1603, various programs and data required for the operation of the device 1600 can also be stored. The computing unit 1601, the ROM 1602, and the RAM 1603 are connected to each other via a bus 1604. An input / output (I / O) interface 1605 is also connected to the bus 1604.

[0244] A number of components in the device 1600 are connected to the I / O interface 1605, including: an input unit 1606 such as a keyboard, a mouse, etc.; an output unit 1607 such as various types of displays, speakers, etc.; a storage unit 1608 such as a disk, an optical disk, etc.; and a communication unit 1609 such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 1609 allows the device 1600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0245] The computing unit 1601 may be a variety of general and / or special 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 dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 1601 performs the various methods and processes described above, such as the instance startup method of the microservice. For example, in some embodiments, the instance startup method of the microservice may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 1606. In some embodiments, part or all of the computer program / instructions may be loaded and / or installed on the device 1600 via the ROM 1602 and / or the communication unit 1609. When the computer program / instructions are loaded into the RAM 1603 and executed by the computing unit 1601, one or more steps of the instance startup method of the microservice described above may be performed. Alternatively, in other embodiments, the computing unit 1601 may be configured to execute the instance startup method of the microservice in any other appropriate manner (for example, by means of firmware).

[0246] Various implementations 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 chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented 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 can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0247] The program code for implementing the method of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be implemented. The program code may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0248] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, 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 (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the 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 acoustic input, voice input, or tactile input).

[0250] The systems and techniques described herein can be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), the Internet, and a blockchain network.

[0251] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship of client and server is generated by computer programs / instructions running on respective computers and having a client-server relationship with each other. The server may be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0252] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in the disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in the disclosure can be achieved, and this document does not limit them here.

[0253] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A method for starting an instance of a microservice, wherein: Executed by a distributed storage system, the method includes: Obtaining a checkpoint snapshot of a first instance startup phase sent by a first device, where the checkpoint snapshot is 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; According to the snapshot request, the checkpoint snapshot is sent to the second device, where the checkpoint snapshot includes relevant information required for the second instance to execute the checkpoint coordinated recovery CRaC startup.

2. The method according to claim 1, wherein: The sending the checkpoint snapshot to the second device according to the snapshot request includes: Verifying the checkpoint snapshot according to the snapshot request; In response to passing the verification, sending the checkpoint snapshot to the second device; In response to failure to pass the verification, obtaining a timestamp of a task completion file corresponding to the checkpoint snapshot; In response to the time interval between the timestamp and the current time not exceeding the set time period, after waiting for the set time period, the checkpoint snapshot is re-verified until the number of verifications exceeds the set number of times.

3. The method according to claim 2, wherein: The verifying the checkpoint snapshot according to the snapshot request includes: 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 according to the checkpoint snapshot; The checkpoint snapshot is verified according to the first verification information and the second verification information.

4. The method according to claim 1, wherein: Before obtaining the checkpoint snapshot of the first instance startup phase sent by the first device, the method further includes: Receiving a read lock request sent by the first device; Determining the lock information from a lock file; In response to the lock information being unoccupied, sending the lock information to the first device; receiving an instance identifier of the 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 is not the instance identifier of the first instance, read lock failure information is sent to the first device, where the read lock failure information indicates that the first instance executes CRaC startup.

5. The method according to claim 4, wherein: The method further comprises: In response to the lock information not existing in the lock file, a lock generation function is called to generate the lock information, and the lock information is sent to the first device.

6. The method according to claim 4, wherein: The method further comprises: Determine whether there is currently a task completion file corresponding to the checkpoint snapshot; 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.

7. The method according to any one of claims 1 to 6, wherein: Before obtaining the checkpoint snapshot of the first instance startup phase sent by the first device, the method further includes: receiving a process number verification request sent by the first device, wherein the process number verification request includes a first process number of the first instance that is creating a checkpoint; Reading from the CRaC file a second process number configured for the first instance for creating a checkpoint; In response to the first process number and the second process number being consistent, a creation indication for creating a checkpoint is sent to the first device.

8. The method according to claim 7, wherein: The method further comprises: In response to the first process number and the second process number being inconsistent, reading a recovery startup file; In response to the recovery startup file existing, determining a third process number recorded in the recovery startup file; In response to the first process number and the third process number being consistent, sending a recovery startup indication to the first device; In response to at least one of the absence of the recovery startup file and the inconsistency between the first process number and the third process number, a normal startup indication is sent to the first device.

9. The method according to any one of claims 1 to 6, wherein: The method further comprises: A CRaC file read request is received from the first device or the second device when CRaC is enabled, and in response to the CRaC file not existing, a normal startup indication is sent to the first device or the second device.

10. The method according to any one of claims 1 to 6, wherein: The method further comprises: receiving a CRaC startup process number sent by the first device or the second device after startup is completed, and writing the number into a CRaC file; or, Receive the CRaC recovery process number sent by the first device or the second device after the recovery is completed, and write it into the CRaC recovery file.

11. A method for starting a microservice instance, wherein: Executed by a first device, the first device running a first instance of a microservice, the method comprising: Monitoring the running status of the first instance during the startup phase; In response to the running state satisfying a set condition, obtaining a checkpoint snapshot of the first instance when the running state satisfies the set condition; The checkpoint snapshot is sent to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

12. The method according to claim 11, wherein: Before obtaining the checkpoint snapshot of the first instance when the running state meets the set condition, the method includes: In response to the startup operation of the first instance, preloading and initializing key classes and resources of the first instance based on an object-oriented programming language virtual machine JVM; After the first instance is started, JIT is performed on the first instance to obtain JIT information of the first instance.

13. The method according to claim 11, wherein: The obtaining of a checkpoint snapshot of the first instance when the running state satisfies a set condition includes: Obtaining operating parameters of the first instance when the operating state meets a set condition; The checkpoint snapshot is determined according to the operating parameters and the JIT information.

14. The method according to claim 11, wherein: Before obtaining the checkpoint snapshot of the first instance when the running state meets the set condition, the method further includes: Sending a read lock request to the distributed storage system; receiving the lock information sent by the distributed storage system, and sending the instance identifier of the first instance to the distributed storage system; Receiving read lock failure information sent by the distributed storage system, where the read lock failure information indicates that the first instance executes CRaC startup; Receive an invalid indication of the lock information sent by the distributed storage system, and release the lock information.

15. The method according to claim 14, wherein: The sending a read lock request to the distributed storage system includes: Obtaining the cumulative duration of execution of the JVM and the JIT by the first instance, and in response to the cumulative duration being not greater than the set duration, sending a read lock request to the distributed storage system; In response to the accumulated duration being greater than a set duration, CRaC startup is performed on the first instance.

16. The method according to any one of claims 11 to 15, wherein: The method further comprises: Sending a process number verification request to the distributed storage system, the process number verification request including a first process number of the first instance creating a checkpoint; A creation instruction for creating a checkpoint sent by the distributed storage system is received, wherein the creation instruction is sent when it is verified that the first process number and the second process number are consistent.

17. The method according to claim 16, wherein: The method further comprises: A recovery start indication or a regular start indication is received from the distributed storage system, where the recovery start indication or the regular start indication is sent when it is verified that the first process number and the second process number are inconsistent.

18. The method according to any one of claims 11 to 15, wherein: Before monitoring the running status of the first instance during the startup phase, the method further includes: Determine attribute information of the microservice, and determine whether the first instance has a CRaC function based on the attribute information.

19. The method according to any one of claims 11 to 15, wherein: Before obtaining the checkpoint snapshot of the first instance when the running state meets the set condition, the method further includes: Determine the consumption that was in progress when the checkpoint was created, and terminate the consumption that was in progress.

20. The method according to claim 19, wherein: The determining of the ongoing consumption when the checkpoint is created, and terminating the ongoing consumption, includes: Intercepting and monitoring the thread running function through a probe to obtain an executable task of the first instance, wherein the executable task is the ongoing consumption; The runnable task is terminated in the callback function before the checkpoint is created through the target interface.

21. The method according to claim 19, wherein: The determining of the ongoing consumption when the checkpoint is created, and terminating the ongoing consumption, includes: Monitor web page requests; Before creating a checkpoint, the monitored Web request is terminated, and a response message corresponding to the Web request is returned, wherein the monitored Web request is the ongoing consumption.

22. The method according to any one of claims 11 to 15, wherein: Before obtaining the checkpoint snapshot of the first instance when the running state meets the set condition, the method further includes: Obtain the file descriptor of the current process of the microservice, and determine the resource path pointed to by the file descriptor; According to the resource path, the related resources of the current process of the microservice are closed.

23. A method for starting an instance of a microservice, wherein: Executed by a second device, the second device running a second instance of the microservice, the method comprising: Obtaining a checkpoint snapshot corresponding to the first instance, wherein the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup; Based on the checkpoint snapshot, CRaC startup is performed on the second instance.

24. The method according to claim 23, wherein: The obtaining of the checkpoint snapshot corresponding to the first instance includes: Determine whether the checkpoint snapshot exists in the instance container; In response to the checkpoint snapshot being present in the instance container, reading the checkpoint snapshot from the instance container; In response to the checkpoint snapshot not existing in the instance container, a snapshot acquisition request is sent to the distributed storage system, and the checkpoint snapshot sent by the distributed storage system is received.

25. The method according to claim 23, wherein: The method further comprises: Send the CRaC startup process number to the distributed storage system and write it into the CRaC file; or, The CRaC recovery process number is sent to the distributed storage system and written into the CRaC recovery file.

26. The method of claim 23, wherein: The method further comprises: Determine attribute information of the microservice, and determine whether it has a CRaC function based on the attribute information.

27. The method according to any one of claims 23 to 26, wherein: The method further comprises: The startup script obtains the environment information of the second instance; The environment information is written into environment variables through middleware, and the CRaC startup is performed based on the environment variables and the checkpoint snapshot.

28. The method of claim 22, wherein: The method further comprises: After the CRaC is started or restored, determining whether a resource path exists for the second instance; In response to the existence of the resource path, additionally writing the related resources of the second instance under the resource path; In response to the resource path not existing, a new file is created based on the resource path and the related resources of the second instance are written into the new file.

29. A device for starting a microservice instance, wherein: Applicable to a distributed storage system, the device comprises: An acquisition module, configured to acquire a checkpoint snapshot of a first instance startup phase sent by a first device, wherein the checkpoint snapshot is a snapshot when the 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 is used to send the checkpoint snapshot to the second device according to the snapshot request, where the checkpoint snapshot includes relevant information required for the second instance to execute the checkpoint coordinated recovery CRaC startup.

30. A device for starting a microservice instance, wherein: Applicable to a first device, the first device running a first instance of a microservice, the apparatus comprising: A monitoring module, used to monitor the running status of the first instance during the startup phase; an acquisition module, configured to acquire, in response to the running state satisfying a set condition, a checkpoint snapshot of the first instance when the running state satisfies the set condition; The sending module is used to send the checkpoint snapshot to the distributed storage system, where the checkpoint snapshot includes relevant information required for the second instance to perform CRaC startup.

31. A device for starting a microservice instance, wherein: Applicable to a second device, the second device running a second instance of a microservice, the apparatus comprising: An acquisition module, configured to acquire 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 startup module is used to perform CRaC startup on the second instance based on the checkpoint snapshot.

32. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; 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 according to any one of claims 1 to 28.

33. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1-28.

34. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the method of any one of claims 1-28 is implemented.

Images