Link stress testing method and system based on micro-service architecture, and device and storage medium

Abstract

The embodiments of the present application belong to the technical field of link stress testing. Provided are a link stress testing method and system based on a micro-service architecture, and a device and a storage medium. In the present solution, by means of adding a coloring token to stress testing traffic and performing performance monitoring on a link under test on the basis of a distributed system tracing tool, a problematic node in the link under test can be quickly positioned during stress testing on the basis of the coloring token and collected performance data; and message passing logic and storage logic of application services in an actual production environment for stress testing data are modified efficiently and non-invasively on the basis of a dependency management tool, isolating the stress testing data from authentic data, such that a stress testing result is more authentic and reliable.

Description

Link stress testing method, system, device and storage medium based on microservice architecture Technical Field

[0001] The present application relates to the field of link stress testing technology, and in particular to a link stress testing method, system, device, and storage medium based on a microservice architecture. Background Art

[0002] The microservice architecture consists of a series of relatively independent, fine-grained services. A complete business logic call request may involve several, dozens, or even hundreds of back-end service interfaces. Each service may be developed by a different team, using a different programming language, and may be deployed on different machines and distributed in different data centers.

[0003] For enterprises, the proper implementation of each business logic largely depends on the performance of each service during the invocation of numerous microservices. Therefore, stress testing of business links is particularly important. For example, in the IoT card management and control business scenario, IoT card usage control, including various device-card binding types and regional restriction types, requires data synchronization from the CRM system, followed by user-generated online reporting of RADIUS and CHF messages. Based on the reported usage region and terminal IMEI, rules are used to determine changes in the region and IMEI, and then relevant control actions are taken. Submissions are then made to the order center, which then forwards them to the downstream procurement and control management center and CRM system. These procurement and control systems then interface with network elements to implement IoT card management and control. The entire management and control workflow involves multiple development modules, multiple microservices, and simultaneous debugging across four systems. Stress testing the entire process chain alone requires significant coordination across various service product personnel, involving a large number of service product and development personnel. When performance bottlenecks are encountered, current analysis relies solely on manually analyzing logs from relevant link nodes to locate the problematic node. Consequently, link stress testing in the current microservices architecture is inefficient and inaccurate. Summary of the Invention

[0004] The main purpose of the embodiments of the present application is to propose a link stress testing method, system, device and storage medium based on a microservice architecture, aiming to improve the efficiency and accuracy of link stress testing.

[0005] To achieve the above objectives, one aspect of an embodiment of the present application proposes a link stress testing method based on a microservice architecture, comprising the following steps:

[0006] Determine target production environment information based on the target business scenario, wherein the target production environment information includes link data, business traffic, and data storage range;

[0007] Determine the stress testing flow according to the business flow, and add a coloring mark to the stress testing request in the stress testing flow;

[0008] Create a shadow storage node according to the data storage range, and the shadow storage node is used to store stress testing data generated during the stress testing process;

[0009] Using a dependency management tool, configure the dependency of a stress testing component for each application service involved in the link data, wherein the stress testing component is used to identify stress testing requests and perform message transmission and storage according to the coloring identifier in the stress testing requests;

[0010] Creating and running a stress testing script based on the stress testing traffic and the link data to perform stress testing on the target service link;

[0011] The distributed system tracking tool is used to collect the performance data of each node during the stress test, and the stress test results are determined based on the performance data.

[0012] In some embodiments, determining target production environment information according to a target business scenario includes the following steps:

[0013] Perform joint debugging and testing of the normal traffic of the target business scenario by executing functional regression use cases. During the joint debugging and testing process, a traffic mark is set for the normal regression traffic.

[0014] Determine the link data and data storage scope based on the results of joint debugging and testing of normal traffic;

[0015] According to the data storage range, data in the production database is acquired and cleaned to obtain business data.

[0016] In some embodiments, the shadow storage node includes a shadow library and a shadow table, and creating the shadow storage node according to the data storage range includes the following steps:

[0017] Determine a number of production databases and a number of business tables according to the data storage range;

[0018] Create a shadow library with the same structure according to the structural configuration of the production library, copy the data in the production library to the shadow library, and add a prefix or suffix to the library name of the production library as the library name of the shadow library;

[0019] According to the structural configuration of the business table, a shadow table with the same structure is created in the production database where the business table is located, and the table name of the business table is added with a prefix or a suffix as the table name of the shadow table.

[0020] In some embodiments, the stress testing component includes a control interceptor and a request interceptor;

[0021] The control interceptor is used to intercept the stress test request and write the coloring identifier of the stress test request into the thread variable;

[0022] The request interceptor is used to intercept the service request to be sent, and write the coloring identifier of the thread variable into the header information of the service request.

[0023] In some embodiments, the stress testing component further includes a data isolator;

[0024] The data isolator is used to identify stress testing data according to the coloring identifier of the thread variable, modify the primary key of the stress testing data to a preset field, and then store the stress testing data in a shadow storage node.

[0025] In some embodiments, the link stress testing method based on the microservice architecture further includes the following steps:

[0026] Determining a calling object for calling an external communication interface according to the link data;

[0027] An interface simulation component is added to the calling object, wherein the interface simulation component is used to identify stress testing data and replace the external communication interface call of the stress testing data with a simulation interface call.

[0028] In some embodiments, the link stress testing method based on the microservice architecture further includes the following steps:

[0029] Determine the trend change curve of the performance data of each node through the moving average algorithm;

[0030] Determine the fluctuation range of performance data of each node through the standard deviation algorithm;

[0031] A link stress test risk warning is performed based on the trend change curve and the fluctuation range of the performance data.

[0032] To achieve the above objectives, another aspect of the present application provides a link stress testing system based on a microservice architecture, including:

[0033] The first module is used to determine target production environment information according to the target business scenario, wherein the target production environment information includes link data, business traffic and data storage range;

[0034] The second module is used to determine the stress testing flow according to the business flow and add a coloring mark to the stress testing request in the stress testing flow;

[0035] A third module is used to create a shadow storage node according to the data storage range, and the shadow storage node is used to store the stress testing data generated during the stress testing process;

[0036] A fourth module is configured to use a dependency management tool to configure the dependencies of a stress testing component for each application service involved in the link data, wherein the stress testing component is used to identify stress testing requests and perform message transmission and storage according to the coloring identifier in the stress testing requests;

[0037] A fifth module is configured to create and run a stress testing script based on the stress testing traffic and the link data to perform stress testing on the target service link;

[0038] The sixth module is used to collect performance data of each node during the stress test through a distributed system tracking tool, and determine the stress test results based on the performance data.

[0039] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes an electronic device, which includes a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for realizing connection and communication between the processor and the memory. When the program is executed by the processor, the link stress testing method based on the microservice architecture described in the above embodiment is realized.

[0040] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a storage medium, which is a computer-readable storage medium used for computer-readable storage. The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the link stress testing method based on the microservice architecture described in the above embodiment.

[0041] The link stress testing method, system, device and storage medium based on the microservice architecture proposed in this application add coloring tags to the stress testing traffic and monitor the performance of the tested link based on the distributed system tracing tool, so that the problem nodes in the tested link can be quickly located based on the coloring tags and the collected performance data during the stress testing process; based on the dependency management tool, the message transmission logic and storage logic of the application service for the stress testing data in the actual production environment are efficiently and non-invasively modified to achieve isolation of the stress testing data and the real data, making the stress testing results more real and reliable. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] FIG1 is a flow chart of a link stress testing method for a microservice architecture provided in an embodiment of the present application;

[0043] FIG2 is a flow chart of step S101 in FIG1 ;

[0044] FIG3 is a flow chart of step S103 in FIG1 ;

[0045] FIG4 is a flowchart of a link stress testing method for a microservice architecture provided by another embodiment of the present application;

[0046] FIG5 is a flowchart of a link stress testing method for a microservice architecture provided by another embodiment of the present application;

[0047] FIG6 is a schematic diagram of an IoT card management and control process according to an embodiment of the present application;

[0048] FIG7 is a schematic diagram of the message transmission process of each microservice provided in an embodiment of the present application;

[0049] FIG8 is a schematic diagram of the data storage process of the MQ message middleware provided in an embodiment of the present application;

[0050] 9 is a schematic diagram of a process for calling an external communication interface service according to an embodiment of the present application;

[0051] FIG10 is a schematic diagram comparing the actual traffic processing process and the stress testing process in a production environment provided by an embodiment of the present application;

[0052] FIG11 is a schematic diagram of a link stress testing system based on a microservice architecture according to an embodiment of the present application;

[0053] FIG12 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0055] It should be noted that although the system diagrams illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the system or the sequence in the flowcharts. The terms "first," "second," and so on, in the specification, claims, and drawings, are used to distinguish similar items and are not necessarily used to describe a specific sequence or precedence.

[0056] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0057] First, let’s analyze some of the terms used in this application:

[0058] RADIUS (Remote Authentication Dial-In User Service) is an authentication, authorization, and accounting protocol widely used in computer networks. The RADIUS protocol plays a crucial role in 4G wireless networks. In 4G LTE networks, the RADIUS protocol is used to authenticate and authorize users on wireless devices (such as smartphones and tablets).

[0059] CHF (Charging Function): Responsible for generating charging data records, serving as the quota control node for online charging, and performing online charging rate processing for various user services.

[0060] The IMEI (International Mobile Equipment Identity), commonly known as a mobile phone serial number or "serial number," is used to identify each individual mobile phone or other mobile communication device within a mobile phone network, serving as a mobile phone ID. The serial number consists of 15 to 17 digits. The first eight digits (TAC) are the model approval number, which distinguishes the phone's brand and model. The next two digits (FAC) are the final assembly number, representing the final assembly location. The last six digits (SNR) are the serial number, representing the production sequence number.

[0061] CRM (Customer Relationship Management) refers to the methods and strategies used by enterprises to manage and analyze data interactions with customers throughout their life cycle, and uses corresponding information technology to coordinate sales, services, and marketing systems between enterprises.

[0062] Based on this, the embodiments of the present application provide a link stress testing method, system, device and storage medium based on a microservice architecture, aiming to improve the efficiency and accuracy of link stress testing.

[0063] The recommended methods and devices, electronic devices, and storage media provided in the embodiments of the present application are specifically described through the following embodiments. First, the link stress testing method of the microservice architecture in the embodiments of the present application is described.

[0064] The link stress testing method of the microservice architecture provided in the embodiment of the present application relates to the field of link stress testing technology. The link stress testing method of the microservice architecture provided in the embodiment of the present application can be applied to the terminal, can also be applied to the server side, and can also be software running in the terminal or the server side. In some embodiments, the terminal can be a smart phone, a tablet computer, a laptop computer, a desktop computer, etc.; the server side can be configured as an independent physical server, or can be configured as a server cluster or distributed system composed of multiple physical servers, and can also be configured as a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application of the link stress testing method for the microservice architecture, etc., but is not limited to the above forms.

[0065] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.

[0066] FIG1 is an optional flowchart of a link stress testing method for a microservice architecture provided in an embodiment of the present application. The method in FIG1 may include but is not limited to steps S101 to S106.

[0067] Step S101, determining target production environment information according to a target business scenario, wherein the target production environment information includes link data, business traffic, and data storage range;

[0068] Step S102: Determine the stress test flow according to the business flow, and add a coloring mark to the stress test request in the stress test flow;

[0069] Step S103: Create a shadow storage node according to the data storage range. The shadow storage node is used to store stress testing data generated during the stress testing process.

[0070] Step S104: Using a dependency management tool, configure the dependency of a stress testing component for each application service involved in the link data. The stress testing component is used to identify stress testing requests and perform message transmission and storage based on the coloring identifier in the stress testing requests.

[0071] Step S105: Create and run a stress test script based on the stress test traffic and link data to perform stress testing on the target service link;

[0072] Step S106: Using a distributed system tracking tool, collect performance data of each node during the stress test, and determine the stress test result based on the performance data.

[0073] In steps S101 to S106 shown in the embodiment of the present application, by adding coloring tags to the stress test traffic and monitoring the performance of the tested link based on the distributed system tracing tool, the problem nodes in the tested link can be quickly located based on the coloring tags and the collected performance data during the stress test process; based on the dependency management tool, the message transmission logic and storage logic of the application service for the stress test data in the actual production environment are efficiently and non-invasively modified to achieve isolation between the stress test data and the real data, making the stress test results more real and reliable.

[0074] In step S101 of some embodiments, relevant information about the production environment required for stress testing can be analyzed based on the target business scenario. Generally, different business scenarios correspond to corresponding production environments. The production environment refers to the various nodes passed through during the business implementation process and the business data required to implement the business. Under the microservice architecture, the production environment refers to the call relationship (i.e., link data) of various application services during the business implementation process, the data storage involved (i.e., data storage range), and the business data required to implement the business. The business data of the production environment forms business traffic in a certain time period.

[0075] Taking the IoT card control scenario as an example, refer to Figure 6. When performing IoT card control, it is necessary to connect to the data center within the management platform and synchronize data change messages to the rule center to formulate relevant control rules. The rule engine triggers the corresponding control policy based on the RADIUS message and CHF message indicating the IoT card is online, as well as the change in the terminal IMEI and the online region. After submitting the control policy to the order center, the order center instructs the downstream systems, such as the CRM system and the procurement and control system, on the operations required to be issued to the network element. The CRM and procurement and control systems then connect to the 4G and 5G network elements to issue instructions to execute IoT card control operations. In this business scenario, the corresponding production environment information can include the service link data involved in the order center's guidance of downstream systems and their connection to the network element, the card number control requests sent by the order center (generating business traffic), and the storage location of a series of data from the order center sending the request to the network element to complete the control operation.

[0076] Please refer to FIG. 2 . In some embodiments, step S101 may include but is not limited to steps S201 to S203 :

[0077] Step S201: jointly debug and test the normal traffic of the target business scenario by executing a functional regression use case, wherein a traffic mark is set for the normal regression traffic during the joint debugging and testing process;

[0078] Step S202: Determine the link data and data storage range based on the joint debugging and testing results of normal traffic;

[0079] Step S203: Acquire data in the production database according to the data storage range and clean it to obtain business data.

[0080] In this embodiment, before conducting stress testing on the production environment for the target business scenario, the stress testing requirements can be determined first, including the stress testing scope (such as full-link stress testing and partial-link stress testing of the production environment), stress testing strategy (such as gradual stress testing, increased pulse testing, concurrency testing, and small-flow stress testing), and stress testing purpose (expected QPS and stability requirements). Normal traffic joint debugging can also be used to sort out the production environment system architecture, request link, related technical structure, module division, and the use of middleware such as messages, caches, and databases, and preliminarily analyze potential bottlenecks so as to subsequently increase stress testing monitoring indicators in a targeted manner.

[0081] During normal traffic joint debugging, this is typically accomplished by executing functional regression use cases. This normal regression traffic needs to be tagged with traffic labels to accurately locate the call link. Based on the results of the normal traffic joint debugging, the relevant database storage ranges and third-party service dependencies are identified. Link data is then determined based on these third-party service dependencies. Furthermore, based on the database storage range, a production repository storing normal business requests can be identified. A large number of business requests can be obtained from this production repository, and data filtering and cleaning performed to generate business traffic.

[0082] In step 102 of some embodiments, a stress test flow identical to the actual operation of the production environment is constructed based on the business traffic. A stress test script is then constructed based on the stress test flow to perform full-link stress testing on the production environment, which can improve the accuracy of the link stress test. For full-link stress test flow coloring, the stress test platform tags the output stress request, extracts the stress test tag in the service system, ensures that the tag is present in the entire program context, and can penetrate microservices and various middleware, such as MQ and Fegin, thereby facilitating the rapid location of stress test data. Specifically, the stress test platform can add a color tag to the stress test request by adding a custom tag to the HTTP request header of the stress test request. When different application services call each other, each application service can identify the stress test request flow, and the tag tag can be transparently transmitted to each other, that is, perceived by the application framework. For example, referring to Figure 6, in the IoT card management scenario, before real-time call records are collected to obtain IMEI and AREA changes, a stress test card tagging process and a process for launching the tagged test card on non-bound terminals / non-controlled areas are required.

[0083] In step S103 of some embodiments, the shadow storage node is used to separately store stress testing requests and stress testing regression data, thereby isolating normal business data requests from stress testing data requests and reducing the impact on normal business. The shadow storage node includes several shadow libraries and several shadow tables. The shadow library is constructed based on the production library structure involved in normal business processing, and the shadow table is constructed based on the business table structure involved in normal business processing. In another example, the shadow storage node can also be a shadow queue of the message middleware. The shadow queue is used to cache relevant data of the processing process. The shadow queue is also constructed based on the queue of the message middleware in the production environment.

[0084] Please refer to FIG3 . In some embodiments, step S103 may include but is not limited to steps S301 to S303 :

[0085] Step S301, determining a number of production databases and a number of business tables according to the data storage range;

[0086] Step S302: Create a shadow library with the same structure as the production library according to its structure configuration, copy the data in the production library to the shadow library, and add a prefix or suffix to the production library name as the shadow library name;

[0087] Step S303: Create a shadow table with the same structure in the production database where the business table is located according to the structure configuration of the business table, and add a prefix or suffix to the table name of the business table as the table name of the shadow table.

[0088] In this embodiment, by creating a shadow database with the same structure as the production environment and copying the data from the production database to the shadow database, the usage of the production database is simulated. This not only isolates the stress test data but also improves the accuracy of the database storage performance stress test. By creating a shadow table in the production database with the same structure as the business table, the stress test data can also be isolated through the shadow table when it is stored in the same database as the normal data.

[0089] In step S104 of some embodiments, when different application services call each other, in order to enable the coloring identifier in the stress testing request to be passed between microservices, the processing logic of the application service needs to be modified. However, the production environment involves a large number of application service calls. If the application service code is modified directly, the application service code is prone to errors and inefficiency. Therefore, the embodiment of the present application configures the dependencies of related application services through a dependency management tool, thereby modifying the processing logic of the application service when encountering stress testing data, and realizing link stress testing without intrusion into the business code.

[0090] A dependency management tool, such as the SpringBoot Starter, can help developers quickly build SpringBoot projects and simplify dependency management. By introducing a starter, developers can obtain stress testing component dependencies, eliminating the need to manually add extensive dependency configurations and improving development efficiency. For example, using the SpringBoot starter enables microservice configuration (components) to be autowired. The configuration only registers the corresponding stress testing component when specified conditions are met (for example, incoming stress testing traffic with a color marker). Microservices achieve autowiring of configuration using the @Conditional annotation, which indicates that a component is eligible for registration only when all specified conditions are met. The @Conditional annotation can be used as a method-level annotation on any @Bean method. Like autowiring, the SpringBoot starter aims to simplify configuration and address the complexities of dependency management. When building a web application, instead of compiling all dependency packages and adding them one by one to the project's dependency management, a single spring-boot-starter-web configuration is sufficient. The Spring Boot Starter development specification includes an empty project named xxx-spring-boot-starter-web. This project primarily relies on the pom.xml file to map all required dependencies. It also includes a xxx-spring-boot-autoconfigure project, which primarily writes configuration classes annotated with @Configuration. For this class or its methods annotated with @Bean, a new META-INF file is created in the resources folder of the xxx-spring-boot-starter project, along with a spring.factories file to configure the auto-configuration class. This embodiment avoids modifying individual microservices for stress testing, which would require unnecessary code insertion. Instead, Spring Boot Starter enables non-invasive modification of stress testing logic.

[0091] The stress testing component identifies stress testing requests and transmits and stores messages based on the coloring identifier in the stress testing requests. That is, when an application service is registered with a stress testing component dependency, the stress testing component can identify received stress testing requests, call the next-level service based on the coloring identifier in the stress testing request, and cache, store, or push messages based on the coloring identifier.

[0092] In one embodiment, the stress testing component includes a control interceptor and a request interceptor;

[0093] The control interceptor is used to intercept stress testing requests and write the coloring flag of the stress testing request to the thread variable;

[0094] The request interceptor is used to intercept the service request to be sent and write the coloring identifier of the thread variable into the header information of the service request.

[0095] Specifically, the control interceptor can be an MVC interceptor built on the Spring MVC framework. The MVC interceptor is a component in the Spring MVC framework, similar to a filter in a Servlet. It is mainly used to intercept user requests and perform corresponding processing. In SpringMVC, a custom interceptor class is implemented by implementing the HandlerInterceptor interface. The request interceptor can be a Feign interceptor. The Feign interceptor is a mechanism for operating on requests before sending them, such as setting attributes such as request headers. Feign provides an interceptor mechanism that executes interceptor logic before the actual HTTP call, without the business logic layer being aware of it.

[0096] Referring to Figure 7, after each microservice (i.e., application service) registers its dependency on the stress testing component, the message transmission process using the stress testing component is as follows: After receiving the stress testing request, the MVC interceptor of microservice A obtains the coloring flag in the stress testing request through the header and sets the coloring flag into the current THreadLocal (thread variable), which microservice A then uses when calling microservice B. When microservice A needs to call microservice B, the Fegin interceptor obtains the coloring flag from the ThreadLocal before sending the request and places it into the header of the Fegin-built request, thus enabling stress testing data transmission between microservices.

[0097] In one embodiment, the stress testing component further includes a data isolator;

[0098] The data isolator is used to identify stress testing data based on the coloring identifier of the thread variable, modify the primary key of the stress testing data to a preset field, and then store the stress testing data in the shadow storage node.

[0099] Specifically, after the application service registers the stress testing component dependency, the process of using the stress testing component dependency for data storage is as follows: after the service identifies the stress testing data through the ThreadLocal of the MVC interceptor, when data storage is needed, the data is stored using the data isolator. If it is stress testing data, it is routed to the shadow library, and if it is normal traffic, it is routed to the main library. At the same time, if it is stress testing data, a suffix is ​​added after the primary key of the stress testing data, and the Redis cache data or MQ message middleware data is isolated by different primary keys. For example, please refer to Figure 8, the process of MQ message middleware data isolation is as follows: determine whether there is a coloring identification token from the sending service. If there is a coloring identification token, use the Feign interceptor to add a token to the request header to be sent, use the data isolator to add a suffix after the primary key of the data and then cache it in the shadow queue QUEUE_SHADOW of the MQ service; if there is no coloring identification token, it is directly stored in the normal queue QUEUE of the MQ service, and then the MQ service pushes the message in the queue to the consumer service.

[0100] Furthermore, to prevent the contamination of production logs, full-link log isolation can be implemented. When the web system outputs logs to disk or external devices, if the traffic is marked as stress testing traffic, the logs will be isolated and output to the stress testing log path to avoid affecting production logs.

[0101] Referring to FIG. 4 , in some embodiments, the link stress testing method based on the microservice architecture of the embodiment of the present application may further include, but is not limited to, steps S401 to S402:

[0102] Step S401, determining the calling object of calling the external communication interface according to the link data;

[0103] Step S402 : adding an interface simulation component to the calling object, wherein the interface simulation component is used to identify stress test data and replace the external communication interface call of the stress test data with a simulation interface call.

[0104] Specifically, in order to reduce the impact on users during stress testing, some third-party data interfaces need to be isolated, for example, external communication interfaces such as text messages and emails. Normal data needs to send text messages, but for stress testing data, the external communication interface cannot be directly called to send text messages. This embodiment determines the calling object that needs to call the external communication interface based on the calling relationship of the link data, adds an interface simulation component to the calling object, and when the calling object identifies the stress testing data before calling the external communication interface, it calls the MOCK interface (i.e., the simulation interface) instead when the stress testing data is identified. Furthermore, the third-party MOCK interface can be verified during low-flow stress testing and joint debugging. Please refer to Figure 9 to illustrate the external communication interface of a third party called by an application during the stress testing process. After receiving the request through the request entrance, it is determined whether the request has a coloring identification Token. If it does not exist, it indicates that it is a normal business request, and the third-party interface is directly called. If it exists, it indicates that it is a stress testing request, and the stress testing request is intercepted and verified through the simulation interface.

[0105] In some embodiments of step S105, after creating stress testing traffic through step S102 and configuring the production environment through steps S103 and S104, a stress testing script is created and run according to the stress testing traffic and the stress testing link, so that the stress testing traffic can be jointly debugged in the production environment according to the stress testing link. The method of jointly debugging the stress testing traffic is basically the same as that of jointly debugging normal traffic. During the joint debugging process, the stress testing traffic is marked with a color mark, which can be accurately located when searching for the call chain.

[0106] In some embodiments of step S106, full-link service monitoring is performed throughout the stress testing process using a distributed system tracing tool, monitoring the service's operating status in real time and analyzing the service's call chain. Distributed system tracing tools can be Zipkin, Jaeger, Pinpoint, or SkyWalking, among others. SkyWalking can automatically collect required metrics through probes and perform distributed tracing. Through the call chain and its performance metrics, SkyWalking APM perceives the relationships between applications and services and generates corresponding performance metric data statistics. This embodiment can perform various types of stress testing based on bottleneck node testing requirements, including: single-link low-flow testing, which performs a low-flow stress test on the production environment to expose the most superficial problems and ensure the correctness of the process; single-link stress testing, which verifies the performance baseline data of all interfaces in an interference-free and non-contention-free environment and determines the performance SLA for all interfaces; full-link low-flow stress testing, which performs a low-flow stress test on the production environment to expose the most superficial problems and ensure the correctness of the process; and full-link stress testing, which performs a full-link stress test in a complex scenario based on the production environment's traffic ratio. This can detect resource consumption levels and bottlenecks under conditions of mutual interference and competition.

[0107] Referring to FIG. 5 , in some embodiments, the link stress testing method based on the microservice architecture of the embodiment of the present application may further include, but is not limited to, steps S501 to S503:

[0108] Step S501, determining a trend curve of performance data of each node by using a moving average algorithm;

[0109] Step S502: determining the fluctuation range of the performance data of each node using a standard deviation algorithm;

[0110] Step S503: Perform a link stress test risk warning based on the trend change curve and fluctuation range of the performance data.

[0111] In this embodiment, the Skywaling agent is used to collect call chain data and its performance indicators, such as call success rate and latency. The trend change law of the performance data (call success rate / latency) of each interface is identified by the moving average to obtain a change trend curve. The standard deviation is used to identify the fluctuation range of the performance data layer. The upper and lower limit thresholds of the change trend and the upper and lower limit thresholds of the fluctuation range are combined to identify the reversal phenomenon of the performance data trend of the downstream system, so as to monitor and warn in advance. When the link interface reaches the upper and lower limit thresholds of the change trend or the upper and lower limit thresholds of the fluctuation range, the whole link risk is fused. In addition, the service communication blacklist and whitelist switches between the two service systems can be configured to control the flow of traffic to reduce the link risk. It is also possible to reduce calls or turn off the stress test switch to ensure that the downstream system can run smoothly without being affected by the stress test, and to a certain extent avoid the risks brought by bottlenecks in the downstream system and the lack of support for stress testing.

[0112] According to some possible embodiments of the present application, please refer to Figure 10. Figure 10 provides a schematic diagram comparing the real traffic processing process and the stress test process processing process in a production environment, specifically: the stress test traffic carries a coloring identifier into the production process, and the microservices transmit messages containing the coloring identifier by configuring their own MVC interceptors and Reign interceptors. MQ isolation technology is used to process the stress test data required to be stored or cached by using RoutingKEY+suffix and adding coloring tags, and the processed stress test data is stored in a shadow node with the same structure configuration as the normal traffic storage node. The shadow node types are permanent database, Redis database and cache queue respectively, and the regression data of the stress test request of the consumer service is also stored in the shadow node. In addition, for microservices that call external interfaces, when they call external interfaces for stress test requests, they call the MOCK interface instead, while normal data calls the external interface normally. During the stress test process, Skywalking is used to monitor the traffic and perform stress test analysis on each interface to obtain the stress test results.

[0113] According to some embodiments of the present application, the embodiments of the present application have the following beneficial effects:

[0114] In the IoT card management and control scenario, it is possible to quickly locate the performance bottlenecks of specific services / interfaces during full-link stress testing in various IoT card binding and regional restriction scenarios. It can also improve the analysis of error logs between multiple microservices and across systems, trace back and locate performance bottlenecks layer by layer, and solve the pain point of coordinating the collaborative location and analysis of problems among various systems, product lines, and microservice development.

[0115] Implement non-invasive stress testing in the production environment, colorize stress testing data, and isolate stress testing data from actual data, making stress testing results more realistic and reliable while avoiding the generation of junk data.

[0116] Stress testing in a full-link real-world environment provides trace location and discovery of performance issues, and also serves as a chain of evidence for the accuracy of stress testing results.

[0117] During stress testing, full-link risk circuit breaking can be achieved, which can, to a certain extent, avoid bottlenecks in downstream systems and risks caused by failure to support stress testing.

[0118] Referring to FIG. 11 , an embodiment of the present application further provides a link stress testing system based on a microservice architecture, including:

[0119] The first module is used to determine target production environment information based on the target business scenario, wherein the target production environment information includes link data, business traffic and data storage range;

[0120] The second module is used to determine the stress testing traffic based on the business traffic and add coloring tags to the stress testing requests in the stress testing traffic;

[0121] The third module is used to create a shadow storage node based on the data storage range. The shadow storage node is used to store the stress testing data generated during the stress testing process.

[0122] The fourth module is used to use a dependency management tool to configure the dependencies of the stress testing component for each application service involved in the link data. The stress testing component is used to identify stress testing requests and transmit and store messages based on the coloring identifier in the stress testing requests.

[0123] The fifth module is used to create and run stress testing scripts based on stress testing traffic and link data to perform stress testing on target business links;

[0124] The sixth module is used to collect the performance data of each node during the stress test through the distributed system tracking tool, and determine the stress test results based on the performance data.

[0125] It can be understood that the contents of the above-mentioned link stress testing method embodiment based on microservice architecture are applicable to the present system embodiment. The functions specifically implemented by the present system embodiment are the same as those of the above-mentioned link stress testing method embodiment based on microservice architecture, and the beneficial effects achieved are also the same as those achieved by the above-mentioned link stress testing method embodiment based on microservice architecture.

[0126] An embodiment of the present application further provides an electronic device comprising: a memory, a processor, a program stored in the memory and executable on the processor, and a data bus for enabling communication between the processor and the memory. When the program is executed by the processor, the aforementioned link stress testing method based on a microservices architecture is implemented. The electronic device can be any intelligent terminal, including a tablet computer and an in-vehicle computer.

[0127] Please refer to FIG12 , which illustrates a hardware structure of an electronic device according to another embodiment. The electronic device includes:

[0128] The processor 901 can be implemented as a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application.

[0129] The memory 902 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called by the processor 901 to execute the link stress testing method based on the microservice architecture of the embodiment of the present application;

[0130] Input / output interface 903, used to implement information input and output;

[0131] Communication interface 904, used to implement communication interaction between this device and other devices, which can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WiFi, Bluetooth, etc.);

[0132] Bus 905 , which transmits information between various components of the device (e.g., processor 901 , memory 902 , input / output interface 903 , and communication interface 904 );

[0133] The processor 901 , the memory 902 , the input / output interface 903 and the communication interface 904 are connected to each other in communication within the device via a bus 905 .

[0134] An embodiment of the present application also provides a storage medium, which is a computer-readable storage medium used for computer-readable storage. The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the above-mentioned link stress testing method based on microservice architecture.

[0135] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0136] The embodiments described in the embodiments of this application are intended to more clearly illustrate the technical solutions of the embodiments of this application and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0137] Those skilled in the art will understand that the technical solutions shown in Figures 1-5 do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0138] The system embodiment described above is merely illustrative. The units described as separate components may or may not be physically separate, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0139] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0140] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0141] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of the above units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of systems or units, which can be electrical, mechanical or other forms.

[0143] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0144] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0145] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes multiple instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: various media that can store programs, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0146] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and essence of the present invention should be within the scope of the present invention.

Claims

1. A link stress testing method based on a microservices architecture, characterized in that, It includes the following steps: Determine the target production environment information according to the target business scenario, where the target production environment information includes link data, service traffic, and data storage range; Determine the stress test traffic according to the service traffic, and add a coloring identifier to the stress test requests in the stress test traffic; Create a shadow storage node according to the data storage range, where the shadow storage node is used to store the stress test data generated during the stress test; Use a dependency management tool to configure the dependencies of the stress test components for each application service involved in the link data, where the stress test components are used to identify stress test requests and perform message passing and storage according to the coloring identifiers in the stress test requests; Create and run a stress test script according to the stress test traffic and the link data to perform a stress test on the target business link; Collect the performance data of each node during the stress test through a distributed system tracing tool, and determine the stress test result according to the performance data.

2. The method for link stress testing based on a microservices architecture according to claim 1, wherein The determining the target production environment information according to the target business scenario includes the following steps: Perform joint debugging and testing on the normal traffic of the target business scenario by executing functional regression test cases, where a traffic label is set for the normal regression traffic during the joint debugging and testing process; Determine the link data and the data storage range according to the joint debugging result of the normal traffic joint debugging and testing; Obtain the data in the production database according to the data storage range and perform cleaning to obtain business data.

3. The method for link stress testing based on a microservice architecture according to claim 1, wherein The shadow storage node includes a shadow database and a shadow table. The creating the shadow storage node according to the data storage range includes the following steps: Determine a plurality of production databases and a plurality of business tables according to the data storage range; Create a shadow database with the same structure according to the structure configuration of the production database, copy the data in the production database to the shadow database, and use the production database name with a prefix or a suffix as the shadow database name; Create a shadow table with the same structure in the production database where the business table is located according to the structure configuration of the business table, and use the business table name with a prefix or a suffix as the shadow table name.

4. The method for link stress testing based on a microservices architecture according to claim 1, characterized in that The stress test components include a control interceptor and a request interceptor; The control interceptor is used to intercept stress test requests and write the coloring identifier of the stress test requests to a thread variable; The request interceptor is used to intercept service requests to be sent and write the coloring identifier of the thread variable to the header information of the service requests.

5. The method for link stress testing based on a microservices architecture according to claim 4, wherein The stress test components further include a data isolator; The data isolator is used to identify stress test data according to the coloring identifier of the thread variable, modify the primary key of the stress test data to a preset field, and then store the stress test data in the shadow storage node.

6. The method for link stress testing based on a microservice architecture according to claim 1, wherein The link stress test method based on a microservice architecture further includes the following steps: Determine the call object for calling an external communication interface according to the link data; Add an interface simulation component to the call object, where the interface simulation component is used to identify stress test data and replace the external communication interface call of the stress test data with a simulated interface call.

7. The method for link stress testing based on a microservices architecture according to claim 1, characterized in that, The link stress test method based on a microservice architecture further includes the following steps: Determine the trend change curve of the performance data of each node through a moving average algorithm; Determine the fluctuation range of the performance data of each node through the standard deviation algorithm; Perform stress test risk warning for the link according to the trend change curve and the fluctuation range of the performance data.

8. A link stress testing system based on a microservices architecture, characterized in that, Including: The first module is used to determine the target production environment information according to the target business scenario, where the target production environment information includes link data, service traffic, and data storage range; The second module is used to determine the stress test traffic according to the service traffic and add a coloring identifier to the stress test requests in the stress test traffic; The third module is used to create a shadow storage node according to the data storage range, and the shadow storage node is used to store the stress test data generated during the stress test; The fourth module is used to use a dependency management tool to configure the dependencies of the stress test components for each application service involved in the link data, where the stress test components are used to identify stress test requests and perform message passing and storage according to the coloring identifiers in the stress test requests; The fifth module is used to create and run a stress test script according to the stress test traffic and the link data to perform a stress test on the target business link; The sixth module is used to collect the performance data of each node during the stress test through a distributed system tracing tool and determine the stress test result according to the performance data.

9. An electronic device, characterized in that, The electronic device includes a memory, a processor, a program stored on the memory and executable on the processor, and a data bus for realizing the connection and communication between the processor and the memory. When the program is executed by the processor, the steps of the link stress test method based on the microservice architecture according to any one of claims 1 to 7 are implemented.

10. A storage medium, the storage medium being a computer-readable storage medium for computer-readable storage, characterized in that, The storage medium stores one or more programs, and the one or more programs can be executed by one or more processors to implement the steps of the link stress test method based on the microservice architecture according to any one of claims 1 to 7.

Images