IoT service migration methods, devices, equipment and storage media

Abstract

This application provides a method, apparatus, device, and storage medium for migrating IoT services. The method includes: determining the service to be migrated, the target device, and at least one target transmission path for the service to be migrated based on the communication connection information of the source device; migrating read-write service data in the container layer to the target device according to the target transmission path; migrating read-only service data in each mirror layer to the target mirror layer of the target device based on the source server of the source device and the target server of the target device; and transmitting the collected data of the service to be migrated to the target device according to the target transmission path at a preset period. The method of this application generates the target transmission path based on multiple constraint information, reducing the cost of IoT service migration and improving the efficiency of service migration.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) service technology, and more specifically, to an IoT service migration method, apparatus, device, and storage medium. Background Technology

[0002] With the increasing capacity of IoT devices and the adoption of microservice architectures, services execute on edge devices to process smart sensing data. When edge devices become overloaded, service migration can alleviate this overload. Service migration refers to migrating one or more active services and their runtime configuration files to IoT devices within the same edge network or across edge networks to alleviate overloaded IoT devices.

[0003] In existing technologies, when migrating services, the service is encapsulated in a container, the overloaded device and the target device are identified, the container is migrated as a whole, and then the sensor data of the overloaded device is periodically transferred to the target device after the service migration is completed.

[0004] However, existing solutions for service migration suffer from high device power consumption and high task latency during container migration. Furthermore, edge devices along the migration path incur additional resource consumption. Moreover, existing solutions struggle to accommodate the migration needs of data-intensive and compute-intensive services. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing an IoT service migration method, apparatus, device, and storage medium to solve the problems of high migration cost and low migration efficiency of IoT servers in the prior art.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0007] In a first aspect, this application provides an Internet of Things (IoT) service migration method, the method comprising:

[0008] Based on the communication connection information of the source device, determine the service to be migrated, the target device, and at least one target transmission path of the service to be migrated. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the container of the source device, and the read-only service data is stored in at least one mirror layer of the container.

[0009] Migrate the readable and writable service data in the container layer to the target device according to the target transmission path;

[0010] Based on the source server of the source device and the target server of the target device, the read-only service data in each of the image layers is migrated to the target image layer of the target device;

[0011] The collected data of the service to be migrated is transmitted to the target device according to the target transmission path according to the preset cycle.

[0012] Secondly, this application provides an Internet of Things (IoT) service migration device, the device comprising:

[0013] The determination module is used to determine the service to be migrated, the target device, and at least one target transmission path of the service to be migrated based on the communication connection information of the source device. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the container of the source device, and the read-only service data is stored in at least one mirror layer of the container.

[0014] The first migration module is used to migrate the readable and writable service data in the container layer to the target device according to the target transmission path;

[0015] The second migration module is used to migrate the read-only service data in each of the image layers to the target image layer of the target device, based on the source server of the source device and the target server of the target device.

[0016] The third migration module is used to transmit the collected data of the service to be migrated to the target device according to the target transmission path according to a preset period.

[0017] Thirdly, this application provides an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the IoT service migration method described above.

[0018] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the IoT service migration method described above.

[0019] The beneficial effects of this application are: by transmitting the container layer through the terminal device and the image layer through the server, only the topmost container layer needs to be migrated and transmitted during service migration, eliminating the need to transmit the image layer between IoT devices. This reduces the transmission path of the image layer and achieves lightweight service migration. Determining the service to be migrated, the target device, and the target transmission path based on the communication connection information of the source device can fully consider the resource, time, and energy limitations of the terminal device, thereby reducing the cost and improving the efficiency of service migration. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This paper illustrates an architecture diagram of an Internet of Things (IoT) service system provided in an embodiment of this application.

[0022] Figure 2 A flowchart of an IoT service migration method provided in an embodiment of this application is shown;

[0023] Figure 3 This document illustrates a flowchart illustrating how to determine the service to be migrated, the target transmission path, and the target device, according to an embodiment of this application.

[0024] Figure 4 A flowchart illustrating a method for determining constraint information according to an embodiment of this application is shown;

[0025] Figure 5 This document illustrates a flowchart of a method for determining a target transmission path according to an embodiment of this application.

[0026] Figure 6 A schematic diagram illustrating a crossover variation provided in an embodiment of this application is shown;

[0027] Figure 7 A flowchart of a transmission mirroring layer provided in an embodiment of this application is shown;

[0028] Figure 8 This illustration shows a service migration method provided in an embodiment of this application.

[0029] Figure 9 This document illustrates a flowchart of a method for pulling a mirror layer according to an embodiment of this application.

[0030] Figure 10This paper shows a schematic diagram of the structure of an Internet of Things (IoT) service migration device provided in an embodiment of this application.

[0031] Figure 11 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0033] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0034] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0035] Current research on IoT service migration primarily focuses on virtual machine migration within data centers or the cloud, where virtual machine downtime and migration costs are key performance evaluation factors. With the increasing capacity of IoT devices and the adoption of microservice architectures, services are executed on edge devices to process smart sensor data. When edge devices become overloaded, service migration can be leveraged to alleviate this load. The biggest challenge is determining the optimal edge device or server for migration to accommodate more tasks while minimizing energy consumption. However, considering only energy consumption can lead to increased latency, consequently reducing service quality.

[0036] Based on this, several solutions have been proposed to minimize energy consumption and average latency during container or service migration scheduling. However, containers consist of tiered storage systems, and the underlying storage layer (i.e., the image layer) can be shared among IoT devices. Therefore, migrating an entire container may be inappropriate, as it can lead to high device energy consumption and high task latency.

[0037] Secondly, after the service migration, it is necessary to periodically transfer the sensor data of the overloaded devices to the target devices. Each edge device along the transmission path needs to bear additional resource consumption during the transmission of sensor data, including memory, bandwidth and energy. Therefore, the lifespan of the edge network may be impaired.

[0038] Furthermore, IoT services may be described as compute-intensive, data-intensive, or both compute- and data-intensive. In such cases, it is necessary to determine server migration strategies based on the migration requirements of different service types, a point that cannot be taken into account in the current technology when determining migration strategies.

[0039] Based on this, this application proposes an IoT service migration method. By considering constraints such as capacity limitations, time limitations, and energy limitations of terminal devices when determining the migration strategy, the container layer is transmitted through cloud-edge-device collaboration, and an improved NSGA-II algorithm is used to migrate the container layer and time-series sensor data, thereby improving the efficiency of service migration and reducing the cost of service migration.

[0040] IoT services can be hosted and deployed in containers on terminal devices. It should be noted that containers can consist of a tiered storage system, including a top read-write storage layer, i.e., the container layer, and at least one read-only storage layer outside the top layer, i.e., the image layer.

[0041] like Figure 1 The diagram shown is an architectural schematic of an IoT service migration system as presented in this application. (Refer to...) Figure 1 The system includes a cloud layer, an edge layer, and a terminal layer. The edge layer includes at least one server, and the terminal layer includes multiple terminal devices. Each terminal device runs at least one IoT service. Each server in the edge layer communicates with at least one terminal device in the terminal layer. Each server stores a mirror repository, which includes mirror layers of each service from each terminal device connected to the server.

[0042] It should be noted that the cloud can store image layers of all services. Before the service migration begins, each server in the edge layer can first obtain the image layers of IoT services on the terminal devices connected to it from the cloud.

[0043] Next, combine Figure 2This paper describes the IoT service migration method of this application. The method can be executed by a server or the cloud. Taking a server as an example, the server can communicate with... Figure 1 The IoT service migration system communication connection shown is used, and the method of this application is applied to... Figure 1 Migrate IoT services on mid-terminal devices. For example... Figure 2 As shown, the method includes:

[0044] S201. Based on the source device communication connection information, determine the service to be migrated, the target device, and at least one target transmission path for the service to be migrated. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the source device's container, and the read-only service data is stored in at least one image layer of the container.

[0045] Optionally, the source device can be an end device requiring migration services. The target device can be a resource-sufficient, unloaded end device that is communicatively connected to the source device. (See reference...) Figure 1 Assuming Figure 1 If the resource utilization of terminal device d4 exceeds a preset threshold, indicating device overload, then terminal device d4 can be designated as the source device, and one of the terminal devices connected to it can be selected as the target device. For example, resource utilization could be CPU utilization, and the preset threshold could be 90%. When CPU utilization is greater than or equal to 90%, the terminal device can be designated as the source device.

[0046] Continue to refer to Figure 1 In determining the target device, if only terminal devices within one hop of the source device are considered, since burst requests are likely unevenly distributed across the network, most adjacent devices within one hop of the overloaded device will lack resources. (Refer to...) Figure 1 If the neighboring device d7 of the overloaded device d6 is already short of resources, then d7 cannot be used as the target device. Therefore, when determining the target device, this application does not directly use the neighboring device of the source device as the target device, but also needs to consider the resource usage of the target device.

[0047] Optionally, the communication connection information of the source device can characterize all terminal devices connected to the source device and characterize the resource usage of each terminal device.

[0048] The target transmission path can be the transmission path with the lowest migration cost when migrating the service to be migrated. The target transmission path includes multiple terminal devices arranged in the order of connection.

[0049] Multiple IoT services can run on the source device. When the source device is under load, at least one IoT service can be designated as a service to be migrated. It should be noted that determining which service to migrate can be based on the current usage of the source device and the usage of each terminal device connected to the source device.

[0050] Optionally, the service to be migrated is hosted in a container, which may consist of a tiered storage system, wherein read-write service data is stored in a container layer at the top of the container, and read-only service data is stored in an image layer outside the top of the container, and the number of image layers in the container may be one or more.

[0051] Read-write service data is used to characterize changes made during service runtime, while read-only data includes the service's functional logic and third-party packages used by the service. Furthermore, the service's functional logic can be stored in a custom image layer, while other image layers are used to store third-party packages. The image layer containing read-only service data can be cached on a server connected to the terminal device hosting the service.

[0052] In the process of determining the service to be migrated, the target device, and at least one target transmission path based on the communication connection information of the source device, this application can reduce the cost of service migration by imposing constraints such as resource limitations, time limitations, and energy consumption limitations.

[0053] S202. Migrate the readable and writable service data in the container layer to the target device according to the target transmission path.

[0054] Optionally, the source device can migrate the container layer to the target device through the terminal device connected to it in the terminal layer. Specifically, it can migrate the readable and writable data of the service to be migrated in the container layer to the container layer of the target device.

[0055] It should be noted that when migrating the container layer, any one of the target transmission paths in step S201 above can be selected for transmission.

[0056] S203. Based on the source server of the source device and the target server of the target device, migrate the read-only service data in each image layer to the target image layer of the target device.

[0057] Read-only service data in the mirror layer can be accessed through Figure 1 Migration is performed at the edge layer. The source server can be a server connected to the source device, and the target server can be a server connected to the target device.

[0058] It should be noted that the same mirror layer may exist in the source device and the target device. In order to further reduce migration costs, we can first identify the mirror layer that does not exist in the target device but exists in the source device, and then migrate the read-only service data of these mirror layers from the source device to the target device via the source server and the target server.

[0059] As an example, refer to Figure 1 The source device d6 can first upload the image layer to the server es1 connected to it. Assuming the target device is the terminal device d3 connected to the server es3, the server es1 can pass the image layer to the server es3 so that the terminal device d3 can extract the required image layer from the server es3.

[0060] Existing methods for container migration mostly involve migrating the entire container from the source device to the target device. However, a container consists of a container layer and multiple image layers, resulting in a relatively large file size. Therefore, transferring the entire container between end devices would cause significant overhead for all end devices along the migration path. While there are ideas to transfer the container layer and image layers (which are not present on the target device) to the target device, these still struggle to address the issues of high energy consumption and service latency.

[0061] In this application, by transmitting the container layer to the target device via the terminal device and transmitting the image layer that does not exist in the target device to the target device via the server, the loss of each terminal device along the transmission path is greatly reduced, and the service latency is effectively reduced.

[0062] S204. According to the preset cycle, the collected data of the service to be migrated is transmitted to the target device through the target transmission path.

[0063] During service migration, the data collected by the service also needs to be migrated to the target device so that the target device can further process the collected data and ensure service continuity. The collected data can be time-series sensor data collected by the service.

[0064] Optionally, when the collected data is divided into multiple periodic transmissions, the target transmission path used for each transmission can be the same or different. It should be noted that during data transmission, if there are multiple concurrent tasks, the load on the terminal devices along the transmission path may change. Therefore, the transmission path for the current batch of collected data can be determined in real time from the target transmission path determined in step S201 above, based on the load of the terminal devices along the transmission path.

[0065] In this embodiment, based on the communication connection information of the source device, a service to be migrated, a target device, and at least one target transmission path for the service to be migrated are determined. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the container of the source device, and the read-only service data is stored in at least one image layer of the container. The readable and writable service data in the container layer is migrated to the target device according to the target transmission path. Based on the source server of the source device and the target server of the target device, the read-only service data in each image layer is migrated to the target image layer of the target device. The collected data of the service to be migrated is transmitted to the target device according to the target transmission path according to a preset period.

[0066] By transmitting the container layer via the terminal device and the image layer via the server, only the topmost container layer needs to be migrated and transmitted during service migration. The image layer does not need to be transmitted between IoT devices, reducing the transmission path of the image layer and achieving lightweight service migration. Determining the service to be migrated, the target device, and the target transmission path based on the communication connection information of the source device fully considers the resource, time, and energy limitations of the terminal devices, thereby reducing the cost and improving the efficiency of service migration.

[0067] When determining the service to be migrated, the target device, and the target transmission path, in order to reduce migration costs and improve migration efficiency, the resource capacity, latency, and energy consumption of each terminal device can be limited. The capacity or resources involved include not only the capacity, time, and energy consumed during service execution and migration, but also the capacity, time, and energy consumed during data collection and migration.

[0068] Specifically, collected data is periodically transferred from overloaded devices to target devices via the established migration paths. Data migration typically consumes some resources on the endpoints along the path, releasing these resources upon completion, while also consuming some energy. In fact, some endpoints may participate in multiple paths to migrate different services. When data is migrated via related paths, resource exhaustion on some endpoints can lead to significant latency issues.

[0069] Based on this, this application proposes to find multiple target transmission paths for a service migration to ensure service latency requirements and avoid resource exhaustion of terminal devices, thereby extending network lifetime. Before performing service migration, when determining the target transmission path and target devices, this application can also combine the expected resource usage, expected latency, and expected energy consumption of each terminal device for constraint.

[0070] The following is a further explanation of determining at least one target transmission path for the service to be migrated based on the communication connection information of the source device, such as... Figure 3 As shown, the above step S201 includes:

[0071] S301. Based on the communication connection information of the source device, generate multiple candidate transmission paths for each service in the source device.

[0072] Optionally, for each service in the source device, when generating candidate transmission paths, a target device can be randomly determined first, and multiple candidate transmission paths from the source device to the target device can be generated.

[0073] It should be noted that the terminal devices for each candidate transmission path are different, and the initial number of candidate transmission paths can be preset by the user. If, after randomly selecting a target device, the number of target transmission paths that meet the constraints is 0, then another target device can be randomly selected until the number of target transmission paths meets the preset requirements.

[0074] For example, targeting Figure 1 In the source device d6, services s1, s2 and s3 can each generate three candidate transmission paths, and calculate the candidate transmission paths based on the NSGA-II algorithm to finally obtain at least one target transmission path for each service.

[0075] Alternatively, a depth-first search (DFS) algorithm can be used to find all simple paths as candidate transport paths for each service hosted on the overloaded device. A simple path represents a path consisting of non-repeating devices. Services hosted on the overloaded device and encapsulated in a container are represented as SCs, where all migration paths for each service are limited by the number of network hops and stored in a hash table with key-value pairs. For example, the key-value pair {key:s1→d3,value:[[d6,d2,d3],...]} indicates that service s1 can be migrated to device d3 via multiple paths.

[0076] S302. Determine the constraint information for each candidate transmission path. The constraint information includes: capacity constraint information, time constraint information, and energy constraint information.

[0077] Optionally, capacity constraint information is used to characterize the maximum CPU limit, maximum memory limit, and maximum bandwidth limit of each terminal device on the candidate transmission path, i.e., the maximum CPU, maximum memory, and bandwidth resources required by the terminal device to migrate all services and collect data on the source device. If the capacity constraint information is exceeded, it indicates that the terminal device on the candidate transmission path does not have sufficient capacity to transmit the services to be migrated.

[0078] The time constraint information is used to characterize the maximum latency limit of each terminal device on the candidate transmission path. If the time constraint information is exceeded, it means that the terminal devices on the candidate transmission path may experience problems such as excessive execution time and severe latency when transmitting data for the service to be migrated.

[0079] Energy constraint information is used to characterize the maximum energy loss limit of each terminal device on the candidate transmission path. If the energy constraint information is exceeded, it means that this transmission may cause the terminal devices on the candidate transmission path to run out of energy.

[0080] S303. Determine the target transmission path from multiple candidate transmission paths based on the constraint information, and determine the service to be migrated and the target device based on the target transmission path.

[0081] After determining the constraint information of each candidate transmission path, the constraint information of the terminal devices on each candidate transmission path can be calculated using an objective function to obtain the score of each candidate transmission path. Based on the score of each candidate transmission path, the target transmission path can be determined from multiple candidate transmission paths.

[0082] After determining the target transmission path, the service corresponding to the target transmission path can be designated as the service to be migrated, and the last terminal device in the target transmission path can be designated as the target device.

[0083] It should be noted that during service migration, not all services on the source device are migrated, and the target device for each service migration is not determined. In this application, after generating candidate transmission paths for all services on the source device, the target transmission path is determined from the candidate transmission paths based on constraint information. The service to be migrated and the target device for the migration of the service to be migrated can be determined based on the target transmission path. This not only minimizes the cost of migration but also reduces the resource consumption of migration and improves the efficiency of service migration.

[0084] Furthermore, the process of determining the constraint information for each candidate transmission path, as described above, is as follows: Figure 4 As shown, it includes:

[0085] S401. Based on the available CPU, available memory, and available bandwidth of each terminal device on each candidate transmission path, determine the capacity constraint information of each candidate transmission path, and determine the capacity constraint information of each candidate transmission path based on the capacity constraint information of each terminal device on each candidate transmission path.

[0086] Optionally, the set of all services hosted on all overloaded devices in the network is represented by SC, and the migration paths of all services in SC can be represented by matrix ξ:

[0087]

[0088] Where |SC| represents the number of services in SC, and K represents the number of services that can be provided. i The system can retrieve a maximum of K migration paths, which can be specified by the user. s i The Kth migration path (e.g.) It is the first path of s1), and can be represented by tuples. Where k∈{1,2,…,K}, i∈{1,2,…,|SC|}, and Service i The kth path (i.e. ) represents s i From source device d a (Right now (), through one or more intermediate devices Migrate to target device d c (Right now ),in yes The length. Note. s i Migrate without using the k-th path.

[0089] Each terminal device can be defined as a tuple d. j = (f,m,b,e,c), where j∈{1,2,…,N} is an identifier (N is the total number of terminal devices), f represents computing power (i.e. CPU frequency), m represents its available memory, b represents its available bandwidth, e represents its remaining energy, and c represents its remaining allocable CPU cycles.

[0090] Each IoT service can also be defined as a tuple s i =(d,times,type,hop,T) max Let ,c,m,b,v), where i∈{1,2,…,M} are identifiers (M is the total number of IoT devices), d is the time interval of the time series sensor data, and times is the service time within a certain period. i The number of times data is generated, type∈{dt,cp,dc} indicates s i What type of service is it? dt indicates data-intensive service, cp indicates compute-intensive service, dc indicates compute and data-intensive service, and hop indicates service type. i Network distance limitations, T max s i The maximum acceptable delay, c is the execution delay of s. i The required CPU cycles, m∈{m1,m2,m3} and b∈{b1,b2,b3} represent the CPU cycles required under different conditions. iThe required memory and bandwidth, where m1 and b1 represent the execution of service s i The required memory and bandwidth capacity, m2 and b2 represent the memory and bandwidth required to transmit the checkpoint file of the container layer, m3 and b3 represent the memory and bandwidth required for each transmission of sensor data, and v∈{v1,v2,v3} represents s i The amount of data to be transferred, where v1 represents the amount of data in the checkpoint file of the container layer, v2 represents the amount of data in different image layers between the source and target devices, and v3 represents the amount of data in the data packets for each data migration.

[0091] The capacity constraint information can be calculated as shown in equation (1), where the first row is used to calculate the terminal device d. j Available CPUs, the second line is used to compute the terminal device d j Available memory, the third line is used to calculate the terminal device d j Available bandwidth.

[0092]

[0093] in, Identification services i Is it on the terminal device d? j The function executed above calculates as follows:

[0094]

[0095] A recognition s i Whether it passes d j The migration function is calculated as follows:

[0096]

[0097] M j and B j Through device d j The storage and bandwidth resources required to transmit time-series sensor data from all IoT services in SC are as follows:

[0098] M j =Algorithm 3[0][d j (4)

[0099] B j =Algorithm 3[1][d j (5)

[0100] After obtaining the capacity constraint information of each terminal device, the memory resources occupied by each device can be obtained, with key-value pairs d. j :M jThe other is the bandwidth resources used, with the key-value pair being d. j :B j As one possible implementation, the set of all key-value pairs can be used as the capacity constraint information for the transmission path.

[0101] S402. Determine time constraint information based on the first time when the target device pulls the mirror layer data in the historical period, the second time when the source device and the target device transmit the container layer data in the historical period, and the third time when the source device and the target device transmit the collected data in the historical period.

[0102] Optionally, depending on the service s i Required CPU cycles (denoted as s) i .c) and deployments i The corresponding equipment d j CPU frequency (i.e., d) j f) can calculate service s i Execution time:

[0103]

[0104] in, Is the final deployment s i The equipment.

[0105] Based on the execution time of the service to be migrated, the service migration time, and the data collection migration time, the total time required for the service migration can be obtained. Specifically, the service migration time includes the time for the target device to pull the image layer data and the time for transferring container layer data between the source and target devices.

[0106] Alternatively, it can be obtained immediately by the following formula (7).

[0107]

[0108] in The target server is Elasticsearch. tgt and target equipment The transmission rate can be calculated using the following formula (8).

[0109]

[0110] Where e i and e j It is a forwarding and receiving device, which can be an IoT device or an edge server. l and b w This indicates the transmission bandwidth of LAN and WAN. IoT devices communicate with each other via LAN, while edge servers communicate with each other or with devices via WAN. (P)i T It is a forwarding device e i The transmission power, g i,j It is the corresponding channel gain, given by (dist) i,j ) -α Calculate α, where α is the path loss factor and dist i,j It is e i and e j The distance between them, θ 2 This indicates the background noise power.

[0111] The second time can be obtained by the following formula (9).

[0112]

[0113] Where index is a tuple The index is used to calculate the distance from the source device (i.e., index=0) to the target device. The transmission time of each container layer is calculated, and then the transmission times of each hop are summed to obtain the transmission s. i The time of the container layer.

[0114] Alternatively, the calculation of the third time can be shown in equation (10).

[0115]

[0116] Where k = wp(s) i ,t), is an index function used to find s i The migration path selected for the t-th packet migration:

[0117]

[0118] Where K i It is s i The total number of data migration paths. Note that when container layer migration begins, the target device starts pulling the missing image layer, and the first data migration begins; therefore, services... i The total delay T of the t-th data transmission t (s i )for:

[0119]

[0120] Among them, T r This refers to the time it takes to restart the container on the target device.

[0121] S403. Based on the first energy consumption of each terminal device on each candidate transmission path in transmitting collected data during historical periods and the second energy consumption of transmitting container layer data, determine the energy constraint information of each terminal device on each candidate transmission path, and determine the energy constraint information of each candidate transmission path based on the energy constraint information of each terminal device on each candidate transmission path.

[0122] Optionally, first energy consumption The energy consumption of the terminal device in transmitting and collecting data can be determined by the following formula (13).

[0123]

[0124] Where k = wp(s) i Specifically, for service s i The t-th data migration has the following five cases: (1) If s i There was no migration, and d j It is s i The source device (i.e.) ), then d j (2) If s i Migration and d j It is a source device (i.e.) ), then d j Only consume energy to forward data; (3) if s i Migration and d j The target device (i.e.) ), d j Consume energy to compute data and from the k-th path (i.e. The penultimate device (i.e.) (4) If s i Migration and d j It is an intermediate forwarding device on the k-th path (i.e. ), d j Consume energy to receive data from previous devices (i.e. And forward the data to the next device in the k-th path (i.e. (5) If d j With s i The calculation and forwarding of data are unrelated, then d j No energy is consumed.

[0125] Second energy consumption The energy consumption of the terminal device transmitting the image layer is shown in the following formula (14).

[0126]

[0127] Among them, for service s i The mirror layer migration has the following four cases: (1) If s i Migration and d j It is s i The source device (i.e.) ), then d j Consuming energy to forward the container layer to the next (or second) device (i.e.) ), and forward the image layer to d j Directly connected edge servers (i.e., Elasticsearch) sorc (2) If s i Migration and d j It is an intermediate device in the first path (i.e.) ), d j Consume energy from the previous device in the first path (i.e. ) Receives the container layer and forwards it to the next device (i.e. (3) If s i Migrated and d j It is s i Target device, d j Consume energy from the second-to-last device on the first path (i.e. ) Receive container layer, and from d j Directly connected edge servers (i.e., Elasticsearch) tgt (4) If d j With forwarding s i If the container layer and the image layer are unrelated, then d j No energy is consumed.

[0128] The energy required for a terminal device to complete all services can be expressed as follows (15).

[0129]

[0130] After determining the above constraint information, restrictions can be imposed when determining the target transmission path based on the constraint information.

[0131] Furthermore, this application can generate the target transmission path based on the NSGA-II algorithm, such as... Figure 5 As shown, it includes:

[0132] S501. Add multiple candidate transmission paths to the candidate transmission path set.

[0133] The NSGA-II algorithm uses a fixed population size to iteratively generate new solutions. In this application, the population size can be set to |SC|×K and the population can be encoded. Here, |SC| is the number of services in SC, and K is a specified value representing the maximum number of migration paths that each service in SC can obtain. Specifically, the individuals (or chromosomes, i.e., migration paths of multiple services) in the population can be initialized according to the above S301 step, and the population can be encoded using a real number encoding scheme in most path-related problems to obtain a set of candidate transmission paths.

[0134] like Figure 6 As shown, chromosomes represent the K migration paths for all services in SC, i.e., s1, s2, ..., s |SC| Genes on a chromosome (i.e., real numbers varying within the range {-1, 1, 2, ..., N}) represent the order of a device in a path. Therefore, s i The value of the migration path The j-th (j = 1, 2, ..., N) gene block represents d j It is the g-th device in this path. The source device in the migration path is... It is indicated that the target device is

[0135] like Figure 6 As shown, a migration path of s1, namely [d6,d2,d3], is encoded as a chromosome of length N (e.g., Figure 2 The gene sequence of the device (with a total number of devices N=10), i.e., [-1,2,3,-1,-1,1,-1,-1,-1,-1], where the source device (i.e. ) and target equipment (i.e. The gene value is shown in the dashed box.

[0136] S502. Based on the constraint information, sort each candidate transmission path in the candidate transmission path set according to the fast non-dominated sorting strategy to obtain the first sorting result.

[0137] Optionally, it can be determined whether the candidate transmission path satisfies the constraint of the following formula (16). If it does, the time constraint information is calculated based on the function of the following formula (17) to obtain the time limit score, and the energy constraint information is calculated based on the function shown in formula (18) to obtain the energy limit score. The candidate transmission paths are then sorted quickly according to the time limit score and the energy limit score to obtain the first sorting result.

[0138] If the candidate transmission path does not meet the constraints of the following formula (16), then the time limit score and energy limit score of the candidate transmission path are both set to infinity.

[0139]

[0140]

[0141]

[0142] After performing a fast non-dominated sort, multiple non-dominated fronts can be obtained according to time constraint scores and energy constraint scores. Each non-dominated front contains individuals that do not dominate each other, and individuals in the lower-level front dominate individuals in the higher-level front. A dominance relationship means that if individual A dominates individual B, A's two time constraint scores and energy constraint scores are less than or equal to B's time constraint scores and energy constraint scores, and neither of B's ​​time constraint scores and energy constraint scores is lower than A's.

[0143] It should be noted that, in order to avoid exhausting the resources of the terminal devices, the resource usage and consumption of each device must be calculated and limited. Among them, the energy consumption of each device for data transmission is calculated by the above formula (15). After evaluating the maximum memory and bandwidth resources consumed by each device when migrating and collecting data, the energy consumption, resource consumption and bandwidth resources can be limited by the above formula (18).

[0144] One method to assess the maximum memory and bandwidth resources consumed by each device during data migration could be to initialize two hash tables (dict). m and dict b The dictionary records the time taken for each data packet to be transmitted for each service on each device. By looping through the dictionary, each time interval (T) can be obtained. l ,T r The dictionary calculates the memory and bandwidth resources consumed by each device simultaneously, and then selects the maximum value to add to the dictionary. m and dict b Finally, return the dictionary. m and dict b .

[0145] Furthermore, from T to T+T lcm During this period, the time occupied by each device transmitting each data packet for each migration service can be calculated as follows: First, calculate the time taken for each service's first K... i The moment when each data migration ends, which is also the moment when the k-th data transmission via the k-th path ends. in It is s i The start time of the first data migration, T0, is the start time of the migration strategy. data (si ) is a service i The time required to transmit data once via the k-th path, then select service s. i Former K i The largest in this data migration That is, the first K i The data migration was finally completed at time t. i Then select the largest t among all services. i -K i ×s i .d represents T. Then, the hash table dict records entries from T to T+T. lcm The time taken by each device to transmit data packets for each migration service during this period, where the key-value pair is z[i][k][j]:[(T l ,T r ,s i .t),....], where z represents an individual in the population, which is the same in form as ξ, and i represents the i-th IoT service s i k represents s i The path number traversed during the t-th data migration, where j represents the j-th IoT device d. j ,s i .t represents s i The t-th data migration, T l and T r They represent s respectively i The number of devices used in the t-th data migration is d. j The start and end times.

[0146] S503. In the first sorting result, determine multiple intermediate transmission paths, determine the congestion degree of each intermediate transmission path, and sort each intermediate transmission path according to the congestion degree of each intermediate transmission path to obtain the second sorting result.

[0147] Optionally, crowding degree represents the cumulative distance between an individual and its nearest neighbor in the Pareto top of the uniform sorting. In this application, the candidate transmission paths at the forefront of the first sorting result can be determined as intermediate transmission paths, and crowding degree can be calculated for each intermediate transmission path.

[0148] The degree of congestion can be calculated as shown in equation (19).

[0149]

[0150] Wherein, CD(z) h ) is an individual z h crowded distance, f t (z h+1 ) and f t (z h-1) is the nearest z h The individual's delay time, f e (z h+1 ) and f e (z h-1 ) is the nearest z h The individual's energy consumption, f t (z max ) and f e (z max f and f' are the maximum delay time and energy consumption of all individuals in the frontier where the individual is located, respectively. t (z min ) and f e (z min The minimum value is 0. Crowding distance represents the density around an individual. Individuals with larger crowding distances are generally more likely to be selected to maintain diversity at the frontier and avoid getting trapped in local optima.

[0151] S504. Perform cross-mutation on each intermediate transmission path in the second sorting result to obtain new candidate transmission paths.

[0152] Crossover mutation in intermediate transmission paths can involve crossover or mutation of terminal devices other than the source device. Crossover and mutation operations can involve replacing, deleting, or adding terminal devices other than the source device. Crossover and mutation operations can be performed on different genes, and the resulting new individuals serve as new candidate transmission paths.

[0153] It should be noted that in some cases, after crossover mutation, the new candidate transmission path can be pruned based on constraint information and other constraints. As an example, if the target device of the new candidate transmission path changes, or if there is no communication connection between the target device and the source device, this new candidate transmission path can be deleted to speed up the convergence of the NSGA-II algorithm.

[0154] S505. Take the combination of the new candidate transmission path and the intermediate transmission path as the new candidate transmission path set, and repeat steps S502-S504 until the preset iteration termination condition is reached, and take the intermediate transmission path of the new candidate transmission path set as the target transmission path.

[0155] Optionally, the iteration termination condition can be that the number of iterations reaches a set maximum value, at which point an intermediate transmission path in the new set of candidate transmission paths can be used as the target transmission path.

[0156] As an example, assuming there are N intermediate transmission paths, after obtaining N new candidate transmission paths, the intermediate transmission paths and the new candidate transmission paths can be combined into a new set of candidate transmission paths. The 2N candidate transmission paths in the set are then subjected to fast non-dominated sorting and crowding sorting to obtain N new intermediate transmission paths. Then, crossover mutation is performed on the new N intermediate transmission paths, and the N new candidate transmission paths obtained after crossover mutation are combined with the new N intermediate paths to form a new set of candidate transmission paths. Steps S502-S504 are repeated until the preset iteration termination condition is reached.

[0157] Optionally, all non-dominated individuals in the Pareto first front are optimal solutions, which can be normalized by the corresponding weights of delay and energy consumption. After the weights are summed to 1, the one with the minimum value is taken as the migration strategy.

[0158] It's worth noting that the service types include: compute-intensive services, data-intensive services, and compute-data-intensive services. Compute-intensive services may require more CPU resources but transmit less collected data; data-intensive services may require less CPU resources but transmit more collected data.

[0159] The method in this application, by considering constraints such as resources, time, and capacity in the final determined target transmission path, can prioritize the migration of compute-intensive services from the source device. This reduces losses on devices along the transmission path and lowers migration costs during data transmission. Furthermore, in determining the target transmission path, this application generates one or more target transmission paths for the services to be migrated to ensure service latency requirements are met while preventing resource exhaustion of any terminal device, thereby maximizing the lifespan of the Internet of Things (IoT).

[0160] The following is a further explanation of how to migrate read-only service data from each image layer to the target image layer of the target device, based on the source server of the source device and the target server of the target device.

[0161] Before migrating services, this application allows for the creation of pre-built image repositories on servers to share the same image layer across servers. As an example, the official Docker image repository build tool can be used to efficiently build an image repository on a resource-constrained server. The image for the repository build tool is pulled from the cloud, a data storage directory is created on the server, the repository container is started, and a private repository address is configured. The container can then be restarted to complete the private repository build.

[0162] Before the service migration, each IoT device can download the image layers required by the Docker engine and IoT services, and maintain backups of these image layers in a repository on the server directly connected to it. The functional logic of the IoT services can also be packaged into custom image layers and pushed to the established repository.

[0163] During image layer synchronization, a custom image layer of the service to be migrated on the source device can be pushed to the image repository of the source server. Subsequently, a memory snapshot of the container running the service to be migrated on the source device is transferred to all potential target servers. Next, these servers map the cached ID of the image layer back to its original ID based on the memory snapshot and pull the different image layers required to run the migration service. The original ID is generated for each image layer when the image is built and is used to uniquely identify and distinguish the image layer; it remains the same even on different devices.

[0164] like Figure 7 As shown, the above step S203 includes:

[0165] S701, The source device transmits the read-only service data of the mirror layer to the source server.

[0166] S702, The source server transmits the read-only service data of the image layer to the target server.

[0167] S703, The server of the target device sends the read-only service data of the image layer to the target image layer of the target device.

[0168] Reference Figure 8 When resources or capabilities in an IoT device are overloaded, the cloud center will issue a migration request and check the containers on the original device to obtain memory snapshots. If the dirty memory difference of consecutive memory snapshots is less than a preset threshold, the container can be stopped. At this time, the storage on the source device will not be modified by the container.

[0169] Continue to refer to Figure 8 After the container stops, the source device can send the latest container layer checkpoint file to the target device via the terminal device connected to it. Simultaneously, the target device can pull different image layers from the repository on the server directly connected to it by comparing the image layers of the migrated container and the target device. After this, the image layers and container layers on the source and target devices are synchronized.

[0170] After the image layer and container layer are synchronized, the target device can use the received checkpoint file to restore the container, and the source device can clean up and unload the container to release resources.

[0171] Furthermore, before the source device transmits at least one image layer of the service to be migrated to the source device's server, such as... Figure 9As shown, it includes:

[0172] S901, The source device sends the checkpoint file to the target device via a terminal device that is communicatively connected to the source device.

[0173] S902. The target device determines the target image layer based on the checkpoint file and sends a pull request to the target server. The pull request is used to pull the data of the corresponding image layer from the target server.

[0174] Optionally, the checkpoint file can represent the image layers included in the container of the service to be migrated. The target device can determine the image layer to be pulled, i.e., the target image layer, based on the checkpoint file, and pull the read-only data of the target image layer from the target server.

[0175] Based on the same inventive concept, this application also provides an IoT service migration device corresponding to the IoT service migration method. Since the principle of the device in this application is similar to the IoT service migration method described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0176] Reference Figure 10 The diagram shown is a schematic of an IoT service migration device provided in an embodiment of this application. The device includes:

[0177] The determination module 1001 is used to determine the service to be migrated, the target device, and at least one target transmission path of the service to be migrated based on the communication connection information of the source device. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the container of the source device, and the read-only service data is stored in at least one image layer of the container.

[0178] The first migration module 1002 is used to migrate the readable and writable service data in the container layer to the target device according to the target transmission path;

[0179] The second migration module 1003 is used to migrate read-only service data in each image layer to the target image layer of the target device based on the source server of the source device and the target server of the target device.

[0180] The third migration module 1004 is used to migrate the collected data of the service to be migrated according to a preset cycle.

[0181] The target transmission path transmits the data to the target device.

[0182] Optionally, the determining module 1001 is further configured to: generate multiple candidate transmission paths for each service in the source device based on the communication connection information of the source device;

[0183] Determine the constraint information for each candidate transmission path. The constraint information includes: capacity constraint information, time constraint information, and energy constraint information.

[0184] The target transmission path is determined from multiple candidate transmission paths based on the constraint information, and the service to be migrated and the target device are determined based on the target transmission path.

[0185] Optionally, the determining module 1001 is further configured to: take the service corresponding to the target transmission path as the service to be migrated, and take the last terminal device in the target transmission path as the target device.

[0186] Optionally, the determining module 1001 is further configured to: determine the capacity constraint information of each terminal device on each candidate transmission path based on the available CPU, available memory and available bandwidth of each terminal device on each candidate transmission path, and determine the capacity constraint information of each candidate transmission path based on the capacity constraint information of each terminal device on each candidate transmission path.

[0187] The time constraint information is determined based on the first time when the target device pulls the image layer data in the historical period, the second time when the source device and the target device transmit the container layer data in the historical period, and the third time when the source device and the target device transmit the collected data in the historical period.

[0188] Based on the first energy consumption of each terminal device on each candidate transmission path in transmitting collected data during historical periods and the second energy consumption of transmitting container layer data, the energy constraint information of each terminal device on each candidate transmission path is determined, and the energy constraint information of each candidate transmission path is determined based on the energy constraint information of each terminal device on each candidate transmission path.

[0189] Optionally, the determining module 1001 is also used for:

[0190] A. Add multiple candidate transmission paths to the candidate transmission path set;

[0191] B. Based on the constraint information, sort the candidate transmission paths in the candidate transmission path set according to the fast non-dominated sorting strategy to obtain the first sorting result.

[0192] C. In the first sorting result, determine multiple intermediate transmission paths, determine the congestion of each intermediate transmission path, and sort each intermediate transmission path according to the congestion of each intermediate transmission path to obtain the second sorting result.

[0193] D. Perform cross-mutation on each intermediate transmission path in the second sorting result to obtain new candidate transmission paths;

[0194] E. Take the combination of the new candidate transmission path and the intermediate transmission path as the new candidate transmission path set, and repeat steps B-D until the preset iteration termination condition is reached, and take the intermediate transmission path of the new candidate transmission path set as the target transmission path.

[0195] Optionally, the second migration module 1003 is used to: transfer read-only service data of the image layer from the source device to the source server;

[0196] The source server transmits the read-only service data of the image layer to the target server;

[0197] The target server sends the read-only service data of the image layer to the target image layer of the target device.

[0198] Optionally, the second migration module 1003 is used to: send the checkpoint file from the source device to the target device via a terminal device that is communicatively connected to the source device;

[0199] The target device determines the target image layer based on the checkpoint file and sends a pull request to the target server. The pull request is used to pull the data of the corresponding image layer from the target server.

[0200] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0201] This application embodiment transmits the container layer via the terminal device and the image layer via the server. During service migration, only the topmost container layer needs to be migrated and transmitted, eliminating the need to transmit the image layer between IoT devices. This reduces the transmission path of the image layer and achieves lightweight service migration. Determining the service to be migrated, the target device, and the target transmission path based on the communication connection information of the source device fully considers the resource, time, and energy limitations of the terminal device, thereby reducing the cost and improving the efficiency of service migration.

[0202] This application also provides an electronic device, such as... Figure 11 The diagram shown is a schematic representation of an electronic device structure provided in an embodiment of this application, including: a processor 1101, a memory 1102, and a bus. The memory 1102 stores machine-readable instructions executable by the processor 1101 (e.g., ...). Figure 10 The processor 1101 and the memory 1102 communicate via a bus when the computer device is running. When the machine-readable instructions are executed by the processor 1101, the above-mentioned IoT service migration method is performed.

[0203] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the above-described IoT service migration method.

[0204] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0205] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0206] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for migrating Internet of Things (IoT) services, characterized in that, include: Based on the communication connection information of the source device, multiple candidate transmission paths are generated for each service in the source device. The constraint information of each candidate transmission path is determined, including capacity constraint information, time constraint information, and energy constraint information; a target transmission path is determined from multiple candidate transmission paths based on the constraint information, and a service to be migrated and a target device are determined based on the target transmission path. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the source device's container, and the read-only service data is stored in at least one mirror layer of the container. Migrate the readable and writable service data in the container layer to the target device according to the target transmission path; Based on the source server of the source device and the target server of the target device, the read-only service data in each of the image layers is migrated to the target image layer of the target device; The collected data of the service to be migrated is transmitted to the target device according to the target transmission path according to the preset cycle; Determining the target transmission path from multiple candidate transmission paths based on the constraint information includes: A. Add the multiple candidate transmission paths to the candidate transmission path set; B. Based on the constraint information, sort the candidate transmission paths in the candidate transmission path set according to the fast non-dominated sorting strategy to obtain the first sorting result. C. In the first sorting result, determine multiple intermediate transmission paths, determine the congestion degree of each intermediate transmission path, and sort each intermediate transmission path according to the congestion degree of each intermediate transmission path to obtain a second sorting result. D. Perform cross-mutation on each intermediate transmission path in the second sorting result to obtain new candidate transmission paths; E. Take the combination of the new candidate transmission path and the intermediate transmission path as a new candidate transmission path set, and repeat steps B-D until the preset iteration termination condition is reached, and take the intermediate transmission path of the new candidate transmission path set as the target transmission path.

2. The IoT service migration method according to claim 1, characterized in that, The step of determining the service to be migrated and the target transmission path based on the target transmission path includes: The service corresponding to the target transmission path is taken as the service to be migrated, and the last terminal device in the target transmission path is taken as the target device.

3. The IoT service migration method according to claim 1, characterized in that, The constraint information for determining each of the candidate transmission paths includes: Based on the available CPU, available memory, and available bandwidth of each terminal device on each candidate transmission path, determine the capacity constraint information of each terminal device on each candidate transmission path, and determine the capacity constraint information of each candidate transmission path based on the capacity constraint information of each terminal device on each candidate transmission path. The time constraint information is determined based on the first time when the target device pulls the mirror layer data in the historical period, the second time when the source device and the target device transmit the container layer data in the historical period, and the third time when the source device and the target device transmit the collected data in the historical period. Based on the first energy consumption of each terminal device on each candidate transmission path in transmitting collected data during historical periods and the second energy consumption of transmitting container layer data, the energy constraint information of each terminal device on each candidate transmission path is determined, and the energy constraint information of each candidate transmission path is determined based on the energy constraint information of each terminal device on each candidate transmission path.

4. The IoT service migration method according to claim 1, characterized in that, The process of migrating the read-only service data in each of the image layers to the target image layer of the target device, based on the source server of the source device and the target server of the target device, includes: The source device transmits the read-only service data of the image layer to the source server; The source server transmits the read-only service data of the image layer to the target server; The target server outputs the read-only service data of the image layer to the target image layer of the target device.

5. The IoT service migration method according to claim 4, characterized in that, Before the source device transmits at least one image layer of the service to be migrated to the server of the source device, the process includes: The source device will send the checkpoint file to the target device via a terminal device that is communicatively connected to the source device; The target device determines the target image layer based on the checkpoint file and sends a pull request to the target server. The pull request is used to pull the data of the corresponding image layer from the target server.

6. An Internet of Things (IoT) service migration device, characterized in that, include: The determining module is used to generate multiple candidate transmission paths for each service in the source device based on the communication connection information of the source device; The constraint information of each candidate transmission path is determined, including capacity constraint information, time constraint information, and energy constraint information; a target transmission path is determined from multiple candidate transmission paths based on the constraint information, and a service to be migrated and a target device are determined based on the target transmission path. The target transmission path includes multiple terminal devices arranged in sequence. The service to be migrated includes: readable and writable service data, read-only service data, and collected data. The readable and writable service data is stored in the container layer of the source device's container, and the read-only service data is stored in at least one mirror layer of the container. The first migration module is used to migrate the readable and writable service data in the container layer to the target device according to the target transmission path; The second migration module is used to migrate the read-only service data in each of the image layers to the target image layer of the target device, based on the source server of the source device and the target server of the target device. The third migration module is used to transmit the collected data of the service to be migrated to the target device according to the target transmission path according to a preset period; The determining module is specifically used for: A. Add the multiple candidate transmission paths to the candidate transmission path set; B. Based on the constraint information, sort the candidate transmission paths in the candidate transmission path set according to the fast non-dominated sorting strategy to obtain the first sorting result. C. In the first sorting result, determine multiple intermediate transmission paths, determine the congestion degree of each intermediate transmission path, and sort each intermediate transmission path according to the congestion degree of each intermediate transmission path to obtain a second sorting result. D. Perform cross-mutation on each intermediate transmission path in the second sorting result to obtain new candidate transmission paths; E. Take the combination of the new candidate transmission path and the intermediate transmission path as a new candidate transmission path set, and repeat steps B-D until the preset iteration termination condition is reached, and take the intermediate transmission path of the new candidate transmission path set as the target transmission path.

7. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores program instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the program instructions to perform the steps of the Internet of Things service migration method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the Internet of Things service migration method as described in any one of claims 1 to 5.

Images