A runtime switching method and a terminal device

Abstract

This application relates to a runtime switching method and a terminal device. The method includes: freezing the business processing process corresponding to the first instance when it is determined that a first instance will be switched from a first runtime to a second runtime; the first runtime and the second runtime are different runtimes in a container runtime and a Wasm runtime, respectively; obtaining first runtime status data corresponding to the first instance, the first runtime status data being used to indicate the runtime status of the first instance; creating a second instance on the node corresponding to the second runtime; migrating the first runtime status data to the second instance to obtain second runtime status data; migrating the first file system data of the file system corresponding to the first instance to the file system corresponding to the second instance to obtain second file system data; starting the second instance based on the second runtime status data and the second file system data; and redirecting service requests corresponding to the first instance to the second instance.

Description

Technical Field

[0001] This application relates to the field of cloud-native computing. More specifically, it relates to a runtime switching method and a terminal device. Background Technology

[0002] In cloud-native heterogeneous workload environments with different types of workloads, including CPU-intensive, memory-intensive, and I / O-intensive workloads, traditional container technologies (such as Docker containers) offer good isolation and portability, but have long startup times (usually in the order of seconds) and high resource overhead, making them particularly inefficient when handling bursty or lightweight heterogeneous workloads. Meanwhile, WebAssembly (Wasm), as a lightweight virtualization technology, has the advantages of millisecond-level startup speed and low resource consumption, but its functionality is limited to sandbox environments and cannot directly support complex enterprise applications or legacy systems.

[0003] Therefore, there is an urgent need for a performance and resource optimization solution for cloud-native heterogeneous workload environments to improve the current problems of low resource utilization, high response latency, and poor system adaptability. Summary of the Invention To solve the above-mentioned technical problems, or at least partially solve them, embodiments of this application provide a runtime switching method and a terminal device.

[0004] In a first aspect, embodiments of this application provide a runtime switching method, comprising: freezing the business processing process corresponding to the first instance when it is determined that a first instance will be switched from a first runtime to a second runtime; the first runtime is one of a container runtime and a Wasm runtime, and the second runtime is one of the container runtime and the Wasm runtime that is different from the first runtime; obtaining first runtime status data corresponding to the first instance, the first runtime status data being used to indicate the runtime status of the first instance; creating a second instance on the node corresponding to the second runtime; migrating the first runtime status data to the second instance to obtain second runtime status data; migrating the first file system data of the file system corresponding to the first instance to the file system corresponding to the second instance to obtain second file system data; starting the second instance based on the second runtime status data and the second file system data; and redirecting service requests corresponding to the first instance to the second instance.

[0005] In this embodiment, when it is determined that the first instance should be switched from the first runtime to the second runtime, the following steps are taken: the business processing process corresponding to the first instance is frozen, the first runtime status data corresponding to the first instance is obtained, a second instance is created on the node corresponding to the second runtime, and then the first runtime status data is migrated to the second instance to obtain the second runtime status data; the first file system data of the file system corresponding to the first instance is migrated to the file system corresponding to the second instance to obtain the second file system data; based on the second runtime status data and the second file system data, the second instance is started; and the service requests corresponding to the first instance are redirected to the second instance. Thus, during the process of switching the first instance from the first runtime to the second runtime, dynamic hot switching is achieved through zero-interruption migration rather than static resource allocation. This ensures that the system can dynamically and hot-swap between Wasm runtime and container instances with zero interruption based on load characteristics during operation. In this way, when the initial runtime is container runtime and the load characteristics shift from high density to lightweight, timely hot-swap from container runtime to Wasm runtime can improve resource utilization and reduce response latency. Conversely, when the initial runtime is Wasm runtime and the load characteristics shift from lightweight to high density, timely switch from Wasm runtime to container runtime can improve system adaptability, flexibility, and resource utilization. This enables performance and resource optimization in cloud-native heterogeneous load environments, thereby addressing the current issues of low resource utilization, high response latency, and poor system adaptability.

[0006] In some embodiments of this application, the method further includes: if the number of times the load information of the first instance satisfies the switching condition within a first time period is greater than or equal to a number threshold, determining to switch the first instance from the first runtime to the second runtime; wherein the switching condition is used to indicate that the load information matches the second runtime.

[0007] In this embodiment, based on whether the load information of the first instance within a certain period of time meets the switching conditions, the system determines whether it needs to switch the first instance from the first runtime to the second runtime. In this way, based on the monitoring of the load information of the first instance over a certain period of time, it can accurately determine whether a runtime switch is needed. Then, when a runtime switch is needed, the system's flexibility and resource utilization are improved through zero-interruption hot switching, thereby achieving performance and resource optimization of the cloud-native heterogeneous load environment and improving the current problems of low resource utilization, high response latency, and poor system adaptability.

[0008] In some embodiments of this application, the method further includes: inputting historical load information of a first instance into a load prediction model and outputting load prediction information, the load prediction information being used to indicate that the load information of the first instance matches the second runtime within a target time period; and based on the load prediction information, determining to switch the first instance from the first runtime to the second runtime within a second duration before the target time period arrives.

[0009] In this embodiment, a pre-trained load prediction model predicts future load information changes of an instance based on historical load information. The system switches before the predicted change period (target period) is reached. Thus, within the target period of load information change, a second runtime instance matching the load information within the target period can be run, which can improve the current problems of low resource utilization, high response latency, and poor system adaptability.

[0010] In some embodiments of this application, migrating the first running state data to a second instance to obtain second running state data includes: serializing the first running state data to obtain a first migration data stream; sending the first migration data stream to a node corresponding to the second runtime; deserializing the first migration data stream at the node corresponding to the second runtime to obtain the first running state data; performing data transformation processing on the first running state data to obtain second running state data matching the second runtime; and saving the second running state data to the second instance.

[0011] In this embodiment of the application, by performing serialization, data transmission, deserialization, and data conversion on the first running state data corresponding to the first instance, the second running state data matching the second runtime can be obtained quickly. Then, based on the second running state data, the second instance can be started quickly, thereby realizing business processing based on the second instance.

[0012] In some embodiments of this application, obtaining the first running state data corresponding to the first instance includes: obtaining the third running state data corresponding to the first instance; performing data transformation processing on the third running state data to obtain the first running state data that matches the second running state.

[0013] In this embodiment, after the node corresponding to the first runtime obtains the runtime status data of the first instance, it performs data transformation processing to obtain the first runtime status data that matches the second runtime. Thus, based on the first runtime status data, the second instance can perform service recovery based on the second runtime status data, thereby facilitating hot switching during runtime.

[0014] In some embodiments of this application, after redirecting the service request corresponding to the first instance to the second instance, the method further includes: determining whether the second instance is stable by monitoring the startup indicators of the second instance; and destroying the first instance if the second instance is determined to be stable.

[0015] In this embodiment, the first instance is destroyed only when the second instance is determined to be stable. This way, if the second instance is determined to be unstable, the first instance can be restored in a timely manner, ensuring that the service corresponding to the first instance is not interrupted.

[0016] In some embodiments of this application, the method further includes: unfreezing the business processing process corresponding to the first instance if it is determined that the second instance is unstable; and redirecting the service request corresponding to the second instance to the first instance.

[0017] In this embodiment of the application, by setting a rollback mechanism after the runtime switching process is successfully executed, if it is determined that the second instance is unstable, the business processing process corresponding to the first instance is unfrozen; and the service requests corresponding to the second instance are redirected to the first instance, which can ensure that the service corresponding to the first instance is not interrupted.

[0018] In some embodiments of this application, the method further includes: unfreezing the business processing process corresponding to the first instance if the runtime switching process of switching the first instance from the first runtime to the second runtime fails.

[0019] In this embodiment of the application, by setting a rollback mechanism in the runtime switching process, the business processing process corresponding to the first instance can be unfrozen in the event that the runtime switching process fails, thus ensuring that the service corresponding to the first instance is not interrupted.

[0020] In some embodiments of this application, the method further includes: logging and debugging if the runtime switching process of switching the first instance from the first runtime to the second runtime fails.

[0021] In this embodiment of the application, if the runtime switching process fails, the cause of the runtime switching failure can be determined and the problem can be solved by logging and debugging, so as to avoid the next switch failing or to change the switching scheme when the next runtime switch is required.

[0022] In a second aspect, embodiments of this application provide a terminal device, including: a memory configured to store a computer program; and a processor configured to cause the terminal device to implement the runtime switching method described in the first aspect when the computer program is invoked.

[0023] Thirdly, embodiments of this application provide a computer-readable storage medium, including: storing a computer program on the computer-readable storage medium, wherein when the computer program is executed by a processor, it implements the runtime switching method as shown in the first aspect.

[0024] Fourthly, embodiments of this application provide a computer program product, including: when the computer program product is running on a computer, causing the computer to implement the runtime switching method as shown in the first aspect. Attached Figure Description

[0025] To more clearly illustrate the implementation methods in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0026] Figure 1 One of the flowcharts of a runtime switching method according to some embodiments is shown; Figure 2 A second flowchart illustrating a runtime switching method according to some embodiments is shown; Figure 3 A third flowchart illustrating a runtime switching method according to some embodiments is shown; Figure 4 A fourth flowchart illustrating a runtime switching method according to some embodiments is shown; Figure 5 Fifth of a series of flowcharts illustrating a runtime switching method according to some embodiments; Figure 6 A flowchart of a runtime switching method according to some embodiments is shown in diagram six; Figure 7 A flowchart of a runtime switching method according to some embodiments is shown as diagram seven; Figure 8 A structural block diagram of a runtime switching system according to some embodiments is shown; Figure 9 Eighth schematic diagram of a runtime switching method according to some embodiments is shown; Figure 10 A structural block diagram of a terminal device according to some embodiments is shown. Detailed Implementation

[0027] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0028] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0029] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0030] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0031] The cloud-native computing field has developed rapidly in recent years, with container orchestration systems, represented by Kubernetes, becoming mainstream and supporting microservice architectures and automated deployment. However, existing technologies face several drawbacks when handling heterogeneous loads: first, slow container startup (cold start problem) due to image loading and file system mounting overhead; second, resource waste, with traditional containers over-allocating resources under lightweight loads, leading to low utilization; and third, a lack of dynamic adaptation mechanisms, as current systems mostly use static configurations and cannot respond to load changes in real time. Therefore, in cloud-native environments, while traditional container technologies (such as Docker containers) offer good isolation and portability, they have long startup times (usually in the thousands) and high resource overhead, making them particularly inefficient when handling bursty or lightweight heterogeneous loads.

[0032] Among them, container cold starts are slow: container images are mostly GB in size, and starting them requires completing the entire process of "image pulling → decompression → mounting of multi-layer file system (OverlayFS)," which involves a large amount of network I / O and disk I / O; the execution time of light-load (such as scheduled tasks and low-frequency interfaces) is even much shorter than the startup time, and the "second-level" overhead of cold starts is infinitely amplified.

[0033] Among these issues, resource waste occurs because Kubernetes requests / limits are statically configured, and users often "over-configure" them to avoid insufficient resources (for example, configuring 500m CPU for a lightweight service that only requires 50m CPU). Lightweight tasks account for a high proportion of heterogeneous loads, resulting in cluster resource utilization generally being less than 30%, and computing power being severely idle.

[0034] One of the problems is the lack of a dynamic adaptation mechanism: traditional scaling up and down (such as HPA) is based solely on CPU / memory thresholds and has a cooldown period of about 5 minutes. It cannot cope with heterogeneous scenarios such as "instantaneous bursts of traffic" and "short-term tidal loads". Either the untimely scaling up and down leads to service unavailability, or frequent scaling up and down causes cluster jitter.

[0035] Wasm, as a lightweight virtualization technology, boasts advantages such as millisecond-level startup speed and low resource consumption. However, its functionality is limited by the sandbox environment, making it unable to directly support complex enterprise-level applications or legacy systems. As an emerging technology, Wasm has been integrated into cloud platforms, but it is primarily used for function-level computation and struggles to seamlessly integrate with containers.

[0036] Wasm is essentially a binary instruction format, not a traditional "virtual machine" (such as JVM / VMware). Its execution logic is as follows: the compiled Wasm module is extremely small, requiring no full operating system or runtime like containers / virtual machines; instructions are directly parsed and executed by the host environment (browser / independent runtime), with almost no "warm-up" cost at startup; the sandbox environment itself is lightweight, allocating only necessary memory / CPU resources without redundant overhead. A simple analogy: traditional containers are like "furnished studio apartments," while Wasm is like "capsule rooms with only a bed"—fast startup, small footprint, but limited space for movement.

[0037] Wasm's sandbox is designed for secure isolation, prohibiting access to the host system's core resources by default. Complex enterprise applications and legacy systems, however, rely heavily on these resources: System call limitations: It cannot directly call OS kernel interfaces (such as process management, disk I / O, and advanced network socket operations), while legacy systems (such as older C / C++ services and ERP systems) often heavily depend on these interfaces; Difficulty in state persistence: The memory within the sandbox is temporary, making it impossible to directly manipulate persistent storage such as databases and file systems (requiring the use of the host environment's "bridging" APIs, which incurs high development costs); Poor compatibility: Legacy systems are often developed based on specific architectures (x86) and specific languages ​​(COBOL, Fortran), and Wasm's compilation / adaptation support for these niche technologies is insufficient; Lack of distributed capabilities: Enterprise applications require service discovery, load balancing, and transaction management capabilities, which Wasm itself lacks, requiring reliance on external frameworks.

[0038] The root of these shortcomings lies in the heterogeneity of virtualization technologies: containers emphasize isolation and compatibility, while Wasm focuses on lightweight and security, and the two have not achieved unified runtime management.

[0039] WebAssembly (Wasm) is a binary instruction format based on a stack-based virtual machine. Originally used in browsers, it has been extended to server-side runtimes (such as Wasmtime and WasmEdge), supporting compilation in multiple languages ​​(such as Rust and C++), and offering sandbox isolation and near-native performance. Container technology, based on Linux cgroups and namespaces, provides process-level isolation. Heterogeneous workloads refer to the diversity of workloads, such as AI inference (CPU / GPU intensive), data processing (memory intensive), and web services (I / O intensive). WebAssembly (Wasm) complements containers' shortcomings in lightweight workloads—Wasm modules are KB in size, start in milliseconds, and can be deployed in a hybrid manner with containers and Wasm applications in Kubernetes. Existing runtime systems like Kubernetes support Pod-level deployment, but switching workloads requires restarting instances, causing service interruptions. In edge computing and serverless scenarios, dynamically managing heterogeneous workloads has become a hot topic, but hot-swapping support between Wasm and containers is lacking.

[0040] Kubernetes + CRI (Container Runtime Interface): such as containerd or CRI-O, supports container operation, but has limited integration with Wasm. Wasm Pods are only implemented through plugins (such as krustlet), but switching requires manual intervention. The drawback is the lack of dynamic hot switching, which leads to unbalanced load.

[0041] WasmCloud or Fermyon Spin: Focuses on the Wasm actor model and supports distributed Wasm modules, but is not compatible with traditional containers. Its drawback is limited functionality and inability to handle complex legacy applications.

[0042] AWS Firecracker or Google gVisor: offer micro VMs and sandboxed containers, but do not implement Wasm-container switching, and resource overhead remains high.

[0043] Figure 1 The flowchart illustrates the steps of implementing a runtime switching method according to one or more embodiments of the present invention. The execution subject of the runtime switching method can be a server or an electronic device, or a functional module or functional entity within the server or electronic device capable of implementing the runtime switching method; no limitation is made here. In this embodiment, an example is provided with a server as the execution subject, and the runtime switching method may include the following steps S101 to S107.

[0044] S101. If it is determined that the first instance will be switched from the first runtime to the second runtime, the business processing process corresponding to the first instance shall be frozen.

[0045] The first runtime is one of the container runtime and the Wasm runtime, and the second runtime is one of the container runtime and the Wasm runtime that is different from the first runtime.

[0046] It is understandable that if the first runtime is a container runtime, then the second runtime is a Wasm runtime; if the first runtime is a Wasm runtime, then the second runtime is a container runtime.

[0047] The first instance is an instance that runs based on the first runtime, and the first instance is an instance created and run on the node corresponding to the first runtime.

[0048] In some embodiments of this application, the first instance can be switched from the first runtime to the second runtime based on the load information of the first instance within a certain period of time, or the first instance can be switched from the first runtime to the second runtime based on the historical load information of the first instance, or the first instance can be switched from the first runtime to the second runtime based on the user's switching command, or the first instance can be switched from the first runtime to the second runtime based on other information. The specific method can be determined according to the actual situation and is not limited here.

[0049] Freezing the business processing process corresponding to the first instance means suspending the business processing process corresponding to the first instance.

[0050] Freezing the business processing process ensures the consistency of runtime status data before and after runtime switching, avoiding data corruption and logical anomalies after runtime switching. Moreover, the precise freezing of the business processing process achieves a balance between "preserving traffic and preserving data"—only pausing business processing without interrupting network monitoring, ensuring that traffic is not affected during instance operations. Furthermore, it simplifies the status capture logic, reduces recovery risks, and improves operational efficiency, making it the core design for "secure and efficient instance operation" in container cloud or Wasm lightweight runtime scenarios.

[0051] It can achieve the following: By using fine-grained signal control or custom APIs to perform process-level freezing, it is possible to freeze only the business processing logic while retaining the network listening / traffic receiving capabilities, so that external traffic is not interrupted (requests can arrive normally and return basic responses, but there is no business layer processing). This is also the core implementation method of pseudo-pause or soft freeze in container cloud scenarios, which is different from full freeze at the container runtime level (i.e., interrupting the network and interrupting all processes).

[0052] The core logic is: the granularity of freezing is precisely controlled at the business processing process (or business processing thread), rather than the network listening process (or network listening thread), so that the container's network stack, port listening, and basic request response capabilities remain normal, only stopping core business logic calculations, data processing, and other operations. From the outside, the service is always "online" and traffic is uninterrupted. This is also the essential difference from the standard pause operation (full process freeze and network freeze).

[0053] Signal control utilizes Linux's native process signals for fine-grained freezing. The core principle is to avoid using SIGSTOP / SIGTSTP (full process freeze) and instead use custom signals (SIGUSR1 / SIGUSR2) to enable "conditional freezing" of the program, making it the most lightweight implementation.

[0054] For example, the user-defined signals SIGUSR1 / SIGUSR2 (without default behavior, handled by the program itself) reserved by Linux can be used to pre-register signals in the service code, achieving "freezing the business thread upon receiving a signal and resuming it upon releasing the signal". The core process is as follows: When the service starts, the signal handling functions for SIGUSR1 (freeze) / SIGUSR2 (resume) are registered; when the service is running normally, the network listening thread and the business processing thread are separated: the listening thread continuously listens to the port, receives requests and puts them into the task queue, and the business thread takes tasks from the queue for processing; when kill-SIGUSR1[PID] is sent to the process, the signal handling function is triggered, pausing the task consumption of the business thread (the task queue can choose to cache or directly return a fallback response), but the listening thread continues to work normally and continues to receive external traffic; when kill-SIGUSR2[PID] is sent to the process, the signal handling function is triggered, the task consumption of the business thread is resumed, and the service returns to normal processing logic. Under this signal control condition, external traffic is not interrupted at all, and requests can reach the service port normally without timeout or port unreachability; during the request processing freeze, a fallback response (such as 200 OK + empty data or maintenance prompt) can be returned, or a small number of requests can be temporarily cached (depending on the queue size) to avoid request loss; resource status: CPU usage is greatly reduced (only the listening thread is running), memory is reserved, and the network stack is normal.

[0055] API call freezing can be implemented at the process level through custom health check APIs or freeze control APIs. It is the mainstream solution for enterprise services, which is more flexible, monitorable, and batch-operable than signal control. The core is that the service itself exposes control interfaces, which are called by the platform or manually to achieve fine-grained freezing.

[0056] The custom freeze control API (actively triggered) exposes a dedicated control interface (e.g., / api / v1 / service / freeze / / api / v1 / service / resume) during service development. This interface performs authentication (to prevent unauthorized calls). After the call, the service controls the execution / pause of business logic through internal state switches. The core process is as follows: The service maintains a global freeze state flag (e.g., is_frozen:bool), which defaults to false (normal). Calling the / freeze interface sets the flag to true, pausing business threads, data processing, database interactions, etc., while only network listening and API responses are maintained. Calling the / resume interface sets the flag to false, resuming all business logic. Optionally, the / api / v1 / service / state interface can be exposed to monitor the service's current freeze state, facilitating platform scheduling decisions.

[0057] The health check API adaptation (platform linkage) is based on the container cloud platform's ReadinessProbe. Services expose custom health check interfaces (e.g., / actuator / health / custom, adapted to frameworks like SpringBoot / Go / Node.js). The interface return value controls the business freeze status. The core process is as follows: the health check interface returns in two layers: a basic layer (network / port status, always returning 200) and a business layer (processing capacity status, returning a custom identifier such as 503 Service Unavailable when frozen). The platform only performs traffic scheduling based on the basic layer (ensuring traffic is always forwarded to the instance), while the service itself controls whether to process requests based on the business layer status. When freezing is required, the business layer return status is modified through platform / manual API calls, triggering the business logic freeze. Recovery is achieved by reversing the process. In this scenario, external traffic remains uninterrupted, with the platform consistently forwarding traffic to the instance. Requests are never lost or timed out. Request processing allows for customized responses (such as maintenance pages, business degradation data, and cached data), supporting traffic shaping / backup strategies for a superior user experience compared to signal control. The platform can also be integrated with the container cloud platform's automated scheduling (such as batch API calls to freeze the cluster), supporting monitoring, alerts, and logging, and allowing for traceability of freeze / recovery operations.

[0058] S102. Obtain the first running status data corresponding to the first instance.

[0059] The first running status data is used to indicate the running status of the first instance.

[0060] It is understandable that the first running status data is used to indicate the running status of the first instance before the business processing process corresponding to the first instance is frozen.

[0061] The first runtime state data includes the minimum data necessary to restore the first instance to operation. This data may include process context, open file handles, environment variables, etc., and the specific details can be determined based on the actual situation; no restrictions are imposed here.

[0062] The first runtime state data can be snapshot data stored in the form of a snapshot. In some embodiments of this application, if the first runtime is a container runtime, the CRIU tool can be used to generate snapshot data; if the first runtime is a Wasm runtime, the Wasmtime's store snapshot function can be used to serialize memory and global variables to obtain snapshot data, i.e., the first runtime state data.

[0063] After a business process is paused, the states of memory, global variables, file handles, etc. will be fixed at "a certain point in time". Snapshot tools (CRIU / Wasmtime) can capture static and consistent state data completely and accurately. After recovery or migration, the instance will not have a disordered state where "half of the data is old and half is new".

[0064] S103. Create a second instance on the node corresponding to the second runtime.

[0065] The second instance is an instance that runs based on the second runtime. The second instance is an instance created and run on the node corresponding to the second runtime.

[0066] In this context, the instance of a container runtime is a pod, while the instance of a Wasm runtime is a dynamically executable entity that has an independent execution environment and a running state after the Wasm module is loaded into the runtime. It can be understood as a running Wasm program.

[0067] S104. Migrate the first running state data to the second instance to obtain the second running state data.

[0068] The core objective of memory data migration is to completely transfer active, structured data (such as objects, process states, variables, etc.) from the source instance (first instance) to the target instance (second instance).

[0069] S105. Migrate the data of the first file system corresponding to the first instance to the file system corresponding to the second instance to obtain the data of the second file system.

[0070] In this embodiment of the application, by migrating the file system data corresponding to the first instance to the second instance, it can be ensured that "dynamic or local file data is not lost and business logic is not interrupted" after the instance switch. It only applies to "dynamic files on the local side of the instance" and is a key operation to supplement insufficient snapshot data and ensure data integrity during instance switch.

[0071] Migrate file system data (you can use rsync or similar tools to copy persistent volume data). During the migration process, ensure data consistency through checksum verification.

[0072] S106. Based on the second running state data and the second file system data, start the second instance.

[0073] It is understandable that, based on the second running state data and the second file system data, the running state of the first instance is restored in the second instance, enabling the second instance to have the ability to process business.

[0074] S107. Redirect the service request corresponding to the first instance to the second instance.

[0075] It is understandable that the service requests corresponding to the instance are redirected to the new instance, and the second runtime begins to receive and execute the new requests, thus achieving a smooth transition of business operations.

[0076] For example, a traffic proxy (such as an Envoy sidecar) can be used to update service routes, redirecting incoming requests to a second instance (by updating the Kubernetes Endpoint). The first instance remains in standby mode but does not process new requests, ensuring zero interruption (switchover time < 100ms).

[0077] In this embodiment, when it is determined that the first instance should be switched from the first runtime to the second runtime, the following steps are taken: the business processing process corresponding to the first instance is frozen, the first runtime status data corresponding to the first instance is obtained, a second instance is created on the node corresponding to the second runtime, and then the first runtime status data is migrated to the second instance to obtain the second runtime status data; the first file system data of the file system corresponding to the first instance is migrated to the file system corresponding to the second instance to obtain the second file system data; based on the second runtime status data and the second file system data, the second instance is started; and the service requests corresponding to the first instance are redirected to the second instance. Thus, during the process of switching the first instance from the first runtime to the second runtime, dynamic hot switching is achieved through zero-interruption migration rather than static resource allocation. This ensures that the system can dynamically and hot-swap between Wasm runtime and container instances with zero interruption based on load characteristics during operation. In this way, when the initial runtime is container runtime and the load characteristics shift from high density to lightweight, timely hot-swap from container runtime to Wasm runtime can improve resource utilization and reduce response latency. Conversely, when the initial runtime is Wasm runtime and the load characteristics shift from lightweight to high density, timely switch from Wasm runtime to container runtime can improve system adaptability, flexibility, and resource utilization. This enables performance and resource optimization in cloud-native heterogeneous load environments, thereby addressing the current issues of low resource utilization, high response latency, and poor system adaptability.

[0078] This application relates to the field of cloud-native computing, specifically a runtime system design combining containerization and Wasm technology. It focuses on the dynamic management of heterogeneous workloads, including different types such as CPU-intensive, memory-intensive, and I / O-intensive workloads. By integrating the Wasm runtime onto container orchestration platforms like Kubernetes, it achieves seamless virtualization resource switching. This application is applicable to edge computing, serverless architecture, and hybrid cloud scenarios, significantly improving the efficiency and cost-effectiveness of handling heterogeneous workloads. Through a dynamic hot-switching mechanism, this application ensures that the system can switch between the Wasm module and container instances based on real-time load characteristics without service interruption during operation, thereby optimizing performance and resource efficiency.

[0079] In some embodiments of this application, combined with Figure 1 ,like Figure 2 As shown, prior to S101, the runtime switching method provided in this application embodiment may further include the following S108.

[0080] S108. If, within a first time period, the number of times the load information of the first instance satisfies the switching condition is greater than or equal to the number of times a threshold is reached, it is determined to switch the first instance from the first runtime to the second runtime.

[0081] The first duration can be determined based on the actual situation and is not limited here.

[0082] The number of times threshold can be determined according to the actual situation, and is not limited here.

[0083] The switching condition is used to indicate that the load information matches the second runtime.

[0084] The load information may include at least one of the following: compute density, memory utilization, CPU utilization, I / O throughput, and network latency. Other information may also be included, but is not limited here.

[0085] For example, when the load information includes compute density, the switching condition may include the compute density within the range corresponding to the second runtime; when the load information includes memory utilization, the switching condition may include the memory utilization within the range corresponding to the second runtime; when the load information includes CPU utilization, the switching condition may include the CPU utilization within the range corresponding to the second runtime; when the load information includes I / O throughput, the switching condition may include the I / O throughput within the range corresponding to the second runtime; when the load information includes network latency, the switching condition may include the memory utilization within the range corresponding to the second runtime. Other conditions may also be included, which can be determined based on actual circumstances and are not limited here.

[0086] In some embodiments of this application, if the number of times the load information of the first instance satisfies the switching condition within a first duration is less than a threshold, it is determined that the first instance does not need to be switched from the first runtime to the second runtime. The first duration is determined based on a sliding time window with a preset step size. The preset duration can be the duration for collecting load information once, and the duration of the sliding time window is the first duration. If it is determined that the first instance does not need to be switched from the first runtime to the second runtime within the first duration before the current moment, it is further determined whether the load information within the next preset duration satisfies the switching condition. Then, the relationship between the number of times the load information of the first instance satisfies the switching condition and the threshold is determined within the next first duration (including the next preset duration). This determines whether the first instance needs to be switched from the first runtime to the second runtime within the next first duration, and so on. When a runtime switch is required, the runtime switch process is executed. After a successful runtime switch, the number of times the load information of the first instance satisfies the switching condition within the first duration under the switched runtime is recounted to determine whether another runtime switch is needed. If a runtime switch is not required, it is further determined whether a runtime switch is needed within the next first duration.

[0087] In some embodiments of this application, within a first time period, the number of times the load information of the first instance satisfies the switching condition is greater than or equal to a threshold number may include the total number of times the load information of the first instance satisfies the switching condition within the first time period (including the number of times the switching condition is met consecutively and the number of times the switching condition is met intermittently) being greater than or equal to the threshold number, or the total number of times the load information of the first instance continuously satisfies the switching condition within the first time period (including only the number of times the switching condition is met consecutively) being greater than or equal to the threshold number. The specific number may be determined according to the actual situation and is not limited here.

[0088] In this embodiment, based on whether the load information of the first instance within a certain period of time meets the switching conditions, the system determines whether it needs to switch the first instance from the first runtime to the second runtime. In this way, based on the monitoring of the load information of the first instance over a certain period of time, it can accurately determine whether a runtime switch is needed. Then, when a runtime switch is needed, the system's flexibility and resource utilization are improved through zero-interruption hot switching, thereby achieving performance and resource optimization of the cloud-native heterogeneous load environment and improving the current problems of low resource utilization, high response latency, and poor system adaptability.

[0089] In some embodiments of this application, combined with Figure 1 ,like Figure 3 As shown, prior to S101, the runtime switching method provided in this application embodiment may further include the following S109 and S110.

[0090] S109. Input the historical load information of the first instance into the load prediction model and output load prediction information. The load prediction information is used to indicate that the load information of the first instance matches the second runtime within the target time period.

[0091] The load prediction model can be obtained from a pre-trained machine learning model.

[0092] Among them, the historical load information is obtained based on historical statistical load information.

[0093] The target time period can be determined based on the actual situation and is not limited here.

[0094] S110. Based on the load prediction information, within a second duration before the target time period arrives, determine to switch the first instance from the first runtime to the second runtime.

[0095] The second duration can be determined based on the actual situation and is not limited here.

[0096] In this embodiment, a pre-trained load prediction model predicts future load information changes of an instance based on historical load information. The system switches before the predicted change period (target period) is reached. Thus, within the target period of load information change, a second runtime instance matching the load information within the target period can be run, which can improve the current problems of low resource utilization, high response latency, and poor system adaptability.

[0097] In some embodiments of this application, combined with Figure 1 ,like Figure 3 As shown, the above S104 can be specifically implemented by the following S104a to S104e.

[0098] S104a. The first running state data is serialized to obtain the first migration data stream.

[0099] S104b: Send the first migration data stream to the node corresponding to the second runtime.

[0100] S104c, at the node corresponding to the second runtime, the first migration data stream is deserialized to obtain the first runtime state data.

[0101] S104d: Perform data transformation processing on the first running state data to obtain the second running state data that matches the second running state.

[0102] The data conversion process involves performing runtime adaptation processing on the first running state data, that is, converting the first running state data adapted to the first running state into the second running state data adapted to the second running state.

[0103] For example, data transformation processing may include one or more of the following: system call mapping, network I / O adaptation, environment and security negotiation, and application hook execution.

[0104] Specifically, system call mapping involves using an intermediate layer (similar to a bridge or dedicated processor) to convert memory state data from system calls corresponding to the first runtime to system calls corresponding to the second runtime. For example, if the first runtime is a container runtime and the second runtime is a Wasm runtime, the system call mapping includes parsing captured syscall logs and using a shim layer to convert container-native calls to WASI equivalent calls (e.g., converting `open` to `fd_prestat_get` + `fd_open`); if the first runtime is a Wasm runtime and the second runtime is a container runtime, the system call mapping includes converting memory state data from WASI equivalent calls to container-native calls.

[0105] Network I / O adaptation specifically involves rebuilding the socket connection. For instance, if the first runtime is a container runtime and the second runtime is a Wasm runtime, then network I / O adaptation includes rebuilding the socket connection; if the first runtime is a Wasm runtime and the second runtime is a container runtime, then network I / O adaptation includes directly restoring the socket file descriptor (fd).

[0106] It's understandable that network connections need to be rebuilt when switching between different runtimes, such as connections from container to agent and from container to container. When a new instance is created, network-level connections need to be established, and this information is included in the state snapshot. Network I / O adaptation not only affects traffic redirection but also the container's own access connections to databases, caches, etc.

[0107] Among these, environmental and safety consultations include the unified injection of environmental variables and the reapplication of capabilities constraints.

[0108] Application hook execution includes calling registered custom hooks to handle specific states (such as connection pool reconstruction).

[0109] In some embodiments of this application, after the file system data is migrated from the first runtime to the second runtime, it is also necessary to perform data conversion processing on the file system data. For example, if the first runtime is a container runtime and the second runtime is a Wasm runtime, the data conversion processing includes injecting directories and file descriptors using the WASI preopens mechanism and restoring the current working directory and offset; if the first runtime is a Wasm runtime container runtime and the second runtime is a Wasm runtime, the data conversion processing includes reconstructing a complete file view. S104e, Save the second running status data to the second instance.

[0110] It is understandable that the second instance is used to restore services based on the second running state data.

[0111] If the second runtime is a Wasm runtime, the second runtime state data can be injected into the memory space of the Wasm module (using Wasmtime's Memory API); if the second runtime is a container runtime, the second runtime state data can be injected into the container process (using CRIU restore).

[0112] In this embodiment of the application, by performing serialization, data transmission, deserialization, and data conversion on the first running state data corresponding to the first instance, the second running state data matching the second runtime can be obtained quickly. Then, based on the second running state data, the second instance can be started quickly, thereby realizing business processing based on the second instance.

[0113] It can be understood that the entire process of memory data migration is divided into three major stages: source processing, data transmission, and destination processing. Among them, serialization only occurs at the source (converting memory data into a transmittable format); deserialization only occurs at the destination (restoring the transmitted format back to memory data); the data transmission stage does not involve these two operations, and only data is moved.

[0114] First, pause the business process of the first instance (to prevent data modification during serialization and ensure consistency), and lock the memory areas to be migrated (such as heap memory and process state memory). Then, iterate through and filter the core data in memory (excluding temporary caches and useless data), and extract structured data (such as Java objects, Go structs, and network / file states of container processes). The serialization process involves calling serialization tools / protocols (such as Protobuf, JSON, custom serialization using the container's CRIU tool, and Python pickle) to convert the extracted memory data (including data structures, values, and memory address mappings) into a byte stream / string (not directly executable, but transferable across network / storage). Perform integrity verification (such as MD5 hashing) on ​​the serialized byte stream to ensure data integrity, and then encapsulate it into a transmission packet. During the data transmission (no serialization / deserialization) process, the serialized byte stream from the source end is transmitted to the target end via network (TCP / RDMA) or storage medium (local disk, distributed storage). This stage only performs data transmission and verification, without modifying the data format. Receive the transmission packet, verify the hash value to ensure the data is consistent with the source; during the deserialization process, call the deserialization tool / protocol matching the source to restore the byte stream into a memory data structure recognizable by the target instance (such as rebuilding Java objects, restoring the memory address mapping of container processes, and thread states); write the deserialized structured data into the memory area of ​​the second instance to restore the memory layout consistent with the first instance; unlock the memory, start / restore the business process of the second instance, the process reads the restored memory data, and restores normal service.

[0115] In some embodiments of this application, the runtime state data of the first instance can be transformed at the node corresponding to the second runtime. This means that after obtaining the runtime state data, no transformation is performed; a snapshot is directly generated, then serialized and migrated. The data is then deserialized or transformed again at the node corresponding to the second runtime, and finally stored in memory. Alternatively, the runtime state data of the first instance can be transformed at the node corresponding to the first runtime. This means that after obtaining the runtime state data, it is first transformed, then a snapshot is generated, then serialized and migrated. At the target node, it is deserialized and directly stored in memory. The specific method can be determined based on actual circumstances and is not limited here.

[0116] In some embodiments of this application, combined with Figure 1 ,like Figure 5 As shown, S102 can be implemented by S102a to S102b, and S104 can be implemented by S104f to S104i.

[0117] S102a. Obtain the third running status data corresponding to the first instance.

[0118] S102b: Perform data transformation processing on the third running state data to obtain the first running state data that matches the second running state.

[0119] S104f: Serialize the first running state data to obtain the first migration data stream.

[0120] S104g: Send the first migration data stream to the node corresponding to the second runtime.

[0121] S104h, at the node corresponding to the second runtime, the first migration data stream is deserialized to obtain the first runtime status data.

[0122] The first running status data is the same as the second running status data.

[0123] S104i, Save the second running status data to the second instance.

[0124] In this embodiment, after the node corresponding to the first runtime obtains the runtime status data of the first instance, it performs data transformation processing to obtain the first runtime status data that matches the second runtime. Thus, based on the first runtime status data, the second instance can perform service recovery based on the second runtime status data, thereby facilitating hot switching during runtime.

[0125] In this embodiment, since the node corresponding to the second runtime has relevant interfaces and underlying dependent library functions, the data conversion processing of the running status data of the first instance performed by the node corresponding to the second runtime can be completed more conveniently and quickly. Compared with the data conversion processing of the running status data of the first instance performed by the node corresponding to the first runtime, the adaptation problems that may occur when the node corresponding to the first runtime performs the conversion to the node corresponding to the second runtime can be avoided.

[0126] In some embodiments of this application, combined with Figure 4 ,like Figure 6 As shown, after S107, the runtime switching method provided in this application embodiment may further include S111 and S112 as described below.

[0127] S111. Determine whether the second instance is stable by monitoring the startup metrics of the second instance.

[0128] S112. If the second instance is determined to be stable, destroy the first instance.

[0129] For example, health check probes can be used to monitor the startup metrics of the second instance to determine if it is stable (e.g., stable CPU usage, no error logs). If the second instance is verified to be stable (e.g., via a liveness probe), the first instance can be destroyed, and the Kubernetes API can be notified to update resource allocation.

[0130] Destroying the first instance can be understood as calling the Kubernetes API to delete the old Pod (if the first runtime is a container runtime, delete the first instance) or terminate the Wasm store (if the first runtime is a Wasm runtime, terminate the Wasm store), thus releasing resources. Simultaneously, the Kubernetes API updates the cluster state to ensure resource balance.

[0131] In this embodiment, the first instance is destroyed only when the second instance is determined to be stable. This way, if the second instance is determined to be unstable, the first instance can be restored in a timely manner, ensuring that the service corresponding to the first instance is not interrupted.

[0132] In some embodiments of this application, combined with Figure 6 ,like Figure 7 As shown, after S111, the runtime switching method provided in this application embodiment may further include S113 and S114 as described below.

[0133] S113. If it is determined that the second instance is unstable, unfreeze the business processing process corresponding to the first instance.

[0134] S114. Redirect the service request corresponding to the second instance to the first instance.

[0135] In this embodiment of the application, by setting a rollback mechanism after the runtime switching process is successfully executed, if it is determined that the second instance is unstable, the business processing process corresponding to the first instance is unfrozen; and the service requests corresponding to the second instance are redirected to the first instance, which can ensure that the service corresponding to the first instance is not interrupted.

[0136] In some embodiments of this application, the runtime switching method provided in the embodiments of this application may further include the following S115.

[0137] S115. If the runtime switching process of switching the first instance from the first runtime to the second runtime fails, unfreeze the business processing process corresponding to the first instance.

[0138] It is understandable that if an anomaly occurs in the runtime switching process before the service request corresponding to the first instance is redirected to the second instance, the business processing process corresponding to the first instance will be unfrozen. Unfreezing the business processing process corresponding to the first instance can be understood as restoring the business processing process corresponding to the first instance.

[0139] Runtime failover failure includes any anomalies in the runtime failover process, and failure to complete the runtime failover process within the third time period. The third time period is a threshold duration for runtime failover. During the third time period, the first instance remains in standby mode. The third time period can be determined based on actual circumstances and is not limited here.

[0140] In this embodiment of the application, by setting a rollback mechanism in the runtime switching process, the business processing process corresponding to the first instance can be unfrozen in the event that the runtime switching process fails, thus ensuring that the service corresponding to the first instance is not interrupted.

[0141] In some embodiments of this application, the runtime switching method provided in the embodiments of this application may further include the following S116.

[0142] S116. If the runtime switching process of switching the first instance from the first runtime to the second runtime fails, log and debug.

[0143] In this embodiment of the application, if the runtime switching process fails, the cause of the runtime switching failure can be determined and the problem can be solved by logging and debugging, so as to avoid the next switch failing or to change the switching scheme when the next runtime switch is required.

[0144] This application proposes a runtime switching system based on Wasm runtime and container runtime for heterogeneous workloads. For example... Figure 8 As shown, the system includes at least one node based on the Wasm runtime (represented by Wasm runtime 805 in the figure), at least one node based on the container runtime (represented by container runtime 806 in the figure), and the system also includes a monitoring module 801, a decision engine 802, a switching agent 803, and Kubernetes 804.

[0145] Monitoring Module 801: Used for real-time monitoring of the load information (performance metrics) of each node instance (such as the first instance) in the system, including one or more of the following: CPU utilization, memory usage, I / O throughput, network latency, and compute density. It collects data by integrating Prometheus or similar tools and transmits this data to the decision engine. The function of this monitoring module is to provide a data foundation, ensuring that decisions are based on accurate load information and avoiding delays or incorrect judgments.

[0146] Decision Engine 802: Receives real-time load information of instances from the monitoring module. Based on this information, it analyzes whether the current load is suitable for the current runtime (whether it matches the current runtime) using preset rules (such as threshold judgment). Then, based on the number of times the instance's real-time load information matches the switching conditions within a certain time period (such as a first duration), it determines whether to switch the current runtime (first runtime) to the target runtime (second runtime). It also receives real-time load information from the monitoring module as historical load information. All historical load information received from the monitoring module is input into the load prediction model. Based on the currently obtained historical load information, it predicts whether a runtime switch will be needed in a future time period. Essentially, the decision engine determines whether to perform a runtime switch based on changes in load characteristics (such as switching from high computing density to low density) and, if a switch is determined, issues a switch command to the switch agent. The decision engine's function is intelligent decision-making, supporting custom strategies for determining runtime switch based on load information, which can improve the system's adaptability.

[0147] Switching Agent 803: This agent performs the actual runtime hot-swap operation, including capturing the current instance's runtime state data (such as snapshot data) and file system data, serializing / deserializing the runtime state data, migrating the runtime state data and file system data, and restoring the business runtime state of the source instance (the instance before the runtime switch) in a newly created instance (the instance after the runtime switch) corresponding to the target runtime (Wasm or container). It interacts with Wasm runtimes (such as Wasmtime) and container runtimes (such as containerd) to ensure uninterrupted migration. The switching agent's functions are state management and data migration, and it supports a rollback mechanism in case of failure.

[0148] Wasm Runtime 805: Executes Wasm modules, providing a lightweight sandbox environment suitable for low resource loads. Features include module loading, execution, and isolation.

[0149] Container runtime 806: Executes container instances, providing process-level isolation, suitable for complex workloads. Features include image management and namespace isolation.

[0150] Kubernetes 804: An external orchestration platform that provides resource scheduling and API support.

[0151] In some embodiments of this application, such as Figure 8As shown, the runtime failover system can also include a unified scheduler 807, which serves as the system entry point, integrates with the Kubernetes API Server, and manages resource allocation and instance lifecycle. It coordinates the entire failover process, ensuring resource reallocation after the failover. The unified scheduler's functionality includes compatibility with the existing cloud-native ecosystem, providing extended interfaces, and supporting multi-cluster deployments.

[0152] For example, suppose the first runtime is a container runtime, the second runtime is a Wasm runtime, and the current instance is the first instance, such as Figure 9 The diagram shows the specific process flow for runtime switching, including S901 to S910 below.

[0153] S901, System startup initialization.

[0154] The system startup process includes the following initialization steps: S901a, Initialize Wasm runtime.

[0155] For example, the Wasmtime engine loads the necessary Wasm module configurations.

[0156] S901b, Initialize container runtime.

[0157] For example, containerd configures cgroups and namespaces.

[0158] S901c and the unified scheduler are registered with the Kubernetes RuntimeClass to ensure that instances can specify dynamic runtime.

[0159] S901d, monitoring module starts data acquisition agent.

[0160] S901e, the decision engine loads the decision model.

[0161] S901f, Switch Agent Preparation State Migration Tool.

[0162] For example, CRIU for checkpoint / restore.

[0163] S902, the monitoring module performs real-time load monitoring.

[0164] The real-time load monitoring process specifically includes the following steps: S902a The monitoring module periodically collects load information of the first instance from Kubernetes.

[0165] The S902b monitoring module sends the collected load information to the decision engine.

[0166] The monitoring module packages the collected load information (in JSON format) and transmits it to the decision engine.

[0167] S903, the decision engine makes decisions.

[0168] The decision-making process includes: S903a, The decision engine determines, based on the load information of the first instance, to switch the first instance from the container runtime to the Wasm runtime.

[0169] S903b: The decision engine sends a switching command to the switching agent.

[0170] The switching instruction can include the source runtime (first runtime, container runtime) and its corresponding node ID (the node ID of the node corresponding to the first runtime), the target runtime (second runtime, Wasm runtime) and its corresponding node ID (the node ID of the node corresponding to the second runtime).

[0171] S904. Switching Agents: Based on the switching command, the business processing process corresponding to the first instance is frozen.

[0172] S905. Switch the proxy to obtain the first running status data corresponding to the first instance.

[0173] S906. Switch the agent to create a second instance on the node corresponding to the Wasm runtime.

[0174] S907. Switch the agent to migrate the first running state data to the second instance to obtain the second running state data.

[0175] S908. Switch the agent to migrate the data of the first file system corresponding to the first instance to the file system corresponding to the second instance, and obtain the data of the second file system.

[0176] S909. Switch agent based on second running status data and second file system data, start second instance.

[0177] S910, Switch Proxy: Redirect service requests corresponding to the first instance to the second instance via traffic proxy.

[0178] In this embodiment, each module of the runtime switching device can implement the runtime switching method provided in the above method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0179] like Figure 10As shown, this application embodiment also provides a terminal device 1000, which can be the aforementioned electronic device or server. The terminal device 1000 includes: a processor 1001, a memory 1002, and a computer program stored in the memory 1002 and executable on the processor 1001. When the computer program is executed by the processor 1001, it implements the various processes executed by the runtime switching method described above and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0180] The present invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described runtime switching method and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0181] The computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0182] The present invention provides a computer program product, comprising: when the computer program product is run on a computer, causing the computer to implement the above-described runtime switching method.

[0183] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0184] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A runtime switching method, characterized in that, include: If it is determined that the first instance will be switched from the first runtime to the second runtime, the business processing process corresponding to the first instance shall be frozen. The first runtime is one of the container runtime and the Wasm runtime, and the second runtime is one of the container runtime and the Wasm runtime that is different from the first runtime. Obtain the first running status data corresponding to the first instance, wherein the first running status data is used to indicate the running status of the first instance; A second instance is created on the node corresponding to the second runtime. The first running status data is migrated to the second instance to obtain the second running status data; Migrate the first file system data of the file system corresponding to the first instance to the file system corresponding to the second instance to obtain the second file system data; Based on the second running status data and the second file system data, start the second instance; Redirect the service request corresponding to the first instance to the second instance.

2. The method according to claim 1, characterized in that, The method further includes: If, within a first time period, the number of times the load information of the first instance satisfies the switching condition is greater than or equal to a threshold number, it is determined to switch the first instance from the first runtime to the second runtime. The switching condition is used to indicate that the load information matches the second runtime.

3. The method according to claim 1, characterized in that, The method further includes: The historical load information of the first instance is input into the load prediction model, and the load prediction information is output. The load prediction information is used to indicate that the load information of the first instance matches the second runtime within the target time period. Based on the load prediction information, within a second duration prior to the arrival of the target time period, it is determined to switch the first instance from the first runtime to the second runtime.

4. The method according to claim 1, characterized in that, The step of migrating the first running status data to the second instance to obtain the second running status data includes: The first running state data is serialized to obtain the first migration data stream; Send the first migration data stream to the node corresponding to the second runtime; At the node corresponding to the second runtime, the first migration data stream is deserialized to obtain the first runtime status data; The first running status data is transformed to obtain second running status data that matches the second running state. Save the second running status data to the second instance.

5. The method according to claim 1, characterized in that, The step of obtaining the first running status data corresponding to the first instance includes: Obtain the third running status data corresponding to the first instance; The third running status data is processed by data transformation to obtain the first running status data that matches the second running status.

6. The method according to claim 1, characterized in that, After redirecting the service request corresponding to the first instance to the second instance, the method further includes: By monitoring the startup metrics of the second instance, it can be determined whether the second instance is stable; Once the second instance is determined to be stable, the first instance is destroyed.

7. The method according to claim 6, characterized in that, The method further includes: If the second instance is determined to be unstable, the business processing process corresponding to the first instance is unfrozen. Redirect the service request corresponding to the second instance to the first instance.

8. The method according to claim 1, characterized in that, The method further includes: If the runtime switching process of switching the first instance from the first runtime to the second runtime fails, the business processing process corresponding to the first instance is unfrozen.

9. The method according to any one of claims 1-8, characterized in that, The method further includes: If the runtime switching process of switching the first instance from the first runtime to the second runtime fails, log and debug.

10. A terminal device, characterized in that, include: Memory, configured to store computer programs; The processor is configured to cause the terminal device to implement the runtime switching method of any one of claims 1 to 9 when a computer program is invoked.

Images