CN117370134A - Micro service performance evaluation method and device, electronic equipment and storage medium - Google Patents

Abstract

The present disclosure relates to a method, an apparatus, an electronic device, and a storage medium for evaluating micro-service performance, where the method includes: monitoring the running process of the micro-service system to obtain perceived topology information; the perceived topology information covers at least one topology relation of resource scheduling and service calling of micro services in the micro service system; constructing fault simulation information according to the perceived topology information; performing fault scene simulation in the micro-service system according to the fault simulation information; and analyzing real-time performance data of the preset monitoring index before, during and after the fault scene simulation to obtain the stability evaluation result of the micro-service system. The scheme realizes automatic fault scene simulation and automatic evaluation of the stability of the micro-service system, and the evaluation result is more accurate.

Description

Microservice performance evaluation methods, devices, electronic equipment and storage media

Technical field

The present disclosure relates to the technical field of microservices, and in particular, to a method, device, electronic device and storage medium for evaluating the performance of microservices.

Background technique

A microservice system is a collection of multiple microservices. It is a form of software architecture that can be flexibly organized, upgraded and iterated. The functions of a complex application software can be realized by splitting multiple microservices. Each microservice can be deployed, run and upgraded independently and can be developed independently using different development languages. It has the advantages of flexible expansion and convenient maintenance. In the process of realizing the required functions of the microservice system, if one or more microservices fails, it may cause the entire microservice system to be unavailable or have its functions affected. Therefore, it is necessary to conduct stability testing and evaluation of the microservice system. .

In the process of realizing the concept of the present disclosure, the inventor found that there are at least the following technical problems in related technologies: in related technologies, most of them require technicians to manually set test rules and manually conduct stability testing of microservice systems, and writing test rules The premise is that technical personnel need to be proficient in the relevant knowledge of the microservice system and be able to design appropriate test cases. This is highly demanding for technical personnel, time-consuming and labor-intensive. The way of preset test rules and test cases will also cause testing And the evaluation is not comprehensive, and it is impossible to adapt the test according to the actual operating scenario, and the accuracy of the evaluation needs to be improved.

Contents of the invention

In order to solve the above technical problems or at least partially solve the above technical problems, embodiments of the present disclosure provide a microservice performance evaluation method, device, electronic device and storage medium.

In the first aspect, embodiments of the present disclosure provide a method for evaluating microservice performance. The above evaluation method includes: monitoring the operation process of the microservice system to obtain perceived topology information; the above perceived topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the above microservice system; based on the above perceived topology information, Construct fault simulation information; perform fault scenario simulation in the above microservice system based on the above fault simulation information; analyze the real-time performance data of preset monitoring indicators before, during and after the fault scenario simulation to obtain the above microservice system stability evaluation results.

According to an embodiment of the present disclosure, constructing fault simulation information based on the above-mentioned sensing topology information includes: determining a target object that needs to be fault simulated based on the above-mentioned sensing topology information and a preset fault type; for the above-mentioned target object, constructing the same as the above-mentioned preset Fault simulation content corresponding to the fault type; wherein the above fault simulation information includes the above target object and the above fault simulation content.

According to embodiments of the present disclosure, the above-mentioned preset fault types include at least one of the following fault types: instance down, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking, dependent service unavailability Use and rely on service delays.

According to an embodiment of the present disclosure, the above-mentioned sensing topology information includes: node information of the first microservice node with a call dependency relationship, and call dependency relationships between the first microservice nodes. Among them, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes: when the above-mentioned preset fault type is the first fault type, based on the above-mentioned calling dependency relationship and the above-mentioned first microservice The node information of the node determines the first target microservice node for fault simulation; the above-mentioned first fault type includes at least one of the following: dependent service unavailability, dependent service delay; for the above-mentioned target object, construct the above-mentioned preset fault type The corresponding fault simulation content includes: constructing fault simulation content corresponding to the above-mentioned first fault type for the above-mentioned first target microservice node.

According to an embodiment of the present disclosure, the above-mentioned sensing topology information includes: the above-mentioned sensing topology information includes: node information of the second microservice node deployed in the above-mentioned microservice system, and the allocation topology relationship and priority of the second microservice node for resource scheduling. information. Among them, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes: when the above-mentioned preset fault type is the second fault type, based on the node information of the above-mentioned second microservice node and The above priority information determines the second target microservice node for fault simulation; or, based on the node information of the above second microservice node, the above priority information and the above distribution topology relationship, determines the second target microservice for fault simulation. node. The above-mentioned second fault type includes at least one of the following: instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, and process blocking. Constructing fault simulation content corresponding to the above preset fault type for the above target object includes: constructing fault simulation content corresponding to the above second fault type for the above second target microservice node.

According to embodiments of the present disclosure, the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation are analyzed to obtain the stability evaluation results of the above-mentioned microservice system, including: changes to the above-mentioned real-time performance data Analyze the rules to obtain real-time damage degree information of each fault scenario to the steady state of the microservice system during and after the fault scenario simulation; determine each fault based on the preset assigned score of each fault scenario and the above real-time damage degree information Stability score under the scenario; based on the above stability score and the pre-assigned weight of each failure scenario, a comprehensive stability score of the above microservice system is generated, and the above comprehensive stability score is used as the above stability evaluation result.

According to an embodiment of the present disclosure, the above-mentioned evaluation method further includes: obtaining the first historical status data of each microservice in the above-mentioned microservice system when it is in a steady state of operation and the second historical status data corresponding to an abnormality; according to the above-mentioned first history The status data and the above-mentioned second historical status data determine the candidate monitoring indicators used to represent the operation status of the microservice; the above-mentioned candidate monitoring indicators are used as indicator options corresponding to each microservice in the indicator configuration interface; receive the user's input in the above-mentioned indicator configuration interface For the selection information and custom indicator information of indicator options; based on the above selection information and the above custom indicator information, generate preset monitoring indicators corresponding to each microservice.

In the second aspect, embodiments of the present disclosure provide an evaluation device for microservice performance. The above-mentioned evaluation device includes: a monitoring module, a construction module, a fault simulation module and an evaluation module. The above-mentioned monitoring module is used to monitor the operation process of the microservice system and obtain perceptual topology information; the above-mentioned perceptual topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the above-mentioned microservice system. The above building modules are used to construct fault simulation information based on the above sensing topology information. The above fault simulation module is used to simulate fault scenarios in the above microservice system based on the above fault simulation information. The above-mentioned evaluation module is used to analyze the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation to obtain the stability evaluation results of the above-mentioned microservice system.

In a third aspect, embodiments of the present disclosure provide an electronic device. The above-mentioned electronic equipment includes a processor, a communication interface, a memory and a communication bus. The processor, communication interface and memory complete communication with each other through the communication bus; the memory is used to store computer programs; the processor is used to execute everything on the memory. When storing programs, implement the evaluation method of microservice performance as mentioned above.

In a fourth aspect, embodiments of the present disclosure provide a computer-readable storage medium. The computer program is stored on the computer-readable storage medium. When the computer program is executed by the processor, the evaluation method of microservice performance as described above is implemented.

The above technical solutions provided by the embodiments of the present disclosure have at least some or all of the following advantages:

By monitoring the running process of the microservice system, the sensing topology information is obtained. Since the above sensing topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the above microservice system, multiple microservices can be automatically sensed. At least one of the allocation topology relationship and relative priority in the resource scheduling process, and the network topology relationship in the service invocation process of microservices; then the fault scenario simulation based on the fault simulation information constructed based on the above-mentioned perceived topology information can be more accurate. Simulate various fault scenarios that may occur during the operation of the microservice system, analyze the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation, and obtain the stability evaluation of the above microservice system. The result is also more accurate and complete. The above solution automatically simulates fault scenarios and automatically evaluates the stability of the microservice system. The evaluation results are more accurate. Compared with the solution that manually sets test rules and test cases and manually conducts stability testing of the microservice system, it reduces the cost. It improves the technical threshold for testers and improves the automation of testing and the accuracy of test results.

Description of the drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure.

In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or related technologies will be briefly introduced below. It is obvious to those of ordinary skill in the art that , other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 schematically shows the system architecture of a microservice performance evaluation method suitable for embodiments of the present disclosure;

Figure 2 schematically shows a flow chart of a method for evaluating microservice performance according to an embodiment of the present disclosure;

Figure 3 schematically shows a detailed implementation flow chart of step S220 according to an embodiment of the present disclosure;

Figure 4A schematically shows a schematic diagram of the implementation process of steps S310 and S320 according to an embodiment of the present disclosure;

Figure 4B schematically shows a schematic diagram of the implementation process of steps S310 and S320 according to another embodiment of the present disclosure;

Figure 5 schematically shows a flow chart of a method for evaluating microservice performance according to another embodiment of the present disclosure;

Figure 6 schematically shows a structural block diagram of a microservice performance evaluation device according to an embodiment of the present disclosure;

FIG. 7 schematically shows a structural block diagram of an electronic device provided by an embodiment of the present disclosure.

Detailed ways

In order to make the purpose, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments These are some, but not all, of the embodiments of the present disclosure. Based on the embodiments in this disclosure, all other embodiments obtained by those of ordinary skill in the art without any creative efforts fall within the scope of protection of this disclosure.

A first exemplary embodiment of the present disclosure provides a method for evaluating microservice performance.

Figure 1 schematically shows the system architecture of a microservice performance evaluation method suitable for embodiments of the present disclosure.

In the embodiments of the present disclosure, a collection of multiple microservices required by application software to implement one or more functions (for example, a certain business function) is described as a microservice system. Referring to FIG. 1 , the system architecture 100 suitable for the microservice performance evaluation method according to the embodiment of the present disclosure includes: a microservice system 110 and a performance evaluation application 120 , where the microservice system 110 can be deployed based on various methods, for example, including But it is not limited to the following deployment methods: single-machine multi-process deployment method, multi-machine multi-process deployment method, container-based deployment method, container orchestrator-based (for example, deployment based on k8s) deployment method, cloud function-based (for example, API function) ) deployment method.

The above single-machine multi-process deployment method uses multiple microservices as multiple processes in a single server.

Multi-machine multi-process deployment is an upgraded version of single-machine multi-process deployment, which achieves high availability and scalability by providing multiple servers.

The container-based deployment method is to package microservices in containers for deployment. It has high concurrency and can run multiple instances in the container image without causing conflicts.

The deployment method based on the container orchestrator is based on the container orchestrator for container deployment and resource scheduling. For example, taking the k8s (abbreviation for kubernetes) container orchestrator as an example, the smallest running unit pod (pod is the smallest resource management component in kubernetes, It is also a resource object that minimizes running containerized applications) and is scheduled to a worker node. A pod can contain one or more containers. Each container is used to run a microservice, and the pod serves as a process running in the cluster.

The deployment method based on cloud functions is to construct each microservice as a cloud function interface, and when the microservice needs to be called, the service can be called based on the corresponding interface. The embodiments of this disclosure do not limit the specific deployment method of the microservice system.

The above-mentioned performance evaluation application 120 is used to execute the evaluation method of microservice performance provided by embodiments of the present disclosure, and can automatically simulate fault scenarios and automatically evaluate the stability of the microservice system. The above-mentioned performance evaluation application 120 can be installed on the server corresponding to the microservice system, and the server serves as an example of a microservice performance evaluation device. The server installed by the performance evaluation application 120 may specifically be, but is not limited to: a host (corresponding to a single-machine multi-process deployment method), a master node of a service cluster (a multi-machine multi-process deployment method), a service node running a container, or a server with a container. Orchestrator and master node for resource scheduling and control, or cloud server management and control device, etc.

The above microservices include but are not limited to various types of services, which can be adapted to the needs of business applications, operational applications, development applications, testing applications, operation and maintenance applications, etc., such as: login services, face recognition services, identity authentication services, authority allocation services, AI algorithm services, order services, logistics services, payment services, etc.

Figure 2 schematically shows a flow chart of a method for evaluating microservice performance according to an embodiment of the present disclosure.

Referring to Figure 2, the evaluation method of microservice performance provided by the embodiment of the present disclosure includes the following steps: S210 to S240.

In step S210, the running process of the microservice system is monitored to obtain perceptual topology information; the perceptual topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the microservice system.

In some embodiments, the above-mentioned perceived topology information can be obtained by monitoring at least one of the running processes of resource invocation and service invocation during the operation of the microservice system.

The above-mentioned microservice system 110 includes multiple microservices, such as microservice 1, microservice 2, and microservice 3 illustrated in Figure 1. When implementing one or more functions of application software, there will be a process in which microservices call other services. In some embodiments, it can be adapted to the deployment mode of the microservice system, on the host, the main node of the service cluster, the service node running the container, the main node with a container orchestrator and resource scheduling management and control, or the management and control device of the cloud server. Wait for the first sensing module to be installed on the server. The first sensing module is used to sense service calls and construct network call links when a service call occurs in a certain microservice (for example, during the execution of the login microservice The face recognition service and verification code service must be called, the order microservice must call the payment service during the order settlement process), and multiple network call links must be integrated to obtain the network topology relationship of the microservice system during the service call process. For example, during the execution of the login microservice, the verification code service and the face recognition service need to be called. When the service call is detected, the relationship between the login microservice and the verification code service, and the login microservice and the face recognition service will be constructed. network call link. The order microservice needs to call the payment service during the order settlement process. When the service call is detected, a network call link between the order microservice and the payment service will be constructed.

When implementing one or more functions of application software, there will also be resource scheduling situations. Multiple microservices serve as processes (corresponding to single-machine multi-process deployment mode, multi-machine multi-process deployment mode), container microservices (corresponding to based on During the process of running or being called, there will be changes to the CPU, memory, input and output (IO), Scheduling of network, disk and other resources. In some embodiments, it can be adapted to the deployment mode of the microservice system, on the host, the main node of the service cluster, the service node running the container, the main node with a container orchestrator and resource scheduling management and control, or the management and control device of the cloud server. Wait for the second sensing module to be installed on the server. The second sensing module is used to sense resource scheduling, construct the allocation topology relationship when scheduling resources to a certain microservice, and based on the monitored resource scheduling logic. Determine the relative priority of individual microservices in resource allocation. For example, when microservices 1 to 3 all apply for kernel resources, allocate the T1 to T2 (for example, the left-closed and right-open interval, excluding the right endpoint value) period of CPU1 in the dual-core operating system to microservice 1. Allocate the T1~T3 period of CPU2 to microservice 2, during which microservice 3 is in a scheduling waiting state. When microservice 1 releases the kernel resources, allocate the T2~T4 period of CPU1 to microservice 3; it can be constructed according to the resource scheduling situation Allocate topological relationships, and at the same time, according to the high-priority resource allocation logic, it can be determined that the priority of microservice 1 is higher than the priority of microservice 3.

In step S220, fault simulation information is constructed based on the above perceived topology information.

Since the above-mentioned sensing topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the above-mentioned microservice system, it can automatically sense the distribution topology relationship and relative priority of multiple microservices in the resource scheduling process, and the microservices' resource scheduling and service invocation. If the service has at least one network topology relationship in the process of calling the service, then fault scenario simulation based on the fault simulation information constructed from the above sensing topology information can more accurately simulate various fault scenarios that may occur during the operation of the microservice system. .

In step S230, fault scenario simulation is performed in the microservice system based on the above fault simulation information.

Fault simulation can also be called fault drill. It is a practice that follows the principles of chaos engineering. It simulates various abnormal states that may occur in the production system by arranging various types of faults in the form of software. Based on the analysis and response to the abnormal state, further Optimize the microservice architecture, resource scheduling or processing logic to help improve the fault tolerance of the microservice system and avoid the catastrophic consequences of real emergencies.

In some embodiments, the above fault simulation information includes: the target object that needs to be fault simulated and the fault simulation content. The above fault simulation content can correspond to the following fault types: instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking, dependent service unavailability, dependent service delay, etc.; fault simulation content Specific information includes but is not limited to: simulation parameters for fault simulation, simulation duration, simulation frequency, fault simulation trigger conditions and other information.

In some embodiments, individual fault scenarios can be simulated one by one to test the response capability and stability of the microservice system under a single fault; multiple fault scenarios can also be combined for simulation to test the comprehensive performance of the microservice system. Coping ability and stability under failure.

In step S240, the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation are analyzed to obtain the stability evaluation results of the above-mentioned microservice system.

The above-mentioned preset monitoring indicators are indicators related to the functional evaluation of microservices. For example, they can be indicators that can have objective change patterns (repeatable implementation) as fault scenarios occur and can reflect changes in microservice performance, so that The stability of the microservice system can be evaluated based on changes in these preset monitoring indicators. For order services, the corresponding preset monitoring indicators include but are not limited to: order success rate, whether the page display is normal, whether the payment page jumps normally, whether the payment is successful, etc.

In some embodiments, the real-time performance data of the microservice system before, during, and after fault scenario simulation is scored based on a preset scoring algorithm. The real-time performance data corresponding to each preset monitoring indicator is used as the input of the scoring algorithm. The scoring algorithm outputs the stability score at each moment during and after the simulation of each fault scenario.

In some embodiments, the above-mentioned scoring algorithm can mainly perform scoring based on the importance of the fault, the degree of damage caused by the fault to the business steady-state indicators, and other related factors.

In the above step S240, the real-time performance data of the preset monitoring indicators before, during and after the simulation of the fault scenario are analyzed to obtain the stability evaluation results of the above-mentioned microservice system, including: analyzing the change rules of the above-mentioned real-time performance data. Analyze and obtain the real-time damage degree information of each fault scenario to the steady state of the microservice system during and after the fault scenario simulation; based on the preset distribution score of each fault scenario and the above real-time damage degree information, determine the damage level of each fault scenario. Stability score; based on the above stability score and the pre-assigned weight of each failure scenario, a comprehensive stability score of the above microservice system is generated, and the above comprehensive stability score is used as the above stability evaluation result.

The steady state of microservice system operation means that the business, function or operation of the microservice system is in a healthy and stable state. As the simulation of the fault scenario progresses, the changes in the real-time performance data corresponding to the preset monitoring indicators will show certain patterns, such as changing in the direction of deterioration. Consider the impact of the deterioration of the real-time performance data on the performance of the microservice system. If it affects If it is larger, the damage degree represented by the corresponding real-time damage degree information will also be larger. For example, in the process of implementing the order function of the microservice system, in the process of simulating a fault scenario in which the payment service function that the order microservice relies on is unavailable, the corresponding order success rate, whether the page display is normal, and payment Indicators such as whether page jump is normal and payment is successful will change accordingly. For example, whether the payment page jump is normal and payment is successful, the data of these two monitoring indicators will change from normal jump to no jump, payment exception, etc. In this way, real-time damage degree information of the steady state of the microservice system can be obtained. In some embodiments, the score and the change trend of the score can be divided according to the correlation degree of the preset monitoring index to stability. The greater the correlation, the more scores are divided. The change of the monitoring index after the fault scenario can be It is a qualitative change or a quantitative change. For qualitative changes, the score can be divided into corresponding grade intervals; for quantitative changes, the specific score can be linearly adjusted according to the degree of quantitative change.

In some embodiments, similar faults can be divided into one major category, and scores can be evenly distributed among multiple major categories of faults. For example, according to the full score of 100 points in the steady state of operation, there are a total of 4 major categories of faults. The total score of each fault category is 25 points, which indicates the stable operation status of the microservice system under this fault category; if there are multiple faults under each fault category, the specific score assigned to each fault can be flexibly allocated. It can be distributed evenly or assigned corresponding scores according to the relative importance of different faults, actual frequency of occurrence, etc. In some embodiments, the preset assigned score of a certain fault scenario × (1 - real-time damage degree information (for example, it can be in the form of a percentage)) = the stability score under the fault scenario. In some embodiments, the preset assigned score of a certain fault scenario × (1 - real-time damage degree information (for example, it can be in the form of a percentage)) × adjustment coefficient = stability score under the fault scenario; the above adjustment coefficient is expressed by In order to adjust the accuracy of the stability score, adjustments and optimizations can be made based on the gap between the simulation results and the performance of the actual fault scenario.

In some embodiments, generating a comprehensive stability score of the above-mentioned microservice system based on the above-mentioned stability score and the pre-assigned weights of each failure scenario includes: calculating the relationship between the stability score under each failure scenario and the respective corresponding weights. Weighted sum, which serves as a comprehensive score for the stability of the microservice system.

In the embodiment including steps S210 to S240, the perceptual topology information is obtained by monitoring the running process of the microservice system, because the above perceptual topology information covers at least one topology of resource scheduling and service invocation of microservices in the above microservice system. Relationship, can automatically sense at least one of the distribution topology relationship and relative priority of multiple microservices in the process of resource scheduling, and the network topology relationship in the process of microservices calling services; then the system constructed based on the above perceived topology information Using fault simulation information to simulate fault scenarios can more accurately simulate various fault scenarios that may occur during the operation of the microservice system, and analyze the real-time performance data of preset monitoring indicators before, during and after the fault scenario simulation. , the obtained stability evaluation results of the above-mentioned microservice system are also more accurate and complete. The above solution automatically simulates fault scenarios and automatically evaluates the stability of the microservice system. The evaluation results are more accurate. Compared with the solution that manually sets test rules and test cases and manually conducts stability testing of the microservice system, it reduces the cost. It improves the technical threshold for testers and improves the automation of testing and the accuracy of test results.

FIG. 3 schematically shows a detailed implementation flow chart of step S220 according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, referring to FIG. 3 , the above-mentioned step S220 constructs fault simulation information based on the above-mentioned sensing topology information, including the following steps: S310 and S320.

In step S310, the target object that needs to be fault simulated is determined based on the above-mentioned perceived topology information and the preset fault type.

According to embodiments of the present disclosure, the above-mentioned preset fault types include at least one of the following fault types: instance down, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking, dependent service unavailability Use and rely on service delays. The above preset fault types support configuration and customization, and users can set the fault types through the visual interface of the performance evaluation application.

In step S320, for the above target object, fault simulation content corresponding to the above preset fault type is constructed.

For fault types such as instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking, etc., it is necessary to use the perceived topology information corresponding to resource scheduling, because it is necessary to determine in advance which objects will be targeted for fault simulation. and detection of monitoring indicators. For example, if there are one or more containers in a pod (each container is used to run a microservice), and the pod is a process running in the cluster, it is necessary to perform CPU failure simulation, memory failure simulation, etc. for a certain pod. Based on the perceived allocation topology relationship and relative priority of resource scheduling, the object that needs to simulate faults is first located, and then the fault simulation is performed. That is, the pre-perceived topological relationship needs to be used to determine the object for which the fault is simulated (for example, which object specifically needs to be simulated for various faults).

For failure types such as dependent service unavailability and dependent service delay, it is necessary to use the sensing topology information corresponding to the service call, because it is necessary to determine in advance which dependent services should be simulated for service unavailability or delay simulation.

In the embodiment including the above steps S310 and S320, by perceiving at least one topological relationship between resource scheduling and service invocation of microservices in the microservice system and utilizing these topological relationships, the fault can be relatively objectively and accurately located. The simulated target object is simulated and the corresponding fault scenario is simulated, which effectively improves the fit between the simulated fault and the real fault scenario, so that the real-time performance data of the preset monitoring indicators in the fault simulation is closer to the reaction state in the real fault scenario. , improve the accuracy of microservice system stability evaluation.

FIG. 4A schematically shows a schematic diagram of the implementation process of steps S310 and S320 according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, with reference to FIG. 4A , the above-mentioned sensing topology information includes: node information of the first microservice node with a call dependency relationship, and call dependency relationships between the first microservice nodes. The first microservice node may be some or all of the microservices in the above microservice system. The first microservice node is a node called by other services or a node that calls other services.

In the above-mentioned step S310, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes the following step S310a: when the above-mentioned preset fault type is the first fault type, based on the above-mentioned calling dependency relationship and the node information of the above-mentioned first microservice node to determine the first target microservice node for fault simulation. The above-mentioned first fault type includes at least one of the following: dependent service unavailability, dependent service delay.

In the above step S320, constructing fault simulation content corresponding to the above preset fault type for the above target object includes the following step S320a: constructing fault simulation content corresponding to the above first fault type for the above first target microservice node.

FIG. 4B schematically shows a schematic diagram of the implementation process of steps S310 and S320 according to another embodiment of the present disclosure.

According to another embodiment of the present disclosure, with reference to FIG. 4B , the above-mentioned sensing topology information includes: the above-mentioned sensing topology information includes: node information of the second microservice node deployed in the above-mentioned microservice system, and the second microservice node performs Allocation topology relationship and priority information for resource scheduling. The second microservice node can be some or all of the microservices in the above microservice system. The second microservice node is a running node to which resources are allocated, or a node that queues resources.

In the above-mentioned step S310, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes the following step S310b-1: In the case where the above-mentioned preset fault type is the second fault type, according to the above-mentioned third fault type, Determine the second target microservice node for fault simulation based on the node information of the two microservice nodes and the above priority information; or, include the following step S310b-2: When the above preset fault type is the second fault type, according to The node information of the above-mentioned second microservice node, the above-mentioned priority information and the above-mentioned allocation topology relationship determine the second target microservice node for fault simulation. The above-mentioned second fault type includes at least one of the following: instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, and process blocking.

In the above step S320, constructing fault simulation content corresponding to the above preset fault type for the above target object includes the following step S320b: constructing fault simulation content corresponding to the above second fault type for the above second target microservice node.

In some implementation scenarios, the resource scheduling process in the microservice system changes dynamically, and the previously perceived allocation topology relationship scenarios (for example, the T1~T2 period of CPU1 is allocated to microservice 1, during which microservice 3 is in a scheduling waiting state ; Assign the T1~T3 period of CPU2 to microservice 2; assign the T2~T4 period of CPU1 to microservice 3). This is different from the scenario faced when performing fault simulation (for example, it is the T5 period, and T5 is later than T4 and T3). Then only priority information is used as a reference factor for resource scheduling and allocation. That is, the resource scheduling allocation result during the current fault simulation is determined based on the priority information of resource scheduling between the second microservice nodes and the node information of the above-mentioned second microservice node, and the resource scheduling allocation result is determined based on the resource scheduling allocation result. The second target microservice node for fault simulation.

In other implementation scenarios, the scenario currently faced when performing fault simulation is the scenario corresponding to the constructed allocation topology relationship, and the above allocation topology relationship and priority can be used as reference factors for resource scheduling and allocation. That is, the resource scheduling allocation result during the current fault simulation is determined based on the above-mentioned allocation topology relationship, the priority information for resource scheduling between the second micro-service nodes and the node information of the above-mentioned second micro-service node, and based on the resource The scheduling allocation result determines the second target microservice node for fault simulation.

Figure 5 schematically shows a flow chart of a method for evaluating microservice performance according to another embodiment of the present disclosure.

According to an embodiment of the present disclosure, in addition to the above-mentioned steps S210 to S240, the above-mentioned evaluation method also includes a process of constructing preset monitoring indicators; the above-mentioned construction of preset monitoring indicators includes the following steps: S510, S520, S530 and S540. To simplify For illustration, only steps S510 to S540 are shown in FIG. 5 . The above steps S510 to S540 are executed before step S240.

In step S510, the first historical status data of each microservice in the above-mentioned microservice system when it is running in a steady state and the second historical status data corresponding to an abnormality are obtained.

The above-mentioned first historical status data is the status data during the actual operation of each microservice, and the second historical status data is the status data corresponding to the abnormality of each microservice in response to a real fault scenario.

In step S520, candidate monitoring indicators used to represent the running status of the microservice are determined based on the above-mentioned first historical status data and the above-mentioned second historical status data.

The above candidate monitoring indicators are used as indicator options corresponding to each microservice in the indicator configuration interface.

In step S530, the user's selection information and customized indicator information for indicator options in the above indicator configuration interface are received.

In some embodiments, in order to meet the personalized needs of performance evaluation or some special testing needs, by setting a custom indicator configuration function in the indicator configuration interface, users can not only select existing indicator options, but also choose based on business performance Evaluate needs and use the custom indicator configuration function to set custom indicator information.

In step S540, preset monitoring indicators corresponding to each microservice are generated based on the above selection information and the above custom indicator information.

In the embodiment including steps S510 to S540, most of the indicator options can be generated by intelligent analysis by the performance evaluation application, reducing the time and labor costs required to manually set indicators; at the same time, it also supports user customization The configuration of indicators improves the intelligence and flexibility of building preset monitoring indicators, helps meet the needs of various performance testing and evaluation scenarios, and has wide applicability.

A second exemplary embodiment of the present disclosure provides an evaluation device for microservice performance.

Figure 6 schematically shows a structural block diagram of a microservice performance evaluation device according to an embodiment of the present disclosure.

Referring to FIG. 6 , the microservice performance evaluation device 600 provided by the embodiment of the present disclosure includes: a monitoring module 601 , a construction module 602 , a fault simulation module 603 and an evaluation module 604 .

The above-mentioned monitoring module 601 is used to monitor the running process of the microservice system and obtain perceptual topology information; the above-mentioned perceptual topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the above-mentioned microservice system.

The above-mentioned building module 602 is used to construct fault simulation information based on the above-mentioned sensing topology information.

The above-mentioned fault simulation module 603 is used to perform fault scenario simulation in the above-mentioned microservice system based on the above-mentioned fault simulation information.

The above-mentioned evaluation module 604 is used to analyze the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation to obtain the stability evaluation results of the above-mentioned microservice system.

According to an embodiment of the present disclosure, the above-mentioned evaluation device further includes: a monitoring index building module.

The above-mentioned monitoring indicator building module is used to: obtain the first historical status data of each microservice in the above-mentioned microservice system when it is running in a steady state and the second historical status data corresponding to an abnormality; according to the above-mentioned first historical status data and the above-mentioned third 2. Historical status data to determine candidate monitoring indicators used to represent the running status of microservices; the above candidate monitoring indicators are used as indicator options corresponding to each microservice in the indicator configuration interface; receive the user's selection of indicator options in the above indicator configuration interface information and custom indicator information; based on the above selection information and the above custom indicator information, the preset monitoring indicators corresponding to each microservice are generated.

According to an embodiment of the present disclosure, constructing fault simulation information based on the above-mentioned sensing topology information includes: determining a target object that needs to be fault simulated based on the above-mentioned sensing topology information and a preset fault type; for the above-mentioned target object, constructing the same as the above-mentioned preset Fault simulation content corresponding to the fault type; wherein the above fault simulation information includes the above target object and the above fault simulation content.

According to embodiments of the present disclosure, the above-mentioned preset fault types include at least one of the following fault types: instance down, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking, dependent service unavailability Use and rely on service delays.

According to an embodiment of the present disclosure, the above-mentioned sensing topology information includes: node information of the first microservice node with a call dependency relationship, and call dependency relationships between the first microservice nodes. Among them, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes: when the above-mentioned preset fault type is the first fault type, based on the above-mentioned calling dependency relationship and the above-mentioned first microservice The node information of the node determines the first target microservice node for fault simulation; the above-mentioned first fault type includes at least one of the following: dependent service unavailability, dependent service delay; for the above-mentioned target object, construct the above-mentioned preset fault type The corresponding fault simulation content includes: constructing fault simulation content corresponding to the above-mentioned first fault type for the above-mentioned first target microservice node.

According to an embodiment of the present disclosure, the above-mentioned sensing topology information includes: the above-mentioned sensing topology information includes: node information of the second microservice node deployed in the above-mentioned microservice system, and the allocation topology relationship and priority of the second microservice node for resource scheduling. information. Among them, determining the target object that needs to be fault simulated based on the above-mentioned perceived topology information and the preset fault type includes: when the above-mentioned preset fault type is the second fault type, based on the node information of the above-mentioned second microservice node and The above priority information determines the second target microservice node for fault simulation; or, based on the node information of the above second microservice node, the above priority information and the above distribution topology relationship, determines the second target microservice for fault simulation. node. The above-mentioned second fault type includes at least one of the following: instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, and process blocking. Constructing fault simulation content corresponding to the above preset fault type for the above target object includes: constructing fault simulation content corresponding to the above second fault type for the above second target microservice node.

According to embodiments of the present disclosure, the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation are analyzed to obtain the stability evaluation results of the above-mentioned microservice system, including: changes to the above-mentioned real-time performance data Analyze the rules to obtain real-time damage degree information of each fault scenario to the steady state of the microservice system during and after the fault scenario simulation; determine each fault based on the preset assigned score of each fault scenario and the above real-time damage degree information Stability score under the scenario; based on the above stability score and the pre-assigned weight of each failure scenario, a comprehensive stability score of the above microservice system is generated, and the above comprehensive stability score is used as the above stability evaluation result.

For more details or beneficial effects of this embodiment, please refer to the detailed description of the first embodiment, which will not be described again here.

Any number of the functional modules included in the above-mentioned evaluation device 600 can be combined and implemented in one module, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in one module. At least one of the functional modules included in the evaluation device 600 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, or a system on a package. system, application specific integrated circuit (ASIC), or can be implemented by hardware or firmware in any other reasonable way to integrate or package the circuit, or by any one of the three implementation methods of software, hardware and firmware, or in any of them. Any appropriate combination of these can be achieved. Alternatively, at least one of the functional modules included in the evaluation device 600 may be at least partially implemented as a computer program module, and when the computer program module is executed, the corresponding function may be executed.

A third exemplary embodiment of the present disclosure provides an electronic device.

FIG. 7 schematically shows a structural block diagram of an electronic device provided by an embodiment of the present disclosure.

Referring to FIG. 7 , an electronic device 700 provided by an embodiment of the present disclosure includes a processor 701 , a communication interface 702 , a memory 703 , and a communication bus 704 . The processor 701 , the communication interface 702 , and the memory 703 complete interactions with each other through the communication bus 704 . communication; the memory 703 is used to store computer programs; the processor 701 is used to implement the above-mentioned evaluation method of microservice performance when executing the program stored in the memory.

A fourth exemplary embodiment of the present disclosure also provides a computer-readable storage medium. The computer program is stored on the computer-readable storage medium. When the computer program is executed by the processor, the evaluation method of microservice performance as described above is implemented.

The computer-readable storage medium may be included in the device or device described in the above embodiments; it may also exist independently without being assembled into the device or device. The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, but is not limited to, portable computer disks, hard disks, random access memory (RAM), and read-only memory (ROM). , erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above. In this disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device.

It should be noted that in the technical solutions provided by the embodiments of the present disclosure, the collection, collection, updating, analysis, processing, use, transmission, storage, etc. of user personal information are all in compliance with relevant laws and regulations and are used. For legitimate purposes and not contrary to public order and good customs. Take necessary measures for users' personal information to prevent illegal access to users' personal information and maintain the security of users' personal information, network security and national security.

It should be noted that in this article, relational terms such as “first” and “second” are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply these There is no such actual relationship or sequence between entities or operations. Furthermore, the terms "comprises," "comprises," or any other variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that includes a list of elements includes not only those elements, but also those not expressly listed other elements, or elements inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or apparatus that includes the stated element.

The above descriptions are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be practiced in other embodiments without departing from the spirit or scope of the disclosure. Therefore, the present disclosure is not to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims (10)

1. An evaluation method for microservice performance, which is characterized by including: Monitor the running process of the microservice system to obtain perceptual topology information; the perceptual topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the microservice system; Construct fault simulation information based on the perceived topology information; Carry out fault scenario simulation in the microservice system according to the fault simulation information; Analyze the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation to obtain the stability evaluation results of the microservice system. 2. The evaluation method according to claim 1, characterized in that, based on the perceived topology information, fault simulation information is constructed, including: According to the perceived topology information and the preset fault type, determine the target object that needs to be fault simulated; For the target object, construct fault simulation content corresponding to the preset fault type; Wherein, the fault simulation information includes the target object and the fault simulation content. 3. The evaluation method according to claim 2, wherein the preset fault type includes at least one of the following fault types: instance downtime, CPU full load, memory full load, disk full, network packet loss, Network delay, process blocking, dependent service unavailability, dependent service delay. 4. The evaluation method according to claim 2, wherein the sensing topology information includes: node information of the first microservice node with a call dependency relationship, and call dependency relationships between the first microservice nodes; Wherein, determining the target object that needs to be fault simulated based on the perceived topology information and the preset fault type includes: when the preset fault type is the first fault type, based on the calling dependency relationship and the The node information of the first microservice node determines the first target microservice node for fault simulation; the first fault type includes at least one of the following: dependent service unavailability, dependent service delay; Constructing fault simulation content corresponding to the preset fault type for the target object includes: constructing fault simulation content corresponding to the first fault type for the first target microservice node. 5. The evaluation method according to claim 2, wherein the sensing topology information includes: node information of a second microservice node deployed in the microservice system, and the second microservice node performs resource scheduling allocation. Topological relationships and priority information; Wherein, determining the target object that needs to perform fault simulation according to the perceived topology information and the preset fault type includes: when the preset fault type is the second fault type, according to the second microservice node Determine the second target microservice node for fault simulation based on the node information and the priority information; or determine the second target microservice node for fault simulation based on the node information of the second microservice node, the priority information and the distribution topology relationship. The simulated second target microservice node; wherein the second fault type includes at least one of the following: instance downtime, CPU full load, memory full load, disk full, network packet loss, network delay, process blocking; Constructing fault simulation content corresponding to the preset fault type for the target object includes: constructing fault simulation content corresponding to the second fault type for the second target microservice node. 6. The evaluation method according to claim 1, characterized in that the real-time performance data of the preset monitoring indicators before, during and after the fault scenario simulation are analyzed to obtain the stability evaluation result of the microservice system. ,include: Analyze the change patterns of the real-time performance data to obtain information on the real-time damage degree of each fault scenario to the steady state of the microservice system during and after the fault scenario simulation; Determine the stability score for each fault scenario based on the preset assigned score for each fault scenario and the real-time damage degree information; According to the stability score and the pre-assigned weight of each failure scenario, a comprehensive stability score of the microservice system is generated, and the comprehensive stability score is used as the stability evaluation result. 7. The evaluation method according to claim 1, further comprising: Obtain the first historical state data of each microservice in the microservice system when it is in a steady state of operation and the second historical state data corresponding to an exception; According to the first historical status data and the second historical status data, candidate monitoring indicators used to represent the operation status of the microservice are determined; the candidate monitoring indicators are used as indicator options corresponding to each microservice in the indicator configuration interface; Receive the user's selection information and customized indicator information for indicator options in the indicator configuration interface; According to the selection information and the custom indicator information, preset monitoring indicators corresponding to each microservice are generated. 8. An evaluation device for microservice performance, which is characterized by including: A monitoring module, used to monitor the running process of the microservice system and obtain perceptual topology information; the perceptual topology information covers at least one topological relationship between resource scheduling and service invocation of microservices in the microservice system; A building module used to construct fault simulation information based on the sensing topology information; A fault simulation module, configured to perform fault scenario simulation in the microservice system based on the fault simulation information; The evaluation module is used to analyze the real-time performance data of the preset monitoring indicators before, during and after the simulation of the fault scenario to obtain the stability evaluation results of the microservice system. 9. An electronic device, characterized in that it includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus; Memory, used to store computer programs; The processor is used to implement the method described in any one of claims 1-7 when executing a program stored in the memory. 10. A computer-readable storage medium with a computer program stored thereon, characterized in that when the computer program is executed by a processor, the method according to any one of claims 1-7 is implemented.