A Microservice Architecture Method and System for Industrial Internet Platforms Based on Cloud-Edge Collaboration

Abstract

This application relates to the field of internet platform architecture technology, and discloses a method and system for a microservice architecture of an industrial internet platform based on cloud-edge collaboration. The method includes: constructing a control link time-limit tensor and a microservice interlocking adjacency graph; obtaining resource status data of each computing node within the control cycle and calculating the real-time carrying capacity matrix of each computing node; generating a time-limit violation composite penalty function; performing deterministic priority dynamic routing for computing instances of different business types, deploying the computing instances to edge computing nodes or cloud computing nodes for operation; performing end-to-end worst-case latency simulation verification on the routing plan of the computing instances, and obtaining the simulation verification results; triggering a security degradation strategy or a fault self-healing strategy, and updating the parameters of the time-limit violation composite penalty function. This application improves the end-to-end latency determinism and system operational reliability of the control link on the industrial internet platform.

Description

Technical Field

[0001] This application relates to the field of Internet platform architecture technology, and in particular to a microservice architecture method and system for an industrial Internet platform based on cloud-edge collaboration. Background Technology

[0002] As the core hub connecting underlying devices and upper-layer applications, the Industrial Internet platform needs to simultaneously support multiple services with significantly different real-time requirements, such as control loops, protocol conversion, AI inference, and data uploading, on limited computing resources. Traditional solutions employ monolithic or fixed-partition deployment architectures, statically binding each service module to specific computing nodes. This fails to dynamically allocate resources based on load changes, resulting in uneven node load and low resource utilization. As the number of controlled devices and the complexity of control loops increase, static deployment architectures struggle to complete end-to-end responses within control deadlines. The lack of priority mechanisms when critical and non-critical services compete for resources on the same node easily leads to deadline breaches and even cascading timeouts. Furthermore, when a node fails, statically bound service instances cannot automatically migrate and recover, causing control link interruptions requiring manual intervention, resulting in long recovery times and high maintenance costs. Summary of the Invention

[0003] To address the aforementioned technical issues, this application provides a cloud-edge collaborative industrial internet platform microservice architecture method and system, which enables the coexistence and operation of multiple microservices with vastly different real-time requirements on a resource-constrained cloud-edge collaborative platform, ensuring that critical control services are never overwhelmed by non-critical services and thus do not time out.

[0004] Firstly, this application provides a microservice architecture method for an industrial internet platform based on cloud-edge collaboration. The method is applied to an industrial internet platform that includes edge computing nodes and cloud computing nodes. The industrial internet platform deploys various types of computing instances in a containerized microservice format and manages them uniformly through a service registry. The method includes: Obtain the operating parameters and network status data of the controlled devices in the industrial internet platform, and construct a control link time limit tensor and a microservice interlock adjacency graph; Obtain resource status data of each computing node within the control period, and calculate the real-time load margin matrix of each computing node; Based on the control link time limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix, a time limit violation composite penalty function is generated; Based on the time-limited default composite penalty function, deterministic priority dynamic routing is performed on computing instances of different business types, and the computing instances are deployed to the edge computing node or the cloud computing node for operation; The routing plan of the computation instance is subjected to end-to-end worst-case latency simulation verification to obtain the simulation verification results; Based on the simulation verification results or the fault status of the target computing node, a security degradation strategy or a fault self-healing strategy is triggered, and system status feedback data after the strategy execution is obtained to update the parameters of the time-limited default composite penalty function.

[0005] Secondly, this application provides a cloud-edge collaborative industrial internet platform microservice architecture system, the system comprising: The data modeling unit is used to acquire the operating parameters and network status data of the controlled devices in the industrial internet platform, and to construct the control link time limit tensor and microservice interlock adjacency graph. The resource monitoring unit is used to acquire resource status data of each computing node during the control period and calculate the real-time load margin matrix of each computing node. The penalty generation unit is used to generate a time-limit violation composite penalty function based on the control link time-limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix. The dynamic routing unit is used to perform deterministic priority dynamic routing of computing instances of different business types according to the time-limited default composite penalty function, and deploy the computing instances to the edge computing node or the cloud computing node for operation; The simulation verification unit is used to perform end-to-end worst-case latency simulation verification on the routing plan of the computation instance and obtain the simulation verification result. The execution feedback unit is used to trigger a security degradation strategy or a fault self-healing strategy based on the simulation verification results or the fault status of the target computing node, and to obtain system status feedback data after the strategy execution to update the parameters of the time-limited default composite penalty function.

[0006] Compared with the prior art, the beneficial effects of the present invention are at least as follows: First, by using a control link time-limit tensor and a microservice interlock adjacency graph, device time-limit constraints and microservice call dependencies are formalized into structured data. Subsequent scheduling can then efficiently query via array indexing and graph traversal, eliminating the performance bottleneck of searching parameter tables one by one. A penalty function generation model integrates the target control deadline, dependency weight values, and target capacity margin values ​​into a single quantitative indicator, transforming scheduling decisions from qualitative judgments to quantitative optimizations, allowing for precise comparison of default risks across different combinations. Then, a deterministic priority dynamic routing mechanism assigns decreasing business type weight coefficients to four types of microservice instances, ensuring that critical control services receive resources deterministically under any load, and compensating for historical default instances through a dynamic priority boosting mechanism. Finally, an end-to-end latency simulation model of the control link decomposes the control link into five latency sub-modules and injects worst-case parameter verification. During the implementation of routing schemes, default risks are identified, and security degradation or fault self-healing strategies are triggered in a timely manner for correction, achieving a shift from static scheduling to dynamic adaptive control. Finally, a security degradation strategy is implemented to release non-critical business resources in stages when latency exceeds limits, and a fault self-healing strategy is implemented to automatically migrate and recover affected instances based on an interlocked adjacency graph when a node fails, ensuring continuous system operation without manual intervention. A closed-loop feedback mechanism adjusts the weight coefficients of the penalty function generation model after strategy execution, enabling continuous optimization of scheduling decisions throughout the control cycle and adapting to changes in operating conditions. Attached Figure Description

[0007] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a flowchart illustrating a cloud-edge collaborative industrial internet platform microservice architecture method in an embodiment of this application. Figure 2 This is a timeline diagram illustrating a typical fault self-healing process according to an embodiment of this application. Figure 3 This is a schematic diagram of a cloud-edge collaborative industrial internet platform microservice architecture system according to an embodiment of this application. Detailed Implementation

[0009] This application provides a method and system for a cloud-edge collaborative industrial internet platform microservice architecture. The terms "first," "second," "third," "fourth," etc. (if present)," in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0010] For ease of understanding, the specific process of the embodiments of this application is described below. A microservice architecture method for an industrial internet platform based on cloud-edge collaboration is applied to an industrial internet platform that includes edge computing nodes and cloud computing nodes. The industrial internet platform deploys various types of computing instances in the form of containerized microservices and manages them uniformly through a service registry. Please refer to [link to relevant documentation]. Figure 1 One embodiment of a cloud-edge collaborative industrial internet platform microservice architecture method in this application includes: Step S1: Obtain the operating parameters and network status data of the controlled devices in the industrial internet platform, and construct the control link time limit tensor and microservice interlock adjacency graph.

[0011] Furthermore, a control link time-limit tensor and a microservice interlock adjacency graph are constructed, including: Obtain the device number, sampling period, control cutoff time limit, and link delay data to the edge computing node of the controlled device. Organize the sampling period, control cutoff time limit, and link delay data into a control link delay tensor with device number, time step, and time limit type as three dimensions.

[0012] Query the call chain information between computing instances. Construct a microservice interlocked adjacency graph with computing instances as nodes, call chain information as directed edges, and at least one of call frequency and dependency tightness as edge weights. When there is a transitive call path from the first computing instance through the second computing instance to the third computing instance, accumulate the weights of each edge along the transitive call path to obtain the transitive dependency weight.

[0013] Specifically, in a cloud-edge collaborative industrial internet platform, controlled devices include sensors, actuators, controllers, and equipment such as CNC machine tools, robotic arms, and conveyor belts on the production line. These devices continuously generate operational parameter data (such as physical quantities like temperature, pressure, speed, and position) and network status data (such as communication link latency, packet loss rate, and bandwidth usage). A data acquisition module is deployed on the device side, periodically reading device register values ​​to obtain operational parameters using standard industrial protocols (such as OPC UA and Modbus). A network monitoring agent is deployed at network nodes, calculating end-to-end latency by recording the sending and receiving timestamps of data packets, and statistically analyzing packet loss rate and bandwidth usage within a time window to obtain network status data. After acquiring the above operational parameters and network status data, the system constructs a control link time constraint tensor and a microservice interlocking adjacency graph, unifying heterogeneous time constraint information and microservice call dependencies into structured data that can be directly queried and calculated for subsequent scheduling decisions.

[0014] The process of constructing the control link time limit tensor is as follows: For each controlled device, obtain its device number (i.e., the unique identifier of the device in the industrial internet platform), sampling period (i.e., the time interval between the device acquiring data or executing control actions), control cutoff time limit (i.e., the maximum allowable time from the start of data acquisition to the control command reaching the actuator; exceeding this time limit will lead to control failure), and link delay data from the controlled device to the edge computing node. The limitation to "to the edge computing node" rather than "to the cloud computing node" is because the controlled device communicates directly with the edge computing node via fieldbus or industrial Ethernet. Link delay is the physical transmission delay from the device to the edge node, while there is no direct link between the controlled device and the cloud node, and its delay cannot be directly measured. After obtaining the above four types of data, the sampling period, control cutoff time limit, and link delay data are organized into a control link time limit tensor, with the device number as the first dimension, the time step as the second dimension, and the time limit type as the third dimension. The control link time limit tensor is essentially a three-dimensional array. Each slice of the first dimension corresponds to a controlled device. The second dimension records the parameter changes of that device at different time steps. The third dimension stores time limit types such as sampling period, control cutoff time, and link delay. This allows subsequent scheduling processes to efficiently query any device's time limit parameters at any time using array indexes, without needing to search the device parameter table one by one. The control link time limit tensor supports dynamic updates; when the sampling period or control cutoff time of a device changes with production task adjustments, the corresponding element in the tensor is updated accordingly.

[0015] The process of constructing a microservice interlocked adjacency graph is as follows: Query the call chain information between each computing instance on the platform (i.e., the actual remote call records between microservice instances, including the caller, callee, and call frequency). Treat each computing instance as a node in the graph, and the call chain information as directed edges (the direction of the edges points from the callee to the caller, indicating that the caller depends on the output of the callee). Use at least one of call frequency and dependency tightness as the original edge weight, and normalize the original edge weights so that their values ​​are within the range of zero to one. Use the normalized values ​​as the edge weights to construct the microservice interlocked adjacency graph. Call frequency refers to the number of calls between two computing instances per unit time. A higher call frequency indicates more frequent data interaction and a tighter dependency relationship between the two. Dependency tightness is a quantitative indicator derived from a comprehensive evaluation of the response time requirements of the call chain and the impact of call failures on the overall system functionality. The stricter the response time requirements or the greater the impact of call failures, the higher the tightness. The larger the edge weight, the more significant the impact of the dependency relationship on the overall real-time performance of the system. The normalization process is as follows: when the call frequency is used as the original edge weight, the call frequency is divided by the maximum call frequency among all call chains on the platform to obtain the normalized edge weight; when the dependency tightness is used as the original edge weight, the dependency tightness is divided by the maximum score of the evaluation scale to obtain the normalized edge weight. The normalized edge weights are located in the range of zero to one. The closer the value is to one, the tighter the dependency relationship; the closer the value is to zero, the looser the dependency relationship. This ensures that the subsequent multiplication and accumulation calculation of transitive dependency weights have consistent dimensions and comparable numerical ranges. In the microservice interlocked adjacency graph, when there is a transitive call path from the first computing instance through the second computing instance to the third computing instance (i.e., the first computing instance indirectly depends on the output of the third computing instance), the weights of each edge along this transitive call path are accumulated to obtain the transitive dependency weight between the first computing instance and the third computing instance. The cumulative calculation of transitive dependency weights can be achieved by multiplying the weights of each edge on the path (a smaller product indicates a more fragile path and a greater likelihood of amplifying the impact of indirect dependencies) or by taking the minimum value of the weights of each edge on the path (the minimum value reflects the weakest link in the transitive path). By identifying and quantifying transitive dependencies, the microservice interlocking adjacency graph not only represents the direct call dependencies between computing instances but also depicts the cumulative effect of dependencies propagating downstream along the call chain. This allows subsequent scheduling processes to simultaneously evaluate the status of all upstream dependent instances when allocating nodes to a computing instance, avoiding cascading timeouts caused by downstream instances waiting due to upstream instance delays.

[0016] Step S2: Obtain the resource status data of each computing node within the control period, and calculate the real-time load margin matrix of each computing node.

[0017] Further, the real-time load margin matrix of each computing node is calculated, including: At the beginning of each control cycle, the CPU allocation data, memory allocation data, and network bandwidth allocation data of each computing node are collected and determined as the amount of resources occupied by each computing node. The amount of resources occupied includes the resources allocated to running container instances and the resources reserved for critical business operations.

[0018] Calculate the difference between the total resource capacity and the occupied resource amount of each compute node. Organize the difference into a real-time capacity reserve matrix using compute node identifier as the row index and resource type as the column index. When a compute instance is deployed to a target compute node, the container resource quota of the compute instance is deducted from the real-time capacity reserve matrix accordingly.

[0019] Specifically, in a cloud-edge collaborative industrial internet platform, computing nodes include edge computing nodes and cloud computing nodes. Edge computing nodes are deployed close to the controlled devices and are responsible for handling control tasks with high real-time requirements; cloud computing nodes are deployed in data centers and are responsible for handling computationally intensive tasks. Each computing node has certain computing resources, including a central processing unit, memory, and network bandwidth. The control cycle refers to the time required for the industrial control system to execute one complete control loop (from data acquisition to command issuance), and its length is usually aligned with the device with the shortest sampling period among the controlled devices. At the beginning of each control cycle, the system needs to understand the resource usage of each computing node to provide accurate resource availability information for subsequent microservice instance scheduling decisions. Therefore, it is necessary to collect resource status data and calculate a real-time capacity margin matrix.

[0020] At the start of each control cycle, the system collects allocated data for the CPU, memory, and network bandwidth of each compute node. "Allocated data" is used instead of "occupied data" because resource management needs to distinguish between "allocated but not yet used" and "being consumed." In a containerized deployment environment, compute instances run as containers. The container orchestration system allocates specific resource quotas (such as the number of CPU cores and memory limits) to each container instance, while reserving additional resource quotas for critical services (such as security interlock control loops) to ensure sufficient computing power under burst loads. These allocated quotas, regardless of whether they are actually consumed by container instances, cannot be reassigned to other instances. Therefore, "allocated data" encompasses both resources allocated to running container instances and resources reserved for critical services. These three types of allocated data are defined as the occupied resource amount of each compute node, reflecting the total amount of resources on the node that have been designated for specific uses and cannot be used for new scheduling.

[0021] After obtaining the occupied resource amount, the difference between the total resource capacity of each computing node (i.e., all available resources configured for the node, including the total number of CPU cores, total memory capacity, and total network bandwidth) and the occupied resource amount is calculated. This difference represents the remaining resources that the node can currently use to support new computing instances. Using the computing node identifier as the row index (each row corresponds to one edge computing node or cloud computing node) and the resource type as the column index (each column corresponds to resource dimensions such as CPU, memory, and network bandwidth), the above differences are organized into a real-time capacity reserve matrix. The real-time capacity reserve matrix is ​​essentially a two-dimensional table, where the element in the i-th row and j-th column represents the remaining available capacity of the i-th computing node in the j-th resource dimension. By organizing the capacity reserve data in matrix form, the subsequent scheduling process can efficiently query the available capacity of any node in any resource dimension through row and column indices in batches, and supports matrix operations to achieve joint evaluation of multiple nodes and multiple resource dimensions.

[0022] After a compute instance is deployed to a target compute node via routing decisions, the container resource quota of that compute instance (i.e., the number of CPU cores, memory size, and bandwidth limit allocated to the instance by the container orchestration system) needs to be deducted accordingly from the real-time capacity reserve matrix. In the row corresponding to the target compute node, the amount of various resources occupied by the instance is subtracted from the corresponding column elements to ensure that the matrix always reflects the latest resource availability status. This avoids subsequent scheduling decisions from allocating too many instances to the same node based on outdated capacity reserve data, which could lead to resource overload.

[0023] Step S3: Generate a time-limited default composite penalty function based on the control link time-limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix.

[0024] Furthermore, a time-limited default compound penalty function is generated, including: For each compute instance to be scheduled, the target control deadline of the controlled device associated with the compute instance is extracted from the control link time limit tensor, the dependency weight value between the compute instance and other compute instances is extracted from the microservice interlock adjacency graph, and the target load margin value of the candidate compute node is extracted from the real-time load margin matrix.

[0025] The target control deadline, dependency weight value, and target carrying capacity value are input into a pre-established penalty function generation model for weighted calculation. The corresponding penalty function value for scheduling the computing instance to the candidate computing node is output. The combination of all computing instances to be scheduled and all candidate computing nodes is traversed to generate a time limit default composite penalty function.

[0026] Specifically, after constructing the control link time limit tensor, the microservice interlock adjacency graph, and the real-time load margin matrix, the system has mastered the time limit constraint information of controlled devices, the call dependencies between computing instances, and the resource availability status of each computing node. However, these three types of data belong to different dimensions and units, and cannot be directly used to compare the merits of different scheduling schemes. Therefore, they need to be unified into a single quantitative indicator, namely the time limit default composite penalty function. Time limit default refers to the situation where a computing instance fails to complete the calculation and return the result within the specified control deadline. Once this occurs, it may lead to delayed control commands, interlocking logic failure, or even security incidents. The purpose of the time limit default composite penalty function is to calculate a penalty function value for each combination scheme of "scheduling a computing instance to a candidate computing node". The smaller the value, the lower the risk of time limit default and the better the scheduling scheme under that scheme, and vice versa. The subsequent scheduling process will sort different combination schemes based on this penalty function value and select the scheme with the smallest penalty value for routing.

[0027] For each compute instance to be scheduled, the system needs to extract the corresponding feature parameters from three types of pre-constructed data structures. First, the target control deadlines of the controlled devices associated with the compute instance are extracted from the control link time limit tensor. Each compute instance is responsible for handling the control tasks of one or more controlled devices, and its target control deadline is determined by the control deadlines of the associated devices. If multiple devices are associated, the most stringent deadline is taken as the target control deadline. The shorter the target control deadline, the more stringent the timeliness requirements of the instance, and the greater the risk of default when scheduled to a resource-constrained node. Therefore, the target control deadline is the input dimension reflecting the urgency of the time limit in the penalty function. Second, the dependency weight values ​​between the compute instance and other compute instances are extracted from the microservice interlocking adjacency graph. The dependency weight value reflects the degree of dependence of the instance on the output results of other instances. The larger the weight value, the more the timely completion of the instance depends not only on its own computing resources but also on the timely completion of upstream dependent instances. If the upstream instance is delayed, the instance faces the risk of cascading waiting. Therefore, the dependency weight value is the input dimension reflecting the dependency risk in the penalty function. Finally, the target capacity margin value of the candidate computing nodes is extracted from the real-time capacity margin matrix, which represents the remaining available resources of the candidate node in terms of CPU, memory, network bandwidth, etc. The smaller the capacity margin, the more strained the node's resources are. Newly scheduled instances to this node may be queued for execution due to resource contention, increasing the probability of time-limit default. Therefore, the target capacity margin value is an input dimension reflecting resource sufficiency in the penalty function.

[0028] The three types of feature parameters (target control deadline, dependency weight value, and target capacity margin value) are used as input data and weighted by a pre-established penalty function generation model. Since the dimensions and numerical ranges of the three types of feature parameters are inconsistent—the target control deadline is a millisecond-level time quantity, the dependency weight value is a dimensionless normalized value, and the target capacity margin value represents resources such as CPU cores, memory capacity, or bandwidth—directly performing a weighted sum would cause the parameter with the largest numerical range to suppress the contribution of other parameters, rendering the weight coefficients meaningless. Therefore, before inputting them into the penalty function generation model, the three types of feature parameters need to be normalized separately. The normalization method for the target control deadline is as follows: subtract the minimum control deadline value of all controlled devices on the platform from the current target control deadline, and then divide by the difference between the maximum and minimum control deadline values ​​to obtain a normalized deadline value within the range of zero to one. The dependency weight value has already been limited to the range of zero to one by the normalization process during the microservice interlock adjacency graph construction process and does not require secondary normalization. The normalization method for the target capacity margin is as follows: divide the target capacity margin of the current candidate node by the total capacity of the resource type to obtain the normalized capacity margin, which takes a value between zero and one. After normalization, all three types of parameters take values ​​between zero and one, have consistent dimensions and comparable numerical ranges, and enable the subsequent weighting coefficients to effectively adjust the relative contributions of each dimension.

[0029] The penalty function generation model is the core model in this application used to fuse multi-dimensional heterogeneous scheduling constraint parameters into a single quantitative index. Its input data consists of the normalized target control deadline, dependency weight value, and target carrying capacity margin value, and the output data is the penalty function value for scheduling the computation instance to the candidate computation node. The penalty function generation model needs to be pre-established before the online scheduling process starts. Its establishment process includes the following steps: First, extract scheduling records of multiple historical control cycles from the historical operation database of the industrial internet platform as a training sample set. Each training sample contains three types of input feature parameters from a historical scheduling event (the normalized target control deadline, dependency weight value, and normalized target carrying capacity margin value of the candidate node in this scheduling) and the actual default penalty value of this scheduling. The actual penalty value for default is a continuous value calculated based on the actual execution results of the historical scheduling: If the computational instance completes on time in this scheduling, the safety margin is calculated based on the ratio of the difference between its end-to-end delay and the control deadline to the control deadline; the larger the safety margin, the lower the actual penalty value for default. If the computational instance defaults on the deadline in this scheduling, the cost of default is calculated based on the ratio of the timeout duration to the control deadline and whether the default triggers downstream cascading delays; the longer the timeout or the greater the cascading impact, the higher the actual penalty value for default. The actual penalty value also falls within the range of zero to one, having the same numerical range and physical meaning as the predicted penalty function value. Then, initial weight coefficients are set for the three types of input feature parameters, and the sign constraints of the weight coefficients are determined. The weight coefficient corresponding to the target control deadline is positive (the tighter the deadline, the higher the risk of default, and the greater the penalty should be). The weight coefficient corresponding to the dependency weight value is positive (the stronger the dependency, the more severe the consequences of default, and the greater the penalty should be). The weight coefficient corresponding to the target carrying capacity margin value is negative (the more abundant the margin, the lower the risk of default, and the smaller the penalty should be). The specific values ​​of the initial weight coefficients can be initialized using equal weights or set with prior values ​​based on domain experience. Subsequently, the weight coefficients are iteratively optimized using the training sample set: in each iteration, the three types of feature parameters in the training sample are weighted and calculated with the current weight coefficients to obtain the predicted penalty function value. The loss function value is calculated based on the mean square error between the predicted penalty function value and the actual default penalty value. The weight coefficients are updated according to the gradient descent direction to reduce the mean square error. This iteration is repeated until the loss function value converges to below the preset threshold or reaches the maximum number of iterations. After training, the converged weight coefficients are fixed as the model parameters of the penalty function generation model, so that the penalty function value can be output in real time for any new combination of feature parameters in the subsequent online scheduling process.

[0030] The working principle of the penalty function generation model is to assign weight coefficients obtained during training to each input parameter and then perform linear or nonlinear combination calculations: In the linear weighting method, the penalty function value is equal to the sum of the products of each input parameter and its corresponding weight coefficient. The sign settings of the three types of coefficients allow the penalty function value to simultaneously reflect the joint impact of the three dimensions of "time urgency," "dependency risk," and "resource adequacy" on default risk. In the nonlinear combination method, cross terms or exponential transformation terms between input parameters can be introduced on the basis of linear weighted sums to capture the interaction effects between different factors. After the initial values ​​of the aforementioned weight coefficients are determined during the model pre-training stage, they can also be dynamically adjusted in subsequent closed-loop feedback based on the strategy execution effect, enabling the model to continuously adapt to changes in working conditions.

[0031] After performing the weighted calculation on a single computing instance and a single candidate computing node combination, the penalty function value for that combination is obtained. Subsequently, the process of feature parameter extraction and weighted calculation is repeated for each combination, iterating through all combinations of computing instances to be scheduled and all candidate computing nodes. The penalty function values ​​of all combinations are then aggregated to generate the time-limit default composite penalty function. This function is essentially a mapping relationship with the "computing instance-candidate computing node" combination as the independent variable and the penalty function value as the dependent variable. Subsequent scheduling processes can directly compare the merits of any combination by querying this function, thus transforming scheduling decisions from qualitative judgment to quantitative optimization.

[0032] Step S4: Based on the time-limited default compound penalty function, perform deterministic priority dynamic routing of computing instances of different business types, and deploy the computing instances to edge computing nodes or cloud computing nodes for operation.

[0033] Furthermore, deterministic priority dynamic routing is performed, including: Based on the business attribute identifiers of the computing instances, the computing instances are divided into control closed-loop microservice instances, inference microservice instances, protocol conversion microservice instances, and cloud upload microservice instances. The priority values ​​of each type of microservice instance are calculated based on the time-limited default composite penalty function. Among them, the control closed-loop microservice instance corresponds to the highest business type weight coefficient, and the cloud upload microservice instance corresponds to the lowest business type weight coefficient. When any computing instance fails to complete on time in the previous control period, the priority value of the corresponding computing instance in the current control period is increased.

[0034] Based on the priority values ​​from high to low, and combined with the resource reserves of each computing node in the real-time load margin matrix and the dependency order in the microservice interlock adjacency graph, target computing nodes are allocated to each type of microservice instance in turn. The corresponding container images are pulled from the container image repository and the container is instantiated and started on the target computing node. The access address and running status of the computing instance are registered to the service registry center.

[0035] Furthermore, after registering the access address and running status of the computing instance to the service registry, it also includes: The system acquires operational status data of the message middleware in the industrial internet platform. Compute instances utilize the message middleware's publish-subscribe mechanism to achieve cross-node data flow. Cloud-based microservice instances subscribe to message topics on the edge side, aggregate them according to a preset upload batch size, and then upload them to the cloud big data center. Based on the message middleware's queue backlog depth, message production rate, and message consumption rate, a target consumption rate is calculated. The target number of replicas for the compute instances is determined based on the ratio of the target consumption rate to the single-instance consumption rate. The preset upload batch size is adjusted according to the queue backlog depth. The compute instances are elastically scaled up or down based on the target number of replicas, and the access addresses of the scaled-up instances are updated through the service registry.

[0036] Specifically, in step S3, the system has generated a time-limit default composite penalty function for all combinations of "computation instances - candidate computing nodes" using a penalty function generation model. This function provides a basis for quantitatively evaluating the merits of different scheduling schemes. However, computing instances on the industrial internet platform undertake business tasks with diverse functions and vastly different real-time requirements. Directly sorting all instances uniformly based on the penalty function value would lead to critical control business and non-critical data business competing for resources at the same level, failing to guarantee the fundamental requirement of deterministic real-time response for the industrial control system. Therefore, this step introduces a deterministic priority dynamic routing mechanism, which superimposes the inherent priority level of business type and a dynamic adjustment strategy based on historical performance on the basis of the quantitative evaluation of the penalty function. This ensures that critical control closed-loop business receives priority computing resources under any load conditions, while also ensuring the normal operation of non-critical business.

[0037] Specifically, the first step in deterministic priority dynamic routing is the classification of computing instances by business type. The system obtains the business attribute identifier of each computing instance (i.e., metadata attached to the computing instance, describing the instance's business functions and real-time requirements). Based on the business type field in the business attribute identifier, all computing instances are classified into four categories: control closed-loop microservice instances (microservice instances that directly participate in the closed-loop control of controlled equipment, responsible for completing the complete loop of data acquisition, control algorithm calculation, and command issuance in a very short time, with the most stringent real-time requirements), inference microservice instances (microservice instances that perform machine learning inference tasks, such as defect detection based on visual images or fault prediction based on sensor data, with secondary real-time requirements but higher computing resource requirements), protocol conversion microservice instances (microservice instances responsible for data format conversion between different industrial protocols, such as converting Modbus protocol data to OPC UA standard format, mainly ensuring data format compatibility), and cloud upload microservice instances (microservice instances that upload edge-side aggregated data to the cloud big data center, with the lowest real-time requirements, mainly focusing on the reliability and integrity of data transmission).

[0038] After the partitioning is completed, the system calculates the priority value of each type of microservice instance based on the time-limited default penalty function. Since the time-limited default penalty function in step S3 is calculated separately for each "computation instance - candidate computation node" combination, the same computation instance has multiple penalty function values ​​when facing multiple candidate computation nodes. Therefore, it is necessary to select the minimum value from all penalty function values ​​of the instance as the optimal solution penalty value for that instance. This minimum value reflects the default risk of the optimal scheduling solution that the instance can obtain under the current resource conditions. The smaller the value, the more likely it is that there is at least one node that can allow the instance to run with extremely low risk, indicating a relatively low urgency. Conversely, if the minimum value is still large, it means that even selecting the optimal node cannot effectively reduce the default risk, and the scheduling urgency of the instance is higher. The priority value is calculated as follows: the negative of the optimal solution penalty value of the instance is used as the base score (the smaller the penalty value, the lower the default risk and the better the solution; the higher the base score after negative calculation), and then multiplied by the business type weight coefficient corresponding to the business type to which the instance belongs. The business type weight coefficient is a pre-set value reflecting the inherent importance of various business types. The control loop microservice instance corresponds to the highest business type weight coefficient because it is directly related to industrial safety and product quality; the cloud upload microservice instance corresponds to the lowest business type weight coefficient because it does not directly affect the real-time performance of the control process; the weight coefficients of the inference microservice instance and the protocol conversion microservice instance are in between. By setting the business type weight coefficient in descending order, the priority of the control loop instance is always higher than that of other types of instances at the same penalty function value level, thus obtaining deterministic guarantees in resource competition. Based on this, the system also introduces a dynamic priority boosting mechanism: when any computing instance fails to complete on time in the previous control cycle, a time limit breach occurs, and the system boosts the priority value of that instance in the current control cycle to compensate for the impact of the previous cycle's delay on the control process and prevent continuous breaches from causing a continuous deterioration of the system state. This dual priority strategy of "static business type weight + dynamic historical performance adjustment" allows the priority value to reflect both the inherent importance of the business and adapt to the real-time operating status of the system.

[0039] After calculating the priority values ​​of all instances, the system allocates target compute nodes to each type of microservice instance in descending order of priority value, taking into account the resource availability of each compute node in the real-time capacity reserve matrix and the dependency order in the microservice interlock adjacency graph. "Taking into account the real-time capacity reserve matrix" means that when selecting a target compute node, the system checks whether the resource availability of candidate nodes in the matrix meets the container resource quota requirements of the instance to be scheduled. If the availability is insufficient, the node is skipped, and other candidate nodes are considered. "Taking into account the dependency order in the microservice interlock adjacency graph" means that when allocating nodes, the system follows the call topology defined by the dependency graph, ensuring that upstream instances that are depended upon are deployed and started before downstream instances that depend on them, preventing downstream instances from idling while waiting for upstream data. After determining the target compute node for each instance, the system performs containerized deployment: It pulls the corresponding container image from the container image repository (a centralized repository storing container images of all microservice instances), which contains standardized software packages including the microservice runtime code and its dependencies. On the target compute node, it instantiates and starts the container, creating and running an independent container process based on the container image. Then, it registers the access address of this compute instance—the network address used by other instances or clients to access the instance's service interface—with its running status (currently running, starting, or experiencing an error) to the service registry. The service registry is a core infrastructure component in the microservice architecture, maintaining a real-time mapping between the access addresses and running status of all microservice instances. Other instances can discover and call target instances by querying the service registry without hardcoding network addresses. When an instance migrates or scales up / down, causing a change in the access address, the record in the service registry is updated accordingly. Downstream dependent instances can obtain the latest access address by subscribing or actively querying, thus achieving automatic maintenance of service call relationships.

[0040] After registering the access address and running status of the computing instances to the service registry, the system also obtains the running status data of the message middleware in the industrial internet platform to elastically scale the computing instances. The message middleware is a core component in microservice architecture that enables asynchronous decoupling between services. It provides a publish-subscribe mechanism, where computing instances act as publishers, publishing data to specific message topics—the logical classification channels for messages. Other computing instances that subscribe to these topics automatically receive messages under those topics. Through this mechanism, cross-node data flow can be achieved without directly establishing point-to-point connections between computing instances, reducing the coupling between services. In the industrial internet platform, cloud-based microservice instances subscribe to message topics on the edge side, receiving collected data and processing results published by various instances on edge computing nodes. Multiple messages are aggregated and uploaded to the cloud big data center in batches according to a preset batch size—the number of messages aggregated in each upload operation—to reduce network connection frequency and transmission overhead. The system acquires runtime status data from the message middleware, including queue backlog depth (the number of messages not yet consumed; a deeper backlog indicates the consumption rate is lagging behind the production rate), message production rate (the number of new messages generated per unit time), and message consumption rate (the number of messages consumed per unit time). Based on these three metrics, the target consumption rate—the desired message consumption rate—is calculated to gradually reduce the queue backlog within an acceptable range. The ratio of the target consumption rate to the single-instance consumption rate of a single compute instance is then determined as the target number of replicas. The single-instance consumption rate is the number of messages a single instance can consume per unit time under normal load, and the target number of replicas refers to the number of consumer instances needed to reach the target consumption rate. Simultaneously, the preset upload batch size for cloud-based microservice instances is adjusted based on the queue backlog depth. Larger batch sizes are used to accelerate processing when the backlog is deep, while regular batch sizes are restored when the backlog is shallow to reduce the amount of data transmitted per transmission. After determining the target number of replicas and the adjusted upload batch size, the system elastically scales up and down the compute instances based on the target number of replicas. If the current number of running replicas is less than the target, new replicas are added; if it is more than the target, redundant replicas are reduced. After scaling up and down, the access addresses of newly added instances are registered with the service registry or the addresses of instances to be removed are deregistered from the service registry to ensure that the service registry always reflects the latest instance topology status.

[0041] Step S5: Perform end-to-end worst-case latency simulation verification on the routing plan of the computation instance to obtain the simulation verification results.

[0042] Furthermore, the simulation verification results are obtained, including: Obtain the container deployment plan and container migration plan of the compute instance on the target compute node to generate a routing plan. The routing plan includes the container startup sequence of each compute instance, and the container startup sequence satisfies the call dependency relationship defined by the microservice interlock adjacency graph.

[0043] Based on the routing plan, an end-to-end latency simulation model of the control chain is constructed. The end-to-end latency simulation model of the control chain includes a data acquisition latency submodule, a network transmission latency submodule, a container scheduling latency submodule, a data waiting latency submodule, and an instruction issuance latency submodule. The latency parameters of each submodule are determined according to the load status of the corresponding computing node in the real-time load margin matrix.

[0044] Inject worst-case parameters into the end-to-end delay simulation model of the control chain, set the delay value of each sub-module to its upper limit under maximum load conditions, and sum them to obtain the end-to-end delay value of the calculation instance under worst-case conditions, which is used as the simulation verification result.

[0045] Specifically, in step S4, the system has allocated all computing instances to target computing nodes and completed containerized deployment through a deterministic priority dynamic routing mechanism. However, the penalty function value upon which the routing decision relies is a static evaluation calculated based on the current resource snapshot and time limit parameters, without considering the cumulative impact of dynamic factors such as container startup order, cross-node data transmission contention, and node load fluctuations on the actual end-to-end latency. Industrial control scenarios require control commands to reach the actuators within strict deadlines, and the order of penalty function values ​​alone cannot provide a deterministic latency guarantee. Therefore, this step performs end-to-end worst-case latency simulation verification on the generated routing plan. By constructing a latency simulation model covering the entire control link process and injecting worst-case operating parameters into it, the system verifies whether the routing plan can still meet the time limit constraints under the most unfavorable conditions, thereby identifying and eliminating schemes with default risks before the actual execution of the scheduling scheme.

[0046] The first step in end-to-end worst-case latency simulation verification is to obtain complete information about the routing plan. The system obtains the container deployment plan and container migration plan for each compute instance on the target compute node. The container deployment plan describes which target compute node each compute instance's container image will be deployed to, how much resource quota will be allocated, and in what order it will be started. The container migration plan describes instances that need to be migrated from the original node to a new node due to insufficient resources or node failure, and their migration sequence. A routing plan is generated based on the container deployment plan and container migration plan. This routing plan is a complete scheduling scheme for the deployment, migration, and operation of all compute instances on the platform, which includes the container startup sequence of each compute instance. The container startup sequence refers to the time arrangement of each container instance completing initialization and entering the ready state in sequence. This sequence must satisfy the call dependency relationship defined by the microservice interlocking adjacency graph, that is, the upstream instance that is depended on must start before the downstream instance that depends on it. If a downstream instance starts before its upstream data source is ready, it will be in an idle waiting state, which not only wastes computing resources, but may also be judged as abnormal by the container orchestration system due to initialization timeout and trigger a restart loop, further increasing the system load.

[0047] After obtaining the routing plan, the system constructs an end-to-end delay simulation model of the control chain based on the routing plan. This end-to-end delay simulation model is a simulation calculation model used in this application to simulate the delay of each link in the complete transmission path of control commands from the data acquisition end to the actuator end. Its input data includes the deployment location of each computing instance in the routing plan, the container startup sequence, and the load status parameters of the corresponding computing nodes in the real-time load margin matrix. The output data is the end-to-end delay value of each computing instance under the worst-case scenario. The working principle of this model is to decompose the entire process of the control link from data generation to command execution into five cascaded delay links. Each link is modeled by a delay sub-module, and then the delay values ​​of the five sub-modules are summed to obtain the total end-to-end delay. The five latency sub-modules are as follows: Data acquisition latency sub-module, which simulates the time required for a sensor to convert a physical quantity into a digital signal and write it to the data buffer; its latency parameter is affected by the device's sampling accuracy and the characteristics of the signal conditioning circuit. Network transmission latency sub-module, which simulates the time required for data to be transmitted from the edge computing node to the target computing node or across nodes; its latency parameter is affected by link bandwidth, routing hop count, and network congestion. Container scheduling latency sub-module, which simulates the time required for a container orchestration system to allocate computing tasks to container instances, load the runtime environment, and trigger computation; its latency parameter is affected by the container image size, the number of concurrent containers on the node, and the CPU scheduling strategy. Data waiting latency sub-module, which simulates the time required for a computing instance to queue in a message queue while waiting for output data from upstream dependent instances; its latency parameter is affected by the processing speed of the upstream instance and the number of messages at the front of the queue. Command issuance latency sub-module, which simulates the time required for control commands to be transmitted from the computing node to the actuator and received by the actuator; its latency parameter is affected by the command message size and the response speed of the actuator-side communication interface.

[0048] The delay parameters of each submodule are not fixed values, but are determined by calibration based on the load status parameters of the corresponding computing nodes in the real-time load margin matrix. Specifically, each delay submodule maintains a load-delay mapping function, which describes the mapping relationship between the node load level and the delay value. Its parameters are calibrated based on the current load margin value of the node in the real-time load margin matrix and the corresponding historical delay monitoring data. The calibration process is as follows: the node load status recorded in the real-time load margin matrix in the current control cycle and the actual observed delay data of each link on the node are used as a set of reference data points. These are substituted into the load-delay mapping function to determine the undetermined coefficients in the function, so that the function can accurately reflect the trend of load changes on delay near the current operating condition. When the load margin of a node is small (i.e., the load is high), the calibrated mapping function predicts that the delay will increase faster under higher load; conversely, when the load margin is large, the predicted delay growth is relatively slow. When injecting worst-case parameters later, the system sets the load input value of each submodule to the maximum load condition, and calculates and outputs the upper limit of the delay of each submodule under the maximum load condition by the calibrated load-delay mapping function, instead of manually specifying a fixed value.

[0049] After the end-to-end latency simulation model of the control chain is constructed, the system injects worst-case parameters into the model for simulation verification. Worst-case parameters refer to extreme parameter settings that simultaneously superimpose all adverse factors that may increase latency. Specifically, the load input values ​​of each submodule are set to the maximum load condition. The calibrated load-latency mapping function calculates and outputs the upper limit of latency for each submodule under the maximum load condition. The load input of the data acquisition latency submodule is the full-load state corresponding to the device's maximum sampling frequency; the load input of the network transmission latency submodule is the congested state where the link bandwidth is fully occupied; the load input of the container scheduling latency submodule is the saturated state where all node resource quotas are allocated to running instances; the load input of the data waiting latency submodule is the queuing state where all upstream dependent instances are simultaneously in peak computing conditions; and the load input of the instruction issuance latency submodule is the load state where the executor communication interface processes the maximum concurrent messages. The upper limit latency values ​​of the five submodules are summed to obtain the end-to-end latency value of the computing instance under the worst-case condition, which serves as the simulation verification result. The simulation verification result represents the maximum delay that the control link may experience under extreme conditions where all adverse conditions occur simultaneously. If the maximum delay is still lower than the control cutoff time limit of the controlled device associated with this instance in the control link time limit tensor, it indicates that the routing plan has sufficient safety margin. If the maximum delay exceeds the control cutoff time limit, it indicates that the routing plan has a time limit default risk and needs to be adjusted by triggering a security degradation strategy or fault self-healing strategy in subsequent steps.

[0050] Step S6: Trigger a security degradation strategy or a fault self-healing strategy based on the simulation verification results or the fault status of the target computing node, and obtain the system status feedback data after the strategy is executed to update the parameters of the time-limited default composite penalty function.

[0051] Furthermore, based on the simulation verification results, security degradation strategies or fault self-healing strategies are triggered, including: The end-to-end delay value in the simulation verification result is compared with the preset delay threshold, which is determined by the product of the control cutoff time limit in the control link time limit tensor and the preset safety margin coefficient.

[0052] If the end-to-end latency value is greater than the latency threshold, then the tiered degradation measures will be executed in the order of cloud-uploaded microservice instances, protocol conversion microservice instances, and inference microservice instances. The tiered degradation measures include at least one of the following: reducing the priority value of the corresponding instance, reducing the number of container replicas, or extending the execution cycle.

[0053] If a failure is detected in the target compute node, the compute instances deployed on the failed node and the downstream dependent instances affected by the failure are identified according to the microservice interlock adjacency graph. The container images of the compute instances are migrated to the standby compute node and the running state is restored on the standby compute node. The updated access address is pushed to the downstream dependent instances through the service registry, thus completing the fault self-healing.

[0054] Furthermore, the parameters of the updated time-limited default compound penalty function are as follows: After the graded degradation measures or fault self-healing are completed, the resource usage change data of each computing node and the execution latency change data of the computing instance are collected as system status feedback data; based on the contribution of each factor in the system status feedback data to the end-to-end latency improvement, the values ​​of the corresponding weight coefficients in the time limit default composite penalty function are adjusted.

[0055] Specifically, in step S5, the system has obtained the end-to-end latency values ​​of each computing instance under the worst-case operating condition through the end-to-end latency simulation model of the control chain, which serves as the simulation verification result. This simulation verification result reveals the latency upper limit of the routing plan under extreme conditions. However, the simulation verification itself is only a risk assessment of the scheduling scheme and cannot directly eliminate the identified default risks. Meanwhile, during operation, the industrial internet platform may experience sudden anomalies such as computing node hardware failures and network interruptions. These anomalies cannot be predicted by the simulation verification, but they can still cause computing instances deployed on faulty nodes to fail to complete their computing tasks on time. Therefore, this step executes a security degradation strategy or a fault self-healing strategy based on either the simulation verification result or the fault state of the target computing node. When there is a default risk in the scheduling scheme, resources are proactively released to alleviate system load; when a node fails, affected instances are quickly migrated to restore service capabilities. After the strategy is executed, system status feedback data is collected to update the weight coefficients of the penalty function generation model in a closed loop, enabling subsequent control cycle scheduling decisions to be continuously optimized based on the operational experience of the current cycle.

[0056] The trigger condition for the security degradation strategy is to compare the end-to-end delay value in the simulation verification result with a preset delay threshold. The delay threshold is a security boundary for judging whether the routing plan is acceptable. Its value is determined by multiplying the control cutoff time limit in the control link time limit tensor with a preset security margin coefficient. The security margin coefficient is a positive number less than 1 (e.g., 0.85), used to reserve a certain proportion of time margin as a safety buffer on top of the control cutoff time limit. This ensures that even if additional delays not covered by the simulation model occur in actual operation, such as operating system scheduling jitter or garbage collection pauses, the control link still has a high probability of completing within the cutoff time limit. The setting of the delay threshold makes the judgment standard more stringent than the control cutoff time limit. The degradation measure is triggered as long as the simulation verification result exceeds the delay threshold, rather than the control cutoff time limit itself, thus intervening in advance before the actual breach occurs.

[0057] If the end-to-end latency exceeds the latency threshold, the system will implement tiered degradation measures in the following order: cloud upload microservice instance, protocol conversion microservice instance, and inference microservice instance. The degradation order follows the principle of "non-critical business processes first, critical business processes last": the cloud upload microservice instance is only responsible for uploading edge data to the cloud data center and has no direct impact on the real-time control process, therefore it is degraded first; the protocol conversion microservice instance is responsible for industrial protocol format conversion, and its interruption only affects data parsing of newly connected devices without affecting the already running control loop, therefore it is ranked second; the inference microservice instance performs machine learning inference tasks such as fault prediction and defect detection, and although its results affect long-term operation and maintenance decisions, its direct impact on the current control cycle is limited, therefore it is ranked third; the control loop microservice instance directly participates in the real-time control of the controlled equipment and is not within the degradation scope. The tiered degradation measures include at least one of the following three methods: reducing the priority value of the corresponding instance, causing it to allocate computing resources to more critical instances in subsequent scheduling cycles; reducing the number of container replicas, i.e., reducing the number of container instances running for this service type to the minimum required to maintain basic functionality, freeing up resources and network bandwidth for control loop instances; and extending the execution cycle, i.e., reducing the triggering frequency of this instance from a higher frequency to a lower frequency, reducing the computing load per unit time. The system executes degradation measures step by step in the above order. After each level is executed, the simulation model is reconstructed based on the degraded container deployment status and the updated real-time load margin matrix to evaluate whether the expected end-to-end latency of the degraded routing scheme in the next control cycle has fallen below the latency threshold. If it has fallen below the threshold, the degradation stops; if it still does not meet the threshold, the degradation continues for the next level of service type until the expected latency recovers to a safe range or the degradation of all three levels of non-critical services has been completed.

[0058] Another trigger for security degradation strategies is the failure state of the target compute node. If the system detects a failure in a target compute node, such as a lost heartbeat signal, hardware anomaly alarm, or operating system crash, it identifies all compute instances deployed on the failed node and their downstream dependent instances affected by the failure based on the microservice interlocking adjacency graph. Here, "downstream dependent instances" refers to other instances that directly or indirectly depend on the output of instances on the failed node through directed edges in the microservice interlocking adjacency graph. Although these instances themselves are not faulty, they face the risk of not functioning properly due to the interruption of the upstream data source. After identification, the system migrates the container images of each compute instance on the failed node to a standby compute node. This involves re-pulling the corresponding container images from the container image repository, instantiating and starting the containers on the pre-configured standby node, and restoring the running state before the failure during startup. This includes loading the most recent checkpoint data from persistent storage or replaying recently unprocessed messages from the message middleware, enabling the migrated instances to continue execution from the breakpoint before the failure without re-initializing from scratch. After container migration is complete, the system pushes the new access address of the migrated instance to all downstream dependent instances through the service registry. Upon receiving the updated access address, the downstream dependent instances send subsequent data requests and call requests to the new address, thereby restoring the complete service call chain and completing fault self-healing. The fault self-healing process utilizes the dependency topology information represented by the microservice interlocking adjacency graph and the dynamic address management capabilities provided by the service registry, realizing fully automated recovery from fault detection, dependency identification, instance migration to address updates. Affected services can be restored within seconds without manual intervention.

[0059] For example, Figure 2 This is a timeline diagram of a typical fault self-healing process, such as... Figure 2 As shown, the entire self-healing process includes five key stages: fault detection, dependency identification, container migration, address update, and service recovery. This verifies that the application can automatically complete the migration of computing instances and update of dependencies on faulty nodes within seconds.

[0060] After security degradation measures or fault self-healing are implemented, the system collects resource usage change data for each computing node and execution latency change data for computing instances as system status feedback data. Resource usage change data reflects the redistribution of load across nodes after degradation or migration, while execution latency change data reflects the actual improvement in end-to-end latency of the control link before and after policy implementation. Based on the contribution of each factor in the system status feedback data to end-to-end latency improvement, the system adjusts the corresponding weight coefficients in the penalty function generation model. The contribution is evaluated as follows: the change in each input dimension (normalized target control deadline, dependency weight value, and normalized target capacity margin value) before and after policy implementation is calculated and multiplied by the corresponding weight coefficient to obtain the independent contribution value of each dimension to the penalty function value change. Then, the absolute value of each dimension's independent contribution value is divided by the sum of the absolute values ​​of all dimensions' independent contribution values ​​to obtain the contribution percentage of each dimension. For example, if the node's capacity margin increases significantly after the strategy is implemented, causing the absolute value of the independent contribution of the capacity margin dimension to account for 60% of the sum of the three dimensions, it indicates that the change in capacity margin has the greatest contribution to the decrease in the penalty function value (i.e., latency improvement). The impact of this factor on latency under the current operating conditions is underestimated, and its corresponding weight coefficient should be appropriately increased; conversely, it should be appropriately decreased. Through this closed-loop feedback adjustment based on actual operating results, the weight coefficient of the penalty function generation model can gradually approach the optimal configuration reflecting the real operating conditions in continuous control cycles, enabling subsequent cycle scheduling decisions to more accurately match the actual operating characteristics of the system.

[0061] The above describes a cloud-edge collaborative industrial internet platform microservice architecture method based on embodiments of this application. The following describes a cloud-edge collaborative industrial internet platform microservice architecture system based on embodiments of this application. Please refer to [link to relevant documentation]. Figure 3 One embodiment of a cloud-edge collaborative industrial internet platform microservice architecture system in this application includes: The data modeling unit is used to acquire the operating parameters and network status data of the controlled devices in the industrial internet platform, and to construct the control link time-limit tensor and the microservice interlock adjacency graph.

[0062] The resource monitoring unit is used to acquire resource status data of each computing node during the control period and calculate the real-time load margin matrix of each computing node.

[0063] The penalty generation unit is used to generate a composite penalty function for time limit violations based on the control link time limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix.

[0064] The dynamic routing unit is used to perform deterministic priority dynamic routing of computing instances of different business types based on the time-limited default composite penalty function, and deploy the computing instances to edge computing nodes or cloud computing nodes for operation.

[0065] The simulation verification unit is used to perform end-to-end worst-case latency simulation verification on the routing plan of the computation instance and obtain the simulation verification results.

[0066] The execution feedback unit is used to trigger a security degradation strategy or a fault self-healing strategy based on the simulation verification results or the fault status of the target computing node, and to obtain system status feedback data after the strategy is executed in order to update the parameters of the time-limited default composite penalty function.

[0067] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0068] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 application. 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.

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

Claims

1. A microservice architecture method for an industrial internet platform based on cloud-edge collaboration, characterized in that, The method is applied to an industrial internet platform that includes edge computing nodes and cloud computing nodes. The industrial internet platform deploys various types of computing instances in a containerized microservice architecture and manages them uniformly through a service registry. The method includes: Obtain the operating parameters and network status data of the controlled devices in the industrial internet platform, and construct a control link time limit tensor and a microservice interlock adjacency graph; Obtain resource status data of each computing node within the control period, and calculate the real-time load margin matrix of each computing node; Based on the control link time limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix, a time limit violation composite penalty function is generated; Based on the time-limited default composite penalty function, deterministic priority dynamic routing is performed on computing instances of different business types, and the computing instances are deployed to the edge computing node or the cloud computing node for operation; The routing plan of the computation instance is subjected to end-to-end worst-case latency simulation verification to obtain the simulation verification results; Based on the simulation verification results or the fault status of the target computing node, a security degradation strategy or a fault self-healing strategy is triggered, and system status feedback data after the strategy execution is obtained to update the parameters of the time-limited default composite penalty function.

2. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, Construct a control link time-limit tensor and a microservice interlock adjacency graph, including: Obtain the device number, sampling period, control cutoff time limit, and link delay data to the edge computing node of the controlled device. Organize the sampling period, control cutoff time limit, and link delay data into a control link delay tensor using the device number, time step, and time limit type as three dimensions. The call chain information between the computing instances is queried. The microservice interlocking adjacency graph is constructed with the computing instances as nodes, the call chain information as directed edges, and at least one of call frequency and dependency tightness as edge weights. When there is a transitive call path from the first computing instance to the third computing instance via the second computing instance, the transitive dependency weight is obtained by accumulating the weights of each edge along the transitive call path.

3. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, Calculate the real-time load margin matrix for each computing node, including: At the beginning of each control cycle, the CPU allocated data, memory allocated data, and network bandwidth allocated data of each computing node are collected and determined as the amount of resources occupied by each computing node. The amount of resources occupied includes the resources allocated to running container instances and the resources reserved for critical services. The difference between the total resource capacity of each computing node and the occupied resource amount is calculated. The difference is organized into the real-time capacity reserve matrix using the computing node identifier as the row index and the resource type as the column index. When the computing instance is deployed to the target computing node, the container resource quota of the computing instance is deducted from the real-time capacity reserve matrix accordingly.

4. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, Generate a time-limited default compound penalty function, including: For each computing instance to be scheduled, the target control deadline of the controlled device associated with the computing instance is extracted from the control link time limit tensor, the dependency weight value between the computing instance and other computing instances is extracted from the microservice interlock adjacency graph, and the target load margin value of the candidate computing node is extracted from the real-time load margin matrix. The target control deadline, the dependency weight value, and the target carrying capacity value are input into a pre-established penalty function generation model for weighted calculation. The corresponding penalty function value for scheduling the computing instance to the candidate computing node is output. The combination of all computing instances to be scheduled and all candidate computing nodes is traversed to generate the time limit default composite penalty function.

5. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, Deterministic priority dynamic routing includes: The computing instances are divided into control closed-loop microservice instances, inference microservice instances, protocol conversion microservice instances, and cloud upload microservice instances based on the business attribute identifier of the computing instances, and priority values ​​of each type of microservice instance are calculated based on the time-limited default compound penalty function. According to the priority values ​​from high to low, and combined with the resource reserves of each computing node in the real-time load margin matrix and the dependency order in the microservice interlock adjacency graph, target computing nodes are allocated to each type of microservice instance in sequence. The corresponding container image is pulled from the container image repository and the container is instantiated and started on the target computing node. The access address and running status of the computing instance are registered to the service registry.

6. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 5, characterized in that, After registering the access address and running status of the computing instance to the service registry, the process also includes: The system obtains the running status data of the message middleware in the industrial internet platform. The computing instance realizes cross-node data flow through the publish-subscribe mechanism of the message middleware. The cloud upload microservice instance subscribes to the message topics on the edge side and uploads them to the cloud big data center after aggregating them according to the preset upload batch size. Based on the queue backlog depth, message production rate, and message consumption rate of the message middleware, the target consumption rate is calculated. The target number of replicas of the computing instance is determined based on the ratio of the target consumption rate to the single instance consumption rate. The preset upload batch size is adjusted based on the queue backlog depth. The computing instance is elastically scaled up or down based on the target number of replicas, and the access address of the scaled-up instance is updated through the service registry.

7. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, The simulation verification results include: Obtain the container deployment plan and container migration plan of the computing instance on the target computing node to generate the routing plan, wherein the routing plan includes the container startup sequence of each computing instance, and the container startup sequence satisfies the call dependency relationship defined by the microservice interlock adjacency graph; Based on the routing plan, an end-to-end latency simulation model of the control chain is constructed. The end-to-end latency simulation model of the control chain includes a data acquisition latency submodule, a network transmission latency submodule, a container scheduling latency submodule, a data waiting latency submodule, and an instruction issuance latency submodule. The worst-case operating condition parameters are injected into the end-to-end delay simulation model of the control chain. The delay value of each sub-module is set to its upper limit under the maximum load condition. The end-to-end delay value of the calculation instance under the worst-case condition is obtained by summing the values ​​and serving as the simulation verification result.

8. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 1, characterized in that, Based on the simulation verification results, a security degradation strategy or a fault self-healing strategy is triggered, including: The end-to-end delay value in the simulation verification result is compared with a preset delay threshold. If the end-to-end latency value is greater than the latency threshold, then the graded degradation measures are executed in the order of cloud-uploaded microservice instance, protocol conversion microservice instance, and inference microservice instance. The graded degradation measures include at least one of reducing the priority value of the corresponding instance, reducing the number of container replicas, or extending the execution cycle. If a failure is detected in the target compute node, the compute instances deployed on the failed node and the downstream dependent instances affected by the failure are identified according to the microservice interlock adjacency graph. The container images of the compute instances are migrated to a standby compute node and restored to running status on the standby compute node. The updated access address is pushed to the downstream dependent instances through the service registry, thus completing the fault self-healing.

9. The microservice architecture method for an industrial internet platform based on cloud-edge collaboration as described in claim 8, characterized in that, Update the parameters of the time-limited default compound penalty function, including: After the graded degradation measures or fault self-healing are completed, the resource usage change data of each computing node and the execution latency change data of the computing instance are collected as the system status feedback data. Based on the contribution of each factor in the system status feedback data to the improvement of end-to-end latency, the values ​​of the corresponding weight coefficients in the time-limited default composite penalty function are adjusted.

10. A cloud-edge collaborative industrial internet platform microservice architecture system, used to implement the cloud-edge collaborative industrial internet platform microservice architecture method as described in any one of claims 1-9, characterized in that, The system includes: The data modeling unit is used to acquire the operating parameters and network status data of the controlled devices in the industrial internet platform, and to construct the control link time limit tensor and microservice interlock adjacency graph. The resource monitoring unit is used to acquire resource status data of each computing node during the control period and calculate the real-time load margin matrix of each computing node. The penalty generation unit is used to generate a time-limit violation composite penalty function based on the control link time-limit tensor, the microservice interlock adjacency graph, and the real-time bearer margin matrix. The dynamic routing unit is used to perform deterministic priority dynamic routing of computing instances of different business types according to the time-limited default composite penalty function, and deploy the computing instances to the edge computing node or the cloud computing node for operation; The simulation verification unit is used to perform end-to-end worst-case latency simulation verification on the routing plan of the computation instance and obtain the simulation verification result. The execution feedback unit is used to trigger a security degradation strategy or a fault self-healing strategy based on the simulation verification results or the fault status of the target computing node, and to obtain system status feedback data after the strategy execution to update the parameters of the time-limited default composite penalty function.

Images