Method for updating a computing service and electronic device
By constructing detection information and detection intervals, and detecting the running status of computing services based on resource and performance parameters, the problem of low reliability during computing service updates is solved, and a more reliable update process is achieved.
Patent Information
- Application Number
- CN202611529212.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-29
- Publication Date
- 2026-11-03
AI Technical Summary
In the existing technology, the running status detection method is difficult to accurately identify the actual status during the computing service update process, resulting in low reliability of computing service updates and easy occurrence of misjudgment or failure to handle anomalies in a timely manner.
By acquiring resource and performance parameters, detection information is constructed, detection intervals are divided, and detection conditions are configured. The running status of the target computing service is detected based on its current runtime and the detection information, and then it is decided whether to update.
This improves the reliability of computing service updates and reduces unnecessary update interventions due to misjudgments of operational status or failure to handle operational anomalies in a timely manner.
Smart Images

Figure CN123030211A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more particularly to a method for updating computing services and an electronic device. Background Technology
[0002] In related technologies, during the update process of computing services, to avoid operational anomalies in the new version of the computing service that could affect normal business operations, the running status of the new version of the computing service is usually monitored, and an intervention is determined based on the running status. However, due to the complexity of the operation of computing services, existing running status monitoring methods are unable to accurately identify the actual running status of the computing service, easily misjudging normal operation as anomaly, or failing to detect anomalies in a timely manner. This leads to unnecessary update intervention operations or untimely handling of anomalies, resulting in low reliability of computing service updates. Summary of the Invention
[0003] This application provides a method and electronic device for updating computing services, to at least solve the problem of low reliability of computing service updates in related technologies.
[0004] This application provides a method for updating a computing service, comprising: receiving an update request, wherein the update request is used to request updating a reference computing service running on a computing device to a target computing service; responding to the update request and obtaining detection information corresponding to resource parameters and performance parameters, wherein the resource parameters are used to indicate the loading requirements of resource data required to start the target computing service on the computing device, the performance parameters are used to indicate the computing device's ability to load resource data, the detection information records corresponding detection intervals and detection conditions, the detection information is constructed based on the resource parameters and performance parameters, multiple detection intervals are used to indicate different runtime ranges after the target computing service is started, and the detection conditions are used to indicate the runtime characteristics of the target computing service when a runtime abnormality occurs within the corresponding detection interval; detecting the current runtime of the target computing service based on the current runtime of the target computing service and the detection information, wherein the current runtime is used to indicate the occurrence of runtime abnormalities of the target computing service within the detection interval in which the current runtime falls; and updating the reference computing service based on the current runtime.
[0005] This application also provides a computing service update apparatus, comprising: a receiving module for receiving an update request, wherein the update request is for requesting that a reference computing service running on a computing device be updated to a target computing service; a response module for responding to the update request and obtaining detection information corresponding to resource parameters and performance parameters, wherein the resource parameters are for indicating the loading requirements of resource data required to start the target computing service on the computing device, the performance parameters are for indicating the computing device's ability to load resource data, the detection information records corresponding detection intervals and detection conditions, the detection information is constructed based on the resource parameters and performance parameters, multiple detection intervals are respectively used to indicate different runtime ranges after the target computing service is started, and the detection conditions are used to indicate the running characteristics of the target computing service when a running abnormality occurs within the corresponding detection interval; a detection module for detecting the current running state of the target computing service based on the current runtime of the target computing service and the detection information, wherein the current running state is for indicating the occurrence of running abnormalities of the target computing service within the detection interval in which the current runtime falls; and an update module for updating the reference computing service based on the current running state.
[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the update method of any of the above-described computing services.
[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the update method for any of the above-described computing services.
[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of updating any of the above-described computing services.
[0009] This application addresses the challenge of improving the reliability of computing service updates during the update process. It allows for the acquisition of detection information, which records corresponding detection intervals and conditions, based on the resource data loading requirements of the target computing service and the computing device's resource data loading capabilities. This ensures that the detection conditions for different detection intervals align with the operating status of the target computing service within their respective runtime ranges. Furthermore, the current operating status of the target computing service is detected based on its current runtime and the detection information, and the reference computing service is updated accordingly. This reduces unnecessary update interventions due to misjudgments of the operating status or failure to promptly address operational anomalies. Therefore, this application resolves the technical problem of low reliability in computing service updates, thereby improving the overall reliability of computing service updates. Attached Figure Description
[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0011] Figure 1 This is a hardware structure block diagram of a computing device according to an embodiment of this application;
[0012] Figure 2 This is a flowchart of a computing service update method according to an embodiment of this application;
[0013] Figure 3 This is an interactive schematic diagram of a computing service update method according to an embodiment of this application;
[0014] Figure 4 This is a schematic diagram of a detection interval division according to an embodiment of this application;
[0015] Figure 5 This is a schematic diagram of a computing service update system according to an embodiment of this application;
[0016] Figure 6 This is a structural block diagram of a computing service update apparatus according to an embodiment of this application. Detailed Implementation
[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0018] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0019] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0020] The computing service update method provided in this application embodiment can be executed in edge computing nodes, servers, industrial computers, or other electronic devices with computing capabilities, or it can be executed collaboratively by multiple devices. The following description uses an example running on a computing device. Figure 1 This is a hardware structure block diagram of a computing device according to an embodiment of this application. Figure 1 As shown, the computing device may include at least one ( Figure 1 (Only one is shown) A processor 102, a memory 104 for storing data, a transmission device 106 for communication, and an input / output device 108. The processor 102 may include, but is not limited to, a central processing unit (CPU), a microprocessor (MCU), a field-programmable gate array (FPGA), or other processing devices capable of performing data processing operations. The memory 104 may be used to store computer programs, and the processor 102 can execute the computing service update method in this embodiment by running the computer program stored in the memory 104. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computing device. For example, the computing device may also include components that are larger than... Figure 1 Showing more or fewer components, or having with Figure 1 Different configurations are shown. For example, a computing device may also include device memory, system memory, computing accelerator memory, and computing accelerators, wherein the computing accelerators may include, but are not limited to, graphics processing units (GPUs) or neural processing units (NPUs).
[0021] The memory 104 can be used to store computer programs, such as software programs and modules for storage service management software, like the computer program corresponding to the computing service update method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thus implementing the methods described above. The memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memories. In some instances, the memory 104 may also include memories remotely located relative to the processor 102, which can be connected to the computing device via a network.
[0022] The transmission device 106 is used to receive or send data via a network. This network may include, but is not limited to, the Internet, an intranet, a local area network, a storage area network, a mobile communication network, or a combination thereof. In one instance, the transmission device 106 may be used to receive update requests sent by a cloud management node, or to send update results of computing services to the cloud management node. In another instance, the transmission device 106 may also be used to receive a new version service image of a target computing service, or to send runtime logs and exception information generated during the computing service update process to the cloud management node.
[0023] The input / output device 108 can be used to receive update operations of the computing service or output update results of the computing service. For example, the input / output device 108 may include a display device and an input device. Staff can trigger update operations of the computing service through the input device and view the running status and update results of the target computing service through the display device.
[0024] This embodiment provides a method for updating computing services. Figure 2 This is a flowchart of a computing service update method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:
[0025] Step S12, receive an update request, wherein the update request is used to request that the reference computing service running on the computing device be updated to the target computing service;
[0026] Step S14: Respond to the update request and obtain detection information corresponding to the resource parameters and performance parameters. The resource parameters are used to indicate the loading requirements of the resource data required to start the target computing service on the computing device, and the performance parameters are used to indicate the computing device's ability to load resource data. The detection information records the corresponding detection intervals and detection conditions. The detection information is constructed based on the resource parameters and performance parameters. Multiple detection intervals are used to indicate different runtime ranges after the target computing service is started, and the detection conditions are used to indicate the running characteristics of the target computing service when a running abnormality occurs in the corresponding detection interval.
[0027] Step S16: Detect the current running status of the target computing service based on the current runtime of the target computing service and the detection information. The current running status is used to indicate the occurrence of any abnormal running of the target computing service within the detection interval in which the current runtime falls.
[0028] Step S18: Update the reference computing service according to the current operating status.
[0029] Through the above steps, during the computing service update process, detection information recording corresponding detection intervals and conditions can be obtained based on the loading requirements of the resource data required by the target computing service and the loading capacity of the computing device. This ensures that the detection conditions corresponding to different detection intervals are adapted to the operating status of the target computing service within the corresponding runtime range. Then, the current operating status of the target computing service is detected based on its current runtime and the detection information, and the reference computing service is updated accordingly. This reduces unnecessary update interventions due to misjudgments of the operating status or failure to promptly handle operational anomalies. Therefore, this application solves the technical problem of low reliability in computing service updates, thereby achieving the technical effect of improving the reliability of computing service updates.
[0030] Optionally, in this embodiment, the computing service can be an artificial intelligence (AI) service deployed on a computing device, or other computing services that require loading resource data during startup. The computing service can be used to perform model inference, image processing, data analysis, or other computing tasks.
[0031] Optionally, in this embodiment, the reference computing service is the computing service currently running on the computing device, and the target computing service is the new version of the computing service to be deployed to the computing device. For example, if the AI service currently running on the computing device uses a first-version model to perform inference tasks, and it needs to be updated to use a second-version model, the AI service using the first-version model can be used as the reference computing service, and the AI service using the second-version model can be used as the target computing service. The computing device can start the target computing service after receiving an update request and monitor its running status during operation to determine whether to intervene in the update process based on its running status.
[0032] In the embodiment provided in step S12 above, the update request may, but is not limited to, carrying the service identifier, version identifier, storage address of the new version service image, or the new version service image of the target computing service. The service identifier is used to distinguish different computing services deployed on the computing device, the version identifier is used to distinguish different versions of the same computing service, the storage address is used to indicate the storage location of the new version service image, and the new version service image is used to start the target computing service.
[0033] Optionally, in this embodiment, if the service identifier and version identifier are identified from the update request, the computing device can determine the reference computing service to be updated based on the service identifier and search for the new version service image corresponding to the service identifier and version identifier from the image repository. If the service identifier and the storage address of the new version service image are identified from the update request, the computing device can determine the reference computing service to be updated based on the service identifier and obtain the new version service image from the local storage address.
[0034] In this embodiment, Figure 3 This is an interactive schematic diagram of a computing service update method according to an embodiment of this application. For example... Figure 3 As shown, the cloud management node sends an update request to the computing device; the computing device responds to the update request, obtains the detection information corresponding to the resource parameters and performance parameters, and detects the current running status of the target computing service based on the current runtime of the target computing service and the detection information; subsequently, the computing device updates the reference computing service according to the current running status and returns the update result to the cloud management node.
[0035] Optionally, in this embodiment, the update request can be sent from the cloud management node to the computing device, or it can be generated by the service management program on the computing device.
[0036] In the embodiment provided in step S14 above, the computing device can determine the target computing service to be started this time according to the update request, obtain the resource parameters of the target computing service and the performance parameters of the computing device, and then obtain the detection information corresponding to the resource parameters and performance parameters.
[0037] Optionally, in this embodiment, the resource data can be the data required to start the target computing service. For example, if the target computing service is an AI service, the resource data may include model weight data and data that needs to be loaded into the computing accelerator. The resource data loading requirement may refer to, but is not limited to, the amount of resource data. It is understood that different computing services may use different models and running data, and the amount of data that needs to be loaded at startup may also be different. Therefore, the time required for the computing device to complete the resource data loading may also be different.
[0038] Optionally, in this embodiment, if the configuration information of the target computing service records the amount of resource data required to start the target computing service, the computing device may, but is not limited to, read the amount of data from the configuration information to obtain resource parameters. If the configuration information does not record the aforementioned amount of data, the computing device may, but is not limited to, obtain the resource file corresponding to the resource data, read the size of the resource file, and determine the read value as the resource parameter.
[0039] Optionally, in this embodiment, the computing device can determine performance parameters based on actual data loading. For example, after receiving an update request, the computing device loads a first preset amount of data, calculates the measured loading rate based on the first preset amount of data and the actual loading time, and then determines the measured loading rate as a performance parameter. In another optional embodiment, the computing device can obtain performance parameters from historical operation records, which record the historical loading rates when the computing device added resource data when starting historical computing services. For example, when receiving an update request, the computing device can find the historical loading rate corresponding to a historical computing service of the same type as the target computing service from the historical operation records, and determine the historical loading rate as the performance parameter used for this update.
[0040] In one optional implementation, the computing device can construct detection information based on the resource and performance parameters involved in the update. For example, the computing device can determine the amount of resource data involved in each resource loading operation and the loading rate when the computing device performs the corresponding resource loading operation, based on the multiple resource loading operations required during the startup of the target computing service. It can then predict the estimated time consumption of each resource loading operation, determine the corresponding time boundaries based on the estimated time consumption of each resource loading operation, and thus determine multiple runtime ranges after the target computing service starts, obtaining multiple detection intervals. The computing device can also determine corresponding detection conditions based on the operations that the target computing service needs to perform within each detection interval. For example, within the detection interval for performing model weight reading operations, failure to read model weights can be used as the runtime characteristic indicated by the corresponding detection condition; within the detection interval for performing data transmission operations, failure to transmit data to the computing accelerator can be used as the runtime characteristic indicated by the corresponding detection condition; and within the detection interval after the expected completion of the above resource loading operations, continuous request processing timeouts can be used as the runtime characteristic indicated by the corresponding detection condition.
[0041] In another alternative implementation, the computing device can utilize historical detection information saved during previous computing service updates. For example, the computing device can save historical detection information used in previous updates, as well as historical resource parameters and performance parameters used to construct that historical detection information. If the amount of resource data required for the current update is similar to the amount indicated by the historical resource parameters, and the current loading rate of the computing device is similar to the loading rate indicated by the historical performance parameters, the historical detection information can be obtained as the detection information used for the current update, thus eliminating the need to reconstruct the detection information for each update. For example, the computing device can use the differences between the aforementioned data amounts and the differences between the loading rates within a preset range as a basis for determining whether the current update is similar to the historical update process.
[0042] In another optional implementation, after obtaining the aforementioned historical detection information, the computing device can further adjust the historical detection information based on the resource and performance parameters involved in the current update to obtain the detection information used in the current update. For example, the computing device can re-predict the estimated time consumption of each resource loading operation based on the differences between the resource and performance parameters of the current update and the historical resource and performance parameters used when constructing the historical detection information, and adjust the time boundaries of the relevant detection intervals in the historical detection information accordingly. For instance, if reading model weight data was expected to take 2 seconds during a historical update, but is expected to take 4 seconds in this update due to the increased amount of model weight data, the detection duration of the detection interval performing the model weight reading operation can be adjusted from 2 seconds to 4 seconds. If the operations involved in each detection interval remain unchanged, the corresponding detection conditions can be retained to obtain the adjusted detection information.
[0043] In the embodiment provided in step S16 above, the current runtime can be the elapsed time from the start of the target computing service to the current moment. The computing device can determine the detection interval into which the current runtime falls and its corresponding detection conditions from the detection information recorded as having a corresponding relationship, based on the current runtime, and detect the operation of the target computing service according to these detection conditions to obtain the current operating status. The current operating status can be used to indicate whether an operational anomaly meeting the corresponding detection conditions has been detected within the detection interval into which the current runtime falls.
[0044] In one optional implementation, the computing device can perform operational status detection on the target computing service according to a preset detection cycle. For example, the computing device can obtain the current runtime of the target computing service in each detection cycle, determine the detection interval in which the current runtime falls and its corresponding detection conditions, and then detect whether the operation of the target computing service in that detection cycle meets the operational characteristics indicated by the detection conditions.
[0045] In another alternative implementation, the computing device can also trigger runtime status detection when it detects a runtime event of the target computing service. For example, if it detects a process exit event or an out-of-memory event of the target computing service, the computing device can obtain the current runtime at the time the event occurred, determine the corresponding detection conditions, and then detect whether the event meets the runtime characteristics indicated by the detection conditions.
[0046] In the embodiment provided in step S18 above, the computing device can determine whether to perform an update intervention operation or other operations based on the current operating state. For example, if the current operating state indicates that the target computing service has not experienced an operational anomaly, the computing device can continue to monitor the operating state of the target computing service and record the duration during which the target computing service has not experienced an operational anomaly. When this duration reaches a preset running time, the computing device can send a message to the sender of the update request indicating that the update was successful. If the current operating state indicates that the target computing service has experienced an operational anomaly, the computing device can revert the target computing service to a reference computing service, allowing the reference computing service to reprocess the business request and send a message to the sender indicating that the update failed.
[0047] As an optional solution, detection information corresponding to resource parameters and performance parameters can be obtained in the following ways, but not limited to: S21, generating multiple detection intervals based on resource parameters and performance parameters; configuring detection conditions for each of the multiple detection intervals to obtain detection information; or, S22, searching for detection information corresponding to resource parameters and performance parameters from reference resource parameters, reference performance parameters, and reference detection information that have a corresponding relationship, wherein the reference detection information is constructed based on the corresponding reference resource parameters and the corresponding reference performance parameters.
[0048] In the embodiment provided in step S21 above, the computing device can determine multiple detection intervals after the target computing service is started based on the loading requirements of resource data indicated by the resource parameters and the loading capacity indicated by the performance parameters, and configure corresponding detection conditions for each detection interval.
[0049] Optionally, in this embodiment, for multiple resource loading operations executed sequentially, the computing device can calculate the estimated time for each resource loading operation based on the data volume and loading rate of each operation, and then accumulate the estimated time according to the execution order of the resource loading operations to determine the start and end times of each detection interval. For example, if the first resource loading operation is expected to take 2 seconds and the second resource loading operation is expected to take 3 seconds, then 0 seconds to 2 seconds after startup can be determined as the first detection interval, and 2 seconds to 5 seconds can be determined as the second detection interval.
[0050] Optionally, in this embodiment, for multiple resource loading operations that have a parallel execution relationship, the computing device can determine the expected start time and expected end time of each resource loading operation by combining the expected time consumption and execution relationship of each resource loading operation, and divide multiple detection intervals using the expected start time and expected end time of each resource loading operation as time boundaries. For example, if two resource loading operations both start executing after the target computing service is started, and are expected to end at the 2nd second and the 4th second, respectively, then the 0th to 2nd second and the 2nd to 4th second after startup can be divided into different detection intervals.
[0051] Optionally, in this embodiment, the computing device can pre-store operation types and anomaly detection rules with corresponding relationships, obtain the corresponding anomaly detection rules according to the operation types of the operations that the target computing service needs to perform in each detection interval, and configure the anomaly detection rules as the detection conditions of the corresponding detection interval.
[0052] In the embodiment provided in step S22 above, the computing device can store corresponding reference resource parameters, reference performance parameters, and reference detection information. Each piece of reference detection information is constructed based on the corresponding reference resource parameters and reference performance parameters during historical processing. It is understood that the aforementioned reference detection information is not required to be constructed by this computing device; it can also be constructed by other computing devices or cloud management nodes. For example, the corresponding reference resource parameters, reference performance parameters, and reference detection information can be carried in an update request, received and stored by the computing device; alternatively, they can be pre-distributed by the cloud management node and stored in the computing device's local memory for use in subsequent computing service updates.
[0053] Optionally, in this embodiment, the computing device can perform a precise search based on resource parameters and performance parameters. For example, it can find reference detection information corresponding to reference resource parameters and reference performance parameters that are identical to the resource parameters and performance parameters updated in this instance from the above correspondence, and use this information as the detection information used in this update. In another optional embodiment, the computing device can also search according to a preset parameter range. For example, it can calculate the differences between the resource parameters updated in this instance and each set of reference resource parameters, and the differences between the performance parameters and each set of reference performance parameters, and use the parameter group whose differences are both within the corresponding preset range as the matching result. If the matching result includes a set of parameter groups, the reference detection information corresponding to that set is obtained as the detection information used in this update; if the matching result includes multiple sets of parameter groups, the set of parameter groups with the smallest parameter difference is selected from the matching result, and its corresponding reference detection information is used as the detection information used in this update.
[0054] As an optional approach, multiple detection intervals can be generated based on resource parameters and performance parameters in the following ways, but not limited to: S31, generating a reference duration based on resource parameters and performance parameters, wherein the reference duration is the estimated duration required for the computing device to complete loading resource data; S32, generating a startup detection interval and a running detection interval based on the reference duration, wherein the startup detection interval is used to indicate the range of runtime after the target computing service starts with the reference duration, and the running detection interval is used to indicate the range of runtime after the target computing service starts exceeding the reference duration, and the multiple detection intervals include the startup detection interval and the running detection interval.
[0055] In this embodiment, Figure 4 This is a schematic diagram of a detection interval division according to an embodiment of this application. For example... Figure 4 As shown, the computing device uses the startup time of the target computing service as the time starting point 0, generates a reference duration T based on resource and performance parameters, and uses the reference duration T as the time boundary. The runtime range of the target computing service after startup that does not exceed the reference duration T is defined as the startup detection interval, and the runtime range that exceeds the reference duration T is defined as the operation detection interval. The startup detection interval includes the time corresponding to the reference duration T, while the operation detection interval does not include that time.
[0056] In the embodiment provided in step S31 above, the computing device can determine the estimated time for each resource loading operation based on the amount of resource data involved in each resource loading operation and the loading rate of the computing device, and predict the time required to complete the loading of all resource data by combining the execution relationship of each resource loading operation, and obtain a reference duration.
[0057] Optionally, in this embodiment, for multiple resource loading operations executed sequentially, the computing device can divide the amount of resource data involved in each resource loading operation by the loading rate to obtain the estimated time for each resource loading operation. Then, the estimated time for each resource loading operation is added together according to the execution order to obtain a reference duration. For example, if the estimated time for the model weight reading operation and the data transmission operation are 2 seconds and 3 seconds respectively, and the data transmission operation is executed after the model weight reading operation is completed, the estimated time for the two operations can be added together to obtain a reference duration of 5 seconds.
[0058] Optionally, in this embodiment, for multiple resource loading operations that have a parallel execution relationship, the computing device can determine the expected end time of each resource loading operation based on its expected start time and expected duration, and then determine the reference duration based on the latest expected end time. For example, if two resource loading operations both start executing after the target computing service starts, and are expected to end at 2 seconds and 4 seconds respectively, then 4 seconds can be determined as the reference duration.
[0059] In the embodiment provided in step S32 above, the computing device can use the start time of the target computing service as the start time of the detection interval, and determine the time boundary between the start detection interval and the running detection interval based on the reference duration.
[0060] Optionally, in this embodiment, the computing device can define the runtime range after the target computing service starts, which does not exceed a reference duration, as the startup detection interval, and the runtime range exceeding the reference duration as the running detection interval. In another optional implementation, the computing device can also determine multiple running detection intervals based on the reference duration and a preset detection interval. For example, with a reference duration of 5 seconds and a detection interval of 30 seconds, the 0 to 5 seconds after startup can be defined as the startup detection interval, the runtime range exceeding 5 to 35 seconds as the first running detection interval, the runtime range exceeding 35 to 65 seconds as the second running detection interval, and subsequent running detection intervals can be further divided according to the preset detection interval.
[0061] As an optional approach, a reference duration can be generated based on resource parameters and performance parameters in the following manner, but not limited to: S41, determining the ratio of weight parameters and access parameters as a first loading duration, and determining the ratio of loading parameters and transmission parameters as a second loading duration, wherein the weight parameters are used to indicate the amount of model weight data to be loaded from the device memory of the computing device to the system memory of the computing device required to start the target computing service, the access parameters are used to indicate the loading rate of the computing device loading model weight data from the device memory to the system memory, the loading parameters are used to indicate the amount of accelerator data to be loaded from the system memory to the computing accelerator memory of the computing device required to start the target computing service, and the transmission parameters are used to indicate the transmission rate of the computing device transmitting accelerator data from the system memory to the computing accelerator memory, the resource parameters include weight parameters and loading parameters, the performance parameters include access parameters and transmission parameters, and the resource data includes model weight data and accelerator data; S42, calculating the reference duration based on the first loading duration and the second loading duration.
[0062] In the embodiment provided in step S41 above, the device memory can be a non-volatile memory in the computing device used for persistent data storage, such as a solid-state drive (SSD) or a hard disk drive (HDD). The system memory can be the host memory in the computing device accessible to the processor, such as Double Data Rate Synchronous Dynamic Random Access Memory (DRAM). The computing accelerator memory can be the memory equipped in the computing accelerator in the computing device, such as the GPU's video memory or the NPU's dedicated memory. The computing accelerator can be used to perform computational tasks such as model inference for the target computing service. During the startup process of the target computing service, the computing device can first load the model weight data stored in the device memory into the system memory, and then transfer the accelerator data from the system memory to the accelerator memory for the computing accelerator to perform the corresponding computational tasks.
[0063] Optionally, in this embodiment, the computing device can read the data volume of the model weight data and the data volume of the accelerator data from the configuration information of the target computing service to obtain weight parameters and loading parameters. Simultaneously, after receiving an update request, the computing device can measure its loading rate and transmission rate based on the execution relationship between the model weight data loading operation and the accelerator data transmission operation. When the two operations are executed sequentially, the computing device can first load a second preset data volume from the device memory to the system memory, recording the actual loading time, and then transmit a third preset data volume from the system memory to the computing accelerator memory, recording the actual transmission time. When the two operations are executed in parallel, the computing device can simultaneously execute the data loading operation and the data transmission operation, recording the actual loading time and the actual transmission time respectively. The computing device determines the ratio of the second preset data volume to the actual loading time as the access parameter, and the ratio of the third preset data volume to the actual transmission time as the transmission parameter.
[0064] Optionally, in this embodiment, the computing device can divide the amount of data indicated by the weight parameters by the loading rate indicated by the access parameters to obtain a first loading duration; and divide the amount of data indicated by the loading parameters by the transmission rate indicated by the transmission parameters to obtain a second loading duration. For example, if the amount of model weight data is 3.6GB, of which approximately 3.2GB needs to be loaded into the computing accelerator memory, that is, the amount of accelerator data is 3.2GB, the loading rate of the device memory loading the model weight data into the system memory is 0.9GB / s, and the transmission rate of the system memory transmitting the accelerator data into the computing accelerator memory is 8GB / s, then the first loading duration is 4 seconds, and the second loading duration is 0.4 seconds.
[0065] In the embodiment provided in step S42 above, the computing device can calculate the reference duration using the first loading duration and the second loading duration based on the execution relationship between the loading operation of model weight data and the transmission operation of accelerator data.
[0066] Optionally, in this embodiment, when the two operations are executed sequentially, the computing device can add the first loading time and the second loading time to obtain a reference time. When the two operations are executed in parallel and both operations begin execution after the target computing service is started, the computing device can determine the larger value between the first loading time and the second loading time as the reference time.
[0067] By following the steps above, the time required for the target computing service to complete resource loading can be predicted based on the actual data loading rate of the computing device. The impact of sequential or parallel execution of the two operations on the execution time can also be considered, making it less likely that the target computing service will be misjudged as running abnormally during normal resource loading. At the same time, it reduces the possibility of delays in abnormal handling due to excessively long reserved time, thereby improving the reliability of computing service updates.
[0068] As an optional approach, the reference duration can be calculated based on the first loading duration and the second loading duration in the following manner, but not limited to: S51, obtaining the target preheating count and the single preheating duration, wherein the target preheating count is used to indicate the number of preheating inference operations required to start the target computing service, and the single preheating duration is the average duration required to perform one preheating inference operation; S52, determining the resource preheating duration by multiplying the target preheating count and the single preheating duration; S53, calculating the reference duration based on the first loading duration, the second loading duration, and the resource preheating duration.
[0069] In the embodiment provided in step S51 above, the computing device can read the target number of preheating operations from the configuration information of the target computing service and obtain the single preheating duration from the historical operation record. For example, the historical operation record also records the time consumed by each preheating inference operation when the computing device starts the historical computing service. The computing device can calculate the average of the times consumed each operation to obtain the single preheating duration. In another optional embodiment, the target number of preheating operations can also be preset by the computing device. For the single preheating duration, the computing device can perform multiple preheating inference operations on the corresponding model on the same type of computing device, record the time consumed by each operation, and use the average of the times consumed each operation as the single preheating duration.
[0070] In the embodiment provided in step S52 above, the computing device can predict the time required to complete all preheating inference operations based on the target number of preheating cycles and the duration of each preheating cycle. For example, if the target number of preheating cycles is 4 and the duration of each preheating cycle is 0.15 seconds, then the product of 4 and 0.15 seconds is determined as the resource preheating duration, which is 0.6 seconds.
[0071] In the embodiment provided in step S53 above, the computing device can combine the execution relationship between the loading operation of model weight data and the transmission operation of accelerator data to calculate the total time expected to be required for the loading of computing resources and the warm-up inference operation, and obtain the reference time.
[0072] Through the above steps, based on the prediction of resource loading time according to the actual data loading rate of the computing device and the execution relationship of loading operations, the time required for the target computing service to complete preheating inference is further considered, so that the predicted reference duration can cover the normal resource loading and preheating process, reduce the situation of misjudging the target computing service as running abnormally due to the preheating not being completed, and improve the reliability of computing service updates.
[0073] Optionally, in this embodiment, when the two operations are executed sequentially and the preheating inference operation is executed after the two operations are completed, the computing device can add the first loading duration, the second loading duration, and the resource preheating duration to obtain a reference duration. When the two operations are executed in parallel and the preheating inference operation is executed after both operations are completed, the computing device can add the larger value of the first loading duration and the second loading duration to the resource preheating duration to obtain a reference duration.
[0074] Optionally, in this embodiment, after obtaining the reference duration, the computing device can further adjust the reference duration. For example, the computing device can add a safety margin duration to the reference duration to obtain an adjusted reference duration. The computing device can use the adjusted reference duration as the reference duration for generating the startup detection interval and the running detection interval. The safety margin duration is used to account for the impact of factors such as runtime initialization, computation graph establishment, and the current load of the computing device on the actual startup time, and can be determined by multiplying the reference duration before adjustment by a preset ratio. For example, if the reference duration before adjustment is 5 seconds and the preset ratio is 20%, the safety margin duration is 1 second, and the adjusted reference duration is 6 seconds.
[0075] As an optional solution, detection conditions can be configured for multiple detection intervals respectively to obtain detection information in the following ways, but not limited to: S61, configure a first detection condition for the startup detection interval and configure a second detection condition for the running detection interval. The first detection condition is used to indicate the first running characteristics of the target computing service when a running abnormality occurs in the startup detection interval, and the second detection condition is used to indicate the second running characteristics of the target computing service when a running abnormality occurs in the running detection interval. The first running characteristics are used to characterize the event type of the abnormal running event of the target computing service, and the second running characteristics are used to characterize the degree of abnormality in the processing quality of the target computing service in processing business requests. The multiple detection conditions include the first detection condition and the second detection condition.
[0076] Optionally, in this embodiment, the computing device can configure detection conditions based on pre-saved operation types and anomaly detection rules with corresponding relationships. For example, based on the resource loading operations that the target computing service needs to perform during the startup detection period, anomaly detection rules are obtained to detect events such as abnormal process exit, segmentation fault, out-of-memory (OOM) anomalies, or computing accelerator driver anomalies, thus obtaining the first detection condition; based on the business request processing operations that the target computing service needs to perform during the running detection period, anomaly detection rules are obtained to determine the degree of anomaly of indicators such as request failure rate, request timeout rate, or P95 / P99 inference latency, thus obtaining the second detection condition. Here, P95 inference latency represents the latency value that 95% of the inference requests processed within the statistical time window do not exceed, and P99 inference latency represents the latency value that 99% of the inference requests processed within the statistical time window do not exceed.
[0077] Optionally, in this embodiment, the computing device can also determine the detection conditions based on the configuration information of the target computing service. For example, the computing device can obtain the event types of abnormal operating events that the target computing service needs to monitor from the configuration information to determine the first detection condition; and obtain the service request processing quality indicators and their allowable ranges that the target computing service needs to monitor from the configuration information to determine the second detection condition. If the configuration information does not record the corresponding allowable range, the allowable range can also be determined based on the request processing records during the normal operation of the reference computing service.
[0078] By following the steps above, we can identify key abnormal events that may prevent the target computing service from starting normally within the startup detection interval, rather than directly judging whether the target computing service is experiencing operational abnormalities based on the processing quality of business requests. This reduces the possibility of a normal startup process being mistakenly judged as an operational abnormality. Within the operation detection interval, we can determine whether the target computing service is experiencing operational abnormalities based on the actual processing status of business requests. This reduces the possibility of failing to detect operational abnormalities that affect business processing in a timely manner and improves the reliability of computing service updates.
[0079] As an optional approach, the current running status of the target computing service can be detected based on the current runtime of the target computing service and the detection information in the following ways, but not limited to: S71, find the target detection interval into which the current runtime falls from multiple detection intervals; S72, detect the current running status of the target computing service according to the target detection conditions corresponding to the target detection interval in the detection information.
[0080] In the embodiment provided in step S71 above, the computing device can determine the target detection interval based on the relationship between the current runtime and the start and end times of each detection interval.
[0081] Optionally, in this embodiment, for a detection interval with a start time and an end time, the computing device can compare the current runtime with the start and end times of the detection interval. If the current runtime is greater than the start time of the detection interval and less than or equal to the end time of the detection interval, the detection interval is determined as the target detection interval. For detection intervals without a set end time, for example, representing a runtime range exceeding a reference duration after the target computing service has started, the computing device can determine the detection interval as the target detection interval if the current runtime is greater than the start time of the detection interval.
[0082] In another alternative implementation, the computing device can also save the start and end times of each detection interval in chronological order, and determine the detection interval into which the current running time falls by binary search to obtain the target detection interval.
[0083] In the embodiment provided in step S72 above, the computing device can obtain the target detection conditions corresponding to the target detection interval from the detection information, and detect whether the target computing service has an operational abnormality based on the operating characteristics indicated by the target detection conditions.
[0084] Optionally, in this embodiment, the computing device can acquire the operational data of the target computing service. For example, the computing device can acquire the process status or request processing status of the target computing service, determine whether the acquired operational data meets the operational characteristics indicated by the target detection conditions, and generate the current operational state. In an optional implementation, the computing device can also receive operational events and operational logs reported by the target computing service or its operating environment, extract information related to the target detection conditions from them, determine whether the extracted information meets the operational characteristics indicated by the target detection conditions, and generate the current operational state.
[0085] Optionally, in this embodiment, when multiple detection intervals include a start-up detection interval and a running detection interval, and the current runtime falls within the running detection interval, the following steps may also be performed, but are not limited to: obtaining a model weight loading completion flag and a preheating inference completion flag, wherein the model weight loading completion flag is used to indicate whether the target computing service has completed loading the model weights, and the preheating inference completion flag is used to indicate whether the target computing service has completed a preset number of preheating inference operations; when the model weight loading completion flag indicates that the target computing service has completed loading the model weights, and the preheating inference completion flag indicates that the target computing service has completed a preset number of preheating inference operations, according to the running detection interval... The second detection condition corresponding to the current running status is used to detect the current running status. If the current running time does not exceed the preset maximum allowed time, and the model weight loading completion flag indicates that the target computing service has not completed loading the model weights, or the preheating inference completion flag indicates that the target computing service has not completed the preset number of preheating inference operations, the current running status is detected according to the first detection condition. If the current running time exceeds the preset maximum allowed time, and the model weight loading completion flag indicates that the target computing service has not completed loading the model weights, or the preheating inference completion flag indicates that the target computing service has not completed the preset number of preheating inference operations, then the current running status is determined to indicate that the target computing service has experienced a running abnormality.
[0086] By following the steps above, the detection conditions used in this detection can be determined based on the current runtime of the target computing service, avoiding the use of the same detection conditions across different runtime ranges, thereby reducing the impact of misjudgments of runtime status on computing service updates.
[0087] As an optional approach, the current operating status of the target computing service can be detected according to the target detection conditions corresponding to the target detection interval in the detection information in the following ways, but not limited to: S81, perform at least one detection on the target computing service according to the target detection conditions to obtain at least one detection result, wherein the detection result is used to indicate whether the target computing service has the target operating characteristics indicated by the target detection conditions; S82, compare the abnormality ratio with the target abnormality ratio; S83, if the abnormality ratio is greater than or equal to the target abnormality ratio, determine the current operating status to indicate that the target computing service has experienced an operating abnormality; S84, if the abnormality ratio is less than the target abnormality ratio, determine the current operating status to indicate that the target computing service has not experienced an operating abnormality.
[0088] In the embodiment provided in step S81 above, the computing device can detect the target computing service according to the target detection conditions and record the detection results obtained each time. For example, if the target computing service is detected to have the target operating characteristics, the recorded detection result indicates that an anomaly has been detected; if the target computing service is detected not to have the target operating characteristics, the recorded detection result indicates that no anomaly has been detected.
[0089] Optionally, in this embodiment, the computing device can continuously perform a preset number of detections according to a preset detection cycle to obtain at least one detection result. For example, the computing device can perform a detection once every 1 second, and perform 5 consecutive detections to obtain 5 detection results.
[0090] In the embodiment provided in step S82 above, the anomaly ratio can be the proportion of detection results indicating an anomaly to at least one detection result. The computing device can count the number of detection results indicating an anomaly and determine the ratio of this number to the total number of detection results as the anomaly ratio, and then compare the anomaly ratio with a preset target anomaly ratio.
[0091] Optionally, in this embodiment, the computing device can calculate the anomaly rate among all detection results after completing a preset number of detections. For example, if two out of five detection results indicate anomalies, the anomaly rate is 40%. In another optional embodiment, the computing device can also update the detection results within a preset time range and recalculate the anomaly rate after each new detection result is obtained. For example, the computing device can add newly acquired detection results to the statistical range, remove detection results outside the time range, and recalculate the anomaly rate based on the updated detection results.
[0092] In the embodiments provided in steps S83 and S84 above, the computing device can determine the current operating status based on the comparison result between the abnormality ratio and the target abnormality ratio. For example, if the target abnormality ratio is 20%, and the abnormality ratio is 40%, then the current operating status is determined to indicate that the target computing service has experienced an operational abnormality; if the abnormality ratio is 20% or 10%, then the current operating status is determined to indicate that the target computing service has not experienced an operational abnormality.
[0093] By following the steps above, and based on the detection conditions determined according to the current runtime, multiple detection results can be combined to determine whether the target computing service is experiencing operational abnormalities. This reduces the possibility of misjudging the operational status due to fluctuations in a single detection result and improves the reliability of computing service updates.
[0094] As an optional approach, the target computing service can be tested at least once according to the target detection conditions in the following ways, and at least one detection result can be obtained: S91, when the target operation characteristics are used to characterize the event type of the abnormal operation event, at least one detection is performed on whether the target computing service has an abnormal operation event belonging to the event type, and at least one detection result is obtained; S92, when the target operation characteristics are used to characterize the degree of abnormality of the processing quality of the business request, at least one detection is performed on whether the processing quality of the business request of the target computing service has reached the degree of abnormality, and at least one detection result is obtained.
[0095] In the embodiment provided in step S91 above, the computing device can detect whether a corresponding abnormal operation event has occurred in the target computing service based on the event type indicated by the target detection conditions. For example, if the event type indicated by the target detection conditions includes abnormal process exit, segmentation fault, OOM exception, or computing accelerator driver exception, the computing device can detect whether any of the above-mentioned abnormal operation events has occurred in the target computing service. If an abnormal operation event belonging to the above-mentioned event type is detected, a detection result indicating that the target computing service has the target operation characteristics is generated; if no abnormal operation event belonging to the above-mentioned event type is detected, a detection result indicating that the target computing service does not have the target operation characteristics is generated.
[0096] Optionally, in this embodiment, the computing device can perform detection based on runtime events reported by the target computing service and its operating environment. For example, the computing device can receive process exit events, segmentation fault events, OOM (Out of Memory) exception events, or computing accelerator driver exception events, and compare the event types of the received runtime events with the event types indicated by the target detection conditions to obtain a detection result. In another optional embodiment, the computing device can also perform detection by querying the runtime logs of the target computing service or the status records of the operating environment. For example, the computing device can read newly added runtime logs according to a preset detection period, identify whether the abnormal runtime events indicated by the target detection conditions are recorded, and generate a detection result based on the identification result.
[0097] In the embodiment provided in step S92 above, the computing device can determine the service request processing quality indicators and their anomaly judgment criteria that need to be detected based on the target detection conditions, obtain the request processing data of the target computing service, determine whether the processing quality of the service request reaches the degree of anomaly represented by the target operating characteristics, and obtain the detection result.
[0098] Optionally, in this embodiment, the computing device can perform detection based on preset indicator thresholds. For example, the target detection condition stipulates that a request timeout rate greater than 5% constitutes a corresponding level of anomaly. The computing device can calculate the request timeout rate based on the total number of requests and the number of timeout requests within a detection period, and compare the request timeout rate with 5%. If the request timeout rate is greater than 5%, a detection result indicating that the target computing service has the target operational characteristics is generated; otherwise, a detection result indicating that the target computing service does not have the target operational characteristics is generated.
[0099] In another alternative implementation, the computing device can determine anomaly criteria based on the service request processing quality during normal operation of a reference computing service. For example, the computing device can determine the operational baseline for request processing latency based on request processing records during normal operation of the reference computing service, and set corresponding allowable deviation ranges in the target detection conditions. When detecting the target computing service, the computing device can calculate the request processing latency based on the collected request processing records, and determine whether it exceeds the allowable deviation range of the operational baseline to obtain the detection result.
[0100] As an optional approach, before detecting the current running status of the target computing service based on the current runtime of the target computing service and the detection information, the following steps may be performed, but are not limited to: S101, obtaining target update data, wherein the target update data is used to start the target computing service on the computing device; S102, starting the target computing service using the target update data, and recording the cumulative runtime of the target computing service during the operation of the target computing service; S103, determining the cumulative runtime as the current runtime of the target computing service.
[0101] In the embodiment provided in step S101 above, the target update data may include a new version service image of the target computing service, as well as model files and configuration information required to start the target computing service. After obtaining the new version service image, the computing device can obtain other data required to start the target computing service based on the model file paths and configuration information recorded in the new version service image.
[0102] In the embodiment provided in step S102 above, the computing device can create and start a container instance corresponding to the target computing service based on the target update data, and record the cumulative runtime from the start of the container instance. During the startup process of the container instance, the target computing service can sequentially perform operations such as loading model weight data, transmitting accelerator data, and warming up inference.
[0103] Optionally, in this embodiment, the computing device may record the startup time when starting the container instance of the target computing service, and record the time difference between the current time and the startup time as the cumulative runtime during the operation of the target computing service. In another optional embodiment, the computing device may start a timer when starting the container instance of the target computing service, and record the elapsed time since the container instance started to obtain the cumulative runtime.
[0104] In the embodiment provided in step S103 above, the computing device can obtain the cumulative runtime when it needs to detect the running status of the target computing service, and determine the obtained cumulative runtime as the current runtime used for this detection.
[0105] Optionally, in this embodiment, the computing device can read the cumulative runtime at the arrival of each preset detection period and determine it as the current runtime. In another optional embodiment, when a running event of the target computing service is detected and a running status detection is triggered, the computing device can also update the cumulative runtime according to the occurrence time of the running event and determine the updated cumulative runtime as the current runtime. For example, when the computing device receives a process abnormal exit event, it can determine the time difference between the occurrence time of the event and the start time of the target computing service as the current runtime.
[0106] As an optional approach, the target computing service can be started using the target update data in the following manner, but not limited to: S111, obtaining the difference data between the reference update data and the target update data, wherein the reference update data is used to start the reference computing service, and the difference data is used to indicate the difference content between the reference update data and the target update data; S112, storing the difference data in the device memory of the computing device; S113, starting the target computing service using the target update data, and pausing the reference computing service.
[0107] In the embodiment provided in step S111 above, the computing device can compare the reference update data and the target update data before starting the target computing service to determine the differences between them. For example, the differences may include data content that exists in the reference update data but not in the target update data, data content that exists in the target update data but not in the reference update data, and corresponding data content that has changed. The computing device can generate difference data based on the above differences.
[0108] In the embodiment provided in step S112 above, the computing device can save the difference data to the local persistent storage space in the device memory for use when the reference computing service needs to be restored later.
[0109] Optionally, in this embodiment, the computing device can save the difference data as a local file and record the storage location of the file. In another optional embodiment, the computing device can also write the difference data to a local database and save the difference data along with the service identifier or version identifier of the reference computing service for later retrieval of the corresponding difference data.
[0110] In the embodiment provided in step S113 above, the computing device can create and start a container instance corresponding to the target computing service based on the target update data. After the target computing service is started, the computing device can pause the container instance corresponding to the reference computing service, causing the reference computing service to stop processing business requests, and retain its memory and computing accelerator runtime context if device resources permit.
[0111] Optionally, in this embodiment, the computing device can pause the container instance corresponding to the reference computing service through the freeze function of control groups (Cgroups). In another optional implementation, the computing device can also send a pause command to the container runtime, which will then pause the container instance corresponding to the reference computing service.
[0112] By following the steps above, the differences between the reference update data and the target update data can be saved locally when the target computing service is started, and the reference computing service can be paused. If the target computing service experiences an operational anomaly, the paused reference computing service can be resumed, or the locally saved difference data can be used to restore the reference computing service, thus promptly restoring normal processing of business requests, reducing the impact of operational anomalies on business operations, and improving the reliability of computing service updates.
[0113] As an optional approach, the difference data between the reference updated data and the target updated data can be obtained in the following ways, but not limited to: S121, comparing the reference updated data and the target updated data to obtain difference information, wherein the difference information is used to indicate the data changes between the reference updated data and the target updated data; S122, obtaining difference data items and association information based on the difference information, wherein the difference data items are data items in the reference updated data that differ from the target updated data, and the association information is used to indicate the dependency relationship between the difference data items and other data items in the reference updated data; S123, generating difference data based on the difference information, difference data items, and association information.
[0114] In the embodiment provided in step S121 above, the computing device can compare the reference update data with the target update data to determine the data changes between the two. For example, if the reference update data and the target update data include an old version service image and a new version service image, respectively, the computing device can obtain an old version image list and a new version image list, and based on the image layer identifiers, digest values, and correspondences of image layers recorded in the two image lists, identify image layers that exist in the old version but not in the new version, image layers that exist in the new version but not in the old version, and corresponding image layers in the old and new versions but with changed content, thereby obtaining difference information.
[0115] In another alternative implementation, the computing device can read the image layers and their summary values of the old version service image and the new version service image through the union file system, compare them with the composition of the image layers of the two versions, determine the addition, deletion and modification of the image layers, and obtain the difference information.
[0116] In the embodiment provided in step S122 above, the computing device can obtain difference data items from the reference update data based on the difference information, and determine the dependency relationship between the difference data items and other data items in the reference update data. For example, for an image layer in the old version service image that no longer exists or whose content has changed in the new version service image, the computing device can obtain its original data in the old version service image as a difference data item.
[0117] Optionally, in this embodiment, the computing device can determine the old version image layer that needs to be obtained based on the difference information, read the corresponding original data from the local image layer storage space according to the image layer identifier, and determine the dependency relationship between these image layers and other image layers in the old version service image based on the old version image list, so as to obtain the difference data items and association information.
[0118] In another alternative implementation, the computing device can also read the old version image layer indicated by the difference information through the union file system, obtain the corresponding raw data, and determine the association information based on the organizational relationship of the old version image layer. For example, the association information can record the identifiers of other image layers that the difference image layer depends on, so that the corresponding image layer can be restored according to the original organizational relationship of the old version service image.
[0119] In the embodiment provided in step S123 above, the computing device can organize the difference data items and their associated information into difference data based on the difference information. The difference data can record the identifier of the difference data item in the reference update data, the original data of the difference data item, and the dependency relationship between the difference data item and other data items in the reference update data. For data items with the same content in the reference update data and the target update data, their identifiers can be recorded so that existing local data can be reused later without repeatedly saving their data content; for newly added data items that only exist in the target update data, their addition can be recorded so that the data content of the newly added data item does not need to be saved for restoring the reference update data.
[0120] For example, suppose the old version of the service image includes sequentially associated image layers A, B, and C, and the new version of the service image includes image layer A with identical content, a modified image layer B', and a newly added image layer D. Image layer C from the old version has been deleted from the new version. By comparing the two versions, the computing device can obtain the difference information: image layer B has been modified, image layer C has been deleted, and image layer D has been added. Subsequently, the computing device obtains the original data of the old version image layers B and C as difference data items and obtains the dependency relationships between image layers B and C and the old version image layer A. When generating the difference data, the identifiers and original data of the old version image layers B and C can be saved, and the dependency relationships between the old version image layers A, B, and C can be recorded. In the event that the reference updated data needs to be restored later, the computing device can restore the old version of the service image based on the above dependencies, using the locally retained image layer A and the old version image layers B and C saved in the difference data.
[0121] As an optional solution, the reference computing service can be updated according to the current operating status in the following ways, but not limited to: S131, if the current operating status indicates that the target computing service has experienced an operational abnormality, the target computing service is reverted to the reference computing service, and a first prompt message is sent to the initiator of the update request, wherein the first prompt message is used to indicate that the update of the reference computing service to the target computing service has failed; S132, if the current operating status indicates that the target computing service has not experienced an operational abnormality, it is detected whether the normal operating time of the target computing service without experiencing an operational abnormality has reached a preset operating time; if the normal operating time is detected to have reached the preset operating time, a second prompt message is sent to the initiator, wherein the second prompt message is used to indicate that the update of the reference computing service to the target computing service has been successful; if the normal operating time is detected to have not reached the preset operating time, the process returns to the step of detecting the current operating status of the target computing service based on the current operating time of the target computing service and the detection information.
[0122] Optionally, in the embodiment provided in step S131 above, the computing device may stop executing the current update and revert the target computing service to a reference computing service if the current operating state indicates that the target computing service has experienced an operational anomaly, allowing the reference computing service to reprocess the service request. For example, if the target computing service is detected to have experienced an abnormal process exit, or if the processing quality of the service request reaches the level of abnormality indicated by the corresponding detection conditions, the computing device may perform a rollback and send a first notification message to the initiator of the update request after completing the rollback.
[0123] Optionally, in this embodiment, the computing device can complete the rollback by restoring the suspended reference computing service. In another optional embodiment, the computing device can also restart the reference computing service using locally stored difference data to complete the rollback. After completing the rollback, the computing device can send a first notification message to the initiator. The first notification message may include, but is not limited to, carrying the service identifier of the reference computing service, the version identifier of the target computing service, and the result of the update failure.
[0124] In the embodiment provided in step S132 above, the computing device can continue to confirm whether the target computing service can maintain normal operation even if the current operating status indicates that the target computing service has not experienced any operational abnormalities. The preset runtime can be pre-set according to the operational requirements of the target computing service. If the duration during which the target computing service remains operational without abnormalities has not reached the preset runtime, the current operating status of the target computing service continues to be monitored as needed. If the duration during which the target computing service remains operational without abnormalities has reached the preset runtime, the computing device can confirm that the update was successful and send a second notification message to the initiator. The second notification message may carry the service identifier, version identifier, and the result of the successful update of the target computing service.
[0125] Optionally, in this embodiment, the computing device can perform operational status detection on the target computing service according to a preset detection cycle, and set a counter A with an initial value of zero to record the number of consecutive detections that the target computing service has not experienced operational abnormalities. Each time the current operational status indicates that the target computing service has not experienced an operational abnormality, counter A is incremented by one, and the normal operating duration is determined based on counter A and the preset detection cycle. For example, if the preset detection cycle is 2 seconds, and no operational abnormality is found in 6 consecutive detections, the 10 seconds between the first detection of no operational abnormality and the 6th detection can be determined as the normal operating duration. If an operational abnormality is detected in the target computing service, counter A is reset to zero.
[0126] In another alternative implementation, the computing device may record the time of the first detection that the target computing service is not experiencing any operational anomalies, and initialize the normal operating time to zero. If no operational anomalies are found in subsequent detections, the normal operating time is updated based on the time difference between the current detection time and the previous detection time. For example, if there is a 2-second interval between two adjacent detections, and no operational anomalies are found in either detection, then those 2 seconds can be included in the normal operating time. If an operational anomaly is subsequently detected in the target computing service, the normal operating time is reset to zero.
[0127] Optionally, in this embodiment, the computing device may also terminate the operation of the reference computing service and release the computing resources occupied by the reference computing service after confirming that the update is successful.
[0128] Optionally, in this embodiment, when the update request is sent by the cloud management node, the computing device can send a first prompt message or a second prompt message to the cloud management node via the transmission device. When the update request is generated by the service management program on the computing device, the computing device can return the corresponding prompt message to the service management program so that it can record the update result or display it to the staff.
[0129] By following the steps above, it's possible to determine whether to continue the update based on the operational status of the target computing service. If the target computing service experiences an operational anomaly, a rollback process is used to restore service availability to the reference computing service. Once the target computing service is running normally again, the update is confirmed as successful, minimizing the impact of operational anomalies on service request processing and improving the reliability of computing service updates.
[0130] As an optional solution, the target computing service can be reverted to the reference computing service in the following ways, but not limited to: S141, detecting the validity of the runtime information, wherein the runtime information is used to instruct the runtime context of the reference computing service to pause runtime; S142, if the runtime information is detected to be valid, resuming the runtime of the reference computing service and stopping the runtime of the target computing service; S143, if the runtime information is detected to be invalid, generating reference update data using target update data and difference data; starting the reference computing service using the reference update data and stopping the runtime of the target computing service.
[0131] In the embodiment provided in step S141 above, the computing device can detect whether the runtime context of the reference computing service during its paused operation is still available for continuing to run the reference computing service when a rollback is required. For example, the computing device can detect whether the process corresponding to the reference computing service still exists, and whether the memory and computing accelerator runtime contexts required for the process to continue running are still available. If both runtime contexts are available, the runtime information is determined to be valid; if the process has been terminated or the runtime context required for its continued operation has expired, the runtime information is determined to be invalid.
[0132] Optionally, in this embodiment, the computing device can query the container instance status corresponding to the reference computing service during container runtime, and determine whether the runtime information is valid based on the process status of the container instance and the availability of the runtime context. In another optional embodiment, the computing device can also query whether the corresponding process still exists based on the process identifier recorded when the reference computing service is paused, and further detect whether the memory and computing accelerator runtime context required by the process are still available, to obtain the validity detection result of the runtime information.
[0133] In the embodiment provided in step S142 above, when the running information is detected to be valid, the computing device can release the paused state of the reference computing service, allowing the reference computing service to continue running, and after the reference computing service is able to process the business request normally, the business request is handed over to the reference computing service for processing again, and the target computing service is stopped from running.
[0134] Optionally, in this embodiment, if the container instance corresponding to the reference computing service is frozen by a control group, the computing device can unfreeze the corresponding control group, allowing the process of the reference computing service to resume scheduling. In another optional embodiment, if the container instance corresponding to the reference computing service is paused by the container runtime, the computing device can send a recovery command to the container runtime, which will then resume the operation of the container instance.
[0135] Optionally, in this embodiment, the computing device can check whether the reference computing service can provide services normally through a service status query interface after the reference computing service resumes operation. In another optional embodiment, the computing device can send a test request to the resumed reference computing service and determine whether the reference computing service can process service requests normally based on the processing result of the test request. After confirming that the reference computing service can process service requests normally, the computing device can switch subsequent service requests to the reference computing service and stop the container instance corresponding to the target computing service.
[0136] In the embodiment provided in step S143 above, if invalid running information is detected, the computing device can regenerate the reference update data by utilizing the reusable data content in the target update data and the original content of the reference update data stored in the difference data, and start the reference computing service using the reference update data.
[0137] Optionally, in this embodiment, when the reference update data and the target update data respectively include an old version service image and a new version service image, the computing device can obtain the image layers with the same content in the old and new versions from the target update data based on the image layer identifiers and dependencies recorded in the difference data, and obtain the original data of the image layers that have been deleted or modified in the old version from the difference data, and then generate the reference update data according to the dependencies between the old version image layers. In another optional embodiment, the computing device can also determine the image layers that the reference update data should include based on the locally stored old version image list, and obtain the corresponding image layer data from the target update data and the difference data respectively, and reconstruct the old version service image according to the image layer composition relationship recorded in the old version image list to obtain the reference update data.
[0138] Optionally, in this embodiment, the computing device can use the generated reference update data to create a new container instance and start the reference computing service. In another optional implementation, the computing device can first save the generated reference update data to the local image storage space, and then the container runtime can read the reference update data to create and start the container instance corresponding to the reference computing service. After confirming that the restarted reference computing service can handle business requests normally, the computing device can switch subsequent business requests to the reference computing service and stop running the target computing service.
[0139] By following the steps above, the reference computing service can be directly restored if the runtime context is still available when the reference computing service is suspended; if the runtime context has expired, the reference computing service can be restarted using the target update data and locally stored difference data. This ensures that the normal processing of business requests can be restored in a timely manner after the target computing service experiences an operational anomaly, reducing the impact of operational anomalies on business and improving the reliability of computing service updates.
[0140] Optionally, in this embodiment, in order to better understand the above-described method for updating computing services, the following description of the updating process of computing services is provided in conjunction with optional embodiments, but is not intended to limit the technical solutions of the embodiments of this application.
[0141] This embodiment provides a computing service update system. Figure 5 This is a schematic diagram of a computing service update system according to an embodiment of this application. Figure 5As shown, the update system includes a version update and difference management module 501, a hierarchical status monitoring module 502, a local rollback decision module 503, and a multi-level adaptive rollback module 504. Among them:
[0142] The version update and difference management module 501 is used to obtain the new version AI service image (equivalent to the target update data), obtain the difference data between the new version AI service image and the old version AI service image (equivalent to the reference update data), and save the difference data locally; it uses the new version AI service image to start the container instance corresponding to the new version AI service (equivalent to the target computing service), and pauses the container instance corresponding to the old version AI service (equivalent to the reference computing service). The version update and difference management module 501 is also used to restore the old version AI service image using the new version AI service image and the locally saved difference data when it is necessary to restart the old version AI service.
[0143] The hierarchical status monitoring module 502 is used to obtain detection information based on the resource parameters of the new version of the AI service and the performance parameters of the computing device, and to detect its current running status based on the current runtime of the new version of the AI service and the detection information. The detection information includes the detection conditions corresponding to the startup detection interval and the running detection interval, respectively. Within the startup detection interval, the hierarchical status monitoring module 502 mainly detects events such as abnormal process exits, segmentation faults, insufficient memory, and serious anomalies in the computing accelerator driver; within the running detection interval, it mainly detects the running status of the new version of the AI service based on business indicators such as request failure rate, request timeout rate, and inference latency. The hierarchical status monitoring module 502 sends the detected current running status to the local rollback decision module 503.
[0144] The local rollback decision module 503 is used to determine whether to perform a rollback based on the current running status sent by the hierarchical status monitoring module 502. If the current running status indicates that the new version of the AI service has experienced a running anomaly, a rollback instruction is generated and sent to the multi-level adaptive rollback module 504; if the current running status indicates that the new version of the AI service has not experienced a running anomaly, its running status is monitored, and the update is confirmed to be successful after the normal running time reaches the preset running time.
[0145] The multi-level adaptive rollback module 504 responds to rollback commands sent by the local rollback decision module 503 and checks whether the runtime context of the suspended old version AI service is valid. If the runtime context is valid, the old version AI service is resumed; if the runtime context is invalid, the old version AI service image is restored through the version update and difference management module 501, and the old version AI service is restarted using the restored old version AI service image. The multi-level adaptive rollback module 504 also feeds back the rollback result to the local rollback decision module 503, so that the local rollback decision module 503 can send a first prompt message to the initiator of the update request.
[0146] Optionally, in this embodiment, the update system may further include an asynchronous synchronization module for network outages, which is used to save resource status, business exception logs and rollback results locally when the connection between the computing device and the cloud management node is unavailable, and to report them asynchronously after the connection is restored.
[0147] With the cooperation of the above modules, it is possible to determine whether to perform a rollback based on the running status of the new version of the AI service. When a rollback is required, the appropriate recovery method can be selected based on whether the running context of the old version of the AI service is valid, so as to restore the normal processing of business requests in a timely manner and improve the reliability of computing service updates.
[0148] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0149] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.
[0150] This embodiment also provides a computing service update apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0151] Figure 6 This is a structural block diagram of a computing service update apparatus according to an embodiment of this application; as shown below. Figure 5As shown, the system includes: a receiving module 602, used to receive an update request, wherein the update request is used to request that a reference computing service running on the computing device be updated to a target computing service; a response module 604, used to respond to the update request and obtain detection information corresponding to resource parameters and performance parameters, wherein the resource parameters are used to indicate the loading requirements of resource data required to start the target computing service on the computing device, the performance parameters are used to indicate the computing device's ability to load resource data, the detection information records corresponding detection intervals and detection conditions, the detection information is constructed based on the resource parameters and performance parameters, multiple detection intervals are used to indicate different runtime ranges after the target computing service is started, and the detection conditions are used to indicate the running characteristics of the target computing service when a running abnormality occurs within the corresponding detection interval; a detection module 606, used to detect the current running status of the target computing service based on the current runtime of the target computing service and the detection information, wherein the current running status is used to indicate the occurrence of running abnormalities of the target computing service within the detection interval in which the current runtime falls; and an update module 608, used to update the reference computing service based on the current running status.
[0152] The computing service update apparatus provided in the embodiments of this application is also configured to execute the steps in any of the above-described computing service update method embodiments. For a description of the features in the embodiments corresponding to the computing service update apparatus, please refer to the relevant descriptions in the embodiments corresponding to the computing service update method, which will not be repeated here.
[0153] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0154] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described embodiments of the computing service update method.
[0155] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.
[0156] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.
[0157] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the computing service update method.
[0158] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0159] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for updating computing services.
[0160] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for updating computing services.
[0161] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, CPUs, FPGAs, Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), Systems on Chips (SoCs), Complex Programmable Logic Devices (CPLDs), Microcontroller Units (MCUs), etc. The terms "system," "computing device," or "apparatus" used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The aforementioned computer program (also known as a program, software, software application, application (APP), script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.
[0162] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0163] The above provides a detailed description of a computing service update method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A method for updating a computing service, characterized in that, include: Receive an update request, wherein the update request is used to request that a reference computing service running on the computing device be updated to a target computing service; In response to the update request, detection information corresponding to resource parameters and performance parameters is obtained. The resource parameters are used to indicate the loading requirements of resource data required to start the target computing service on the computing device, and the performance parameters are used to indicate the computing device's loading capacity for the resource data. The detection information records corresponding detection intervals and detection conditions. The detection information is constructed based on the resource parameters and the performance parameters. Multiple detection intervals are used to indicate different runtime ranges after the target computing service is started, and the detection conditions are used to indicate the operating characteristics of the target computing service when an abnormality occurs within the corresponding detection interval. The current running status of the target computing service is detected based on the current runtime of the target computing service and the detection information, wherein the current running status is used to indicate the occurrence of operational anomalies of the target computing service within the detection interval in which the current runtime falls; The reference computing service is updated based on the current operating status.
2. The method according to claim 1, characterized in that, The acquisition of detection information corresponding to resource parameters and performance parameters includes: Multiple detection intervals are generated based on the resource parameters and performance parameters; detection conditions are configured for each of the multiple detection intervals to obtain the detection information; or... The detection information corresponding to the resource parameter and the performance parameter is retrieved from the corresponding reference resource parameter, reference performance parameter and reference detection information, wherein the reference detection information is constructed based on the corresponding reference resource parameter and the corresponding reference performance parameter.
3. The method according to claim 2, characterized in that, The generation of multiple detection intervals based on the resource parameters and the performance parameters includes: A reference duration is generated based on the resource parameters and the performance parameters, wherein the reference duration is the estimated duration required for the computing device to complete loading the resource data; A startup detection interval and a running detection interval are generated based on the reference duration. The startup detection interval is used to indicate the range of runtime of the target computing service after startup with the reference duration, and the running detection interval is used to indicate the range of runtime of the target computing service after startup exceeding the reference duration. The plurality of detection intervals include the startup detection interval and the running detection interval.
4. The method according to claim 3, characterized in that, The step of generating a reference duration based on the resource parameters and the performance parameters includes: The ratio of the weight parameter to the access parameter is determined as the first loading duration, and the ratio of the loading parameter to the transmission parameter is determined as the second loading duration. The weight parameter indicates the amount of model weight data that needs to be loaded from the device memory of the computing device to the system memory of the computing device to start the target computing service. The access parameter indicates the loading rate at which the computing device loads the model weight data from the device memory to the system memory. The loading parameter indicates the amount of accelerator data that needs to be loaded from the system memory to the computing accelerator memory of the computing device to start the target computing service. The transmission parameter indicates the transmission rate at which the computing device transmits the accelerator data from the system memory to the computing accelerator memory. The resource parameters include the weight parameter and the loading parameter. The performance parameters include the access parameter and the transmission parameter. The resource data includes the model weight data and the accelerator data. The reference duration is calculated based on the first loading duration and the second loading duration.
5. The method according to claim 4, characterized in that, The calculation of the reference duration based on the first loading duration and the second loading duration includes: Obtain the target number of preheating operations and the duration of each preheating operation, wherein the target number of preheating operations is used to indicate the number of preheating inference operations required to start the target computing service, and the duration of each preheating operation is the average duration required to perform one preheating inference operation; The product of the target number of preheating cycles and the duration of a single preheating cycle is determined as the resource preheating duration. The reference duration is calculated based on the first loading duration, the second loading duration, and the resource preheating duration.
6. The method according to claim 3, characterized in that, The step of configuring the detection conditions for multiple detection intervals to obtain the detection information includes: A first detection condition is configured for the startup detection interval, and a second detection condition is configured for the operation detection interval. The first detection condition is used to indicate a first operation characteristic of the target computing service when an operation anomaly occurs in the startup detection interval, and the second detection condition is used to indicate a second operation characteristic of the target computing service when an operation anomaly occurs in the operation detection interval. The first operation characteristic is used to characterize the event type of the abnormal operation event of the target computing service, and the second operation characteristic is used to characterize the degree of abnormality in the processing quality of the target computing service in processing business requests. The plurality of detection conditions include the first detection condition and the second detection condition.
7. The method according to claim 1, characterized in that, The step of detecting the current running status of the target computing service based on the current runtime of the target computing service and the detection information includes: Find the target detection interval into which the current runtime falls from the plurality of detection intervals; The current running status of the target computing service is detected according to the target detection conditions corresponding to the target detection interval in the detection information.
8. The method according to claim 7, characterized in that, The step of detecting the current running status of the target computing service according to the target detection conditions corresponding to the target detection interval in the detection information includes: The target computing service is detected at least once according to the target detection conditions to obtain at least one detection result, wherein the detection result is used to indicate whether the target computing service has the target operation characteristics indicated by the target detection conditions; An anomaly ratio is calculated based on at least one of the detection results, wherein the anomaly ratio is the ratio of the number of abnormal detection results to the number of detection results in the at least one detection result, and the abnormal detection results are used to indicate that the target computing service has the target operating characteristics; Compare the stated anomaly ratio with the target anomaly ratio; If the abnormality ratio is greater than or equal to the target abnormality ratio, the current operating status is determined to indicate that the target computing service has experienced an operational abnormality. If the abnormality ratio is less than the target abnormality ratio, the current operating status is determined to indicate that the target computing service has not experienced any operational abnormalities.
9. The method according to claim 8, characterized in that, The step of performing at least one detection on the target computing service according to the target detection conditions to obtain at least one detection result includes: When the target operation feature is used to characterize the event type of abnormal operation event, at least one detection is performed on whether the target computing service has experienced an abnormal operation event belonging to the event type, and at least one detection result is obtained; When the target operating characteristics are used to characterize the degree of abnormality in the processing quality of processing business requests, at least one detection is performed to determine whether the processing quality of the target computing service in processing business requests reaches the degree of abnormality, and at least one detection result is obtained.
10. The method according to claim 1, characterized in that, Before detecting the current running status of the target computing service based on the current runtime of the target computing service and the detection information, the method further includes: Obtain target update data, wherein the target update data is used to start the target computing service on the computing device; The target computing service is started using the target update data, and the cumulative runtime of the target computing service is recorded during its operation. The cumulative runtime is determined as the current runtime of the target computing service.
11. The method according to claim 10, characterized in that, The step of starting the target computing service using the target update data includes: Obtain the difference data between the reference update data and the target update data, wherein the reference update data is used to start the reference calculation service, and the difference data is used to indicate the difference content between the reference update data and the target update data; The difference data is stored in the device memory of the computing device; The target computing service is started using the target update data, and the reference computing service is paused.
12. The method according to claim 11, characterized in that, The step of obtaining the difference data between the reference updated data and the target updated data includes: The reference updated data and the target updated data are compared to obtain difference information, wherein the difference information is used to indicate the data changes between the reference updated data and the target updated data; Based on the difference information, difference data items and association information are obtained, wherein the difference data items are data items in the reference updated data that differ from the target updated data, and the association information is used to indicate the dependency relationship between the difference data items and other data items in the reference updated data; The difference data is generated based on the difference information, the difference data items, and the association information.
13. The method according to claim 11, characterized in that, The step of updating the reference computing service based on the current operating status includes: If the current running status indicates that the target computing service has experienced a running abnormality, the target computing service will be rolled back to the reference computing service, and a first prompt message will be sent to the initiator of the update request, wherein the first prompt message is used to indicate that the update of the reference computing service to the target computing service has failed; If the current operating status indicates that the target computing service is not experiencing any operational anomalies, it checks whether the normal operating time has reached a preset operating time, wherein the normal operating time is the duration during which the target computing service remains operational without any operational anomalies. If the normal operating time has reached the preset operating time, a second notification message is sent to the initiator, wherein the second notification message indicates that the update of the reference computing service to the target computing service was successful. If the normal operating time has not reached the preset operating time, it returns to the step of detecting the current operating status of the target computing service based on the current operating time of the target computing service and the detection information.
14. The method according to claim 13, characterized in that, The step of falling back the target computing service to the reference computing service includes: The validity of the runtime information is detected, wherein the runtime information is used to indicate the runtime context in which the reference computing service is suspended during runtime; If the running information is found to be valid, the reference computing service is resumed and the target computing service is stopped. If the runtime information is found to be invalid, the reference update data is generated using the target update data and the difference data; the reference computing service is started using the reference update data, and the target computing service is stopped.
15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for updating the computing service as described in any one of claims 1 to 14 when executing the computer program.
