CN115396495B - A fault response method for factory microservice system in SDN-FOG environment - Google Patents

Abstract

The invention discloses a fault handling method of a factory micro-service system in an SDN-FOG environment, and relates to the technical field of industrial Internet of things. The invention develops a fault handling scheme of an information physical intelligent factory micro-service system in an SDN-FOG environment. The method comprises the steps of establishing a system model which accords with an actual factory operation scene, establishing a fault processing framework of a micro-service system based on an SDN-FOG environment, establishing an integer programming problem which can simultaneously consider network resource constraint, workflow response time, load, energy consumption and fault coping, designing logic of an application layer fault coping program based on the integer programming problem, and obtaining an optimal response strategy by using a Gurobi solver through two self-adaptive related optimization problems. In the scene of strict requirements on fault processing response time, a suboptimal heuristic algorithm is designed to simplify the flow, the expandability of the provided optimization problem is solved, and the obtained solution is a self-adaptive method and is suitable for the network of the actual factory scene.

Description

A fault response method for factory microservice system in SDN-FOG environment

Technical field

The present invention relates to the technical field of industrial Internet of Things, and in particular to a fault response method for a factory microservice system in an SDN-FOG environment.

Background technique

In recent years, Industry 4.0 has been considered an important driving force for the new generation of industrial revolution, and the Industrial Internet of Things (IIoT) has attracted widespread attention. It can meet various actual factory application scenarios, such as remote adaptation and configuration, intelligent operation and maintenance. , equipment collaborative control, etc. IIoT connects physical entities with computing capabilities based on Internet technology standards, and uses information and data technology to promote production through industrial data modeling, management, and analysis. IIoT generally has strict quality of service (QoS) requirements, such as very short response time requirements, load balancing issues, energy consumption issues, and reliability issues. To support applications with stringent response time requirements, the fog computing paradigm is emerging, given that cloud computing servers are often located far away from on-site equipment and the presence of latency can complicate the process of achieving sufficiently short response times. Fog computing deploys computing resources closer to end users. Fog computing at the edge can quickly calculate and analyze data locally, and transmit relevant on-demand processing data streams from event geographical locations to the core platform, improving overall network efficiency. . In order to improve the management efficiency of edge fog computing devices, software-defined network (SDN) technology can be introduced, which is a paradigm that allows the network to be programmed through an SDN controller, allowing programmable routing optimization when new devices are added. When integrated into the infrastructure, this latency optimization is scalable and flexible. In addition, SDN architecture allows network controllers to monitor networks and computing devices and collect performance information from the infrastructure. Using multiple coordinated SDN controllers in industrial IoT fog infrastructure can improve overall infrastructure QoS. When SDN-based fog infrastructure is deployed in a factory, it can be converted into a cyber-physical smart factory by leveraging IIoT. The digitization of the factory environment helps realize a new automation paradigm and achieve more flexible and safer operations.

In an SDN-FOG environment, factory operations can be implemented by a microservices architecture, a promising architecture that decomposes a single software into a set of loosely coupled containerized microservices, supporting distributed deployment, And associating them to multiple microservice chains to serve requests can significantly shorten the time to change the system and apply the changes to the production environment, reduce development and maintenance costs, and increase flexibility. At present, there are three main categories of optimization problems related to microservice development, deployment, expansion and maintenance in the SDN-FOG environment: First, the decentralized computing distribution problem, which mainly studies which nodes should be used by microservices in fog computing environments and which nodes should Which part of the application is hosted. This type of problem generally takes the average response time as the optimization goal. It is assumed that the network is a static entity that provides a specific delay. The SDN device is responsible for collecting information from the infrastructure and then minimizing the network delay through techniques such as route optimization. However, this type of problem generally Optimization is considered when designing the architecture, and microservice redeployment in case of failure is rarely considered. The second is the problem of optimal controller placement. The delay between the SDN switch and the controller will affect the delay between any two devices in the SDN architecture. This type of problem generally assumes that the traffic will not change according to the delay of the network implementation. Study the relationship between the layout of the controller and the network topology and traffic guidance methods in the network, and then optimize the control delay and data transmission delay. However, this type of problem is generally considered when designing the architecture, and real-time control flow under fault conditions is rarely considered. The third is the path optimization problem. Generally, the response time of the system is regarded as the service quality indicator to be optimized. The response time is the combination of execution time and transmission delay. This type of problem generally establishes a multi-objective optimization problem, jointly considering service execution time and transmission delay, and arranging the most appropriate path for the workflow. However, the scenarios for this type of problem all consider routing optimization during normal operation, and lack of understanding of fault conditions. rerouting considerations.

The application of microservices in industrial scenarios has aroused the interest of the research community. However, as mentioned above, most existing research on applying microservices to smart factories focuses on general architectural principles and optimized deployment solutions. A few works have considered fault response solutions under microservice architecture, and their scope is generally very narrow, providing only limited forms of adaptation (such as self-healing and runtime location adaptation, etc.). These studies combine microservices architecture with adaptive systems designed to monitor their behavior at runtime and change their configuration to survive uncertain operating conditions such as workload changes and failure risk. and enhance the quality attributes of microservice systems. At present, when studying the application of microservices in actual factories, in addition to considering key factors such as execution time and delay, it is also necessary to take dynamic network topology changes, workflow changes, fault prevention and fault handling into consideration.

Designing adaptive systems that enable automatic fault handling involves making design decisions about the environment and the system itself while observing the network environment, and then selecting appropriate adaptation mechanisms. In a microservice architecture based on an SDN-FOG environment, the design space for making adaptive decisions is more complex due to the large number of runtime components that are independent and highly dynamic. The first challenge is: how to develop monitoring and adaptation mechanisms to cope with the diversity of quality attributes of microservice architectures. The main optimization points that can be considered include: 1) Response time. 2) Node reliability. 3) Network overhead. 4) Load balancing (if microservices are only run on one or a few nodes, service execution performance will decrease. Therefore, in fog computing scenarios, performance degradation caused by increased node load generally needs to be considered).

The characteristics of microservice systems, namely independent and frequent deployment, the need for a high degree of automation, and complex operational architecture, can promote further research and development of adaptive systems. Correspondingly, adaptive systems provide a control-oriented perspective. Researching fault response solutions is an important part of designing adaptive systems. Currently, there are two main types of work to design adaptive solutions for microservice architectures: First, through Utilize a large number of theoretical and practical results to design a dynamic programming algorithm to select the best adaptation strategy for each microservice. When the system is running, the information in the network is continuously collected to determine the current actual working status of the controlled object. According to the settings of the application, when the set threshold is reached, the adaptive control law is triggered to adjust the system structure in real time. Or parameters, so that the system always automatically works in the optimal or sub-optimal operating state. The second is to use reinforcement learning methods to learn new adaptation strategies from past adaptation results, improve the quality attributes of the overall microservice system, and achieve strategic reasoning and multi-objective optimization under uncertainty to meet multiple possible interactions. Conflicting service quality requirements. From the perspective of solving models, reinforcement learning is applied to the adaptive solution design of microservice systems due to its significant advantages in solving strategic decision-making problems.

Through the introduction and analysis of the above background, it can be seen that for the cyber-physical smart factory in the SDN-FOG environment, the fault response solution design of the microservice system mainly faces the following three difficulties: 1) The proposed solution not only needs to consider fault response scheme, basic service quality indicators must also be met. For example, when studying the route optimization link of fault recovery, quality indicators such as response time, energy consumption, and load should still be optimized. 2) The existing technology of microservice systems in industrial scenarios rarely considers the design of fault response solutions, and there are more than one problems related to fault response in microservice systems. It is necessary to consider as many related issues as possible, such as fault prevention and re-installation. Routing costs, etc. 3) The number of workflows, the number of fog nodes and the number of required microservices in real industrial scenarios will have an impact on the proposed algorithm. Therefore, the designed solution needs to be flexible in actual scenarios, and the proposed algorithm must be able to Respond quickly to workflows that change dynamically over time.

It can be seen that the research on fog computing, SDN, and microservices are relatively independent. When considering the three together, there is limited research work on the development, deployment, management, and expansion of microservices in the SDN-FOG environment. In this environment, fault response is There are even fewer relevant studies. The existing technology of microservice systems in industrial scenarios has been fully studied on the optimal deployment scheme of microservice systems, but the adaptive design of microservice systems is rarely considered. At present, only a few works have solved the problem of developing adaptive solutions for microservice systems. Regarding the specific challenges of the solution, fault response is a key part of adaptive design, and the number of related research works is also small. Existing technologies for fault response solutions for microservice systems generally have a narrow scope of consideration, focusing more on fault handling and orchestrating new workflows, and insufficient consideration of fault prevention and rerouting costs. The quality attributes of the microservice system are diverse. When designing fault response solutions, there is a lack of comprehensive consideration of response time, node reliability, network overhead and load.

Therefore, those skilled in the art are committed to developing a fault response method for the factory microservice system in the SDN-FOG environment. Build a fault handling framework for the microservice system based on the SDN-FOG environment, construct an integer programming problem that can simultaneously consider network resource constraints, workflow response time, load, energy consumption and fault response, and use the Gurobi solver to obtain the optimal response strategy. For scenarios with strict response time requirements for fault handling, a suboptimal heuristic algorithm is designed to simplify the process, solve the scalability of the optimization problem, and obtain an adaptive solution that is suitable for networks in actual factory scenarios.

Contents of the invention

In view of the above-mentioned defects of the existing technology, the technical problem to be solved by the present invention is to develop a fault response solution for the cyber-physical smart factory microservice system in the SDN-FOG environment. Established a system model that conforms to the actual factory operation scenario, built a fault handling framework for the microservice system based on the SDN-FOG environment, and built a system that can simultaneously consider network resource constraints, workflow response time, load, energy consumption and fault response The integer programming problem is used as the basis to design the logic of the application layer's fault response program. The two adaptive related optimization problems proposed can use the Gurobi solver to obtain the optimal response strategy. For scenarios that require strict response time for fault processing, a suboptimal heuristic algorithm is designed to simplify the process and solve the scalability of the proposed optimization problem. The obtained solution is an adaptive method that is suitable for actual factory scenarios. network of.

In order to achieve the above purpose, the present invention provides a fault response method for a factory microservice system in an SDN-FOG environment, which includes the following steps:

Step 1. Establish a microservice system fault handling architecture based on SDN-FOG environment;

Step 2. System modeling, describing the relationship between infrastructure, transmission network, and fog computing equipment;

Step 3. Construct integer programming problems and fault response procedures;

Step 4. Use the solver to find the optimal response strategy;

Step 5. For fault handling scenarios that require particularly strict fault response time, use a heuristic algorithm.

Further, the microservice system fault handling architecture based on the SDN-FOG environment in step 1 includes an application layer, a control layer, and a base layer.

Further, the application layer includes fault handling programs, timers and functional programs.

Further, the control layer includes various components required for fault response solutions.

Further, the base layer deploys switches that support SDN control. The switches have different failure probabilities in time slots. The central controller is connected to the switches to summarize network topology and traffic information, and dynamically configures the switches using southbound interface programming. ; Each switch is connected to a fog node and combined into one node; each fog node corresponds to a set of industrial IoT devices and fog servers.

Further, the step 1 includes the following steps:

Step 1.1. Sensors connected to factory field equipment continuously collect information. The sensor data is pre-processed and sent to the connected switch that supports SDN control; the network monitoring component collects node information including field equipment, fog nodes and switches from the switch. and link information, and sends the information to the application layer to continuously monitor network traffic;

Step 1.2. The fault detection component determines whether a fault occurs in the transmission network based on the information collected by the network monitoring component; if a fault is detected at the switch or fog node or link, the network monitoring component will determine the current new network topology and the support of each fog node. The set of microservices is sent to the fault response program;

Step 1.3. The fault response program calculates in real time and reallocates resources to the workflow passing through the faulty node or link; the node configuration component allocates resources to the workflow through the scheduling forwarding table and responds to the fault made by the fault response program in the application layer. Decisions are applied to switches and fog nodes;

Step 1.4. Refresh the timer after the configuration is completed. If some microservices in the workflow cannot be completed due to some node or link failures, report the failure type and transfer to manual processing;

Step 1.5: After a complete cycle of the timer, activate the fault prevention component, actively perform periodic reconstruction of the network, optimize the selected path of the workflow, improve the overall service quality and reduce the probability of failure.

Further, the step 2 includes the following steps:

Step 2.1. Transmission network modeling;

Step 2.2, modeling of fog nodes and supported microservice sets;

Step 2.3, workflow modeling;

Step 2.4. Modeling of service quality indicators.

Further, the step 3 includes the following steps:

Step 3.1. Define decision variables;

Step 3.2. Build resource constraints;

Step 3.3. Construct optimization objectives related to decision variables;

Step 3.4: Construct constraints related to decision variables;

Step 3.5. Construct the objective function.

Further, the objective function constructed in step 3.5 includes the problem of network failure recovery and the problem of periodic reconstruction of the network.

Further, the step 4 solver includes the commercial solver Gurobi.

In the preferred embodiment of the present invention, a microservice system fault handling architecture suitable for cyber-physical smart factories is proposed. This architecture utilizes SDN and fog computing technology, and provides problem descriptions of fault recovery and fault prevention. . The corresponding optimization problem is in the form of integer programming, and the optimal response strategy can be obtained using the Gurobi commercial solver.

The proposed method considers the maximum utilization and failure probability of links and nodes, optimizing the load of network equipment and the probability of network failure. Due to the traffic demand in the network, the probability of node or link failure will change over time. For changes, considering fault prevention, this method will dynamically reallocate resources with a small rerouting cost within a predefined time period to keep the network in the best state.

The proposed method can optimize network load and energy consumption to a certain extent, ensure the required service quality level, and can reconfigure the network in real time in the event of node or link failure; and takes into account the quality attributes of the microservice system. Diversity, its weight can be measured according to the actual situation.

The proposed suboptimal heuristic method is able to respond quickly to workflows that change dynamically over time, and the solution is an adaptive approach that is suitable for networks in real factory scenarios.

In actual operational deployment, microservices can be logically grouped according to business needs and quality requirements, which corresponds to the set of microservices supported by each fog node, and can then be layered or distributed with independent, application-aware servers. type structure for collective management.

Compared with the prior art, the present invention has the following obvious substantive features and significant advantages:

1. Integrate SDN, fog computing and microservice technologies, and on the premise of ensuring common service quality indicators, design a microservice system fault handling architecture based on SDN-FOG environment, model the actual factory operation scenario, and provide Problem descriptions for troubleshooting and prevention are provided to design troubleshooting procedures.

2. Comprehensive consideration is given to the diversity of quality attributes of the microservice system. When designing the fault response plan, response time, node reliability, energy consumption and load are all taken into comprehensive consideration, and their weight can be measured according to the actual situation.

3. The proposed scheme considers the maximum utilization of links and nodes, carries out a fault prevention design to prevent overload, also considers the failure probability of links and nodes, and carries out a fault prevention design to limit the failure probability. When rerouting, The cost of network traffic changes is taken into account.

4. In actual operation, microservices can be logically grouped according to business needs and quality requirements, which corresponds to the set of microservices supported by each fog node, and then independent, application-aware servers can be used to layer or Distributed structure for collective management.

The concept, specific structure and technical effects of the present invention will be further described below in conjunction with the accompanying drawings to fully understand the purpose, features and effects of the present invention.

Description of the drawings

Figure 1 is a microservice system fault handling architecture based on SDN-FOG environment according to a preferred embodiment of the present invention;

Figure 2 is a detailed structure of the base layer of a preferred embodiment of the present invention;

Figure 3 is a microservice system fault response process based on SDN-FOG environment according to a preferred embodiment of the present invention;

Figure 4 is a heuristic algorithm flow chart of a preferred embodiment of the present invention.

Detailed ways

The following describes multiple preferred embodiments of the present invention with reference to the accompanying drawings to make the technical content clearer and easier to understand. The present invention can be embodied in many different forms of embodiments, and the protection scope of the present invention is not limited to the embodiments mentioned herein.

In the drawings, components with the same structure are denoted by the same numerals, and components with similar structures or functions are denoted by similar numerals. The size and thickness of each component shown in the drawings are arbitrarily shown, and the present invention does not limit the size and thickness of each component. In order to make the illustrations clearer, the thickness of components is exaggerated in some places in the drawings.

The invention proposes a smart factory microservice system failure response method in an SDN-FOG environment, which includes the following steps:

Step 1: For the cyber-physical smart factory, a microservice system fault handling architecture based on SDN-FOG environment is proposed as shown in Figure 1, which mainly includes the following steps:

S1, fog infrastructure and industrial Internet of Things related equipment are deployed in the factory. Sensors connected to the factory field equipment continuously collect information. The sensor data is pre-processed and sent to its connected switches that support SDN control; the network monitoring component starts from the switch. Collect node information and related link information including field devices, fog nodes and switches, and send the information to the application layer to continuously monitor network traffic.

S2, the fault detection component determines whether a fault occurs in the transmission network based on the information collected by the network monitoring component. If a fault is detected at a switch or fog node or link, the network monitoring component sends the current new network topology and the set of microservices supported by each fog node to the fault response program.

S3, the fault response program calculates in real time and reallocates resources to the workflow passing through the failed node or link. The node configuration component allocates resources to workflows based on the scheduling forwarding table, and applies fault response decisions made by the fault response program in the application layer to switches and fog nodes.

S4, refresh the timer after the configuration is completed. If some microservices in the workflow cannot be completed due to some node or link failures, the failure type will be reported and manual processing will be performed.

S5, after a complete cycle of the timer, activates the fault prevention component, actively performs periodic reconstruction of the network, optimizes the selected path of the workflow, improves the overall service quality, and reduces the probability of failure at a small rerouting cost. .

Specifically, as shown in Figure 1, there are three major layers in the fault handling architecture of the microservice system based on the SDN-FOG environment: 1) the application layer, which includes fault handling programs, timers and other functional programs; 2) the control layer, Contains various components required for fault response solutions; 3) Infrastructure layer. The basic layer deploys multiple switches that support SDN control. These switch nodes have different failure probabilities in time slots. The central controller of the factory Connect to the switch to summarize network topology and traffic information, and use the southbound interface to dynamically program and configure the switch; as shown in Figure 2, in this architecture, each switch is connected to a fog node, which is combined into one node; each switch is connected to a fog node. Each fog node corresponds to a set of industrial IoT devices and fog servers. In this factory scenario, some functional applications are deployed to collect the status of factory equipment through relevant sensors and process it in the fog server to complete corresponding commands and continuously monitor and manage the smart factory. These applications are designed using a microservices architecture and therefore consist of different independent services that perform specific types of processing and whose functionality can be requested individually or combined through workflows.

As shown in the right half of Figure 1, the base layer can be divided into three parts: the physical part includes the physical equipment of the factory; the network part includes switches and master controllers that support SDN; and the computing part includes industrial IoT devices and fog servers.

Step 2: Conduct detailed system modeling of the base layer to describe the relationship between infrastructure, transmission network, and fog computing devices. It mainly includes the following steps:

S1, Transmission network modeling: The network infrastructure is expressed as G={N,L}, N is a set of nodes, and L is a set of links connecting different switches. Node i∈N has a tuple i=<p _i , _ri >, where p _i is the computing processing capability of the fog node (units/s), and one unit represents a microcycle; r _i is the node's RAM (Mb). Link l _ij ∈L is a tuple l _ij =<d _ij ,c _ij >, where d _ij is the delay of the link (ms), c _ij is the maximum capacity of the link (Mb/s), and the node i is the source of the link, and node j is the destination of the link. Considering the avoidance of overload, μ ₁ is used to represent the maximum link utilization, and μ ₂ is used to represent the maximum node utilization; considering fault prevention, P _i (t) is used to represent the failure probability of node i, and P _ij (t) is used to represent the link. The failure probability of road l _ij . Then, the network topology can be represented by the matrix C _N*N , and the propagation delay of the link can be represented by the matrix D _N*N , for example:

S2, modeling of fog nodes and supported microservice sets: considering X different microservices, microservices x∈X can be represented by a tuple x=<pc _x ,r _x >, where pc _x is the unit traffic The processing power required by microservice x (measured in the number of microcycles required), r _x is the amount of RAM (Mb) required by microservice x. The matrix NF _N*X is used to represent the set of microservices supported by each node, and NF _(i,x) =1 indicates that node i supports microservice x. In actual operational deployment, microservices can be logically grouped according to business needs and quality requirements, which corresponds to the set of microservices supported by each fog node.

S3, workflow modeling: Under this architecture, we only consider loop-free routing, that is, nodes and links will not be used twice in workflow routing. F is a collection of workflows, each workflow contains the execution of a specific function, linked between 1 to |Y| microservices, |Y|<|X|, depending on the number of microservices required to execute the function. Workflow f∈F is an ordered tuple f={m ₁ ,m ₂ ,…,m _|f-1| ,m _|f| }. Each element m _a has complete relationship with a microservice x in X. The same format and values, i.e. m _a ∈X, |f|≤|Y|. Let C ^f (t) represent the traffic of f in time slot t. To execute a workflow, data must flow from the node that starts the workflow to the node that executes m ₁ , from there to the node that executes m ₂ , and so on, after the last functional microservice m _|f-1| is completed, m _|f| indicates that the data needs to be returned to the factory equipment or delivered to the control layer. The microservices requested by each workflow are represented by the matrix R _F*X . /> Indicates that workflow f∈F in time slot t requests microservice x∈X. The startup node of workflow f is represented by s _f . After the execution of workflow f, it will be transmitted to node d _f to aggregate information, and then return to the factory equipment or upload to the control layer.

S4, Service quality indicator modeling: 1) Each fog node has two different modes: working and idle. If there is no activated microservice on the fog node, the fog node will be in idle mode; let e _i represent the energy consumption of node i in working mode. In node idle mode, the energy consumption is a small part of the energy consumption in working time e ₀ + e _idle (mainly the working energy consumption e ₀ of the switch plus the static energy consumption e _idle of the fog node). The current state of the fog node is specified by S _1*N (t)∈{0,1}, assuming E(t) is the energy consumption of the network in time slot t. 2) use Indicates the maximum processing delay that workflow f can tolerate, using/> represents the maximum allowable propagation delay of workflow f, and let T(t) be the response time of all workflows in the network in time slot t. 3) The link failure probability and node failure probability of workflow f routed in the network should be less than the predefined thresholds M _l and M _n . 4) The cost of network rerouting in time slot t is measured by the number of routes that need to be changed under the new network configuration compared with the original network configuration.

Step 3: Construct an integer programming problem to describe the fault response procedure, which mainly includes the following steps:

S1, define 0-1 decision variables: 1) matrix Represents the assignment of nodes and microservices to workflows in time slot t. Indicates that microservice m _a in workflow f is executed on node i in time slot t. 2)Matrix/> Is the network link resource allocation of the workflow,/> Indicates that microservice m _a in workflow f is routed through link l _ij in time slot t,/> Indicates that workflow f passes link l _ij in time slot t. 3) The current state of the fog node is specified by S _1*N (t)∈{0,1}.

S2, build resource constraints: Constraint (1) is the link capacity constraint between nodes,

Constraint (2) is used to control the transmission delay of each workflow f in the link,

Constraint (3) is the failure probability constraint of the link responding to workflow f,

Constraint (4) is the RAM capacity constraint of the node that provides the microservice,

Constraint (5) is used to control the processing delay of each workflow in the node,

Constraint (6) is the failure probability constraint of the node responding to workflow f,

S3, construct the optimization objective related to the decision variable, equation (7) is used to calculate the energy consumption E(t) of the network in time slot t

Equation (8) is used to calculate the overall response time T(t) of the network workflow in time slot t

Equation (9) is used to calculate the cost of network rerouting in time slot t Cost(t)

S4, constructing constraints related to decision variables: Constraint (10) means: except for the node that starts the workflow and the node that is delivered after the workflow is completed, other intermediate nodes have traffic input and output.

Constraint (11) stipulates that we only consider loop-free routes in this architecture.

Constraint (12) indicates that when the workflow reaches the node, the requested microservice is executed.

Constraint (13) ensures that the node where the workflow executes the microservice must support the requested microservice.

Constraint (14) ensures that the workflow will not request the same microservice multiple times.

Constraint (15) ensures that the microservice is only executed on the nodes through which the workflow passes.

Constraint (16) means that when the node provides microservices to the workflow, the node is in the working state, where Si(t∈{0,1}

S5, construct the objective function: Under this architecture, two adaptive-related issues are mainly considered, mainly fault response methods.

1) Network failure recovery problem: Objective function 1 gives priority to optimizing the cost of network traffic rerouting, and secondly optimizes the overall response time of the workflow in the network. The goal is to respond quickly, where α ₁ > α ₂ .

minα ₁ Cost(t)+α ₂ T(t)

2) Periodic reconstruction problem of the network: Every time a complete cycle of the timer passes, the overall network is periodically optimized. Objective function 2 mainly optimizes the service execution time and node energy consumption, so that the network reaches the best state while limiting the redundancy. The cost of routing should not be too high. Where β ₁ >β ₂ >β ₃ .

minβ ₁ T(t)+β ₂ E(t)+β ₃ Cost(t)

Step 4: Use the solver to solve to get the optimal response strategy. After step 3, you can get

The expression of optimization problem 1 is:

minα ₁ Cost(t)+α ₂ T(t)

s.t.(1)-(16)

The expression of optimization problem 2 is:

minβ ₁ T(t)+β ₂ E(t)+β ₃ Cost(t)

s.t.(1)-(16)

Both problems are integer programming problems and can be directly input into the commercial solver Gurobi to obtain numerical solutions. The corresponding complete fault response process is shown in Figure 3. In addition, when solving optimization problem 2, you can directly use the commercial solver Gurobi; when solving optimization problem 1, if the fault response time requirements are particularly strict, you can use the suboptimal heuristic algorithm described below.

Step 5: Since the computational complexity of optimization problems under this architecture is relatively high, a suboptimal heuristic method as shown in Figure 4 is proposed. This method is suitable for fault handling scenarios that require stricter fault response time. Able to quickly respond to network traffic that changes over time, this solution is an adaptive method and is suitable for networks in actual factory scenarios. The specific steps are as follows:

S1, the fault detection component activates the fault response program. When solving optimization problem 1, the input of the algorithm is the attributes of the workflow set F _effected through the fault node or link and the current network topology G = {N, L} (if a certain When a node or link fails, the network topology and the set of microservices supported by the node may change), and then resources are allocated to each affected workflow f _i ∈ F _effected in turn.

S2, according to the link capacity constraint (1) and the transmission delay constraint (2), starting from the node CN currently executing m _a ∈ f _i , delete all links whose available capacity or transmission delay cannot meet the workflow requirements, and then get a List K. List K is the path from the current node CN to other nodes that support the currently required microservice ma ₊₁ .

S3, according to the node capacity constraint (4) and the processing delay constraint (5), delete the nodes whose available capacity or processing delay cannot meet the workflow requirements from the list K, and then select the new node with the shortest execution time and satisfying the failure probability constraint from K Node NN.

S4, add the path to the new node NN to the current path, and delete the current node from the network topology to prevent workflow loops. Loop S1-S4 until all microservices in workflow _fi are completed, and then go to S5.

S5, output the path of workflow _fi , which will be completed in the optimal execution time. Continue to allocate resources to the next affected workflow fi ₊₁ , and loop S1-S5 until all affected workflows are processed. Workflow to complete troubleshooting.

The preferred embodiments of the present invention are described in detail above. It should be understood that those skilled in the art can make many modifications and changes according to the concept of the present invention without creative efforts. Therefore, any technical solutions that can be obtained by those skilled in the art through logical analysis, reasoning or limited experiments based on the concept of the present invention and on the basis of the prior art should be within the scope of protection determined by the claims.

Claims (1)

1. A fault response method for the factory microservice system in the SDN-FOG environment, which is characterized by: Includes the following steps: Step 1. Establish a microservice system fault handling architecture based on SDN-FOG environment; Step 2. System modeling, describing the relationship between infrastructure, transmission network, and fog computing equipment; Step 3. Construct an integer programming problem. The two optimization goals are "fault handling" for fault recovery and "fault prevention" for periodic reconstruction; Step 4. Select the Gurobi solver to find the optimal solution to the fault prevention problem; Step 5. Use heuristic algorithms for "fault handling" problems; The microservice system fault handling architecture of step 1 based on SDN-FOG environment includes application layer, control layer and basic layer; The application layer includes fault handling programs, timers and functional programs; The control layer includes various components required for fault response solutions, including network monitoring components, fault detection components, node configuration components, and fault prevention components; In the base layer, switches that support SDN control are deployed. The switches have different failure probabilities in time slots. The central master controller is connected to the switches to summarize network topology and traffic information, and uses southbound interfaces to dynamically program and configure the switches; each The switch connects to a fog node and is combined into one node; each fog node corresponds to a set of industrial IoT devices and fog servers; The step 1 includes the following steps: Step 1.1. Sensors connected to factory field equipment continuously collect information. The sensor data is pre-processed and sent to the connected switch that supports SDN control; the network monitoring component collects node information including field equipment, fog nodes and switches from the switch. and link information, and sends the information to the application layer to continuously monitor network traffic; Step 1.2. The fault detection component determines whether a fault occurs in the transmission network based on the information collected by the network monitoring component; if a fault is detected at the switch or fog node or link, the network monitoring component will determine the current new network topology and the support of each fog node. The set of microservices is sent to the fault response program; Step 1.3. The fault response program calculates in real time and reallocates resources to the workflow passing through the faulty node or link; the node configuration component allocates resources to the workflow through the scheduling forwarding table and responds to the fault made by the fault response program in the application layer. Decisions are applied to switches and fog nodes; Step 1.4. Refresh the timer after the configuration is completed. If some microservices in the workflow cannot be completed due to some node or link failures, report the failure type and transfer to manual processing; Step 1.5. After a complete cycle of the timer, activate the fault prevention component, actively perform periodic reconstruction of the network, optimize the selected path of the workflow, improve the overall service quality and reduce the probability of failure; The step 2 includes the following steps: Step 2.1. Transmission network modeling: Establish network topology matrix and link propagation delay matrix; Step 2.2. Modeling of fog nodes and supported microservice sets: Use a matrix to represent the microservice set supported by each node, and logically group the microservices according to business requirements and quality requirements, corresponding to the microservice set supported by each fog node; Step 2.3. Workflow modeling: F is a collection of workflows. Each workflow contains the execution of a specific function. Workflow f∈F is an ordered tuple f={m ₁ ,m ₂ ,…,m _{| f-1|} ,m _|f| }, to execute a workflow, data must flow from the node that starts the workflow to the node that executes microservice m ₁ , and from there to the node that executes m ₂ , and so on, with the last item After the functional microservice m _|f-1| is completed, m _|f| indicates that the data needs to be returned to the factory equipment or delivered to the control layer; Step 2.4. Modeling of service quality indicators: network energy consumption, workflow response time, predefined thresholds for link failure probability, predefined thresholds for node failure probability, and rerouting costs; The step 3 includes the following steps: Step 3.1. Define decision variables: including workflow matrix, microservices that execute workflow, and network link resource allocation matrix; Step 3.2. Build resource constraints: including link capacity constraints between nodes, transmission delay constraints of each workflow in the link, failure probability constraints of links responding to workflows, and RAM capacity constraints of nodes that provide microservices. , the processing delay constraint of each workflow in the node, and the failure probability constraint of the node responding to the workflow; Step 3.3. Construct optimization objectives related to decision variables: including energy consumption, overall response time, and rerouting cost; Step 3.4. Construct constraints related to decision variables: including when the workflow reaches the node, the requested microservice is executed, ensuring that the workflow does not request the same microservice multiple times, and ensuring that the microservice is only executed on the node through which the workflow passes. When a node provides microservices to the workflow, the node is in a working state; Step 3.5. Construct the objective function: including network failure recovery and periodic network reconstruction; The steps of the heuristic algorithm are as follows: S1, the fault detection component activates the fault response program to solve the fault recovery problem. The input of the algorithm is the attributes of the workflow set through the fault node or link and the current network topology, and then allocates resources to each affected workflow in turn. ; S2, based on the link capacity constraint and transmission delay constraint, starting from the currently executing node, delete all links whose available capacity or transmission delay cannot meet the workflow requirements, and then obtain a list from the current node to other nodes that support the current The path to the node of the required microservice; S3, according to the node capacity constraint and processing delay constraint, delete the nodes whose available capacity or processing delay cannot meet the workflow requirements from the list, and then select a new node with the shortest execution time and satisfying the failure probability constraint; S4, add the path to the new node to the current path, and delete the current node from the network topology to prevent the workflow from looping; loop S1-S4 until all microservices in the workflow are completed, then go to S5; S5, output the path of the workflow, the workflow will be completed in the optimal execution time, continue to allocate resources to the next affected workflow, and loop S1-S5 until all affected workflows are processed and fault handling is completed.