Method and device for efficient scheduling of mimic web executors based on microservices
By adopting an efficient microservice-based scheduling method in the mimic web server, the problem of high operating costs of mimic web servers and difficult to quickly deploy a single-unit architecture in the prior art is solved, and the scheduling with high randomness and high heterogeneity is achieved, which improves the security and performance of mimic defense.
Patent Information
- Application Number
- CN202210638307.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-07
- Publication Date
- 2025-06-06
- Estimated Expiration
- 2042-06-07
AI Technical Summary
The executors of existing mimicry web servers are mainly based on physical machines and virtual machines, resulting in high operating costs and great performance impact. At the same time, the single-unit architecture is difficult to meet the requirements of rapid rotation cleaning and rapid deployment.
The microservice-based mimicry web execution body efficient scheduling method is adopted, and through the service registration center, dynamic scheduling components, service gateway, web module component pool and mimicry web execution body set, high randomness and high heterogeneity scheduling system are realized. The specific steps include collecting historical operation information, calculating security coefficients and differences values, determining survival time and call order, randomly replacing web modules, etc.
It realizes efficient scheduling of mimicry web services in a microservice environment, reduces operating costs and performance impacts, and enhances the overall security of mimicry defense.
Smart Images

Figure CN114936083B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of cyberspace security, and in particular to a method and device for efficient scheduling of a microservice-based mimicry web executor. Background Art
[0002] Web sites have become the main channel for people to obtain information. With the further advancement of digitalization, their importance is increasing day by day. As a platform for hosting and providing Internet websites and services, web servers have become the main target of network attacks. Various security issues such as tampering with web pages, backdoor implantation, DDoS attacks, etc. are emerging in an endless stream. Their security has received widespread attention in the field of cyberspace security.
[0003] Mimicry defense, as an emerging active defense technology, has been proven in many fields to effectively protect against unknown vulnerabilities and backdoors. Mimicry web server, as a typical application of mimicry defense in web security, has been applied in many important systems, and its security protection capabilities have also been verified. However, in the application practice of mimicry web server, the following problems have also been found. First, the current executor of mimicry web server is mainly based on physical machines and virtual machines, which makes the operation cost of mimicry web service expensive and lossy. It is difficult to apply and promote, and also has a great impact on the operation performance of web service. In addition, most of the current mimicry defense web servers still adopt a monolithic architecture, which is difficult to meet the requirements of rapid rotation and cleaning of mimicry on the one hand, and the modules in the executor are severely coupled on the other hand, which is difficult to meet the requirements of rapid construction and deployment of web executors. In response to this, industry researchers have proposed a mimicry defense construction technology based on microservices. The mimicry defense construction technology based on microservices can effectively decouple the modules, quickly locate problems, and facilitate the operation and maintenance of mimicry defense web servers. At the same time, by combining microservices and web front-end and back-end separation technology, the inconsistency problem of front-end interfaces between different executors can be effectively solved, further reducing the difficulty of developing mimic defense web services. Compared with the mimic executor of a monolithic architecture, the scheduling algorithm of the mimic web service based on microservices is much more complicated, specifically involving tasks such as the selection of executors, dynamic construction of executors, and dynamic cleaning and rotation.
[0004] Aiming at the problem that the current monolithic architecture mimetic scheduling technology is difficult to apply in microservice-based mimetic web services, and the lack of scheduling algorithms applied in current services, the present invention provides a method for efficient scheduling of mimetic web executors in a microservice environment. Summary of the invention
[0005] 1. Technical issues to be resolved
[0006] The technical problem to be solved by the present invention is how to provide a method for scheduling heterogeneous executors of a mimetic web server to solve the problem of low scheduling algorithm performance of mimetic web services under a microservice architecture.
[0007] (II) Technical solution
[0008] The first objective of the present invention is to solve the above technical problems and provide a method for efficient scheduling of a mimetic web executor based on microservices.
[0009] The method of the present invention performs scheduling in a mimetic web system based on microservices; the mimetic web system based on microservices includes a service registration center, a dynamic scheduling component, a service gateway, a web module component pool and a mimetic web execution body set. Among them:
[0010] The service registration center completes the registration function of the mimic web service and monitors the service status.
[0011] The dynamic scheduling component completes the construction process of the mimetic web service call chain. The web service call chain is the execution process of the microservice in the mimetic web system. The dynamic scheduling component is used to build the control relationship between each microservice and the request. The scheduling objects include the mimetic web execution body set and the web module component pool. The mimetic web execution body set contains multiple equivalent execution bodies with different structures and the same functions (for example, the business functions are the same, but the vulnerabilities, the languages used, the running status and other attributes are different). In the microservice scenario, the heterogeneous execution body is a web service call chain composed of heterogeneous web modules. In each layer of the web service call chain, the web module component pool of the current layer includes an active web module set and a callable backup web module set. The active web module refers to the web module that is currently working.
[0012] The service gateway completes the forwarding function of external requests.
[0013] In the process of composing a set of pseudo-web execution bodies by the scheduling method of the present invention, the high randomness and high heterogeneity of the composition result of the web service call chain are taken as the goal. In the rotation process of the execution body of the traditional pseudo-web system, the entire execution body is not replaced. Instead, when the survival time of a web module in the web service call chain is reached, the scheduling method of the present invention randomly selects a web module that can maintain the difference value to replace the original web module. The main steps of the method are as follows:
[0014] Step (1), collect the historical operation information and web module information of all web modules in the microservice and store them in the database; the web module information includes the number of vulnerabilities, vulnerability types, and programming languages of the web modules; according to the number of vulnerabilities and vulnerability types of the web modules, the vulnerability threat level evaluation score of the corresponding web modules is obtained in combination with the CVSS public vulnerability assessment system. i ;
[0015] Step (2): Calculate the safety factor of all web modules in the microservice
[0016] Step (3) calculates the difference between each web module in each layer of the service call chain and other web modules in the current service call chain layer; specifically:
[0017] According to the safety factor of the web module, the difference value C between each web module i and other web modules in the current service call chain layer is calculated:
[0018] C={c i,j |j=1,2,…,n,i≠j}
[0019] c i,j =s*e i,j
[0020] Where s represents the weighting coefficient;
[0021] Step (4), calculate the survival time
[0022] Step (5), determine the calling order of the web module, as follows:
[0023] 5-1 Send a query request to the database to obtain the calling information of the web module in the web module component pool; the calling information of the web module includes the calling status of the current web module, vulnerability information and type, programming language, and resource usage;
[0024] 5-2 Calculating the confidence of the web module
[0025] The web module first initializes the confidence when it is generated If the result of a web service call chain is abnormal, the abnormal web module i is determined through link tracking, and the confidence of the web module is reduced. Then determine whether the current web module confidence is greater than the preset confidence lower limit P d , if not, clean the current web module, if yes, rotate the current web module to the backup web module set, and jump to step 5-3; if all web service call chain results are normal, no additional processing is done, and jump to step 5-3;
[0026] 5-3 Calculate the difference between any two web modules in the same service call chain hierarchy
[0027] Calculate the difference between any two web modules i and j in the same service call chain hierarchy based on the query results of step 5-1 And written into the database, where P = [p 1 ,p 2 ,…,p t ] T represents the weight coefficient between web modules of all service call chains, and t represents the number of service call chain layers;
[0028] 5-4 determines whether the current web module has been used by a service call chain. If so, returns to step 5-3. If not, continues to determine whether the current service call chain continuously uses the same programming language. If so, returns to step 5-3. If not, jumps to step 5-5 to calculate the difference value between service call chains.
[0029] 5-5 Calculate the difference between service call chains
[0030] Randomly select b web modules in the same service call chain layer to form the backup web module set N of this layer in the current service call chain; according to the difference value ω between web modules at the same service call chain layer ij , calculate the difference h between different service call chains i and j ij :
[0031]
[0032] in represents the confidence of web module i, and b represents the total number of service call chains;
[0033] Step (6), calculate the comprehensive coefficient of the inactive web modules in the backup web module set
[0034] Calculate the scheduling time distance set T of all web modules in the backup web module set 1 =[t 1 ,t 2 ,…,t m ], normalize it to the interval [0,1], and calculate the comprehensive coefficient set S of the inactive web modules in the backup web module set ij ;
[0035]
[0036]
[0037] in, Indicates the current moment in the current microservice system. Represents web module n m The time when it was last called, m represents the number of inactive web modules in the backup web module set, Indicates T 1 The transpose of .
[0038] Step (7), calculate the random generated number interval of the backup web module
[0039] 7-1 According to the comprehensive coefficient set S ij Minimum value s min and the maximum value s max , normalize all comprehensive coefficients to the range of 0 to 1 to obtain s′ ij ; s′ ij Minimum value s′ min Zoom in to single digits to get the generation interval range Q of the jth inactive web module j in the i-th layer ij :
[0040] Q ij =s′ ij *G
[0041] Where G represents the magnification factor, usually a multiple of 10.
[0042] 7-2 According to the following formula, the maximum value of the inactive web module generation interval in the backup web module set is obtained, and finally the random number range interval (0, A] of the inactive web module j is formed;
[0043]
[0044] Where |N| represents the number of elements in the backup web module set N.
[0045] 7-3 Randomly generate a number interval (x) for each inactive web module in the backup web module set l ,y l ], l represents the lth inactive web module, y l =x l +Q ij ; If the backup web module set has a newly added l+1th inactive web module, the random number range interval is updated to (0, A] = (0, A + Q ij ];
[0046] Step (8): When the inactive web module i in the backup web module set reaches the survival time or the abnormal web module is cleaned off the line, a random number in the interval (0, A) is generated. If the random number falls in the interval (x l ,y l], the lth inactive web module in the backup web module set is called to replace the web module at the same level in the service call chain; if the difference between the service call chains after replacement and the difference between the service call chains before replacement is greater than the threshold H, the current scheduling is considered feasible, and the original web module a i Go offline or rejoin the backup web module set.
[0047] The second object of the present invention is to provide an efficient scheduling device for a mimetic web executor based on microservices, comprising:
[0048] Web module information database, which stores the historical operation information, web module information, and vulnerability threat level evaluation scores of all web modules in the microservices. i ;
[0049] The first calculation unit is used to calculate the safety factor of all web modules in the microservice web module component pool;
[0050] The second calculation unit calculates the difference value between any two web modules in each layer of the service call chain;
[0051] The third calculation unit is used to calculate the survival time of all web modules in the microservice web module component pool;
[0052] A web module scheduling strategy unit is used to determine the calling order of web modules in the web module component pool;
[0053] A fourth calculation unit calculates a comprehensive coefficient of inactive web modules in the backup web module set;
[0054] A fifth calculation unit, calculating a random generation number interval of a backup web module;
[0055] The web module scheduling unit is used to implement the calling of the active web module and the inactive web module according to the randomly generated number interval and number interval generated by the fifth calculation unit.
[0056] A third object of the present invention is to provide a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method described above.
[0057] A fourth object of the present invention is to provide a computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described is implemented.
[0058] Compared with the prior art, the present invention has the following beneficial effects:
[0059] (1) The present invention can complete mimetic scheduling with high randomness and high heterogeneity in mimetic web services based on microservices;
[0060] (2) The present invention proposes a method for calculating the survival time of each web module, which takes into account the security features of the web module while controlling the regular cleaning of the web module, thereby enhancing the overall security of the microservice-based mimicry defense web server. BRIEF DESCRIPTION OF THE DRAWINGS
[0061] Figure 1 is a flow chart of the method of the present invention;
[0062] Figure 2 The present invention is a flowchart of a method for determining a calling sequence of web modules.
[0063] Figure 3 It is a flow chart of the scheduling strategy of the web module of the present invention. DETAILED DESCRIPTION
[0064] The present invention will be further analyzed below in conjunction with the accompanying drawings.
[0065] like Figure 1 In the process of composing a set of pseudo-web execution bodies by the scheduling method of the present invention, the high randomness and high heterogeneity of the composition result of the web service call chain are taken as the goal. In the rotation process of the execution body of the traditional pseudo-web system, the entire execution body is not replaced. Instead, when the survival time of a web module in the web service call chain is reached, the scheduling method of the present invention randomly selects a web module that can maintain the difference value to replace the original web module. The main steps of the method are as follows:
[0066] Step (1), collect the historical operation information and web module information of all web modules in the microservice and store them in the database; the web module information includes the number of vulnerabilities, vulnerability types, and programming languages of the web modules; according to the number of vulnerabilities and vulnerability types of the web modules, the vulnerability threat level evaluation score of the corresponding web modules is obtained in combination with the CVSS public vulnerability assessment system. i ;
[0067] The historical operation information of the web module includes the CPU resources and memory resources occupied by the current web module, and the high concurrent access time;
[0068] The above-mentioned vulnerability numbers and types are derived from the CVSS public vulnerability assessment system. The rest of the web module information comes from known information and log information during web module runtime.
[0069] Step (2): Calculate the safety factor of all web modules in the microservice
[0070] 2-1 According to the number of vulnerabilities of all web modules in the web module component pool and their corresponding vulnerability types, obtain the number of common vulnerabilities n between backup web module i and backup web module j ij =|V i ∩V j |, where V i represents the vulnerability set of backup web module i, V j represents the vulnerability set of backup web module j, |·| represents the number-taking function;
[0071] 2-2 Evaluate the score based on the vulnerability threat level of the web module i , get the threat level evaluation score z of the common vulnerabilities of web module i and web module j x , and finally the safety factor e can be obtained i,j for:
[0072]
[0073] 2-3 According to the number and type of vulnerabilities in the web module, obtain the safety factor set E between each web module i and other web modules in the current call chain layer = {e i,j |j=1,2,…,n,i≠j}, n represents the number of web modules in the current call chain layer;
[0074] Step (3), calculate the difference between any two web modules in each layer of the service call chain
[0075] According to the safety factor of the web module, the difference value C between each web module i and other web modules in the current service call chain layer is calculated:
[0076] C={c i,j |j=1,2,…,n,i≠j}
[0077] c i,j =s*e i,j
[0078] Where s represents the weighting coefficient;
[0079] Step (4), calculate the survival time
[0080] Perform an attack test on each web module to obtain the average time it takes for an attacker to attack once And record the expected time for a successful attack as
[0081] according to The expected lifetime of the current web module i is obtained as
[0082] according to Then we can further get the expected probability density function μ of the expected survival time of the current web module i time and standard deviation σ time :
[0083]
[0084]
[0085] Where n represents the number of all web modules in the web module component pool.
[0086] We can further obtain the survival time probability density function of the current web module:
[0087]
[0088] Where x represents the actual lifetime of the current web module.
[0089] The survival time corresponding to the current web module is randomly generated according to this probability density function f(x).
[0090] Step (5), determine the calling order of the web modules, such as Figure 2
[0091] When calling a web module, it is necessary to ensure the differences between web modules in the same service call chain layer and the non-homology of adjacent web modules in the service call chain, so as to determine the calling order of each web module, as follows:
[0092] 5-1 Send a query request to the database to obtain the calling information of the web module in the web module component pool; the calling information of the web module includes the calling status of the current web module, vulnerability information and type, programming language, and resource usage;
[0093] 5-2 Calculating the confidence of the web module
[0094] The web module first initializes the confidence when it is generated If the result of a web service call chain is abnormal, the abnormal web module i is determined through link tracking, and the confidence of the web module is reduced. Then determine whether the current web module confidence is greater than the preset confidence lower limit P d , if not, clean the current web module, if yes, rotate the current web module to the backup web module set, and jump to step 5-3; if all web service call chain results are normal, no additional processing is done, and jump to step 5-3;
[0095] 5-3 Calculate the difference between any two web modules in the same service call chain hierarchy
[0096] Calculate the difference between any two web modules i and j in the same service call chain hierarchy based on the query results of step 5-1 And written into the database, where P = [p 1 ,p 2 ,…,p t ] T represents the weight coefficient between web modules of all service call chains, and t represents the number of service call chain layers;
[0097] 5-4 determines whether the current web module has been used by a service call chain. If so, returns to step 5-3. If not, continues to determine whether the current service call chain continuously uses the same programming language. If so, returns to step 5-3. If not, jumps to step 5-5 to calculate the difference value between service call chains.
[0098] 5-5 Calculate the difference between service call chains
[0099] Randomly select b web modules in the same service call chain layer to form the backup web module set N of this layer in the current service call chain; according to the difference value ω between web modules at the same service call chain layer ij , calculate the difference h between different service call chains i and j ij :
[0100]
[0101] in represents the confidence of web module i, and b represents the total number of service call chains;
[0102] The result of the above web service call chain can be judged by a voter.
[0103] In order to ensure the heterogeneity of the final executable body, the following principles are used to select the backup web module: first, each web module can be used by only one service call chain; second, the same programming language cannot be used continuously in a service call chain.
[0104] Step (6), calculate the comprehensive coefficient of the inactive web modules in the backup web module set
[0105] Calculate the scheduling time distance set T of all web modules in the backup web module set 1 =[t 1 ,t 2 ,…,t m ], normalize it to the interval [0,1], and calculate the comprehensive coefficient set S of the inactive web modules in the backup web module set ij ;
[0106]
[0107]
[0108] in, Indicates the current moment in the current microservice system. Represents web module n m The time when it was last called, m represents the number of inactive web modules in the backup web module set, Indicates T 1 The transpose of .
[0109] Step (7), calculate the random generated number interval of the backup web module
[0110] 7-1 According to the comprehensive coefficient set S ij Minimum value s min and the maximum value s max , normalize all comprehensive coefficients to the range of 0 to 1 to obtain s′ ij ; s′ ij Minimum value s′ min Zoom in to single digits to get the generation interval range Q of the jth inactive web module j in the i-th layer ij :
[0111] Q ij =s′ ij *G
[0112] Where G represents the magnification factor, usually a multiple of 10.
[0113] 7-2 According to the following formula, the maximum value of the inactive web module generation interval in the backup web module set is obtained, and finally the random number range interval (0, A] of the inactive web module j is formed;
[0114]
[0115] Where |N| represents the number of elements in the backup web module set N.
[0116] 7-3 Randomly generate a number interval (x) for each inactive web module in the backup web module set l ,y l ], l represents the lth inactive web module, y l =x l +Q ij ; If the backup web module set has a newly added l+1th inactive web module, the random number range interval is updated to (0, A] = (0, A + Q ij ];
[0117] Step (8), such as Figure 3 , when the inactive web module i in the backup web module set reaches the survival time or the abnormal web module is cleaned off the line, a random number in the range of (0, A] is generated. If the random number falls in the range of (x l ,y l ], the lth inactive web module in the backup web module set is called to replace the web module at the same level in the service call chain; if the difference between the service call chains after replacement and the difference between the service call chains before replacement is greater than the threshold H, the current scheduling is considered feasible, and the original web module a i Go offline or rejoin the backup web module set.
Claims
1. A method for efficient scheduling of mimetic web executors based on microservices, Features The following steps are involved: Step (1) collects the historical operation information and web module information of all web modules in the microservice, and obtains the vulnerability threat level evaluation score z according to the number and type of vulnerabilities in the web module. i , stored in a database; the web module information includes the number of vulnerabilities, the type of vulnerabilities, and the programming language of the web module; Step (2) calculates the safety factor of all web modules in the microservice web module component pool; specifically: 2-1 According to the number of vulnerabilities of all web modules in the web module component pool and their corresponding vulnerability types, obtain the number of common vulnerabilities n between backup web module i and backup web module j ij =|V i ∩V j |, where V i represents the vulnerability set of backup web module i, V j represents the vulnerability set of backup web module j, |·| represents the number-taking function; 2-2 Evaluate the score based on the vulnerability threat level of the web module i , get the threat level evaluation score z of the common vulnerabilities of web module i and web module j x , and then get the safety factor e i,j for: 2-3 According to the number and type of vulnerabilities in the web module, obtain the safety factor set E between each web module i and other web modules in the current service call chain layer = {e i,j |j=1,2,…,n,i≠j}, n represents the number of web modules in the current service call chain layer; Step (3) calculates the difference between each web module in each layer of the service call chain and other web modules in the current service call chain layer; specifically: According to the safety factor of the web module, the difference value C between each web module i and other web modules in the current service call chain layer is calculated: C={c i,j |j=1,2,…,n,i≠j} c i,j =s*e i,j Where s represents the weighting coefficient; Step (4), calculate the survival time of each web module; specifically: perform an attack test on each web module and obtain the average time spent by the attacker for one attack And record the expected time for a successful attack as according to The expected lifetime of the current web module i is obtained as according to Then we can further get the expected probability density function μ of the expected survival time of the current web module i time and standard deviation σ time : Where n represents the number of all web modules in the web module component pool; Further obtain the survival time probability density function of the current web module: Where x represents the actual survival time of the current web module; According to this probability density function f(x), the survival time corresponding to the current web module is randomly generated; Step (5) determines the calling order of the web modules in the web module component pool, as follows: 5-1 Send a query request to the database to obtain the calling information of the web module in the web module component pool; the calling information of the web module includes the calling status of the current web module, vulnerability information and type, programming language, and resource usage; 5-2 Calculating the confidence of the web module The web module first initializes the confidence when it is generated If the result of a web service call chain is abnormal, the abnormal web module i is determined through link tracking, and the confidence of the web module is reduced. Then determine whether the current web module confidence is greater than the preset confidence lower limit P d , if not, clean the current web module, if yes, rotate the current web module to the backup web module set, and jump to step 4-3; if all web service call chain results are normal, no additional processing is done, and jump to step 4-3; 5-3 Calculate the difference between any two web modules in the same service call chain hierarchy Calculate the difference between any two web modules i and j in the same service call chain hierarchy based on the query results of step 5-1 And written into the database, where P=[p 1 ,p 2 ,…,p t ] T represents the weight coefficient between web modules of all service call chains, and t represents the number of service call chain layers; 5-4 determines whether the current web module has been used by a service call chain. If so, returns to step 5-3. If not, continues to determine whether the current service call chain continuously uses the same programming language. If so, returns to step 5-3. If not, jumps to step 5-5 to calculate the difference value between service call chains. 5-5 Calculate the difference between service call chains Randomly select b web modules in the same service call chain layer to form the backup web module set N of this layer in the current service call chain; according to the difference value ω between web modules at the same service call chain layer ij , calculate the difference h between different service call chains i and j ij : in represents the confidence of web module i, and b represents the total number of service call chains; Step (6), calculate the comprehensive coefficient of the inactive web modules in the backup web module set Calculate the scheduling time distance set T of all web modules in the backup web module set 1 =[t 1 ,t 2 ,…,t m ], normalize it to the interval [0,1], and calculate the comprehensive coefficient set S of the inactive web modules in the backup web module set ij ; in, Indicates the current moment in the current microservice system. Represents web module n m The time when it was last called, m represents the number of inactive web modules in the backup web module set, Indicates T 1 The transpose of Step (7), calculate the random generated number interval of the backup web module 7-1 According to the comprehensive coefficient set S ij Minimum value s min and the maximum value s max , normalize all comprehensive coefficients to the range of 0 to 1 to obtain s′ ij ; s′ ij Minimum value s' min Zoom in to single digits to get the generation interval range Q of the jth inactive web module j in the i-th layer ij : Q ij =s′ ij *G Where G represents the magnification factor, usually a multiple of 10; 7-2 According to the following formula, the maximum value of the inactive web module generation interval in the backup web module set is obtained, and finally the random number range interval (0, A] of the inactive web module j is formed; Where |N| represents the number of elements in the backup web module set N; 7-3 Randomly generate a number interval (x) for each inactive web module in the backup web module set l ,y l ], l represents the lth inactive web module, y l =x l +Q ij ; If the backup web module set has a newly added l+1th inactive web module, the random number range interval is updated to (0, A] = (0, A + Q ij ]; Step (8): When the inactive web module i in the backup web module set reaches the survival time or the abnormal web module is cleaned off the line, a random number in the interval (0, A) is generated. If the random number falls in the interval (x l ,y l ], then the lth inactive web module in the backup web module set is called to replace the web module at the same level in the service call chain; if the difference between the difference values between the service call chains after replacement and the difference values between the service call chains before replacement is greater than the threshold H, then the current scheduling is considered feasible, and the original web module is offline or rejoined to the backup web module set.
2. The method according to claim 1, Features Step (1) The historical operation information of the web module includes the CPU resources and memory resources occupied by the current web module and the high concurrent access time.
3. A device for efficiently scheduling a microservice-based mimetic web execution body according to any one of claims 1 to 2, Features include: Web module information database, which stores the historical operation information, web module information, and vulnerability threat level evaluation scores of all web modules in the microservices. i ; The first calculation unit is used to calculate the safety factor of all web modules in the microservice web module component pool; The second calculation unit calculates the difference value between any two web modules in each layer of the service call chain; The third calculation unit is used to calculate the survival time of all web modules in the microservice web module component pool; A web module scheduling strategy unit, used to determine the calling order of web modules in the web module component pool; A fourth calculation unit calculates a comprehensive coefficient of inactive web modules in the backup web module set; A fifth calculation unit, calculating a random generation number interval of a backup web module; The web module scheduling unit is used to implement the calling of active web modules and inactive web modules according to the randomly generated number interval and number interval generated by the fifth computing unit.
4. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 2.
5. A computing device, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 2 is implemented.
Citation Information
Patent Citations
Scenario-based dynamic scheduling method for heterogeneous execution of mimic web server
CN109218440A
Executor service function recursive mimicry system and method
CN111935103A