A cloud-native application testing method and system based on a sidecar technology

Abstract

This application relates to the field of cloud-native technology and provides a method and system for testing cloud-native applications based on sidecar technology. The method includes: monitoring changes in the resource files of the cloud-native application; determining the container group where the cloud-native application resides in response to the addition of at least one test configuration information to the resource files of the cloud-native application; and injecting at least one test component into the container group in the form of a sidecar container according to the test configuration information. The cloud-native application is any application deployed in a container cloud platform, and the test component is used to perform corresponding test operations on the cloud-native application. Thus, leveraging the real-time resource file change sensing capability of the container cloud platform, and extending the functionality of the cloud-native application based on sidecar technology, it enables the dynamic injection of test components into the container group in the form of a sidecar container according to the test configuration information, flexibly and conveniently testing cloud-native applications in the container cloud platform.

Description

Technical Field

[0001] This application relates to the field of cloud-native technology, and in particular to a cloud-native application testing method, system, computer-readable storage medium, and electronic device based on sidecar technology. Background Technology

[0002] In cloud-native scenarios, in order to fully verify the quality of the new version of the cloud-native application, real access requests will be used to access the new version of the cloud-native application to conduct comprehensive testing of the new version of the cloud-native application in a manner similar to real-world scenarios. Furthermore, this process should not affect the normal response of the existing version of the cloud-native application to the access requests.

[0003] In related technologies, interceptors or proxy software that supports access request replication are used to replicate real access requests of existing versions of cloud-native applications. The replicated access requests are then distributed to different versions of cloud-native applications, thereby enabling real-world testing of different versions of cloud-native applications.

[0004] However, whether using interceptors or proxy software, copying access requests requires relatively complex configuration operations. Applying these technologies to cloud-native scenarios makes it difficult to flexibly and conveniently test applications and fails to meet the application testing needs of cloud-native scenarios.

[0005] Therefore, there is a need to provide an improved technical solution that addresses the shortcomings of the existing technology. Summary of the Invention

[0006] The purpose of this application is to provide a cloud-native application testing method, system, computer-readable storage medium, and electronic device based on sidecar technology, so as to solve or alleviate the problems existing in the prior art.

[0007] To achieve the above objectives, this application provides the following technical solution:

[0008] In a first aspect, embodiments of this application provide a cloud-native application testing method based on sidecar technology. The method is applied to an application test controller, which is deployed on a container cloud platform, and includes:

[0009] Monitor changes to the resource files of the cloud-native application;

[0010] In response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group in which the cloud-native application resides is determined;

[0011] Based on the test configuration information, inject at least one test component into the container group in the form of a sidecar container;

[0012] The cloud-native application is any application deployed in the container cloud platform, and the testing component is used to perform corresponding testing operations on the cloud-native application.

[0013] In the above scheme, the test configuration information includes a request to copy annotation.

[0014] Correspondingly,

[0015] In response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group where the cloud-native application resides is determined; based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container, specifically:

[0016] In response to the addition of at least one request copy annotation to the resource file of the first application, the first container group in which the first application resides is determined;

[0017] Based on the requested replication annotation, at least one requested replication component is injected into the first container group in the form of a sidecar container;

[0018] The request replication component is used to replicate the access request sent to the first application to obtain an access request copy, and forward the access request copy and the access request to the second application and the first application respectively, so that the second application processes the access request copy to obtain the test result of the second application; wherein the first application is the existing version of the cloud-native application; and the second application is the new version of the cloud-native application.

[0019] In the above scheme, the test configuration information includes result analysis annotations.

[0020] Correspondingly,

[0021] In response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group where the cloud-native application resides is determined; based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container, specifically:

[0022] In response to the addition of at least one result analysis annotation to the resource file of the second application, the second container group in which the second application resides is determined;

[0023] Based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container;

[0024] The result analysis component is used to process the test results of the second application.

[0025] In the above scheme, the result analysis annotation includes the identification information of the result analysis model.

[0026] Correspondingly,

[0027] The results analysis component is specifically used for:

[0028] The result analysis model is determined based on the identification information of the result analysis model;

[0029] The test results of the second application are analyzed based on the aforementioned result analysis model to obtain the analysis results;

[0030] The test results of the second application and the analysis results are stored in the storage system.

[0031] In the above scheme, there are multiple second applications, and the multiple second applications are different new versions of the cloud-native applications. Each request replication annotation newly added to the resource file of the first application corresponds to each second application.

[0032] Correspondingly,

[0033] In response to the resource file of the second application, at least one result analysis annotation is added to determine the second container group where the second application resides; based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container, specifically:

[0034] In response to the addition of at least one result analysis annotation to the resource files of multiple second applications, the second container group in which each second application resides is determined;

[0035] Based on the result analysis annotation, at least one result analysis component is injected into each of the second container groups in the form of a sidecar container.

[0036] In the above scheme, the request to copy annotation includes the identification information of the second container group where the second application resides;

[0037] Correspondingly,

[0038] The request replication component is also used for:

[0039] The second container group where the second application resides is determined based on the identification information of the second container group where the second application resides;

[0040] Establish a network connection with the second container group to forward the copy of the access request to the second application.

[0041] The method in the above scheme further includes:

[0042] In response to the deletion of at least one test configuration information from the resource files of the cloud-native application, the container group in which the cloud-native application resides is determined.

[0043] Based on the test configuration information, delete the corresponding test component in the container group.

[0044] Secondly, embodiments of this application provide a cloud-native application testing system based on sidecar technology. The system includes an application test controller deployed on a container cloud platform. The application test controller includes a resource monitoring unit, a test configuration unit, and a component injection unit.

[0045] The resource monitoring unit is configured to monitor changes in the resource files of the cloud-native application.

[0046] The test configuration unit is configured to add at least one test configuration information in response to the resource file of the cloud-native application, and to determine the container group where the cloud-native application resides.

[0047] The component injection unit is configured to inject at least one test component into the container group in the form of a sidecar container according to the test configuration information.

[0048] The cloud-native application is any application deployed in the container cloud platform, and the testing component is used to perform corresponding testing operations on the cloud-native application.

[0049] Thirdly, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, the computer program being a cloud-native application testing method based on sidecar technology as described above.

[0050] Fourthly, embodiments of this application also provide an electronic device, including: a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the cloud-native application testing method based on sidecar technology as described above.

[0051] Beneficial effects:

[0052] The cloud-native application testing method based on sidecar technology provided in this application deploys an application test controller in a container cloud platform to monitor changes in the resource files of the cloud-native application. When at least one new test configuration information is added to the resource files of the cloud-native application, the container group where the cloud-native application resides is determined. Then, based on the newly added test configuration information, at least one test component is injected into the container group in the form of a sidecar container. This test component performs corresponding test operations on the cloud-native application. Thus, leveraging the container cloud platform's ability to perceive changes in the resource files of the deployed cloud-native application in real time, and flexibly extending the functionality of the cloud-native application based on sidecar technology, the method dynamically injects test components relatively independent of the cloud-native application's business logic into the container group in the form of sidecar containers. Test component configuration requires only simple operations, allowing for flexible and convenient testing of cloud-native applications in the container cloud platform to meet the application testing needs in cloud-native scenarios. Attached Figure Description

[0053] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. Wherein:

[0054] Figure 1 This is a flowchart illustrating a cloud-native application testing method based on sidecar technology provided according to some embodiments of this application;

[0055] Figure 2 This is a schematic diagram illustrating the logic of cloud-native applications processing access requests according to some embodiments of this application;

[0056] Figure 3 This is a logical schematic diagram of a cloud-native application testing method based on sidecar technology provided according to some embodiments of this application;

[0057] Figure 4 This is a schematic diagram of the structure of a cloud-native application testing system based on sidecar technology according to some embodiments of this application;

[0058] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to some embodiments of this application;

[0059] Figure 6 This is a hardware structure diagram of an electronic device provided according to some embodiments of this application. Detailed Implementation

[0060] The present application will now be described in detail with reference to the accompanying drawings and embodiments. Various examples are provided by way of explanation and not by way of limitation. In fact, those skilled in the art will recognize that modifications and variations can be made to the present application without departing from the scope or spirit thereof. For example, a feature shown or described as part of one embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desirable that the present application encompass such modifications and variations that fall within the scope of the appended claims and their equivalents.

[0061] In the following description, the terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific order of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0062] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing embodiments of this disclosure only and is not intended to limit this disclosure.

[0063] In the development of computer software applications, various tests are typically performed on the developed application, and the application code is modified and improved based on the test results. Application testing is generally divided into four stages: unit testing, integration testing, system testing, and acceptance testing. Acceptance testing, also known as delivery testing, is the final testing conducted before the application is officially released. Applications that pass acceptance testing can then be officially deployed and launched. Acceptance testing employs black-box testing techniques, requiring the use of real data to test the application.

[0064] Acceptance testing can be further divided into Alpha testing and Beta testing. Alpha testing is conducted by real users in a development environment, or by software developers in a controlled environment simulating actual operation. Beta testing is conducted by real users in a real-world usage environment.

[0065] In cloud-native scenarios, when conducting beta testing on a new version of a cloud-native application, in order to fully verify the quality of the new version without affecting the normal access of the existing version, it is usually necessary to deploy both the existing and new versions of the cloud-native application in a container cloud platform environment. Access requests are then replicated and distributed so that both versions process the requests simultaneously. The processing result of the existing version is sent as a response to the recipient, while the processing result of the new version is used as the test result for analysis and retention.

[0066] In related technologies, interceptors or proxy software that supports access request replication are used to replicate access requests and then send the replicated access requests to different versions of cloud-native applications.

[0067] Specifically, the interceptor approach involves adding an interception module to the code of the existing version of the cloud-native application. The interceptor acts as the entry point for access requests in the existing version of the cloud-native application. After intercepting and copying the access requests, the access requests are allowed to enter the existing version of the cloud-native application normally, and the copied access request is sent to the new version of the cloud-native application.

[0068] The solution using proxy software involves deploying the proxy software in the container cloud platform environment, configuring access request replication and forwarding within the proxy software, sending access requests originally directed to the existing version of the cloud-native application to the proxy software for replication, and then sending the two identical copies of the access requests to the existing version of the cloud-native application and the new version of the cloud-native application, respectively.

[0069] However, in related technologies, when using interceptors to copy access requests, it is necessary to add functional modules to the source code of the existing version of the cloud-native application. This requires code modification for each related cloud-native application, resulting in a high degree of coupling between the interceptor and the functionality of the cloud-native application. Consequently, the implementation and maintenance of cloud-native application testing based on interceptors are quite difficult.

[0070] When using proxy software to replicate access requests, it relies on the proxy software's request replication and forwarding functions. Furthermore, the request replication and forwarding functions also require corresponding rule configurations in the proxy software. These configurations are not only cumbersome to perform, but also cannot be automated, which greatly reduces the testing efficiency of cloud-native applications.

[0071] With the development of cloud-native technologies, microservice architecture has gradually become the mainstream architecture in the cloud-native field. In a microservice architecture, a business system is broken down into multiple microservice applications as business modules. Each business module provides a portion of the business functionality, collectively providing services to the outside world. Overall, different business modules belonging to the same business system have complex calling relationships when providing services to the outside world.

[0072] In other words, microservice architecture places higher demands on the efficiency and flexibility of test management for cloud-native applications. On one hand, different microservice applications need to send access requests to each other, making the access request transmission path of the entire business system extremely complex. Therefore, when testing new versions of cloud-native applications with real access requests, the difficulty and complexity increase significantly, whether modifying code to copy access requests using interceptors or configuring request forwarding rules when using proxy software, resulting in lower test management efficiency for cloud-native applications. On the other hand, microservice architectures require frequent upgrades to different microservice applications, and each upgrade necessitates testing the new version of the microservice application. In this scenario, neither interceptors nor proxy software can flexibly configure or cancel access request copying, failing to meet the flexibility requirements for testing during frequent microservice application upgrades.

[0073] Furthermore, related technologies lack effective management and control over the processing results of access request copies by new versions of cloud-native applications. For example, specific configurations are needed in interceptors or proxy software to prevent the processing results of access request copies by new versions of cloud-native applications and the processing results of access requests by existing versions of cloud-native applications from being sent as responses to the response recipient.

[0074] It is evident that the existing technology suffers from shortcomings such as cumbersome operation and lack of flexibility, making it unsuitable for the testing requirements of new versions of microservice applications under a microservice architecture.

[0075] To address the issues of cumbersome and inflexible application testing operations in cloud-native scenarios, the applicant provides a cloud-native application testing method based on sidecar technology. This method involves deploying an application test controller in a container cloud platform to monitor changes in the resource files of all cloud-native applications. When at least one new test configuration information is detected in a cloud-native application's resource file, the container group containing the cloud-native application is determined based on the resource file. At least one test component is then injected into this container group as a sidecar container. This leverages the container cloud platform's ability to monitor changes in the resource files of deployed cloud-native applications in real time and fully utilizes the sidecar technology's ability to extend the functionality of cloud-native applications within the same container group. Test components are dynamically injected as sidecar containers to execute corresponding test operations. This eliminates the need for coupling test components with the cloud-native application's code and the need to configure request replication and forwarding rules required for testing. Flexible and efficient testing of cloud-native applications can be achieved through simple and quick configuration.

[0076] Exemplary methods

[0077] This application provides a cloud-native application testing method based on sidecar technology, such as... Figure 1 , Figure 2 , Figure 3 As shown, this method is applied to an application test controller, which is deployed on a container cloud platform. The method includes:

[0078] Step S101: Monitor changes in the resource files of cloud-native applications.

[0079] Here, cloud-native applications refer to applications built with cloud computing principles and adapted to cloud computing environments. They are independent, small-scale, loosely coupled, and collaborative deployable units that meet changing user needs through frequent releases, rapid delivery, and quick feedback.

[0080] In this embodiment of the application, the cloud-native application can be any application deployed in a container cloud platform.

[0081] Among them, the container cloud platform is a lightweight PaaS platform built by relying on container technology, combined with cloud-native technology, and using technologies such as containers, container orchestration, service mesh, and microservices.

[0082] Resource files are collections of configuration information for the resources required by cloud-native applications, and each cloud-native application corresponds to at least one resource file. Specifically, all content in a container cloud platform is abstracted as resources, and users need to manage the entire container cloud platform by operating on resources. Container cloud platform resources can be divided into built-in resources (Kubernetes Resources) and custom resources, defined through resource description files (Manifest Files), which are also called resource files.

[0083] In cloud-native scenarios, container cloud platforms can detect changes in resource files. When the content of a resource file changes, the container cloud platform transmits the changes to its components so that the cloud-native application's resources can be modified accordingly.

[0084] In this embodiment, an application test controller is pre-deployed in the container cloud platform to monitor changes in resource files of all cloud-native applications on the container cloud platform.

[0085] Specifically, taking a Kubernetes cluster as an example, the application test controller can monitor changes to resource files of all applications in the Kubernetes cluster through the API-Server component.

[0086] Step S102: In response to the cloud-native application's resource file, add at least one test configuration information to determine the container group where the cloud-native application resides.

[0087] In this embodiment, the application test controller monitors the changes in the resource files of the cloud-native application in real time. When at least one test configuration information is added to the resource files of the cloud-native application, the container group where the cloud-native application is located is determined based on the resource files of the cloud-native application.

[0088] It is understandable that when a cloud-native application is deployed to a container cloud platform, its corresponding resource file records the identification information of the container group where the cloud-native application resides. When at least one test configuration piece of information is added to the resource file of a cloud-native application, the application test controller identifies the cloud-native application that needs to perform test operations through the test configuration information, and determines the container group where the cloud-native application resides based on the identification information of the container group where the cloud-native application resides recorded in the resource file, so as to configure the container group accordingly based on the test configuration information.

[0089] It should be noted that in the resource file, the test configuration information exists in the form of key-value pairs, where the key is used to identify the type of test configuration information and the value is used to store the specific content of the test configuration information.

[0090] Step S103: Based on the test configuration information, inject at least one test component into the container group in the form of a sidecar container.

[0091] The testing component is used to perform corresponding testing operations on cloud-native applications.

[0092] Here, a sidecar is also called a sidecar, which corresponds to a three-wheeled motorcycle in real life. By adding a sidecar to a two-wheeled motorcycle, the capabilities of the two-wheeled motorcycle are expanded, so that the original function is not changed, but new functions are added.

[0093] Similarly, in software architecture, the container where cloud-native applications reside is used to implement business functions, and is referred to as the business container. The sidecar container is like a sidecar of the business container, and is located in the same container group as the business container. Through the sidecar application in the sidecar container, the main application in the business container can be extended or enhanced.

[0094] It should be noted that after injecting at least one test component into the container group in the form of a sidecar container, the container group will include both sidecar containers and application containers. The cloud-native application is deployed in the application container, and the test component is deployed in the sidecar container. The sidecar container has the ability to proactively intercept access requests entering or leaving the application container within the same container group. In other words, the sidecar container will proactively intercept access requests destined for the cloud-native application within the same container group, as well as access requests originating from the cloud-native application, for processing by the test component within the sidecar container.

[0095] Sidecar technology can be used to extend or enhance the functionality of cloud-native applications without the need for additional third-party component configuration and code. For some auxiliary functions that are not related to the core functions of the main application in the business container, they can be implemented by the sidecar application in the sidecar container. The sidecar application is loosely coupled with the main application, and the sidecar application does not need to care about the implementation logic of the business and the language framework.

[0096] Specifically, in this embodiment of the application, based on the test configuration information, the functionality of the cloud-native application is extended using the sidecar technology. Test components are injected into the container group where the cloud-native application resides in the form of a sidecar container, enabling it to perform corresponding test operations.

[0097] In this embodiment, the testing of cloud-native applications is implemented by a testing component within the sidecar container. Testing cloud-native applications is not a core function of the application but rather an auxiliary function, which can be implemented through the testing component within the sidecar container. Thus, based on sidecar technology, the testing component is loosely coupled with the cloud-native application. The testing component does not need to concern itself with the application's business logic or language framework, reducing the development cost and implementation difficulty of the testing component.

[0098] Furthermore, when injecting test components into container groups based on sidecar technology, no additional third-party components need to be configured, nor is it necessary to modify the code in the cloud-native application. Leveraging the container cloud platform's ability to perceive changes in the resource files of the cloud-native application deployed within it in real time, testing of the cloud-native application can be performed simply by adding test configuration information to the resource files of the cloud-native application. This makes testing of cloud-native applications flexible and convenient, not only improving the deployment speed of test components but also maximizing the speed of responding to changes in cloud-native application testing requirements.

[0099] As can be seen from the foregoing description, in order to test the new version of the cloud-native application using real access requests, this application embodiment needs to deploy the new version of the cloud-native application and the existing version of the cloud-native application in the same container cloud platform, and set up an application test controller in the container cloud platform so that the application test controller can monitor the changes in the resource files of the new version of the cloud-native application and the existing version of the cloud-native application.

[0100] In order to replicate access requests sent to existing versions of cloud-native applications and forward copies of the access requests to new versions of cloud-native applications for testing of the new versions of cloud-native applications, this application embodiment adds at least one request replication annotation to the existing versions of cloud-native applications, which will be described in detail below.

[0101] In some embodiments, the test configuration information includes a request replication annotation. Correspondingly, in response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group where the cloud-native application resides is determined. Based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container. Specifically, in response to the addition of at least one request replication annotation to the resource file of the first application, the first container group where the first application resides is determined. Based on the request replication annotation, at least one request replication component is injected into the first container group in the form of a sidecar container.

[0102] The request replication component is used to replicate the access request sent to the first application to obtain a copy of the access request. The copy of the access request and the access request are then forwarded to the second application and the first application, respectively. The second application processes the copy of the access request to obtain the test results of the second application. The first application is an existing version of the cloud-native application, and the second application is a new version of the cloud-native application.

[0103] In this embodiment of the application, the existing version of the cloud-native application is referred to as the first application, and the container group where the first application resides is referred to as the first container group; the new version of the cloud-native application is referred to as the second application, and the container group where the second application resides is referred to as the second container group.

[0104] In this embodiment of the application, the test configuration information includes request replication annotations. When at least one request replication annotation is added to the resource file of the first application, the application test controller determines the first container group where the first application is located based on the resource file of the first application, and injects at least one request replication component into the first container group in the form of a sidecar container.

[0105] As mentioned above, the request replication annotation exists in key-value pairs, where the key identifies the annotation type as a request replication annotation. The application test controller deploys the request replication component in the sidecar container based on the annotation type identified by the key in the request replication annotation, and dynamically deploys the sidecar container in the first container group where the first application resides.

[0106] At this time, the first container group includes the business container where the first application is located and the sidecar container where the request replication component is located. The sidecar container actively intercepts access requests entering and leaving the business container where the first application is located, that is, it intercepts the access requests sent to the first application and the processing results of the access requests sent by the first application, so that the request replication component can process these access requests accordingly.

[0107] In practical applications, when the sidecar container actively intercepts the processing result of an access request from the first application, the request replication component does not process the result of the first application's access request. Instead, it forwards the result directly to the designated recipient as the response to the access request. Thus, when testing a new version of the cloud-native application, the existing version of the cloud-native application still responds to access requests normally, ensuring the normal operation of the business system.

[0108] When the sidecar container actively intercepts an access request destined for the first application, the request replication component replicates the access request to obtain a copy of the access request, and sends the access request and the copy of the access request to the first container group where the first application is located and the second container group where the second application is located, thereby realizing the replication and forwarding of the access request.

[0109] Specifically, when the container cloud platform is a Kubernetes cluster, see, for example, [link to example]. Figure 2 If you need to test a second application deployed in a Kubernetes cluster, deploy the first and second applications in the same Kubernetes cluster and set up an application test controller in that Kubernetes cluster to listen for changes in the resource files of all cloud-native applications in the cluster based on the API-Server component.

[0110] As you can understand, the API-Server component monitors changes to resource files in all native applications, including both the first and second applications. When a resource file in either the first or second application changes, the API-Server component transmits the change information to the application test controller, which then performs the appropriate actions based on the changes.

[0111] In practice, after the first and second applications are deployed and no new test configuration information is added to the resource files of the first application, the first application receives access requests from the third application (here, the third application can be any other application in the cluster besides the first and second applications), and after processing the access requests, sends the response to the designated recipient (such as the fourth application).

[0112] When the application test controller detects through the API-Server component that at least one new test configuration information has been added to the resource files of the first application, and the newly added test configuration information includes a request to copy annotation, it needs to intercept the access request sent by the third application to the first application.

[0113] In this embodiment of the application, the access request sent by the third application to the first application is intercepted by the request copying component.

[0114] Specifically, see Figure 3 The application test controller will inject the request replication component into the first container group where the first application is located in the form of a sidecar container, based on the type of annotation identified by the key of the request replication annotation.

[0115] The request replication component actively intercepts access requests sent from a third application to a first application through a sidecar container, and replicates the access request to obtain a copy of the access request; then the copy of the access request and the access request are forwarded to the second application and the first application, respectively.

[0116] In this embodiment of the application, after the access request is copied to obtain a copy of the access request, the request copying component sends the access request to the first application, which will not affect the normal access of the third application to the first application.

[0117] The request copy component sends a copy of the access request to the second application, which then processes the copy and obtains the test results from the second application.

[0118] It should be noted that the copy of the access request obtained by copying the access request through the request replication component is exactly the same as the real access request, thus enabling comprehensive testing of the second application in a similar real-world scenario.

[0119] In some embodiments, the request to copy annotation includes identification information of the second container group where the second application resides; correspondingly, the request to copy component is further configured to: determine the second container group where the second application resides based on the identification information of the second container group where the second application resides; and establish a network connection with the second container group to forward the access request copy to the second application.

[0120] In this embodiment of the application, the request to copy annotation exists in the form of key-value pairs, where the value is the identification information of the second container group where the second application is located.

[0121] The request replication component determines the second container group where the second application is located based on the identification information of the second container group recorded in the value, and then establishes a network connection with the second container group to forward the access request copy to the second application, thereby enabling testing of the second application based on the real access request.

[0122] In order to analyze the test results of the new version of the cloud-native application, this application embodiment adds at least one result analysis annotation to the new version of the cloud-native application, which will be described in detail below.

[0123] In other embodiments, the test configuration information includes result analysis annotations. Correspondingly, in response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group where the cloud-native application resides is determined. Based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container. Specifically, in response to the addition of at least one result analysis annotation to the resource file of the second application, the second container group where the second application resides is determined. Based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container.

[0124] The results analysis component is used to process the test results of the second application.

[0125] In this embodiment, the test configuration information includes result analysis annotations. When at least one result analysis annotation is added to the resource file of the second application, the application test controller determines the second container group where the second application is located through the resource file of the second application, and injects at least one result analysis component into the second container group in the form of a sidecar container.

[0126] Results analysis annotations exist in key-value pairs, where the key identifies the type of annotation as a results analysis annotation. The application test controller determines which results analysis component to deploy in the sidecar container based on the annotation type identified by the key in the results analysis annotation, and then deploys the sidecar container in the second container group where the second application resides.

[0127] At this time, the second container group includes the business container where the second application is located and the sidecar container where the result analysis component is located. The sidecar container actively intercepts the access request copy sent to the second application and the processing result of the access request copy sent by the second application (i.e. the test result of the second application), so that the result analysis component can perform the corresponding processing.

[0128] In some embodiments, the result analysis annotation includes the identification information of the result analysis model. Correspondingly, the result analysis component is specifically used to: determine the result analysis model based on the identification information of the result analysis model; analyze the test results of the second application based on the result analysis model to obtain the analysis results; and store the test results of the second application and the analysis results in the storage system.

[0129] In this embodiment of the application, the result analysis annotation exists in the form of key-value pairs, where the value is the identification information of the result analysis model.

[0130] In practice, when the sidecar container actively intercepts a copy of the access request sent to the second application, the result analysis component does not process the copy of the access request. Instead, the second application processes the copy of the access request to obtain the test results of the second application.

[0131] After the results analysis component actively intercepts the test results of the second application sent by the sidecar container, it determines the results analysis model used for the test results of the second application based on the identification information of the results analysis model recorded in the value, and analyzes the test results of the second application based on the results analysis model to obtain the analysis results. Then, the results analysis component stores the test results and analysis results of the second application in the storage system for application developers to access.

[0132] See also Figure 3The application test controller will inject the result analysis component into the second container group where the second application is located in the form of a sidecar container, based on the type of annotation identified by the key of the result analysis annotation.

[0133] The results analysis component actively intercepts the test results of the second application sent by the second application through the sidecar container. Based on the identifier information of the results analysis model recorded in the value of the results analysis annotation, it uses the results analysis model to analyze the test results of the second application to obtain the analysis results. Then, the test results and analysis results of the second application are stored in the storage system.

[0134] It should be noted that when there are multiple result analysis components, you only need to match each result analysis model with each result analysis component to use multiple result analysis models to analyze the test results of the same second application and obtain multiple analysis results for the test results of the same second application.

[0135] In this embodiment of the application, without any specific configuration, the test results of the access request copy and the second application can be processed separately by the result analysis component in the sidecar container. This avoids sending the processing results of the access request copy and the processing results of the access request as responses to the response recipient, thus realizing effective analysis, management and control of the test results of the second application.

[0136] In some embodiments, there are multiple second applications, which are different new versions of cloud-native applications. Each request replication annotation added to the resource file of the first application corresponds to each second application. Correspondingly, in response to the addition of at least one result analysis annotation to the resource file of the second application, the second container group in which the second application resides is determined. Based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container. Specifically, in response to the addition of at least one result analysis annotation to the resource files of multiple second applications, the second container group in which each second application resides is determined. Based on the result analysis annotation, at least one result analysis component is injected into each second container group in the form of a sidecar container.

[0137] In this embodiment of the application, there are multiple second applications, which means that multiple different new versions of cloud-native applications can be tested simultaneously.

[0138] When testing multiple new versions of cloud-native applications simultaneously, simply deploy these second applications and their corresponding first applications (i.e., existing versions of cloud-native applications) in the same container cloud platform, add multiple request replication annotations to the resource files of the first application, and each newly added request replication annotation corresponds to each second application.

[0139] At this time, the application test controller listens to the resource files of the multiple second applications. When at least one result analysis annotation is added to the resource files of the multiple second applications, the second container group where each second application is located is determined according to the resource file of each second application. Based on the result analysis annotation, at least one result analysis component is injected into each second container group in the form of a sidecar container.

[0140] In this way, by adding multiple request replication annotations to the resource file of the first application, each request replication annotation corresponds to each second application, it is possible to use the same access request to test multiple different new versions of cloud-native applications simultaneously, and compare the test results of different new versions of cloud-native applications to achieve regression testing of cloud-native applications.

[0141] In some embodiments, the provided method further includes: in response to the deletion of at least one test configuration information from the resource files of the cloud-native application, determining the container group where the cloud-native application resides; and deleting the corresponding test component in the container group based on the test configuration information.

[0142] In practical applications, the application test controller continuously monitors changes to resource files of all cloud-native applications on the cloud container platform. When the application test controller detects that at least one test configuration information has been deleted from the resource files of a cloud-native application, it determines the container group where the cloud-native application resides and dynamically deletes the corresponding test components from the container group based on the deleted test configuration information.

[0143] Specifically, taking a Kubernetes cluster as an example, the application test controller can continuously monitor changes in resource files of all applications in the Kubernetes cluster through the API-Server component. When the application test controller detects that a request replication annotation or a result analysis annotation has been deleted from a resource file, it dynamically deletes the request replication component in the first container group or the result analysis component in the second container group.

[0144] Understandably, when the request replication component and result analysis component are dynamically deleted, access requests sent to the first application will no longer be intercepted and replicated, but will directly reach the first application. Thus, by dynamically adding or deleting test configuration information in the resource files of cloud-native applications, test configurations for cloud-native applications can be quickly set or canceled, achieving a flexible and convenient approach to testing cloud-native applications.

[0145] In summary, this application deploys an application test controller in a container cloud platform to monitor changes in the resource files of cloud-native applications. When at least one new test configuration information is added to the resource files of the cloud-native application, the container group containing the cloud-native application is determined. Then, based on the newly added test configuration information, at least one test component is injected into the container group in the form of a sidecar container. This test component performs corresponding test operations on the cloud-native application. Thus, leveraging the container cloud platform's ability to monitor changes in the resource files of deployed cloud-native applications in real time, and utilizing sidecar technology to flexibly extend the functionality of cloud-native applications, this application dynamically injects test components, relatively independent of the cloud-native application's business logic, into the container group in the form of a sidecar container. Test component configuration requires only simple operations, allowing for flexible and convenient testing of cloud-native applications in the container cloud platform to meet the application testing needs of cloud-native scenarios.

[0146] In this application, leveraging the advantage of sidecar technology in extending application functionality, the sidecar container actively intercepts access requests from the business container, and sets up a request replication component in the sidecar container to replicate the access requests from the business container. The request replication component does not need to be coupled with the application in the business container, so there is no need to modify the application code, thereby reducing the workload of testing cloud-native applications.

[0147] In this application, a request replication annotation is added to the resource file of the cloud-native application to mark the first application that needs to perform access request replication. Based on the addition and deletion of the request replication annotation in the resource file of the first application, the request replication component is automatically injected and deleted in the container group where the application is located in the form of a sidecar container. The implementation of the solution is flexible and can meet the needs of application testing in cloud-native scenarios.

[0148] In this application, the method of adding result analysis annotations to the resource files of cloud-native applications is used to mark the second application that needs to be analyzed for test results. Based on the addition and deletion of result analysis annotations, the result analysis component is automatically injected and deleted in the container group where the second application is located in the form of a sidecar container. This allows for the analysis of test results using different types of result analysis models according to test requirements.

[0149] Exemplary System

[0150] This application provides a cloud-native application testing system based on sidecar technology. Figure 4 This is a schematic diagram of the structure of a cloud-native application testing system based on sidecar technology, according to some embodiments of this application. Figure 4As shown, the system includes an application test controller, which is deployed on a container cloud platform. The application test controller includes a resource monitoring unit 401, a test configuration unit 402, and a component injection unit 403.

[0151] Resource monitoring unit 401 is configured to monitor changes in resource files of cloud-native applications;

[0152] Test configuration unit 402 is configured to add at least one test configuration information in response to the resource files of cloud-native applications, and to determine the container group where the cloud-native application resides.

[0153] The component injection unit 403 is configured to inject at least one test component into the container group in the form of a sidecar container according to the test configuration information.

[0154] Among them, cloud-native applications are any applications deployed in the container cloud platform, and the testing components are used to perform corresponding test operations on cloud-native applications.

[0155] The cloud-native application testing system for sidecar technology provided in this application embodiment can implement the process and steps of any of the above-mentioned cloud-native application testing methods for sidecar technology and achieve the same technical effect, which will not be described in detail here.

[0156] Exemplary device

[0157] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to some embodiments of this application; such as Figure 5 As shown, the electronic device includes:

[0158] One or more processors 501;

[0159] A computer-readable medium may be configured to store one or more programs 502. When one or more processors 501 execute one or more programs 502, the following steps are performed: monitoring changes in the resource files of the cloud-native application; in response to the addition of at least one test configuration information to the resource files of the cloud-native application, determining the container group where the cloud-native application resides; and injecting at least one test component into the container group in the form of a sidecar container based on the test configuration information; wherein the cloud-native application is any application deployed in the container cloud platform, and the test component is used to perform corresponding test operations on the cloud-native application.

[0160] Figure 6 The hardware structure of an electronic device provided according to some embodiments of this application; such as Figure 6 As shown, the hardware structure of the electronic device may include: a processor 601, a communication interface 602, a computer-readable medium 603, and a communication bus 604.

[0161] The processor 601, communication interface 602, and computer-readable storage medium 603 communicate with each other via communication bus 604.

[0162] Optionally, the communication interface 602 can be an interface of a communication module, such as the interface of a GSM module.

[0163] Specifically, processor 601 can be configured to: monitor changes in the resource files of cloud-native applications; determine the container group where the cloud-native application resides in response to the addition of at least one test configuration information to the resource files of the cloud-native application; and inject at least one test component into the container group in the form of a sidecar container based on the test configuration information; wherein the cloud-native application is any application deployed in the container cloud platform, and the test component is used to perform corresponding test operations on the cloud-native application.

[0164] The processor 601 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or it can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor.

[0165] The electronic devices described in this application exist in various forms, including but not limited to:

[0166] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and primarily aim to provide voice and data communication. These terminals include: smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones, etc.

[0167] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, possessing computing and processing capabilities, and generally also have mobile internet access features. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0168] (3) Portable entertainment devices: These devices can display and play multimedia content. This category includes audio and video players (e.g., iPods), handheld game consoles, e-book readers, as well as smart toys and portable car navigation devices.

[0169] (4) Server: A device that provides computing services. The components of a server include a processor, hard disk, memory, system bus, etc. Servers are similar to general computer architectures, but because they need to provide highly reliable services, they have higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0170] (5) Other electronic devices with data interaction functions.

[0171] It should be noted that, depending on the implementation needs, the various components / steps described in the embodiments of this application can be broken down into more components / steps, or two or more components / steps or parts of the operation of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of this application.

[0172] The methods described in the embodiments of this application can be implemented in hardware, firmware, or as software or computer code that can be stored in a recording medium (such as CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk), or as computer code downloaded over a network that is originally stored in a remote recording medium or non-transitory machine storage medium and will be stored in a local recording medium. Thus, the methods described herein can be stored on a recording medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware (such as an ASIC or FPGA) for such software processing. It is understood that the computer, processor, microprocessor controller, or programmable hardware includes storage components (e.g., RAM, ROM, flash memory, etc.) capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the cloud-native application testing method based on sidecar technology described herein is implemented. Furthermore, when a general-purpose computer accesses the code used to implement the methods shown herein, the execution of the code transforms the general-purpose computer into a dedicated computer for executing the methods shown herein.

[0173] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application of the technical solution and the constraints involved. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.

[0174] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0175] The device and system embodiments described above are merely illustrative. The units referred to as separate entities may or may not be physically separate. The entities mentioned 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 the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0176] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cloud-native application testing method based on sidecar technology, characterized in that, The method is applied to an application test controller, which is deployed on a container cloud platform and includes: Monitor changes to the resource files of the cloud-native application; In response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group in which the cloud-native application resides is determined; Based on the test configuration information, inject at least one test component into the container group in the form of a sidecar container; Wherein, the cloud-native application is any application deployed in the container cloud platform, and the testing component is used to perform corresponding testing operations on the cloud-native application; The test configuration information includes a request replication annotation, which is in key-value pair format. The key identifies the annotation type as a request replication annotation, and the value is the identifier information of the second container group where the second application resides. Correspondingly, in response to the resource file of the cloud-native application, at least one test configuration information is added to determine the container group where the cloud-native application resides. Based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container, specifically: In response to the addition of at least one request copy annotation to the resource file of the first application, the first container group in which the first application resides is determined; Based on the requested replication annotation, at least one requested replication component is injected into the first container group in the form of a sidecar container; The request replication component is used to replicate the access request sent to the first application to obtain an access request copy, and forward the access request copy and the access request to the second application and the first application respectively, so that the second application processes the access request copy to obtain the test result of the second application; wherein the first application is the existing version of the cloud-native application; and the second application is the new version of the cloud-native application. The request replication component is also used to: determine the second container group where the second application is located based on the identification information of the second container group where the second application is located; Establish a network connection with the second container group to forward the copy of the access request to the second application; The method further includes: in response to the deletion of at least one test configuration information from the resource files of the cloud-native application, determining the container group in which the cloud-native application resides; Based on the test configuration information, delete the corresponding test component in the container group.

2. The cloud-native application testing method based on sidecar technology according to claim 1, characterized in that, The test configuration information includes result analysis annotations. Correspondingly, In response to the addition of at least one test configuration information to the resource file of the cloud-native application, the container group where the cloud-native application resides is determined; based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container, specifically: In response to the addition of at least one result analysis annotation to the resource file of the second application, the second container group in which the second application resides is determined; Based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container; The result analysis component is used to process the test results of the second application.

3. The cloud-native application testing method based on sidecar technology according to claim 2, characterized in that, The result analysis annotations include the identification information of the result analysis model. Correspondingly, The results analysis component is specifically used for: The result analysis model is determined based on the identification information of the result analysis model; The test results of the second application are analyzed based on the aforementioned result analysis model to obtain the analysis results; The test results of the second application and the analysis results are stored in the storage system.

4. The cloud-native application testing method based on sidecar technology according to claim 2, characterized in that, There are multiple second applications, and these multiple second applications are different new versions of the cloud-native applications. Each newly added request replication annotation in the resource file of the first application corresponds to each second application. Correspondingly, In response to the resource file of the second application, at least one result analysis annotation is added to determine the second container group where the second application resides; based on the result analysis annotation, at least one result analysis component is injected into the second container group in the form of a sidecar container, specifically: In response to the addition of at least one result analysis annotation to the resource files of multiple second applications, the second container group in which each second application resides is determined; Based on the result analysis annotation, at least one result analysis component is injected into each of the second container groups in the form of a sidecar container.

5. A cloud-native application testing system based on sidecar technology, characterized in that, The system includes an application test controller deployed on a container cloud platform. The application test controller comprises a resource monitoring unit, a test configuration unit, and a component injection unit. The resource monitoring unit is configured to monitor changes in the resource files of the cloud-native application. The test configuration unit is configured to add at least one test configuration information in response to the resource file of the cloud-native application, and to determine the container group where the cloud-native application resides. The component injection unit is configured to inject at least one test component into the container group in the form of a sidecar container according to the test configuration information. Wherein, the cloud-native application is any application deployed in the container cloud platform, and the testing component is used to perform corresponding testing operations on the cloud-native application; The test configuration information includes a request replication annotation, which is in key-value pair format. The key identifies the annotation type as a request replication annotation, and the value is the identifier information of the second container group where the second application resides. Correspondingly, in response to the resource file of the cloud-native application, at least one test configuration information is added to determine the container group where the cloud-native application resides. Based on the test configuration information, at least one test component is injected into the container group in the form of a sidecar container, specifically: In response to the addition of at least one request copy annotation to the resource file of the first application, the first container group in which the first application resides is determined; Based on the requested replication annotation, at least one requested replication component is injected into the first container group in the form of a sidecar container; The request replication component is used to replicate the access request sent to the first application to obtain an access request copy, and forward the access request copy and the access request to the second application and the first application respectively, so that the second application processes the access request copy to obtain the test result of the second application; wherein the first application is the existing version of the cloud-native application; and the second application is the new version of the cloud-native application. The request replication component is also used to: determine the second container group where the second application is located based on the identification information of the second container group where the second application is located; Establish a network connection with the second container group to forward the copy of the access request to the second application; The system further includes: in response to the deletion of at least one test configuration information from the resource files of the cloud-native application, determining the container group where the cloud-native application resides; Based on the test configuration information, delete the corresponding test component in the container group.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer program is a cloud-native application testing method based on sidecar technology as described in any one of claims 1-4.

7. An electronic device, characterized in that, include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the cloud-native application testing method based on sidecar technology as described in any one of claims 1-4.

Images