Micro-service instance deployment method, system, equipment and medium

Abstract

The embodiment of the invention provides a micro-service instance deployment method, system and device and a medium, and the method comprises the steps: obtaining the current load information of a smart home system, and predicting the predicted load information of a future target time according to the current load information; determining the container capacity set for the micro-service instance, and determining the number of currently required container instances according to the container capacity and the predicted load information; and creating or deleting the container according to the number of the currently required container instances, and deploying the micro-service instances into the currently existing container. Through the embodiment of the invention, the scheduling of the dynamic container can be realized based on the load prediction, so that the waste of resources can be avoided, and the problems of performance bottleneck and the like are also avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of detection, and in particular to a micro-service instance deployment method, system, device and medium. BACKGROUND

[0002] With the rapid development of smart home, the number of smart devices in the home is increasing, and the home host as a local micro server is responsible for device interconnection, data processing and service deployment.

[0003] Although users can control devices by creating scenes in real time or sending commands, the current deployment and resource allocation of micro-service instances of the home host are prone to cause problems such as resource waste or performance bottleneck. SUMMARY

[0004] In view of the above problems, a micro-service instance deployment method, system, device and medium are proposed to overcome the above problems or at least partially solve the above problems, comprising:

[0005] A micro-service instance deployment method applied to a smart home system, the method comprising:

[0006] Obtaining current load information of the smart home system, and predicting future target time prediction load information according to the current load information;

[0007] Determining the container capacity set for the micro-service instance, and determining the current required container instance number according to the container capacity and the prediction load information;

[0008] According to the current required container instance number, creating or deleting a container, and deploying the micro-service instance into the currently existing container.

[0009] Optionally, the method further comprises:

[0010] According to the current load information, determining a current load vector, and determining a comprehensive load score of the smart home system according to the current load vector;

[0011] When the comprehensive load score exceeds a preset score threshold, the step of predicting future target time prediction load information according to the current load information is performed.

[0012] Optionally, the micro-service instance is deployed into the currently existing container, comprising:

[0013] Determining the resource waste rate and response delay after the micro-service instance is deployed into the currently existing container;

[0014] Based on the resource waste rate and the response delay, the micro-service instance is deployed.

[0015] Optionally, the smart home system comprises a plurality of smart devices, and the method further comprises:

[0016] determining a device feature vector of each smart device and a requirement vector of the micro-service instance;

[0017] determining a matching degree of the micro-service instance and each smart device according to the device feature vector and the requirement vector;

[0018] deploying a container with the micro-service instance to a smart device according to the matching degree.

[0019] Optionally, the deploying a container with the micro-service instance to a smart device according to the matching degree comprises:

[0020] determining a matching degree matrix according to the matching degree;

[0021] determining a target smart device matched by the micro-service instance according to the matching degree matrix, and deploying a container with the micro-service instance in the target smart device.

[0022] Optionally, the method further comprises:

[0023] when receiving a target task of the micro-service instance, decomposing the target task into at least one sub-task according to a dependency graph;

[0024] adding the at least one sub-task to an execution queue according to a priority of each sub-task and a dependency relationship between the sub-tasks.

[0025] Optionally, the method further comprises:

[0026] determining a communication delay and a load imbalance contribution of the smart home system;

[0027] adjusting the priority of the sub-tasks according to the communication delay and the load imbalance contribution.

[0028] Optionally, the method further comprises:

[0029] when detecting a network interruption of the smart home system, allocating resources to sub-tasks higher than a first priority and putting sub-tasks lower than a second priority into a dormant state.

[0030] The embodiment of the present application further provides a micro-service instance deployment system, which is applied to a smart home system and comprises:

[0031] a resource optimization subsystem configured to acquire current load information of the smart home system, and predict predicted load information of a target time in the future according to the current load information; determine a container capacity set for the micro-service instance, and determine a current required container instance number according to the container capacity and the predicted load information;

[0032] a container management subsystem configured to create or delete a container, and deploy the micro-service instance into the existing container.

[0033] Optionally, the deployment system further comprises:

[0034] a heterogeneous adaptation subsystem configured to convert data protocols of each smart device in the smart home system.

[0035] Optionally, the deployment system further comprises:

[0036] a service optimization subsystem configured to realize communication and task coordination between different micro-service instances.

[0037] Optionally, the system further comprises:

[0038] a local fault-tolerant subsystem configured to allocate resources for sub-tasks higher than a first priority, and put sub-tasks lower than a second priority into a dormant state when detecting a network interruption of the smart home system.

[0039] The embodiment of the present application further provides an electronic device, including a processor, a memory and a computer program stored in the memory and capable of running on the processor, and the computer program is executed by the processor to realize the deployment method of the micro-service instance.

[0040] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by a processor to realize the deployment method of the micro-service instance.

[0041] The embodiment of the present application has the following advantages:

[0042] In the embodiment of the present application, the current load information of the smart home system is acquired, and the predicted load information of a target time in the future is predicted according to the current load information; the container capacity set for the micro-service instance is determined, and the current required container instance number is determined according to the container capacity and the predicted load information; the container is created or deleted according to the current required container instance number, and the micro-service instance is deployed into the existing container. Through the embodiment of the present application, the dynamic container scheduling can be realized based on the load prediction, so that the waste of resources can be avoided, and the performance bottleneck and other problems can be avoided. BRIEF DESCRIPTION OF DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the present application, the drawings needed to be used in the description of the present application will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and all other drawings obtained by those skilled in the art without creative labor on the basis of these drawings also belong to the protection scope of the present application.

[0044] Figure 1 is a step flow chart of a micro-service instance deployment method according to an embodiment of the present application;

[0045] Figure 2 is a step flow chart of another micro-service instance deployment method according to an embodiment of the present application;

[0046] Figure 3 is a step flow chart of another micro-service instance deployment method according to an embodiment of the present application;

[0047] Figure 4 is a step flow chart of another micro-service instance deployment method according to an embodiment of the present application;

[0048] Figure 5 is a step flow chart of another micro-service instance deployment method according to an embodiment of the present application;

[0049] Figure 6 is a structural schematic diagram of a micro-service instance deployment system according to an embodiment of the present application;

[0050] Figure 7 is a structural schematic diagram of another micro-service instance deployment system according to an embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application will be further described in detail below in combination with the drawings and specific embodiments. Obviously, the described embodiments are some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor also belong to the protection scope of the present application.

[0052] With the rapid development of smart home, the number of smart devices in the home is increasing, and the home hub as a local micro server is responsible for device interconnection, data processing and service deployment. Although users can control devices by creating scenes or sending commands in real time, the deployment and resource allocation of home hub micro service instances cannot be dynamically adjusted according to changes in system load (such as CPU (Central Processing Unit), memory usage) or user demand (such as new devices or complex tasks), resulting in resource waste or performance bottlenecks, especially in multi-device concurrent scenarios. In view of this, the embodiment of the present application provides a method for deploying a home hub micro service instance based on dynamic containerization, which can avoid resource waste and performance bottlenecks by scheduling dynamic containers based on load prediction. For example, refer to Figure 1 , a step flowchart of a micro service instance deployment method according to an embodiment of the present application is shown.

[0053] As shown in Figure 1 , the micro service instance deployment method can include the following steps:

[0054] Step 101, obtain the current load information of the smart home system, and predict the predicted load information of the target time in the future according to the current load information.

[0055] The smart home system can include a plurality of smart devices, and the smart devices can be devices with certain computing power or devices without computing power that can only be controlled. The smart devices can include devices such as home hubs and smart speakers, and the embodiments of the present application do not limit

[0056] In some feasible embodiments, the containerization technology is applied in the smart home system; in the resource-limited home hub scenario, in order to avoid complex scheduling, the current load information of the smart home system can be obtained first, and the predicted load information of the smart home system at the target time in the future can be predicted based on the current load information, so as to predict the computing resource demand, and based on this, the container can be created or deleted, thereby reducing the complexity of scheduling decisions.

[0057] The current load information can include the usage of various resources in the smart home system, such as CPU usage, memory usage, network delay, etc.

[0058] The predicted load information can also include CPU usage, memory usage, network delay, etc.; the current load information can be used to describe the current used load situation, and the predicted load information can be used to describe the predicted load situation that can be used in the future target time.

[0059] Exemplarily, the predicted load information can be obtained based on current load information based on an LSTM (Long Short-Term Memory) model.

[0060] The LSTM model can adopt a 2-layer LSTM network (64 hidden units per layer), input current load information (for example, a [CPU, Mem, Net_delay] sequence in the past 60 seconds), and output predicted load information (for example, load prediction in the future 5 minutes).

[0061] When training the LSTM model, 30 days of historical data (sampled every second) can be used, and after normalization, the training / validation set is divided by 8:2, the Adam optimizer (lr=0.001) is used to train 100 rounds with the MSE (Mean Squared Error) as the loss function. After deployment, 60 seconds of load data is input in real time to predict the load in the next 5 minutes. If MSE>0.05, retrain with new data every week. Only when new features (such as I / O load) are added, adjust the model structure, and the embodiments of the present application are not limited to this.

[0062] Step 102, determine the container capacity set for the microservice instance, and determine the current required container instance number according to the container capacity and the predicted load information.

[0063] After determining the predicted load information, the container capacity set for the microservice instance, i.e., the capacity required by a single container, can be determined. The container capacity can be pre-set, which can correspond to the service provided by the microservice instance, and the embodiments of the present application are not limited to the specific value.

[0064] After determining the container capacity and the predicted load information, the number of containers required for deploying the microservice instance, i.e., the current required container instance number, can be determined according to the container capacity and the predicted load information.

[0065] Exemplarily, the current required container instance number N can be calculated by the following formula and rounded to an integer:

[0066] N=ceil(L_pred / C_cap).

[0067] Wherein, L_pred is the predicted load information, and C_cap is the container capacity.

[0068] Step 103, create or delete containers according to the current required container instance number, and deploy the microservice instance into the currently existing containers.

[0069] After determining the current required container instance number, containers can be created or deleted based on the current required container instance number; for example, if N is greater than the current number of containers, new containers can be created based on the container capacity; conversely, if N is less than the current number of containers, the excess containers can be deleted, and the tasks on these deleted containers can be migrated to other containers.

[0070] After creating or deleting containers, resources can be allocated to the currently existing containers, and microservice instances can be deployed in the currently existing containers for running to implement specific functions on the home host, such as device control (light, air conditioner control), data processing (sensor data analysis), or communication management (MQTT message processing).

[0071] In some possible embodiments, the microservice instances can include multiple, and one microservice instance can be deployed in one container for processing specific tasks or services of the smart device.

[0072] In the embodiments of the present application, current load information of the smart home system is acquired, and predicted load information of a target time in the future is predicted according to the current load information; container capacity set for the microservice instance is determined, and current required container instance number is determined according to the container capacity and the predicted load information; containers are created or deleted according to the current required container instance number, and the microservice instances are deployed into the currently existing containers. Through the embodiments of the present application, dynamic container scheduling can be implemented based on load prediction, so that resource waste can be avoided, and problems such as performance bottleneck can also be avoided.

[0073] Referring to Figure 2 , another step flowchart of a microservice instance deployment method according to an embodiment of the present application is shown, which can include the following steps:

[0074] Step 201, current load information of the smart home system is acquired, and predicted load information of a target time in the future is predicted according to the current load information.

[0075] In some possible embodiments, the containerization technology is applied in the smart home system; in the resource-limited home host scenario, in order to avoid scheduling complexity, the current load information of the smart home system can be acquired first, and the predicted load information of the smart home system at a target time in the future is predicted based on the current load information, so as to predict the computing resource demand, and containers are created or deleted based on this, so as to reduce the complexity of scheduling decisions.

[0076] Step 202, container capacity set for the microservice instance is determined, and current required container instance number is determined according to the container capacity and the predicted load information.

[0077] After determining the predicted load information, the container capacity set for the microservice instance, i.e., the capacity required by a single container, can be determined.

[0078] After determining the container capacity and the predicted load information, the current required container instance number required for deploying the microservice instance can be determined according to the container capacity and the predicted load information.

[0079] Step 203, create or delete containers according to the current required container instance number.

[0080] After determining the current required container instance number, containers can be created or deleted based on the current required container instance number; for example, if N is greater than the current number of containers, new containers can be created based on the container capacity; conversely, if N is less than the current number of containers, excess containers can be deleted, and tasks on these deleted containers can be migrated to other containers.

[0081] Step 204, determine the resource waste rate and response delay after the microservice instance is deployed to the currently existing containers.

[0082] After creating or deleting containers, resources can be allocated to the currently existing containers, and the microservice instance can be deployed in the currently existing containers for running to implement specific functions on the host computer.

[0083] In some possible embodiments, the resource waste rate and the response delay that can occur after the microservice instance is deployed to the currently existing containers can be determined. The resource waste rate and the response delay can be predicted or actual data measured after the microservice instance is deployed in the containers for a period of time.

[0084] The resource waste rate can be calculated by the following formula:

[0085] Resource waste rate = (allocated CPU, memory, network resources - actual used resources) / allocated CPU, memory, network resources.

[0086] The response delay can be the average response delay in a period of time.

[0087] Step 205, deploy the microservice instance based on the resource waste rate and the response delay.

[0088] After determining the resource waste rate and the response delay, the microservice instance can be deployed in min(w1*R_waste+w2*T_delay) (R_waste is the resource waste rate, T_delay is the response delay, w1 and w2 are weights; w1 and w2 are pre-set by a system designer according to specific application requirements, and are used to balance the influence of resource waste and task delay in the optimization strategy), for example: high-priority tasks (such as security monitoring) can be assigned to low-load containers to reduce T_delay; low-priority tasks (such as data analysis) are assigned to resource-rich containers to reduce R_waste.

[0089] In the embodiment of the application, the current load information of the smart home system is obtained, and the predicted load information of the target time in the future is predicted according to the current load information; the container capacity set for the microservice instance is determined, and the current required container instance number is determined according to the container capacity and the predicted load information; the container is created or deleted according to the current required container instance number; the resource waste rate and the response delay after the microservice instance is deployed to the currently existing container are determined; and the microservice instance is deployed based on the resource waste rate and the response delay. Through the embodiment of the application, dynamic container scheduling can be realized based on load prediction, so that resource waste can be avoided, and problems such as performance bottleneck can also be avoided. Deploying the microservice instance with the purpose of minimizing the resource waste rate and the response delay can avoid the problems of resource waste and excessive response delay.

[0090] Referring to Figure 3 , a step flowchart of another microservice instance deployment method according to an embodiment of the application is shown, which can include the following steps:

[0091] Step 301, according to the current load information, the current load vector is determined, and the comprehensive load score of the smart home system is determined according to the current load vector.

[0092] In some feasible embodiments, the containerization technology is applied in the smart home system; in the resource-limited home scene, in order to avoid scheduling complexity, the current load information of the smart home system can be obtained first, and the predicted load information of the smart home system at the target time in the future is predicted based on the current load information, so as to predict the resource demand, and create or delete the container based on this, so as to reduce the complexity of scheduling decision.

[0093] For example, a trigger mechanism can be set to execute the deployment method of the microservice instance mentioned in the embodiment of the application; for example: a preset time interval can be set, and when the time interval comes, the deployment and resource allocation are performed again.

[0094] In addition, it can also be determined whether to re-deploy and allocate resources based on the current state of the smart home system. Specifically, after obtaining the current load information, the current load vector can be determined.

[0095] For example, the current load information can include CPU usage percentage, memory usage percentage, average network delay, etc. The current load vector can be represented as follows:

[0096] L = [CPU, Mem, Net_delay] ;

[0097] Wherein, CPU can represent CPU usage percentage; Mem can represent memory usage percentage; Net_delay can represent average network delay, in milliseconds.

[0098] After obtaining the current load vector, the comprehensive load score of the smart home system can be calculated based on the current load vector. The comprehensive load score can be used to evaluate the load of the smart home system. The larger the value, the greater the load of the smart home system. The smaller the value, the smaller the load of the smart home system.

[0099] For example, the following formula can be used to calculate the comprehensive load score Load_score:

[0100] Load_score = w_cpu * CPU + w_mem * Mem + w_net * Net_delay;

[0101] Wherein, the weights w_cpu, w_mem, w_net can be set according to actual conditions, for example: w_cpu is 0.4, w_mem is 0.4, w_net is 0.2, the present embodiment is not limited to this.

[0102] Step 302, when the comprehensive load score exceeds the preset score threshold, the predicted load information of the target time in the future is predicted according to the current load information.

[0103] After determining the comprehensive load score, it can be determined whether the current load score exceeds the preset score threshold. For example, the score threshold can be set according to actual conditions, for example: 80, the present embodiment is not limited to this.

[0104] In some possible embodiments, the score threshold can be determined based on the available resources of the smart home system, for example: it can be determined based on CPU, memory, etc.

[0105] In other possible embodiments, the score threshold value can also be set directly for each resource; then the step of predicting the future target time based on the current load information to predict the load information is directly determined based on the relationship between the current load information and the score threshold value. For example: the score threshold values of CPU and memory are set to 80% and 100 ms respectively, and the embodiments of the present application are not limited thereto

[0106] If the comprehensive load score does not exceed the preset score threshold value, the new current load information can be obtained based on the new current load information.

[0107] On the contrary, if the comprehensive load score exceeds the preset score threshold value, the step of predicting the future target time based on the current load information to predict the load information can be performed.

[0108] Step 303, determine the container capacity set for the microservice instance, and determine the current required container instance number according to the container capacity and the predicted load information.

[0109] After determining the predicted load information, the container capacity set for the microservice instance, i.e., the capacity required by a single container, can be determined.

[0110] After determining the container capacity and the predicted load information, the current required container instance number required for deploying the microservice instance can be determined according to the container capacity and the predicted load information.

[0111] Step 304, create or delete containers according to the current required container instance number.

[0112] After determining the current required container instance number, containers can be created or deleted based on the current required container instance number; for example, if N is greater than the current number of containers, new containers can be created based on the container capacity; on the contrary, if N is less than the current number of containers, the excess containers can be deleted, and the tasks on these deleted containers can be migrated to other containers.

[0113] Step 305, determine the resource waste rate and response delay after the microservice instance is deployed to the currently existing containers.

[0114] After creating or deleting containers, resource allocation can be performed on the currently existing containers, and the microservice instance can be deployed in the currently existing containers for running to realize specific functions on the home host.

[0115] In some possible embodiments, the resource waste rate and the response delay that can occur after the microservice instance is deployed to the currently existing containers can be determined. The resource waste rate and the response delay can be predicted or actual data measured after the microservice instance is deployed in the containers for a period of time.

[0116] Step 306, deploying the microservice instance based on the resource waste rate and the response delay.

[0117] After determining the resource waste rate and the response delay, the microservice instance can be deployed in min(w1*R_waste+w2*T_delay) (R_waste is the resource waste rate, T_delay is the response delay, w1 and w2 are weights; w1 and w2 are pre-set by system designers according to specific application requirements, and are used to balance the influence of resource waste and task delay in the optimization strategy), for example: high-priority tasks (such as security monitoring) can be assigned to low-load containers to reduce T_delay; low-priority tasks (such as data analysis) are assigned to resource-rich containers to reduce R_waste.

[0118] In the embodiment of the application, according to the current load information, the current load vector is determined, and according to the current load vector, the comprehensive load score of the smart home system is determined; when the comprehensive load score exceeds the preset score threshold, the prediction load information of the target time in the future is predicted according to the current load information; the container capacity set for the microservice instance is determined, and the current required container instance number is determined according to the container capacity and the prediction load information; according to the current required container instance number, the container is created or deleted; the resource waste rate and the response delay after the microservice instance is deployed to the currently existing container are determined; the microservice instance is deployed based on the resource waste rate and the response delay. Through the embodiment of the application, dynamic container scheduling can be realized based on load prediction, so that resource waste can be avoided, and problems such as performance bottleneck can also be avoided. And the microservice instance is deployed with the purpose of minimizing the resource waste rate and the response delay, which can avoid the problems of resource waste and excessive response delay.

[0119] Referring to Figure 4 , another step flow chart of the microservice instance deployment method of the embodiment of the application is shown, which can include the following steps:

[0120] Step 401, obtaining the current load information of the smart home system, and predicting the prediction load information of the target time in the future according to the current load information.

[0121] In some feasible embodiments, the containerization technology is applied in the smart home system; in the resource-limited home scene, in order to avoid scheduling complexity, the current load information of the smart home system can be obtained first, and the prediction load information of the smart home system at the target time in the future is predicted based on the current load information, so as to predict the computing resource demand, and create or delete the container based on this, so as to reduce the complexity of scheduling decision.

[0122] Exemplarily, a trigger mechanism may be set to execute the method for deploying microservice instances according to an embodiment of the present invention; for example, a preset time interval may be set, and redeployment and resource allocation may be performed when the time interval arrives.

[0123] In addition, whether redeployment and resource allocation are required may also be determined based on the current state of the smart home system. Specifically, after obtaining the current load information, the current load vector may be determined.

[0124] After obtaining the current load vector, the comprehensive load score of the smart home system can be calculated based on the current load vector.

[0125] After determining the comprehensive load score, it can be determined whether the current load score exceeds a preset score threshold. For example, the score threshold can be set according to actual conditions, for example, 80, which is not limited in this embodiment of the present invention.

[0126] If the comprehensive load score does not exceed the preset score threshold, new current load information can be obtained.

[0127] On the contrary, if the comprehensive load score exceeds the preset score threshold, the step of predicting load information at a future target time based on the current load information may be performed.

[0128] Step 402: Determine the container capacity set for the microservice instance, and determine the current required number of container instances based on the container capacity and predicted load information.

[0129] After determining the predicted load information, you can then determine the container capacity set for the microservice instance, that is, the capacity required for a single container.

[0130] After determining the container capacity and predicted load information, the current required number of container instances required to deploy the microservice instance can be determined based on the container capacity and predicted load information.

[0131] Step 403: Create or delete a container based on the currently required number of container instances.

[0132] After determining the current required number of container instances, containers can be created or deleted based on the current required number of container instances. For example, if N is greater than the current number of existing containers, new containers can be created based on the container capacity. Conversely, if N is less than the current number of existing containers, excess containers can be deleted and tasks on these deleted containers can be migrated to other containers.

[0133] Step 404: Determine the resource waste rate and response delay after the microservice instance is deployed to the currently existing container.

[0134] After the container is created or deleted, the resource allocation can be performed on the existing container, and the micro-service instance is deployed in the existing container to run to achieve a specific function on the home host.

[0135] In some possible embodiments, the resource waste rate and the response delay that can occur after the micro-service instance is deployed to the existing container can be determined.

[0136] Step 405, deploying the micro-service instance based on the resource waste rate and the response delay.

[0137] After the resource waste rate and the response delay are determined, the micro-service instance can be deployed in min(w1*R_waste+w2*T_delay) (R_waste is the resource waste rate, T_delay is the response delay, w1 and w2 are weights; w1 and w2 are pre-set by the system designer according to the specific application requirement, and are used to balance the influence of resource waste and task delay in the optimization strategy), for example, high-priority tasks (such as security monitoring) can be allocated to low-load containers to reduce T_delay, and low-priority tasks (such as data analysis) can be allocated to resource-rich containers to reduce R_waste.

[0138] Step 406, determining the device feature vector of each smart device and the demand vector of the micro-service instance.

[0139] In some possible embodiments, the device feature vector of each smart device and the demand vector of each micro-service instance can also be determined to achieve accurate matching of heterogeneous devices and containerized services. The device feature vector can be used to represent the performance, properties, etc. of the smart device, for example, the device feature vector can be represented as follows:

[0140] V_d=[P_protocol,P_power,P_freq];

[0141] P_protocol: can be a protocol type (such as Zigbee, Wi-Fi).

[0142] P_power can be the average power consumption.

[0143] P_freq: can be the number of message sending / receiving times, and the communication frequency is calculated.

[0144] The micro-service demand vector can be used to represent the resources required to implement the service corresponding to the micro-service instance, and the micro-service demand vector can be represented as follows:

[0145] V_s=[R_cpu,R_mem,R_net];

[0146] R_cpu: can be the CPU requirement predefined in the configuration file of the microservice instance, which can be adjusted in combination with historical data.

[0147] R_mem: can be the memory requirement specified in the configuration file of the microservice instance (for example, 100MB for a data processing service), which is verified by actual memory usage at runtime.

[0148] R_net: can be the network bandwidth or delay estimated based on the service communication mode (for example, 10ms delay for an MQTT service), in combination with historical message queue data.

[0149] Step 407: determining the matching degree of the microservice instance and each smart device according to the device feature vector and the requirement vector.

[0150] After determining the device feature vector and the requirement vector, the matching degree of the microservice instance and each smart device can be calculated; for example, the matching degree can be calculated by cosine similarity.

[0151] Step 408: deploying the container with the microservice instance to the smart device according to the matching degree.

[0152] After determining the matching degree of the microservice instance and each smart device, the container with the microservice instance can be deployed to the smart device based on the matching degree, so as to deploy the container in a more suitable smart device.

[0153] In the embodiment of the application, the current load information of the smart home system is obtained, and the predicted load information of the target time in the future is predicted according to the current load information; the container capacity set for the microservice instance is determined, and the current required container instance number is determined according to the container capacity and the predicted load information; the container is created or deleted according to the current required container instance number; the resource waste rate and the response delay of the microservice instance after being deployed to the currently existing container are determined; the microservice instance is deployed based on the resource waste rate and the response delay; the device feature vector of each smart device and the requirement vector of the microservice instance are determined; the matching degree of the microservice instance and each smart device is determined according to the device feature vector and the requirement vector; and the container with the microservice instance is deployed to the smart device according to the matching degree. Through the embodiment of the application, dynamic container scheduling can be realized based on load prediction, so as to avoid resource waste and performance bottleneck problems. And based on the matching degree, accurate matching of heterogeneous devices and containerized services can be realized.

[0154] Referring to Figure 5 , another step flowchart of a microservice instance deployment method is shown, which can include the following steps:

[0155] Step 501, obtaining current load information of the smart home system, and predicting future target time prediction load information according to the current load information.

[0156] In some possible embodiments, the containerization technology is applied in the smart home system; in the resource-limited home scenario, in order to avoid scheduling complexity, the current load information of the smart home system can be obtained first, and the prediction load information of the smart home system at the target time in the future is predicted based on the current load information, so as to predict the computing resource demand, and based on this, the container is created or deleted, so as to reduce the complexity of scheduling decision.

[0157] For example, a trigger mechanism can be set to perform the deployment method of the microservice instance mentioned in the embodiments of the application; for example, a preset time interval can be set, and when the time interval comes, the deployment and resource allocation are performed again.

[0158] In addition, whether the deployment and resource allocation need to be performed again can also be determined based on the current state of the smart home system; specifically, after obtaining the current load information, the current load vector can be determined.

[0159] After obtaining the current load vector, the comprehensive load score of the smart home system can be calculated based on the current load vector.

[0160] After determining the comprehensive load score, it can be judged whether the current load score exceeds a preset score threshold; for example, the score threshold can be set according to the actual situation, for example, 80, and the embodiments of the application do not limit this.

[0161] If the comprehensive load score does not exceed the preset score threshold, new current load information can be obtained.

[0162] On the contrary, if the comprehensive load score exceeds the preset score threshold, the step of predicting the future target time prediction load information according to the current load information can be performed.

[0163] Step 502, determining the container capacity set for the microservice instance, and determining the current required container instance number according to the container capacity and the prediction load information.

[0164] After determining the prediction load information, the container capacity set for the microservice instance, that is, the capacity required by a single container, can be determined.

[0165] After determining the container capacity and the prediction load information, the current required container instance number required for deploying the microservice instance can be determined according to the container capacity and the prediction load information.

[0166] Step 503, creating or deleting the container according to the current required container instance number.

[0167] After determining the current required number of container instances, a container can be created or deleted based on the current required number of container instances; for example, if N is greater than the current number of containers, a new container can be created based on the container capacity; conversely, if N is less than the current number of containers, the excess containers can be deleted, and the tasks on these deleted containers can be migrated to other containers.

[0168] Step 504, determine the resource waste rate and response delay after the microservice instance is deployed to the currently existing container.

[0169] After creating or deleting a container, resource allocation can be performed on the currently existing container, and the microservice instance can be deployed in the currently existing container for running to achieve a specific function on the home host.

[0170] In some possible embodiments, the resource waste rate and response delay that can occur after the microservice instance is deployed to the currently existing container can be determined.

[0171] Step 505, deploy the microservice instance based on the resource waste rate and response delay.

[0172] After determining the resource waste rate and response delay, the microservice instance can be deployed in min(w1*R_waste+w2*T_delay) (R_waste is the resource waste rate, T_delay is the response delay, w1 and w2 are weights; w1 and w2 are pre-set by a system designer according to specific application requirements, and are used to balance the influence of resource waste and task delay in the optimization strategy), for example, a high-priority task (such as security monitoring) can be allocated to a low-load container to reduce T_delay, and a low-priority task (such as data analysis) can be allocated to a resource-rich container to reduce R_waste.

[0173] Step 506, determine the device feature vector of each smart device and the demand vector of the microservice instance.

[0174] In some possible embodiments, the device feature vector of each smart device and the demand vector of each microservice instance can also be determined to achieve accurate matching of heterogeneous devices and containerized services.

[0175] Step 507, determine the matching degree of the microservice instance and each smart device according to the device feature vector and the demand vector.

[0176] After determining the device feature vector and the demand vector, the matching degree of the microservice instance and each smart device can be calculated; for example, the matching degree can be calculated by cosine similarity.

[0177] Step 508, determine the matching degree matrix according to the matching degree.

[0178] After determining the matching degree of each micro-service instance and each smart device, a matching degree matrix can be determined based on the matching degree.

[0179] For example, the device feature vector V_d and the demand vector V_s can be normalized to unit vectors (divided by the respective Euclidean norm).

[0180] Then, the dot product V_d·V_s=P_protocol*R_cpu+P_power*R_mem+P_freq*R_net can be calculated, and the cosine similarity can be calculated, with a value between [-1, 1], and the larger the value, the higher the matching degree.

[0181] The calculation process of the matching degree matrix M (size D x S, D is the number of smart devices, S is the number of micro-service instances):

[0182] The matrix structure of the matching degree matrix: M[i, j], which represents the cosine similarity cos(V_d[i], V_s[j]) of device i and micro-service instance j.

[0183] Process: 1. Obtain the device feature vector V_d[i] of the smart device.

[0184] 2. Obtain the demand vector V_s[j] of the micro-service instance j.

[0185] 3. Calculate M[i, j] = cos(V_d[i], V_s[j]).

[0186] 4. Traverse all i and j to fill the matrix. 5. Update the matrix every 5 minutes or when a new device / micro-service is added.

[0187] Step 509, determine the target smart device matched with the micro-service instance based on the matching degree matrix, and deploy the container of the micro-service instance in the target smart device.

[0188] After determining the matching degree matrix, the target smart device matched with each micro-service instance can be determined based on the matching degree matrix, and the container of each micro-service instance can be deployed to the corresponding target smart device.

[0189] For example, a greedy algorithm can be used to select the pairing of smart devices and micro-service instances. The pairing process is as follows:

[0190] Input: Matching degree matrix M (size D x S).

[0191] Process: 1. Initialize an empty pairing list.

[0192] 2. For microservice instance j, select the smart device i with the largest M[i,j] among unassigned devices.

[0193] 3. Assign microservice instance j to the smart device i (i.e. the target smart device of microservice instance j), mark the smart device i as assigned.

[0194] 4. Repeat the matching for each microservice instance until all microservice instances are assigned or no smart device is available.

[0195] 5. If a microservice instance cannot be assigned (no compatible device), add it to the pending assignment queue and reassign it after a new container is created.

[0196] Output: a list of device-service pairings that maximizes the total matching degree.

[0197] Then, based on the output list of device-service pairings, the containers of microservice instances can be deployed to the corresponding target smart devices.

[0198] In the embodiment of the application, the current load information of the smart home system is obtained, and the predicted load information of a target time in the future is predicted according to the current load information; the container capacity set for the microservice instance is determined, and the number of currently required container instances is determined according to the container capacity and the predicted load information; the container is created or deleted according to the number of currently required container instances; the resource waste rate and the response delay after the microservice instance is deployed to the currently existing container are determined; the microservice instance is deployed based on the resource waste rate and the response delay; the device feature vector of each smart device and the demand vector of the microservice instance are determined; the matching degree of the microservice instance and each smart device is determined according to the device feature vector and the demand vector; the matching degree matrix is determined according to the matching degree; the target smart device matched by the microservice instance is determined according to the matching degree matrix, and the container of the microservice instance is deployed in the target smart device. Through the embodiment of the application, dynamic container scheduling can be realized based on load prediction, so that resource waste can be avoided, and problems such as performance bottleneck can be avoided. And precise matching of heterogeneous devices and containerized services can be realized.

[0199] In an embodiment of the application, any one of the above methods can further include the following steps:

[0200] When the target task of the microservice instance is received, the target task is decomposed into at least one subtask according to the dependency graph; the at least one subtask is added to the execution queue according to the priority of each subtask and the dependency relationship between the subtasks.

[0201] In some possible embodiments, after receiving the target task of the microservice instance, the target task (e.g., “light up the light when the door opens”) can be first decomposed into at least one subtask (e.g., “read the door sensor”, “send the light control instruction”) according to a directed acyclic graph (DAG). Illustratively, each target task can be represented as a DAG, the nodes can be subtasks, and the edges can represent the dependency relationship (e.g., “read the sensor” precedes “send the instruction”). The DAG is a graph structure that connects nodes by directed edges and does not have loops.

[0202] After obtaining the respective subtasks, the priority of each subtask can be determined; then, based on the priority of each subtask and the dependency relationship between the subtasks, the subtasks can be added to an execution queue and executed in order. Among them, the subtasks with high priority can be executed first, the subtasks with low priority can be executed later, and the subtasks with execution order can also be executed in the order.

[0203] Illustratively, the subtasks can be added to the task queue according to a hierarchical strategy of high priority (security monitoring, emergency alarm, delay < 50 ms), medium priority (device control such as light, air conditioner, delay < 200 ms), and low priority (data analysis, log recording, delay < 1 s).

[0204] Priority hierarchy: high priority: security monitoring, emergency alarm, delay < 50 ms. Medium priority: device control (such as light, air conditioner), delay < 200 ms. Low priority: data analysis, log recording, delay < 1 s.

[0205] The task queue is used to store tasks, and high-priority tasks are dequeued first. The time slice round-robin algorithm allocates CPU time: in a 10 ms time slice, high-priority tasks account for 70%, medium-priority tasks account for 20%, and low-priority tasks account for 10%. If a high-priority task is delayed for more than 50 ms, suspend the low-priority task and reallocate its container resources.

[0206] The priority queue and the time slice round-robin algorithm are used to allocate resources. If high-priority tasks are accumulated, low-priority tasks can be suspended first, and when resource allocation imbalance (e.g., a container CPU usage is too high) is detected, the time slice and container load are dynamically adjusted to optimize concurrency efficiency.

[0207] Illustratively, when resource allocation imbalance is detected (e.g., a container CPU usage is > 90%), the time slice can be adjusted. Specifically, each container can be allocated a 10 ms time slice, and the tasks can be weighted according to priority (high: 7 ms, medium: 2 ms, low: 1 ms).

[0208] If the imbalance persists, the tasks can be migrated to a low-load container.

[0209] When the task is executed, the decomposed subtasks can be stored in a task queue first; and the execution is performed according to the priority and the submission time.

[0210] The dequeued task is assigned to a low-load container based on a load vector.

[0211] If the high-priority task is delayed for more than 50 ms, the low-priority container is paused by sending a SIGSTOP (Signal Stop) signal, and the CPU and / or memory are redistributed.

[0212] In the embodiment of the application, a task hierarchical scheduling strategy based on priority, time and dependency is introduced to optimize the concurrent execution efficiency of tasks corresponding to multiple micro-service instances.

[0213] In an embodiment of the application, the above method can further include the following steps:

[0214] When the network interruption of the smart home system is detected, resources are allocated to subtasks higher than the first priority, and subtasks lower than the second priority are in a dormant state.

[0215] In some feasible embodiments, when the network interruption is detected, or when it is predicted that the network will be interrupted, the local mode can be switched to, resources are allocated to subtasks higher than the first priority (such as emergency alarm), and subtasks lower than the second priority (user-defined priority table, such as setting the temperature control as high priority) are in a dormant state, and the memory occupation is compressed.

[0216] In some feasible embodiments, all operation data during the network interruption period can be recorded, and after the network is restored, the data is synchronized to the cloud based on the time stamp increment to restore the normal operation mode, so that the smart home system can continuously operate under network interruption.

[0217] In an embodiment of the application, the above method can further include the following steps:

[0218] The communication delay and the load imbalance contribution of the smart home system are determined, and the priority of the subtask is adjusted according to the communication delay and the load imbalance contribution.

[0219] In some feasible embodiments, when the subtask is executed, the communication delay T_comm and the load imbalance contribution R_imbalance of the smart home system can also be determined.

[0220] T_comm can be calculated by the time stamp of the MQTT (Message Queuing Telemetry Transport) message queue, and the average time from sending to responding of the subtask.

[0221] R imbalance = σ([CPU 1, CPU 2,..., CPU n; Mem 1, Mem 2,..., Mem n]) / μ; by calculating the standard deviation of all container CPU and memory usage, divided by the average value.

[0222] After obtaining the communication delay and load imbalance contribution, the priority of the subtask can be adjusted to improve the global efficiency of the MQTT queue. Through dynamic adjustment, the global efficiency of the MQTT queue can be ensured to be always at a high level. The step of adjusting the priority can be performed when the smart home system network is interrupted, or can be performed at any time, and the embodiments of the present application do not limit this.

[0223] For example, the service call allocation (i.e., adjusting the priority) can be adjusted by a weighted round-robin algorithm, and the global performance optimization message queue distribution efficiency is periodically evaluated:

[0224] 1. Optimization target min(T_comm+R_imbalance).

[0225] 2. The weight w i of each microservice instance i = 1 / (T_comm_i+R_imbalance_i), where T_comm_i is its average communication delay, and R_imbalance_i is its load imbalance contribution.

[0226] 3. The tasks corresponding to the microservice instances are distributed according to the weight, and high weight is given priority.

[0227] 4. The weight is updated every 5 minutes according to the new T_comm and R_imbalance.

[0228] Performance evaluation: the global efficiency of the MQTT queue (the number of successfully processed tasks / the total number of tasks) is calculated every 10 minutes. If the efficiency is less than 90%, the weight of the tasks of the container under low load is increased, the weight of the tasks of the container under high load is reduced, and w i is recalculated. The updated weight is applied to the next scheduling period.

[0229] It should be noted that for the method embodiments, in order to simply describe, they are all described as a series of action combinations, but those skilled in the art should know that the embodiments of the present application are not limited by the order of the described actions, because according to the embodiments of the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of the present application.

[0230] Reference Figure 6, shows a structural schematic diagram of a deployment system 60 of a micro-service instance of an embodiment of the present application, which can be applied to a smart home system and can include:

[0231] a resource optimization subsystem 610, configured to acquire current load information of the smart home system, and predict predicted load information of a target time in the future according to the current load information; determine a container capacity set for the micro-service instance, and determine a current required container instance number according to the container capacity and the predicted load information;

[0232] a container management subsystem 620, configured to create or delete a container, and deploy the micro-service instance into the existing container.

[0233] In some possible embodiments, the deployment system can be deployed in the smart home system; for example, it can be deployed in a home host of the smart home system. The deployment system can include the resource optimization subsystem 610 and the container management subsystem 620.

[0234] The resource optimization subsystem 610 can first acquire current load information of the smart home system, and predict predicted load information of the smart home system at a target time in the future based on the current load information, so as to predict the resource requirement, and create or delete the container based on the prediction, thereby reducing the complexity of the scheduling decision.

[0235] Specifically, after the resource optimization subsystem 610 determines the predicted load information, it can further determine a container capacity set for the micro-service instance.

[0236] After the container capacity and the predicted load information are determined, the container number required for deploying the micro-service instance, i.e., the current required container instance number, can be determined according to the container capacity and the predicted load information.

[0237] After the current required container instance number is determined, the container management subsystem 620 can create or delete a container based on the current required container instance number; for example, if N is greater than the current number of containers, the container management subsystem 620 can create a new container based on the container capacity; otherwise, if N is less than the current number of containers, the container management subsystem 620 can delete the redundant containers and migrate the tasks on the deleted containers to other containers.

[0238] For example, the resource optimization subsystem 610 can also be configured to allocate resources and tasks to each container.

[0239] In an embodiment of the present application, the deployment system further includes:

[0240] a heterogeneous adaptation subsystem 640, configured to convert data protocols of each smart device in the smart home system.

[0241] In some feasible embodiments, since different devices may have different protocols, a heterogeneous adaptation subsystem 640 may be provided to convert the data protocols of the smart devices in the smart home system.

[0242] In one embodiment of the present invention, the deployment system further includes:

[0243] The service optimization subsystem 650 is used to implement communication and task collaboration between different microservice instances.

[0244] In some feasible embodiments, a service optimization subsystem 650 may also be provided to implement communication and task collaboration between different microservice instances.

[0245] In one embodiment of the present invention, the deployment system further includes:

[0246] The local fault-tolerant subsystem 660 is configured to allocate resources to subtasks with a priority higher than the first priority and put subtasks with a priority lower than the second priority into a dormant state when a smart home system network interruption is detected.

[0247] In some feasible embodiments, a local fault-tolerant subsystem 660 may be set up to ensure service during network interruptions. For example, when the local fault-tolerant subsystem 660 detects a network interruption or predicts that the network will be disconnected, it may switch the smart home system to local mode and notify the resource optimization subsystem 610 to allocate resources to subtasks with a higher priority than the first (such as emergency alarms), and put subtasks with a lower priority than the second (users can customize the priority table, such as setting temperature control to a high priority) into a dormant state, and compress memory usage.

[0248] In some feasible embodiments, the local fault-tolerant subsystem 660 can record all operating data during the network outage period, and after the network is restored, synchronize the data to the cloud based on timestamp increments to restore the normal operating mode, thereby ensuring that the smart home system can continue to operate during the network outage.

[0249] For example, Figure 7 As shown, the deployment system can be composed of an environment perception subsystem 630, a container management subsystem, a resource optimization subsystem 610, a service optimization subsystem 650, a heterogeneous adaptation subsystem 640, and a local fault tolerance subsystem 660. The environment perception subsystem 630 is in communication with the smart device and the heterogeneous adaptation subsystem 640 respectively; the resource optimization subsystem 610 is in communication with the container management subsystem 620 and the service optimization subsystem 650 respectively; and the service optimization subsystem 650 is in communication with the local fault tolerance subsystem 660.

[0250] The environment perception subsystem 630 is configured to collect device states and user behaviors, and push data to the heterogeneous adaptation subsystem 640 through an event-driven model.

[0251] The environment perception subsystem 630 is configured to obtain raw data from smart devices, and is provided with a multi-protocol access function and an event-driven model, so as to accept data from smart devices of different protocols, and allocate resources and deploy containers when a trigger event (for example, a timing trigger or a resource imbalance trigger) occurs.

[0252] The container management subsystem 620 is configured to manage the life cycle of containers, including creation, destruction and migration.

[0253] The container management subsystem 620 can include a container engine, an image repository and a dynamic scheduler. The container engine is configured to pull images from the image repository and create new containers or terminate redundant containers. The dynamic scheduler is configured to dynamically schedule tasks in the containers, for example, migrating tasks in a container to be terminated to other containers.

[0254] The resource optimization subsystem 610 is configured to analyze the state of system resources in real time and optimize the allocation of containers and tasks.

[0255] The resource optimization subsystem 610 can include a load monitor, an adaptive scheduling algorithm module and a resource allocator. The load monitor is configured to monitor the load of the smart home system. The adaptive scheduling algorithm module is configured to generate a specific strategy for resource scheduling based on the load. The resource scheduler is configured to schedule resources for each container based on the specific strategy.

[0256] The service optimization subsystem 650 is configured to realize communication between microservices and task cooperation.

[0257] The service optimization subsystem 650 can include a service registry and a message middleware. For example, the service optimization subsystem 650 distributes task instructions through a service registry (ETCD (Extended Distributed Key-Value Store)) and an MQTT message queue (i.e., a message middleware).

[0258] The service registry (ETCD) is a key-value store that maintains active microservice instances, including container ID, IP address and port.

[0259] When a task is generated, the service optimization subsystem 650 queries the service registry to obtain the address corresponding to the microservice instance.

[0260] MQTT message queue: tasks are encapsulated as JSON messages (containing task ID, type, parameters), published to the MQTT topic of the corresponding microservice instance, and each microservice instance subscribes to its topic.

[0261] Process: 1. The service optimization subsystem 650 obtains the address corresponding to the microservice instance from the service registry center. 2. The task is published to the target topic through the MQTT broker and routed to the container corresponding to the microservice instance. 3. The container executes the task and returns the result through the response topic.

[0262] The heterogeneous adaptation subsystem 640 is used to abstract heterogeneous devices into a unified interface and adapt containerized services.

[0263] The heterogeneous adaptation subsystem 640 can include a protocol converter, a device feature extractor, and a mapping model; wherein the protocol converter can convert the protocol of the heterogeneous device, the device feature extractor can be used to extract the device feature, and the device feature can be used to obtain the device feature vector. The mapping model can save the mapping relationship between the intelligent device and the microservice instance, and the mapping model is determined based on the matching degree of the microservice instance and each intelligent device.

[0264] The local fault-tolerant subsystem 660 is used to ensure service availability when the network is interrupted.

[0265] The local fault-tolerant subsystem 660 can include a state predictor, a priority manager, a local cache, and an offline self-healing microservice; wherein the state predictor can be used to predict the load condition of the smart home system in the future time period; the priority manager can be used to manage the priority of each subtask or task, and adjust the priority of each subtask and task; the local cache can be used to record all operation data for data synchronization when the network is recovered after the network is interrupted; the offline self-healing microservice can be used for self-recovery of the smart home system when the network is interrupted.

[0266] For example, when the home host is started, the basic image (including device management service and data processing service) is loaded, the container engine, load monitor and service registry center are initialized; at the same time, the environment perception subsystem 630 scans and registers the connected intelligent devices.

[0267] Subsequently, the running phase is entered, the load monitor collects real-time load vector L = [CPU, Mem, Net_delay], and determines the comprehensive load score; if it is detected that the comprehensive load score exceeds the threshold (which can be set to 80%), the adaptive dynamic container scheduling mechanism is triggered.

[0268] The LSTM model is used to predict the comprehensive load score L_pred in the next 5 minutes; the current required container instance number N = ceil(L_pred / C_cap) is calculated, and containers are created or destroyed according to N.

[0269] The allocation of microservice instances and containers is performed according to the task type to optimize the target min(w1*R_waste+w2*T_delay).

[0270] The heterogeneous adaptation subsystem 640 extracts the device feature vector V_d = [P_protocol, P_power, P_freq] (protocol type, power consumption, communication frequency) and the microservice requirement vector V_s = [R_cpu, R_mem, R_net], calculates the matching degree by the cosine similarity cos(V_d, V_s), iteratively calculates the matching degree matrix, and selects the optimal device-service pairing by the greedy algorithm to load the adaptive microservice instance.

[0271] The service coordination subsystem distributes task instructions through the service registry center and the MQTT message queue; then, the service coordination subsystem receives the task, decomposes it into subtasks according to the dependency graph (DAG), and uses a hierarchical strategy according to high priority (security monitoring, emergency alarm, delay < 50ms), medium priority (device control such as lights, air conditioning, delay < 200ms), and low priority (data analysis, log recording, delay < 1s). The priority queue and time slice round-robin algorithm are used to allocate resources. If high-priority tasks are accumulated, low-priority tasks can be suspended first. When resource allocation is uneven (such as high CPU usage of a container), the time slice and container load are dynamically adjusted to optimize concurrency efficiency.

[0272] When the local fault-tolerant subsystem 660 senses an interruption, the smart home system switches to local mode. The out-of-network self-healing microservice predicts the service interruption probability through the Markov model trained by historical data. The priority manager reallocates resources to high-priority services (such as emergency alarms), and low-priority services enter hibernation and compress memory usage (users can customize the priority table, such as setting temperature control as high priority). The local cache (RocksDB) records all operation data. At the same time, the service optimization subsystem 650 analyzes the service registry center data to build a microservice dependency graph to optimize the target min(T_comm+R_imbalance) by adjusting service call allocation through weighted round-robin algorithm, and regularly evaluates the global performance optimization message queue distribution efficiency. Finally, after the network is restored, the cache data is synchronized to the cloud based on the timestamp increment, and the normal operation mode is restored.

[0273] For example, the heterogeneous adaptation subsystem 640 defines a standardized interface description for each type of smart device, based on the JSON format, which can include the following fields:

[0274] -device_id: unique identifier of the device.

[0275] -protocol_type: protocol type (e.g. "Zigbee").

[0276] - capabilities: list of supported functions (e.g. "read_sensor", "send_command").

[0277] - resource_requirements: resource requirements (e.g. CPU, memory, network bandwidth).

[0278] - example interface description:

[0279] {

[0280] "device_id": "device_001",

[0281] "protocol_type": "Zigbee",

[0282] "capabilities": ["read_sensor", "send_command"],

[0283] "resource_requirements": {"cpu": 0.1, "mem": 50, "net": 10}

[0284] }

[0285] Abstract process:

[0286] 1. Heterogeneous adaptation subsystem 640 converts device communication protocols to standardized API calls through protocol translators (pre-installed protocol drivers like Z-Stack for Zigbee or TCP / IP stack for Wi-Fi).

[0287] 2. Each device's functions (e.g. reading sensor data, sending control instructions) are mapped to a unified function call interface, e.g. read(device_id, sensor_type) or control(device_id, command).

[0288] 3. Protocol translators convert specific communication formats (e.g. ZCL commands for Zigbee) to standard JSON messages, which are sent to the MQTT message queue.

[0289] 4. Unified interfaces are stored in the service registry for calls by container management subsystem 620 and priority manager.

[0290] For example, the resources allocated to a container include three parts of CPU, memory and network resources.

[0291] Formula (allocated CPU, memory, network resources - actual used resources) / allocated CPU, memory, network resources is a simplified expression. In actual calculation, the resource waste rate R_waste is calculated based on three parts and then weighted to avoid direct subtraction of a single value.

[0292] 1. Allocated resources: The container management subsystem 620 records the resource allocation of each container (e.g., each container is allocated 20% CPU, 200MB memory, 50ms delay upper limit), and the total allocated resources are summed up.

[0293] 2. Actual used resources: The load monitor collects the actual resource usage (CPU, memory, network) of all containers every second through system interfaces (such as / proc / stat, / proc / meminfo, network traffic statistics).

[0294] 3. Calculation: Calculate the waste rate for each part of the resource, and then weighted sum to get R_waste, unit is percentage ([0,1]).

[0295] For example: Assume that there are 3 containers, each allocated 20% CPU, 200MB memory, 10Mbps bandwidth, and the total allocation is 60% CPU, 600MB memory, 30Mbps bandwidth.

[0296] The actual usage is 50% CPU, 400MB memory, 20Mbps bandwidth.

[0297] Then:

[0298] R_waste_cpu = (60%-50%) / 60% = 0.167

[0299] R_waste_mem = (600-400) / 600 = 0.333

[0300] R_waste_net = (30-20) / 30 = 0.333

[0301] If the weights are 0.4, 0.4, 0.2, then R_waste = 0.4*0.167 + 0.4*0.333 + 0.2*0.333 = 0.267 (26.7%).

[0302] For example, assume that there are D intelligent devices (i = 1, 2,..., D) and S microservice instances (j = 1, 2,..., S).

[0303] For each intelligent device i, obtain the device feature vector V_d[i] = [P_protocol, P_power, P_freq] from the heterogeneous adaptation subsystem 640.

[0304] For each microservice instance j, get the requirement vector V_s[j] = [R_cpu, R_mem, R_net] from the container management subsystem 620.

[0305] Compute M[i,j] = cos(V_d[i], V_s[j]), where cos(V_d, V_s) = (V_d · V_s) / (||V_d|| * ||V_s||).

[0306] Iterate over all i and j, fill the matrix M.

[0307] Example: Let's say there are 2 smart devices (D1, D2) and 2 microservice instances (S1, S2).

[0308] Device feature vectors:

[0309] D1: V_d[1] = [1, 0.5, 0.3] (Zigbee protocol, 50W power normalized, 3Hz frequency normalized)

[0310] D2: V_d[2] = [0, 0.3, 0.5] (Wi-Fi protocol, 30W power normalized, 5Hz frequency normalized)

[0311] Requirement vectors:

[0312] S1: V_s[1] = [0.2, 0.4, 0.1] (20% CPU, 400MB memory, 10ms latency normalized)

[0313] S2: V_s[2] = [0.3, 0.2, 0.3] (30% CPU, 200MB memory, 30ms latency normalized)

[0314] Compute cosine similarity (simplified calculation, assuming vectors are normalized):

[0315] M[1,1] = cos(V_d[1], V_s[1]) = (1*0.2 + 0.5*0.4 + 0.3*0.1) / (||V_d[1]|| * ||V_s[1]||) ≈ 0.85

[0316] M[1,2] = cos(V_d[1], V_s[2]) ≈ 0.72

[0317] M[2,1] = cos(V_d[2], V_s[1]) ≈ 0.65

[0318] M[2,2] = cos(V_d[2], V_s[2]) ≈ 0.90

[0319] Fill the matrix:

[0320] M = [

[0321] [0.85, 0.72], / / D1's match with S1, S2

[0322] [0.65, 0.90] / / D2's match with S1, S2.

[0323] Example task configuration parsing:

[0324] Each task is defined in a configuration file, containing task ID, type (e.g., device control), input (e.g., sensor state), output (e.g., light command), and dependencies (e.g., "read sensor" precedes "send command").

[0325] The priority manager extracts subtasks and dependencies of a task by parsing the configuration file (e.g., JSON format).

[0326] Example JSON configuration:

[0327] {

[0328] "task_id": "T1",

[0329] "type": "device_control",

[0330] "subtasks": [

[0331] {"id": "ST1", "action": "read_door_sensor", "service": "sensor_service"},

[0332] {"id": "ST2", "action": "send_light_command", "service": "light_service"}

[0333] ],

[0334] "dependencies": [

[0335] {"from": "ST1", "to": "ST2"} ]

[0337] }

[0338] Integrate with service registry metadata:

[0339] The service registry stores metadata of all microservice instances, including service ID, container IP, port, and function description (e.g., "sensor_service" handles sensor data).

[0340] The priority manager queries the service registry to match the required services for the subtasks in the task configuration (e.g., "sensor_service" for ST1, "light_service" for ST2).

[0341] Based on the dependencies, the subtasks are mapped as DAG nodes, with dependencies as directed edges.

[0342] DAG construction process:

[0343] Create nodes: Each subtask (ST1, ST2) is a node in the DAG, labeled with its service ID and priority (based on task type, e.g., medium priority for device control).

[0344] Add edges: Directed edges are added according to the "dependencies" field in the configuration (e.g., ST1→ST2, indicating that ST2 depends on ST1).

[0345] Verify acyclic: Check if the DAG is acyclic using a topological sorting algorithm, and if there is a cycle, report an error and require redefinition of the task.

[0346] Output DAG: Stored as an adjacency list, e.g., {ST1:[ST2], ST2:[]}, for the scheduling engine to resolve and assign subtasks.

[0347] For example: Task T1 is decomposed into ST1 (read door sensor) and ST2 (send light instruction).

[0348] DAG representation: ST1→ST2, ST1 calls "sensor_service", ST2 calls "light_service".

[0349] The priority manager assigns subtasks to corresponding containers in topological order (ST1 precedes ST2).

[0350] In the embodiment of the present application, the deployment system comprises: a resource optimization subsystem, configured to acquire current load information of the smart home system, and predict predicted load information of a target time in the future according to the current load information; determine a container capacity set for a micro-service instance, and determine a current required number of container instances according to the container capacity and the predicted load information; and a container management subsystem, configured to create or delete a container, and deploy the micro-service instance into the currently existing container. Through the embodiment of the present application, dynamic container scheduling can be realized based on load prediction, so that resource waste can be avoided, and problems such as performance bottleneck can also be avoided.

[0351] The embodiment of the present application further provides an electronic device, comprising a processor, a memory, and a computer program stored in the memory and capable of running on the processor, and the computer program is executed by the processor to realize the method for deploying the micro-service instance.

[0352] The embodiment of the present application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program, and the computer program is executed by a processor to realize the method for deploying the micro-service instance.

[0353] For the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the related parts are described in the part of the method embodiment.

[0354] Each embodiment in the specification is described in a progressive manner, and each embodiment mainly describes the difference from other embodiments, and the same and similar parts between the embodiments can be referred to each other.

[0355] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the embodiments of the present application can be in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present application can be in the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0356] The embodiments of the present application are described with reference to flowcharts and / or block diagrams according to the method, terminal device (system), and computer program product of the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of the flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the computer or other programmable data processing terminal device produce a device for implementing the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1 a system that carries out the functions specified in one or more flows and / or blocks.

[0357] These computer program instructions can also be stored in a computer readable memory capable of guiding the computer or other programmable data processing terminal device to work in a specific manner, so that the instructions stored in the computer readable memory produce a product including instruction devices, which implement the functions specified in the flowcharts and / or block diagrams. Figure 1 one or more flows and / or blocks Figure 1the function specified in the one or more blocks.

[0358] These computer program instructions can also be loaded into computer or other programmable data processing terminal devices, so that a series of operation steps are performed on the computer or other programmable terminal devices to generate computer-implemented processes, so that the instructions executed on the computer or other programmable terminal devices provide processes for implementing the flowcharts Figure 1 the flowchart or flowcharts and / or blocks Figure 1 the steps of the function specified in the one or more blocks.

[0359] Although the preferred embodiments of the present application have been described, those skilled in the art who have the basic inventive concept can make further changes and modifications to the embodiments. Therefore, the appended claims are intended to include the preferred embodiments and all changes and modifications falling within the scope of the embodiments of the present application.

[0360] Finally, it should also be noted that, in this paper, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or terminal device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or terminal device. Without more limitations, the element defined by the statement "including a…" does not exclude the presence of other identical elements in the process, method, article or terminal device including the element.

[0361] The above describes in detail the deployment method, system, device and medium of one micro-service instance provided, and the principles and implementation modes of the present application are described in this paper. The above description of the embodiments is only used to help understand the method of the present application and its core idea; at the same time, for those skilled in the art, according to the idea of the present application, there will be changes in specific implementation modes and application scope; in view of the above, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for deploying a microservice instance, characterized in that: Applied to a smart home system, the method includes: Obtaining current load information of the smart home system, and predicting predicted load information at a future target time based on the current load information; Determine the container capacity set for the microservice instance, and determine the number of container instances currently required based on the container capacity and the predicted load information; Create or delete containers based on the currently required number of container instances, and deploy the microservice instances to the currently existing containers.

2. The method according to claim 1, characterized in that The method further comprises: determining a current load vector according to the current load information, and determining a comprehensive load score of the smart home system according to the current load vector; When the comprehensive load score exceeds a preset score threshold, the step of predicting load information at a future target time based on the current load information is performed.

3. The method according to claim 1, characterized in that Deploying the microservice instance to a currently existing container includes: Determine the resource waste rate and response delay after the microservice instance is deployed to the currently existing container; The microservice instance is deployed based on the resource waste rate and the response delay.

4. The method according to claim 1, wherein The smart home system includes a plurality of smart devices, and the method further includes: Determine a device feature vector for each smart device and a demand vector for the microservice instance; Determining the matching degree between the microservice instance and each smart device according to the device feature vector and the demand vector; Based on the matching degree, a container with the microservice instance deployed therein is deployed to the smart device.

5. The method according to claim 4, characterized in that The step of deploying the container with the microservice example deployed on the smart device according to the matching degree includes: Determining a matching matrix according to the matching degree; According to the matching matrix, a target smart device that matches the microservice instance is determined, and a container of the microservice instance is deployed in the target smart device.

6. The method according to claim 1, characterized in that The method further comprises: Upon receiving a target task of the microservice instance, decomposing the target task into at least one subtask according to a dependency graph; The at least one subtask is added to the execution queue according to the priority of each subtask and the dependency relationship between the subtasks.

7. The method according to claim 6, characterized in that The method further comprises: determining communication delay and load imbalance contributions of the smart home system; The priorities of the subtasks are adjusted according to the communication delay and the load imbalance contribution.

8. The method according to claim 6, characterized in that The method further comprises: When a network interruption of the smart home system is detected, resources are allocated to subtasks with a higher priority than the first priority, and subtasks with a lower priority than the second priority are put into a dormant state.

9. A deployment system for a microservice instance, characterized in that: Applied to a smart home system, the deployment system includes: a resource optimization subsystem configured to obtain current load information of the smart home system and predict predicted load information at a future target time based on the current load information; determine a container capacity to be set for the microservice instance, and determine the number of container instances currently required based on the container capacity and the predicted load information; The container management subsystem is used to create or delete containers and deploy the microservice instance to an existing container.

10. The system according to claim 9, characterized in that The deployment system further includes: The heterogeneous adaptation subsystem is used to convert the data protocols of each smart device in the smart home system.

11. The system according to claim 9, wherein: The deployment system further includes: The service optimization subsystem is used to implement communication and task coordination between different microservice instances.

12. The system according to claim 9, wherein: The system further comprises: The local fault-tolerant subsystem is configured to allocate resources to subtasks with a priority higher than the first priority and put subtasks with a priority lower than the second priority into a dormant state when a network interruption of the smart home system is detected.

13. An electronic device, characterized in that: The method comprises a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein when the computer program is executed by the processor, the method for deploying a microservice instance according to any one of claims 1 to 8 is implemented.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for deploying a microservice instance according to any one of claims 1 to 8 is implemented.

Images