CN111737128A

CN111737128A - On-line testing method, gray level shunting equipment and storage medium

Info

Publication number: CN111737128A
Application number: CN202010567791.1A
Authority: CN
Inventors: 何赛松; 郝伟; 王气正; 王纯; 徐鹏
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-06-19
Filing date: 2020-06-19
Publication date: 2020-10-02

Abstract

The application discloses an online testing method, a gray level shunting device and a storage medium, and relates to the field of cloud computing. The specific implementation scheme is as follows: receiving an access request forwarded by a service access layer of a cloud product; analyzing the access request to obtain the head data of the access request; after detecting that gray scale identification exists in the request identification of the head data, determining that the access request is a gray scale request, and shunting the gray scale request to a gray scale test environment of the cloud product matched with the gray scale identification; the gray scale test environment runs in the on-line resources of the cloud product, and therefore the gray scale request is executed in the gray scale test environment by using the on-line resources of the cloud product, and the on-line test is achieved.

Description

On-line testing method, gray level shunting equipment and storage medium

Technical Field

The application relates to the field of computers, in particular to the field of cloud computing.

Background

Since the concept of "cloud computing" was first proposed in 2006, the industry has been rapidly developing over a decade and has provided cloud services in various forms. While great social value is brought, product architectures of cloud manufacturers become huge, dependency relationships among products are complicated, and under the conditions of fast iteration and various requirements of users, strict reliability guarantee needs to be provided, so that the overall quality guarantee work of cloud products faces great pressure and challenge. However, compared with a common software product, the quality assurance work of the cloud product is more difficult, and therefore, how to efficiently test the cloud product with low cost becomes a problem to be solved urgently.

Disclosure of Invention

The disclosure provides an online testing method, a gray level shunt device and a storage medium.

According to an aspect of the present disclosure, there is provided an inline test method including:

receiving an access request forwarded by a service access layer of a cloud product;

analyzing the access request to obtain the head data of the access request;

after detecting that gray scale identification exists in the request identification of the head data, determining that the access request is a gray scale request, and shunting the gray scale request to a gray scale test environment of the cloud product matched with the gray scale identification; wherein the gray scale test environment operates in an online resource of a cloud product to execute the gray scale request in the gray scale test environment using the online resource of the cloud product.

According to another aspect of the present disclosure, there is provided a gray dividing device including:

the receiving unit is used for receiving the access request forwarded by the service access layer of the cloud product;

the request analysis unit is used for analyzing the access request to obtain the head data of the access request;

the shunting unit is used for determining that the access request is a gray level request after detecting that gray level identification exists in the request identification of the head data, and shunting the gray level request to a gray level test environment of the cloud product matched with the gray level identification; wherein the gray scale test environment operates in an online resource of a cloud product to execute the gray scale request in the gray scale test environment using the online resource of the cloud product.

According to another aspect of the present disclosure, there is provided a gray-scale shunting device comprising at least one processor; and a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method described above.

According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method described above.

Therefore, the method and the device for testing the cloud product can directly identify the gray level request based on the head data of the access request and shunt the gray level request to the gray level testing environment, so that a universal and low-cost cloud product testing method is provided; in addition, as the gray scale test environment is deployed in online resources of the cloud product, the test process of the gray scale test environment can be completed by fully utilizing the online resources, and the method is low in cost, high in universality and convenient for large-scale engineering application.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not intended to limit the present application. Wherein:

FIG. 1 is a schematic flow chart of an on-line testing method according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an inline testing method in a specific example according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of an online grayscale test supporting cloud products according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a split flow of a gray scale flow controller according to an embodiment of the present application;

FIG. 5 is a schematic interface diagram of a chrome plug-in according to an embodiment of the present application;

FIG. 6 is a business logic diagram of a cloud product according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a complete gray level split of a cloud product according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a high performance offload mechanism according to an embodiment of the application;

FIG. 9 is a test flow diagram of a general real-time drain and offline drain according to an embodiment of the present application;

FIG. 10 is a block diagram of a gray scale shunting device used to implement the on-line testing method of an embodiment of the present application;

fig. 11 is a schematic hardware configuration diagram of a gray-scale shunting device for implementing the online testing method according to the embodiment of the present application.

Detailed Description

The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The cloud product system is complex, the structure is not uniform, the existing scheme can not realize the on-line gray level test at low cost, and based on the method, the scheme aims to realize the general and low-cost full-link gray level test on the cloud product line, and solves the problems that the environment is unstable, the resources are insufficient, the full-link test can not be realized, and the user scene is difficult to construct in the cloud product quality guarantee process. In other words, a general on-line gray scale test scheme for cloud products is provided, and uniform on-line gray scale tests can be safely and efficiently provided for cloud products developed by adopting different technical frameworks at low cost.

Specifically, the present application provides an online testing method, as shown in fig. 1, including:

step S101: the gray level shunting device receives an access request forwarded by a service access layer of the cloud product. Namely, the gray level shunting device receives an access request, and the access request is forwarded to the gray level shunting device after a service access layer of the cloud product receives the access request.

Step S102: and the gray level shunting equipment analyzes the access request to obtain the head data of the access request.

Step S103: after the gray level shunting equipment detects that gray level identification exists in the request identification of the head data, determining that the access request is a gray level request, and shunting the gray level request to a gray level test environment of the cloud product matched with the gray level identification; wherein the gray scale test environment operates in an online resource of a cloud product to execute the gray scale request in the gray scale test environment using the online resource of the cloud product.

For example, in an example, as shown in fig. 2, an online grayscale test can solve the problems of environment, resources, test coverage, and the like in an optimal manner, and is very suitable for quality assurance work of cloud products, specifically, in the online grayscale test, a grayscale user (corresponding to a grayscale request) accesses a grayscale test environment through an online service access layer, and a normal user (corresponding to a normal request) also accesses a formal environment through the online service access layer, where the formal environment and the grayscale test environment are both built depending on online resources of the cloud product, and therefore, the application scheme can reduce resource dependence on a test sandbox; testing can cover the full online link; moreover, a real scenario is used to complete the test; meanwhile, the on-line idle resources are fully utilized, and the problem of testing resources is solved.

In a specific example of the present application, as shown in fig. 1, the detecting in step 103 that a gray scale flag exists in the request flag of the header data includes: the gray level shunting equipment detects whether the request identification of the head data carries a target character string; wherein the target character string comprises at least one character capable of distinguishing the access request as a normal request or a gray level request; and determining that the gray scale identification exists in the head data in response to the detection that the request identification of the head data carries the target character string. That is, the gradation shunting device determines whether the gradation identification exists in the header data based on the detection result. Therefore, the target character string is used as the gray level identification in the access request, so that the technical architecture of the cloud product is not required in the online gray level test process, the cloud product can be realized without modifying a line of codes by business, the modification cost is low, and the test iteration efficiency is improved.

For example, in an example, the grayscale marker is a target character string, and the target character string includes characters capable of distinguishing a grayscale Request from a normal Request, taking a hypertext transfer protocol (http) Request as an example, at this time, the grayscale marker is carried in an http header (i.e., header data) such as a Request, and the Request id can be used for the front and back ends of a cloud product and records all links of one Request, so as to facilitate problem finding. Here, the Request id is generally a 32-bit Universal Unique Identifier (UUID) string, and is typically 16-ary data, such as:

X-Bce-Request-Id:eaef5fdb-9148-49f3-b9d8-6c6373b2f739；

at this time, the last 16 bits may be modified to a specific gray scale, for example, to:

eaef5fdb-9148-49f 3-item label-grayscale split label;

the project label is a combination of 4 random numbers and letters and is used for indicating a project for gray level test so as to facilitate internal maintenance and management; the gray shunting label is a combination of 12 arbitrary numbers and letters and is used for pointing to a gray testing environment. In practical application, the on-line gray level test process can be realized as long as it is ensured that the item label and the gray level shunt label contain letters that are not contained in the normal Request, for example, taking data with Request id being 16-system as an example, at this time, the item label and the gray level shunt label only need to contain g-z that is not contained in the 16-system.

In a specific example of the present application, the grayscale identification is automatically added to the grayscale request through an application editing interface, or is automatically added to the grayscale request through a browser plug-in. For example, the access request is an Application Programming Interface (API) request, and at this time, the grayscale identifier can be automatically added to the grayscale request through the API interface; and when the access request is sent through the browser, the gray level identification can be added to the gray level request through the preset plug-in, so that the operation is simple, and the large-scale engineering application is facilitated.

In a specific example of the application, after detecting that the gray scale identifier does not exist in the request identifier of the header data, the gray scale shunting device determines that the access request is a normal request, and shunts the formal request to a formal environment of the cloud product; wherein the formal environment operates in the online resources of the cloud product to execute the normal request in the formal environment using the online resources of the cloud product. That is to say, as shown in fig. 2, the scheme of the present application can also support the front-end service request of a normal user, and only the gray level shunting device needs to complete shunting, so that the gray level test can not cause any influence on the normal environment under the condition that the on-line resources are fully utilized.

In a specific example of the present application, a formal environment runs in an online resource of the cloud product; based on this, the gray level shunting equipment acquires the user data in the formal environment, processes the user data and then drains the user data to the gray level test environment, so that the gray level test environment is tested by using the user data in the formal environment, and the effect of testing a real user scene is realized on the basis that a user does not need to directly participate.

In a specific example of the present application, the grayscale splitting device obtains a service request identifier generated based on the grayscale request, and stores the service request identifier generated by the grayscale request; and after the gray level shunting equipment determines that the gray level test resource indicated by the service request identification is released, releasing the gray level test resource and releasing the gray level test resource to the gray level test environment. Therefore, the cloud product rear end can distinguish the data of the gray level request based on the service request identification of the gray level request, and simultaneously distinguish the resources used by the service request identification of the gray level request, so that after the gray level test resources are released, the gray level test resources are released and released to the gray level test environment, the gray level test environment can continue to operate normally, and effective distinguishing and management of the resources are realized.

In a specific example of the present application, after detecting that a grayscale policy is not stored in a shared memory, the grayscale splitting device acquires a grayscale policy from a distributed cache system corresponding to the cloud product, and stores the grayscale policy in the shared memory after acquiring the grayscale policy, so as to split the grayscale request based on the grayscale policy stored in the shared memory. In practical application, the grayscale splitting device splits based on a grayscale policy, so that it is ensured that corresponding access requests are split to corresponding environments, and high-performance grayscale splitting is realized.

The following describes the present application in further detail with reference to a specific example, specifically, the present example implements an online grayscale test for a cloud product based on OpenResty and other technologies, as shown in fig. 3, an administrator issues a grayscale policy, a performance comparison, a traffic capture and playback policy, and the like to a central control node through a Web page (e.g., a grayscale management page) of a grayscale test management system, and the central control node stores and forwards the policies to a specified grayscale traffic controller (i.e., a grayscale shunting device); the gray level user can use a unified online service access layer of a cloud product as a normal user, and certainly, in order to use the existing gray level test, the gray level user can also use the gray level access layer and the sandbox access layer, and at this time, all the flow (namely, the access request) is led into the gray level flow controller.

Here, the gray level controller developed based on the OpenResty technology mainly has the following functions:

firstly, an access request can be divided into a normal request and a gray request according to any http information set in a gray strategy, and the normal request and the gray request are respectively forwarded to a gray test environment and a formal environment, wherein the 2 environments are all built by depending on an environment on a cloud line;

secondly, capturing a request and a response of a specified time period and a specified Uniform Resource Locator (URL) into a local database according to a drainage playback strategy, and playing back the request and the response to a gray level test environment after data cleaning and authentication cleaning;

thirdly, distinguishing back-end callback flow according to an order identification (order id) and a resource identification (resource id) generated based on the gray level request, and accurately forwarding the resource used by the callback flow to a gray level test environment or a formal environment after the resource used by the callback flow is released;

and fourthly, receiving commands of system management, upgrading, monitoring and the like initiated by the central control node, and realizing self-operation and maintenance irrelevant to the service.

Therefore, all cloud products with different architectures can be supported, and the gray level test of the link on the whole line can be safely realized at low cost. In addition, in this example, the cloud product can have a formal environment and a gray level test environment in the same online region, and can implement gray level shunting, so that the test iteration completely multiplexes sufficient and stable resources on the line, and simultaneously can cover the entire online link, and meanwhile, the supported flow capturing and playback function can greatly reduce the problem of user scene coverage. In addition, the whole scheme of the example can adapt to all cloud product architectures without modifying a line of codes of the cloud products, and has high performance and high system self-operation and maintenance capability, so that the cost of the gray test on the access line of the complex cloud products is reduced to the minimum.

The present example is described in further detail below in four aspects, specifically,

in the first aspect, the core of the gray scale test is as follows: a flow separation scheme.

Theoretically, all http information with discrimination can be used for gray level traffic shunting, but for cloud products, an efficient and safe shunting mechanism is required, and many existing ways are not applicable, for example, the first way generally has various forwarding regular configurations in a cloud service access layer, and if gray level identifiers are added to newly added fields in parameters such as Session, http header, URL, and the like, a large amount of extra configuration work can be brought, and the cloud products are difficult to fall to the ground. In the second way, since all requests go through an authentication process to obtain a user id, if the user id is used to perform a split according to a white list of a gray level test, a large performance impact is caused and the performance of an on-line normal service is seriously affected. In the third mode, stream information is newly added in a Method, a URL, a Body, and the like, and at this time, code change is involved, and the stream information cannot be commonly used among projects, so that the implementation cost of a service is very high. A fourth method, based on Internet Protocol (IP) or percentage offloading, may cause the backend of offloading to be non-uniform, and may not be used for cloud products with an association relationship between front and back requests.

Based on this, this example designed a particularly elegant splitting scheme: shunting is carried out based on a Request id (namely a Request identifier) in the existing http header which penetrates through the whole cloud product Request link, and a service code or a flow access layer does not need to be changed.

Here, the Request id is widely used in cloud products, and is used for recording all links of one Request by the front end and the back end, so that problem tracing is facilitated. In general, a Request id is a 32-bit UUID string, usually 16-bit data, and is recorded in an http header, for example: X-Bce-Request-Id eaef5fdb-9148-49f3-b9d8-6c6373b2f 739.

In this example, the last 16 bits of the data are modified to specific gray marks: for example:

eaef5fdb-9148-49f 3-item label-grayscale split label;

Thus, by adopting Request id splitting, all the gray splitting schemes shown in fig. 4 can be supported, and at the same time, the following advantages exist:

firstly, Request id is configured according to standards of each cloud service, is processed according to 32-bit strings, is normally transmitted in various flow access layers, does not need any transformation or configuration, and is suitable for all cloud services;

secondly, the Request id generated by the normal user, namely the normal Request, is certain 16-system data (0-9, a-f) and cannot contain g-z letters, so that the traffic of the normal user is ensured not to be led into a gray level test environment to influence the online service;

thirdly, shunting is carried out based on the Request id in the http header, and the shunting performance is very high.

In practical application, a gray user can initiate a Request id Request with a gray identifier by the following method, without any change in the use mode of a normal user:

the first way, API request, only 2 lines of code are needed to add gray scale identification to the gray scale request.

In the second way, as shown in fig. 5, a web page initiates a request, and at this time, a browser plug-in, such as a chrome plug-in, needs to be developed in advance, and then a request configuration grayscale identifier is automatically added to the onbeforeend headers of each web request, so that a plug-in type grayscale opening and closing function is realized, and the method is simple and easy to use.

In a second aspect, a offload scheme for back-end callback requests.

The requests received by the cloud service on the line are generally divided into 2 types, as shown in fig. 6, taking a normal user request as an example, the requests are respectively:

(1) user requests (such as gray level requests and normal requests) are accessed uniformly by the access layer through the flow;

(2) and calling back a request, and logic of the cloud product, including an order request, a charging request and the like.

There is generally no correlation between the user request and the callback request, but the gray level shunting must be able to correctly shunt the user request and the callback request at the same time, otherwise, the data confusion of the formal environment and the gray level test environment will be caused. Because the logic of order execution, charging and the like is an asynchronous calling process, gray scale marks initiated by the front end do not exist in callback requests, and if the requests cannot be correctly processed, data confusion of a gray scale test environment and an online environment can be caused.

Therefore, as shown in fig. 7, in the present application, Request id is adopted for a user Request to perform offloading, and for a Request of an order and a resource operation, a service Request identifier associated with a gray level Request, such as an order Request id and a resource Request id, is recorded in a gray level flow controller, and after a callback interface initiates a Request, offloading is implemented through the order id and the resource id stored in the gray level flow controller, so that accurate front-end and back-end gray level Request offloading is implemented, data correctness of a system is ensured, and meanwhile, accurate release of resources is implemented.

And the third part is a high-performance and safe gray-scale shunting scheme.

The gray-scale flow controller simultaneously hosts online traffic (i.e., traffic corresponding to a normal request) and gray-scale traffic (i.e., traffic corresponding to a gray-scale request), so the gray-scale shunting performance must have no influence on the service. Based on this, the present example implements a high-performance gray-scale shunting mechanism by following ways to ensure no impact on the service. Specifically, as shown in fig. 8, after receiving the grayscale policy set by the system administrator, the central control node issues the grayscale policy to the grayscale traffic controller and the distributed cache system (e.g., redis cluster) at the same time. The gray scale flow controller stores the gray scale strategy in the shared memory, and after a plurality of working processes receive a user request, the flow is divided according to the gray scale strategy in the shared memory. Because the shared memory is volatile, the gray level strategy is lost after restarting or downtime, so when the gray level flow controller distributes requests, if the gray level strategy in the shared memory is found, the gray level flow controller is synchronized once and is subsequently and permanently effective in the redis cluster. Thus, compared with a scheme of periodically acquiring from the redis cluster, the method and the device solve the problem that the gray-scale strategy is not timely effective, and avoid the problem of reduced shunting performance caused by frequent acquisition, for example, when the gray-scale strategy is periodically acquired from the redis cluster once, the gray-scale strategy can be synchronized from the redis cluster according to the acquisition period even if the gray-scale strategy is not changed, and thus the shunting performance can be influenced. Moreover, the gray level distribution realized based on the scheme of the example supports the distribution speed of a single node more than 15000 times/second, has almost the same difference with the native upstream forwarding performance of nginx, and ensures that the performance damage of the gray level distribution does not influence the cloud service.

In a fourth aspect, generic inline drainage and playback testing is supported.

On-line gray level test is not enough only for gray level shunting, and user scene coverage is also one of the keys. There are generally 3 drainage playback schemes in the industry, which are:

the first scheme is as follows: log-based traffic playback; the advantages are that: normal requests are not affected at all; the disadvantages are as follows: the log initiation request needs to be analyzed, and customized development needs to be carried out aiming at different log formats. Scheme II: realizing flow replication based on Transmission Control Protocol (TCP) Copy; the advantages are that: flow replication is carried out from a network layer without penetrating a protocol stack; the disadvantages are as follows: the deployment and operation and maintenance costs are high, and root operation of iptables, kernel starting of iptue and the like are required. The third scheme is as follows: replicating traffic based on Go Replay; the advantages are that: request amplification and filtering are supported; the disadvantages are as follows: each service can be separately deployed on line, and authentication cleaning is not supported.

Obviously, the three schemes are not suitable for cloud products, because, firstly, the cost problem cannot be solved, each service is developed independently, and the cost is high; secondly, the problems of maintenance, online drainage and playback are solved, if machines in all online environments need to be operated independently, each service is maintained independently, and the maintenance cost is high; thirdly, the authentication problem, the request of the real user cannot be directly played back in a drainage manner, which causes the problems of charging and the like, therefore, the request must be converted into a test account number through user authentication cleaning and the like, and the request is requested for the validity period, if the playback request time and the cloud product server time exceed 30 minutes, the server can consider that the request is an expired request and directly refused, and therefore the playback request must be processed to be correctly played back.

Based on this, as shown in fig. 9, the present example implements a low-cost, universal drain and playback test scheme:

(1) because the gray level flow controller can normally host normal flow and gray level flow, various user request parameters and response results can be captured at low cost;

(2) aiming at the test account, the gray level flow controller can directly conduct current in real time, and simultaneously distribute the gray level request to an online environment and a gray level test environment, so that an AB test report can be obtained; of course, off-line drainage can be realized, and the mode is flexible and controllable.

(3) Aiming at the request of a normal user, namely a normal request, the gray level flow controller captures the user request, stores the user request in a database, and plays back the user request to a gray level test environment after data cleaning, authentication cleaning and other processing, so that the test coverage of a user scene is realized, namely, the real flow of the user can be introduced for gray level test, and therefore, the test coverage cost of the user scene can be greatly reduced.

In summary, the online grayscale test scheme of the example has no requirement on the technical architecture of the cloud product, can be implemented without modifying a line of codes by a service, can fully utilize idle, sufficient and stable resources on the line, and improves the test iteration efficiency; meanwhile, the gray level distribution of the front-end service request and the rear-end management request is supported, so that the gray level test is ensured not to cause any influence on the line; moreover, the method covers the whole online link, ensures that the gray level test is completely consistent with the using environment and the flow of an actual user, and can realize the function of opening and closing the gray level in a plug-in mode through controlling the browser plug-in for the browser request, so that the method is simple and easy to use.

The present application further provides a gray splitting device, as shown in fig. 10, including:

a receiving unit 1001, configured to receive an access request forwarded by a service access layer of a cloud product;

a request parsing unit 1002, configured to parse the access request to obtain header data of the access request;

the shunting unit 1003 is configured to determine that the access request is a gray scale request after detecting that a gray scale identifier exists in the request identifier of the head data, and shunt the gray scale request to a gray scale test environment of the cloud product matched with the gray scale identifier; wherein the gray scale test environment operates in an online resource of a cloud product to execute the gray scale request in the gray scale test environment using the online resource of the cloud product.

In an example of the present application, the flow dividing unit includes:

the detection submodule is used for detecting whether the request identifier of the head data carries a target character string or not; wherein the target character string comprises at least one character capable of distinguishing the access request as a normal request or a gray level request;

and the determining submodule is used for responding to the fact that the request identifier of the head data carries the target character string, and determining that the gray-scale identifier exists in the head data.

In an example of the present application, the grayscale identification is automatically added to the grayscale request through an application editing interface or automatically added to the grayscale request through a browser plug-in.

In an example of the application, the offloading unit is further configured to determine that the access request is a normal request after detecting that the gray scale identifier does not exist in the request identifier of the header data, and offload the formal request into a formal environment of the cloud product; wherein the formal environment operates in the online resources of the cloud product to execute the normal request in the formal environment using the online resources of the cloud product.

In an example of the present application, a formal environment is run in online resources of the cloud product; further comprising:

and the drainage unit is used for acquiring the user data in the formal environment, treating the user data and then draining the user data to the gray level test environment so as to test the gray level test environment by using the user data of the formal environment.

In an example of the present application, the method further includes:

the identification management unit is used for acquiring a service request identification generated based on the gray level request and storing the service request identification generated by the gray level request;

and the resource management unit is used for releasing the gray-scale test resource indicated by the service request identification and releasing the gray-scale test resource to the gray-scale test environment after determining that the gray-scale test resource is released.

In an example of the present application, the method further includes:

and the strategy management unit is used for acquiring the gray strategy from the distributed cache system corresponding to the cloud product after detecting that the gray strategy is not stored in the shared memory, and storing the gray strategy in the shared memory so as to shunt the gray request based on the gray strategy stored in the shared memory.

Here, it should be noted that: the description of the above device embodiment is similar to the description of the above method, and has the same beneficial effects as the method embodiment, and therefore, the description thereof is omitted. For technical details not disclosed in the embodiments of the apparatus of the present application, those skilled in the art should refer to the description of the embodiments of the method of the present application for understanding, and for the sake of brevity, will not be described again here.

According to an embodiment of the present application, there is also provided a gray dividing device and a readable storage medium.

Fig. 11 is a block diagram of a grayscale splitting device according to an embodiment of the present application. The grayscale shunting device is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present application that are described and/or claimed herein.

As shown in fig. 11, the gray dividing device includes: one or more processors 1101, a memory 1102, and interfaces for connecting the various components, including a high speed interface and a low speed interface. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions executed within the grayscale shunting device, including instructions stored in or on the memory to display graphical information of the GUI on an external input/output apparatus (such as a display device coupled to the interface). In other embodiments, multiple processors and/or multiple buses may be used, along with multiple memories and multiple memories, as desired. Also, multiple grayscale shunting devices may be connected, with each device providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multi-processor system). In fig. 11, a processor 1101 is taken as an example.

The memory 1102 is a non-transitory computer readable storage medium as provided herein. The memory stores instructions executable by at least one processor to cause the at least one processor to perform the online testing method provided herein. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the online testing method provided herein.

The memory 1102, which is a non-transitory computer readable storage medium, may be used to store non-transitory software programs, non-transitory computer executable programs, and modules, such as program instructions/modules corresponding to the online testing method in the embodiment of the present application (for example, the receiving unit 1001, the request parsing unit 1002, and the shunting unit 1003 shown in fig. 10). The processor 1101 executes various functional applications of the server and data processing, i.e., implements the online test method in the above-described method embodiments, by running non-transitory software programs, instructions, and modules stored in the memory 1102.

The memory 1102 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the gradation shunting device of the on-line test method, or the like. Further, the memory 1102 may include high speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid state storage device. In some embodiments, the memory 1102 may optionally include a memory remotely located from the processor 1101, and these remote memories may be connected to the gray-scale shunting device of the online test method via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

These computer programs (also known as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented using high-level procedural and/or object-oriented programming languages, and/or assembly/machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present application may be executed in parallel, sequentially, or in different orders, and the present invention is not limited thereto as long as the desired results of the technical solutions disclosed in the present application can be achieved.

The above-described embodiments should not be construed as limiting the scope of the present application. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An online testing method, comprising:

analyzing the access request to obtain the head data of the access request;

2. The method of claim 1, wherein the detecting that a gray scale flag is present in the request flag of the header data comprises:

detecting whether the request identification of the head data carries a target character string; wherein the target character string comprises at least one character capable of distinguishing the access request as a normal request or a gray level request;

and determining the access request as a gray level request in response to detecting that the request identifier of the head data carries the target character string.

3. The method of claim 1 or 2, wherein the grayscale identification is automatically added to the grayscale request through an application editing interface or automatically added to the grayscale request through a browser plug-in.

4. The method of claim 1, further comprising:

after detecting that the gray-scale identifier does not exist in the request identifier of the head data, determining that the access request is a normal request, and shunting the formal request to the formal environment of the cloud product; wherein the formal environment operates in the online resources of the cloud product to execute the normal request in the formal environment using the online resources of the cloud product.

5. The method of claim 1 or 4, wherein a formal environment is run in online resources of the cloud product; further comprising:

and acquiring user data in the formal environment, processing the user data, and guiding the processed user data to the gray scale test environment so as to test the gray scale test environment by using the user data of the formal environment.

6. The method of claim 1, further comprising:

acquiring a service request identifier generated based on the gray level request, and storing the service request identifier generated by the gray level request;

and releasing the gray scale test resource indicated by the service request identification to the gray scale test environment after determining that the gray scale test resource is released.

7. The method of claim 1, further comprising:

and after detecting that the gray strategy is not stored in the shared memory, acquiring the gray strategy from a distributed cache system corresponding to the cloud product, and storing the gray strategy in the shared memory so as to shunt the gray request based on the gray strategy stored in the shared memory.

8. A gradation shunting device comprising:

9. The apparatus of claim 8, the flow diversion unit comprising:

10. The apparatus of claim 8 or 9, wherein the grayscale identification is automatically added to the grayscale request through an application editing interface or automatically added to the grayscale request through a browser plug-in.

11. The device according to claim 8, wherein the offloading unit is further configured to determine that the access request is a normal request after detecting that the grayscale identifier does not exist in the request identifier of the header data, and offload the formal request into a formal environment of the cloud product; wherein the formal environment operates in the online resources of the cloud product to execute the normal request in the formal environment using the online resources of the cloud product.

12. The device of claim 8 or 11, wherein a formal environment runs in the online resource of the cloud product; further comprising:

13. The apparatus of claim 8, further comprising:

14. The apparatus of claim 8, further comprising:

15. A gradation shunting device characterized by comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

16. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-7.