A method, device, equipment and medium for marking diffusion service isolation test

Abstract

The application discloses a label diffusion service isolation test method, device, equipment and medium. In the application, a gray scale diffusion label is pre-stored. Each element of the same user includes the gray scale diffusion label. A request type is determined according to a data processing request and the gray scale diffusion label, and is forwarded to a server corresponding to the request type for processing, so that the gray scale test and the stress test scheme are unified. The determination of the request type based on the gray scale diffusion label ensures that all gray scale requests of the same user are verified by a gray scale server. Stress test data and normal business data are stored separately. The stress test data is written into a shadow table, and the normal business data is written into an official table. When stress test data cleaning is triggered, the entire shadow table is cleaned, so that the problem that the delete operation of the stress test data causes the database node fragmentation rate to increase is avoided.

Description

Technical Field

[0001] This application relates to the field of system isolation testing technology, and in particular to a method, apparatus, equipment and medium for testing the isolation of a marker diffusion service. Background Technology

[0002] Generally, business systems need to conduct canary testing before new business is launched and performance testing (i.e., stress testing) before activities. Existing technologies require separate design of solutions for canary testing and stress testing, lacking a unified solution.

[0003] Currently, there are two methods for verifying canary release requests on mobile devices. One is verification based on a configured list, which can perform canary release verification on requests containing fields such as specified user ID, card number, and ID number. The other is verification based on a field hash ratio, which can verify requests containing elements such as user ID, ID number, and card number according to a hash ratio. However, based on the above design, both the configured list and hash ratio methods can only test a limited number of requests in the canary release, because the canary release strategy only targets a few factors and cannot chain all requests from the same user to the canary release server for verification.

[0004] For load testing, the typical approach is to first perform write request load testing, and then use the data from the write request load testing to perform read request load testing. Subsequent load tests generally reuse this test data. However, this load testing approach has the following problems: First, test data and production data are mixed together, which may lead to accidental data deletion during test data cleanup, making it impossible to guarantee data isolation. Second, performing delete operations every time test data is cleaned up increases database node fragmentation. Summary of the Invention

[0005] This application provides a tag diffusion service isolation testing method, apparatus, equipment, and medium to solve the problems of lack of uniformity in gray-scale testing and load testing schemes, inability of gray-scale testing to connect all requests of the same user to the gray-scale server for verification, and increased database node fragmentation rate caused by performing delete operations on load testing data.

[0006] This application provides a method for testing the isolation of a tag diffusion service, the method comprising:

[0007] Receive a data processing request, and determine the request type of the data processing request based on the data processing request and the pre-saved grayscale diffusion marker, wherein each element of the same user includes the grayscale diffusion marker;

[0008] If the data processing request is a grayscale request, the data processing request is forwarded to the grayscale server; in the grayscale server, grayscale testing is performed according to the data processing request, and the grayscale test data is written into the official table.

[0009] If the data processing request is a load testing request, the data processing request is forwarded to the load testing server; in the load testing server, load testing is performed according to the data processing request, and the obtained load testing data is written to the shadow table; when load testing data cleanup is triggered, the shadow table is cleaned up.

[0010] If the data processing request is a normal request, the data processing request is forwarded to a normal server; the normal server processes the business normally and writes the obtained normal business data into the formal table.

[0011] On the other hand, this application provides a marker diffusion service isolation testing apparatus, the apparatus comprising:

[0012] A determination module is used to receive a data processing request and determine the request type of the data processing request based on the data processing request and a pre-saved grayscale diffusion mark, wherein each element of the same user includes the grayscale diffusion mark;

[0013] The testing module is configured to: forward the data processing request to a gray-scale server if the request type is a gray-scale request; perform gray-scale testing on the gray-scale server based on the data processing request and write the gray-scale test data into a formal table; forward the data processing request to a load testing server if the request type is a load testing request; perform load testing on the load testing server based on the data processing request and write the obtained load testing data into a shadow table; clean up the shadow table when load testing data cleanup is triggered; and forward the data processing request to a normal server if the request type is a normal request; process the business normally on the normal server and write the obtained normal business data into a formal table.

[0014] In another aspect, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0015] Memory, used to store computer programs;

[0016] When a processor executes a program stored in memory, it implements the steps of the method described in any of the preceding statements.

[0017] In another aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in any of the above claims.

[0018] This application provides a method, apparatus, device, and medium for testing the isolation of a tag diffusion service. The method includes: receiving a data processing request; determining the request type of the data processing request based on the data processing request and pre-stored grayscale diffusion tags, wherein each element of the same user includes the grayscale diffusion tag; if the request type of the data processing request is a grayscale request, forwarding the data processing request to a grayscale server; in the grayscale server, performing grayscale testing according to the data processing request and writing the grayscale test data into a formal table; if the request type of the data processing request is a load testing request, forwarding the data processing request to a load testing server; in the load testing server, performing load testing according to the data processing request and writing the obtained load testing data into a shadow table; when load testing data cleanup is triggered, cleaning the shadow table; if the request type of the data processing request is a normal request, forwarding the data processing request to a normal server; processing the business normally in the normal server and writing the obtained normal business data into a formal table.

[0019] The above technical solution has the following advantages or beneficial effects:

[0020] This application pre-stores grayscale diffusion markers, where each element of the same user includes a grayscale diffusion marker. The request type is determined based on the data processing request and the grayscale diffusion marker, and then forwarded to the server corresponding to that request type for processing, thus unifying the grayscale testing and load testing schemes. Determining the request type based on the grayscale diffusion marker ensures that all grayscale requests from the same user are verified on the grayscale server. Load testing data and normal business data are stored separately; load testing data is written to a shadow table, and normal business data is written to a formal table. When load testing data cleanup is triggered, the entire shadow table is cleaned, avoiding the problem of increased database node fragmentation caused by delete operations on load testing data. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A schematic diagram of the isolation test process for the marker diffusion service provided in this application;

[0023] Figure 2 This application provides a diagram of the isolated test architecture for the marker diffusion service.

[0024] Figure 3 The service isolation and server switching flowchart provided for this application;

[0025] Figure 4 The grayscale and pressure-test marker diffusion flowchart provided for this application;

[0026] Figure 5 A schematic diagram of the structure of the label diffusion service isolation test device provided in this application;

[0027] Figure 6 A schematic diagram of the electronic device structure provided in this application. Detailed Implementation

[0028] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0029] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0030] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0031] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0032] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0033] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0034] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

[0035] Figure 1 This is a schematic diagram of the label diffusion service isolation test process provided in this application. The process includes the following steps:

[0036] S101: Receive a data processing request, and determine the request type of the data processing request based on the data processing request and the pre-saved grayscale diffusion marker, wherein each element of the same user includes the grayscale diffusion marker.

[0037] If the data processing request type is a grayscale request, proceed to S102; if the data processing request type is a load test request, proceed to S103; if the data processing request type is a normal request, proceed to S104.

[0038] S102: If the data processing request is a grayscale request, the data processing request is forwarded to the grayscale server; in the grayscale server, grayscale testing is performed according to the data processing request, and the grayscale test data is written into the official table.

[0039] S103: If the data processing request is a load testing request, forward the data processing request to the load testing server; in the load testing server, perform load testing according to the data processing request and write the obtained load testing data into the shadow table; when load testing data cleanup is triggered, clean up the shadow table.

[0040] S104: If the data processing request is a normal request, forward the data processing request to the normal server; process the business normally on the normal server and write the obtained normal business data into the formal table.

[0041] The label diffusion service isolation test method provided in this application is applied to electronic devices, such as computers and servers.

[0042] Electronic devices pre-store grayscale diffusion markers. These markers are obtained by applying grayscale tags to various user elements of the same user. These user elements include, for example, the user's mobile phone number, ID number, and user ID.

[0043] The electronic device receives a data processing request and determines the request type based on the data processing request and a pre-saved grayscale diffusion marker. Specifically, the data processing request is matched against fixed fields in the load testing strategy. If a match is successful, the request type is determined to be a load testing request. If no match is found, the data processing request is matched against both the grayscale test list and the grayscale diffusion marker. If a match is successful, the request type is determined to be a grayscale request. If no match is found, the request type is determined to be a normal request.

[0044] The system determines whether a data processing request is a load testing request based on a fixed field in the load testing strategy. If this field is present, it means the data processing request matches the fixed field in the load testing strategy, confirming that the data processing request is a load testing request; otherwise, it is not.

[0045] If it's determined that the data processing request is not a load testing request, then the data processing request is matched against the gray-scale test list and the gray-scale diffusion marker. If a match is successful, the request type is determined to be a gray-scale request. Specifically, the data processing request is first matched against the gray-scale test list, which includes either a gray-scale list or a hash ratio list. The gray-scale list refers to user elements such as phone numbers, ID numbers, and card numbers (which can be added or removed). For example, if gray-scale testing is being conducted on a user with the phone number 131xxxx1234, that user needs to be added to the gray-scale list. When a data processing request contains that phone number, it is a gray-scale request. The hash ratio can be understood as modulo a certain field. When a fixed value in the modulo remainder is found, the request is a gray-scale request. For example, if the modulo value is 10000, and the remainder is 0, the request can be considered a gray-scale request. If the grayscale test list matches successfully, the data processing request is determined to be a grayscale request, and the request is forwarded to the grayscale server. If the grayscale test list does not match successfully, the data processing request is then matched against the grayscale diffusion marker. If a match is found, meaning the element in the data processing request exists in the pre-saved grayscale diffusion marker, the request type is determined to be a grayscale request, and the request is forwarded to the grayscale server. Grayscale diffusion markers are, for example, uc_gray_spread:130xxxx9090 (phone number) and uc_gray_spread:340xxxxxxxx4460 (ID number). uc_gray_spread represents the grayscale marker.

[0046] Data processing requests other than those mentioned above are considered normal requests.

[0047] If the data processing request is a canary release request, it is forwarded to the canary release server. On the canary release server, canary testing is performed based on the data processing request, and the canary test data is written to the official table. If the data processing request is a load testing request, it is forwarded to the load testing server. On the load testing server, load testing is performed based on the data processing request, and the obtained load testing data is written to a shadow table. When load testing data cleanup is triggered, the shadow table is cleaned. Generally, load testing data cleanup is triggered manually. If the data processing request is a normal request, it is forwarded to the normal server. The normal server processes the business normally, and the obtained normal business data is written to the official table.

[0048] This application pre-stores grayscale diffusion markers, where each element of the same user includes a grayscale diffusion marker. The request type is determined based on the data processing request and the grayscale diffusion marker, and then forwarded to the server corresponding to that request type for processing, thus unifying the grayscale testing and load testing schemes. Determining the request type based on the grayscale diffusion marker ensures that all grayscale requests from the same user are verified on the grayscale server. Load testing data and normal business data are stored separately; load testing data is written to a shadow table, and normal business data is written to a formal table. When load testing data cleanup is triggered, the entire shadow table is cleaned, avoiding the problem of increased database node fragmentation caused by delete operations on load testing data.

[0049] For systems sensitive to business continuity and consistency, sending all requests from the same user to a canary server allows for effective observation and monitoring of system operations. Distributing a user's requests across different servers hinders canary testing. Therefore, this application uses write requests to propagate canary markers, linking all actions of the same user and sending all user requests to the canary server for canary verification. For systems with high requirements for the correlation of user behavior, this design ensures the integrity and consistency of canary testing.

[0050] In this application, the process of pre-saving grayscale diffusion markers includes:

[0051] The system receives a first registration request and determines whether the first registration request is a grayscale request. If it is, the system forwards the first registration request to the grayscale server. In the grayscale server, the grayscale write request performs grayscale diffusion marking and saves the various elements of the user in the grayscale marking diffusion list.

[0052] After receiving the first registration request, the electronic device determines whether it is a grayscale request based on either a grayscale list or a hash ratio. If so, the first registration request is forwarded to the grayscale server. On the grayscale server, the grayscale write request is marked with grayscale diffusion tags based on the various elements of the user in the grayscale tag diffusion list and saved. For example, in mobile phone number registration, if the mobile phone number matches the grayscale hash rule, it is forwarded to the grayscale server (biz). After normal business logic processing, the returned user information, such as mobile phone number, ID number, and user ID, needs to be marked with grayscale tags, such as uc_gray_spread:130xxxx9090 and uc_gray_spread:340xxxxxxxx4460. This allows subsequent queries for users using mobile phone number, ID number, etc., to also match the grayscale rule, thus enabling grayscale testing and linking all actions of the same user.

[0053] In this application, the method further includes:

[0054] If the load test request is a load test read request, determine whether the pre-saved load test diffusion flag has expired. If it has not expired, route the load test read request to any server; if it has expired, route the load test read request to the load test server, read the load test data from the shadow table and write it back to the cache, and rewrite the load test diffusion flag to the cache where the load test diffusion flag is pre-saved.

[0055] For example, when a user registers based on their mobile phone number, the load testing server will tag the user's mobile phone number, ID number, userid, and other user elements with load testing flags, such as uc_press_spread:180xxxx3520 and uc_press_spread:130xxxxxxxx3346. Subsequent queries for users using their mobile phone number or ID number will first check if the load testing spread flags in the cache are invalid. If they are valid, the request is forwarded to all servers; otherwise, it is forwarded to the load testing server to retrieve the user information from the shadow table and write it back to the cache. The load testing flags will also be written back, and subsequent read requests will still be routed to all servers for load testing.

[0056] The process of pre-saving pressure test diffusion markers includes:

[0057] The system receives a second registration request and determines whether it is a load testing request. If so, it forwards the second registration request to the load testing server. In the load testing server, the load testing write request performs load testing diffusion marking and saves the various elements of the user in the load testing mark diffusion list.

[0058] After receiving the second registration request, the electronic device determines whether it is a load testing request based on a fixed field. If this field is present, it is a load testing request; otherwise, it is not. If it is, the second registration request is forwarded to the load testing server. On the load testing server, the load testing write request is marked with load testing propagation tags based on various elements of the user in the load testing tag propagation list and saved.

[0059] The purpose of the load testing diffusion flag is to guide the load testing read request to retrieve user information from the shadow table and write the data back to the cache when the flag expires. This allows the user information to be retrieved from the cache, enabling continuous load testing. Without the load testing diffusion flag, when user data in the cache expires, information cannot be retrieved from the shadow table and added to the cache.

[0060] In this application, the method further includes:

[0061] The load test data and the normal business data are written to the same cache.

[0062] At this point, the load test data and normal business data share the same cache. The load test data effectively simulates the normal business data environment, improving the load test performance (tps, messages processed per second).

[0063] In this application, forwarding the data processing request to the grayscale server includes:

[0064] Turn on the grayscale isolation switch to prevent the grayscale server from receiving any requests; turn on the grayscale verification switch and turn off the grayscale isolation switch to prevent the grayscale server from receiving only grayscale requests and forwarding the data processing requests to the grayscale server.

[0065] This application implements service isolation and routing, and enables the conversion of gray-scale servers into normal servers and stress test servers into normal servers.

[0066] Two switches are configured for canary release requests: a canary release isolation switch and a canary release verification switch. If the canary release isolation switch is on, all requests will not be routed to the canary release server, and the canary release server will not accept any requests. If the canary release isolation switch is off and the canary release verification switch is on, then canary release requests will be accepted. If the canary release verification switch is off, then all requests will be accepted, including normal requests and load testing read requests. This logic enables the canary release server to be converted into a normal server.

[0067] The step of forwarding the data processing request to the load testing server includes:

[0068] Turn on the load test isolation switch to prevent the load test server from receiving any requests; turn on the load test switching switch and turn off the load test isolation switch to prevent the load test server from receiving load test requests and forwarding the data processing requests to the load test server.

[0069] Compared to canary release requests, load testing requests also have two switches: a load testing isolation switch and a load testing switching switch. When the load testing isolation switch is on, load testing requests are directly rejected, and other requests are not routed to the load testing server. If the load testing isolation switch is off and the load testing switching switch is on, the load testing server only accepts load testing requests; if the load testing switching switch is off, normal requests can be accepted.

[0070] The step of writing the stress test data into the shadow table includes:

[0071] Turn on the load test isolation switch to prevent the load test server from receiving any requests; turn on the load test switching switch and turn off the load test isolation switch to switch the database from a formal table to a shadow table and write the load test data into the shadow table.

[0072] Here, load testing differs from canary deployment scenarios. The load testing switch, in addition to its function of server routing, also controls the dynamic switching of database tables, enabling the switching between shadow tables and official tables. Before switching, a load testing isolation switch is needed to prevent the load testing server from accepting requests. Furthermore, the routing of load testing requests differs from canary deployment requests. Write requests in load testing are always routed to the load testing server, but the routing of read requests depends on whether the load testing flag has expired. If it has expired, the request is routed to the load testing server; otherwise, it can be routed to any server.

[0073] The write and read requests involved in this application are explained as follows:

[0074] Write requests: Operations that write to the database, such as registering, modifying the user's welcome message, and changing the password.

[0075] Read requests: Read requests that retrieve users by user ID or by mobile phone number, without involving writing to the database.

[0076] The technical effects of the marker diffusion service isolation testing method provided in this application are as follows:

[0077] (1) Unified solution. By using a unified framework and methodology, the stress testing solution and grayscale solution are unified, eliminating the need for separate design and making them easy to maintain and manage.

[0078] (2) Reduce costs and increase efficiency. By controlling the routing, the system ensures safe and reliable deployment, while also enabling the server to function as a gray-scale server, a stress test server, and a normal server, thus saving virtual machine resources.

[0079] (3) Business linkage. By spreading the grayscale marker through write requests, it is possible to link all the behaviors of the same user and send all user requests to the grayscale server for grayscale verification. For systems with high requirements for the correlation of user behaviors, this design ensures the integrity and continuity of grayscale.

[0080] (4) Data Isolation. By isolating stress test data and normal data at the database layer, data cleanup operations are simplified, eliminating the need to worry about which records need to be deleted. This also ensures the safety of data cleanup, preventing accidental deletion. Furthermore, using the `truncate` operation on tables during data cleanup effectively avoids increasing database fragmentation.

[0081] (5) Persistent load testing. The load testing flag is spread through write requests. When the load testing flag is valid, read requests will be routed to all servers. However, when the load testing flag is invalid, read requests will be routed to the load testing server to write back user information and load testing flag to the cache. For systems that perform data hot and cold testing, this design ensures both data isolation and load testing performance.

[0082] This application utilizes marker diffusion in both canary deployment and load testing scenarios. In canary write requests, canary marker diffusion ensures that all subsequent requests from the same user are routed to the canary server, guaranteeing the continuity and integrity of canary verification. In load testing write requests, load testing marker diffusion enables load testing read requests to be routed to the load testing server to read data from the shadow table and write it back to the cache when data in the cache expires, ensuring persistent load testing and improving the performance of load testing read requests, effectively simulating production scenarios. The shadow table stores load testing data, so the data written back to the cache is also load testing data. This application incorporates service isolation and server switching. By differentiating between load testing requests, canary requests, and normal requests, and using preset switches and markers, requests are routed to the corresponding servers. Furthermore, both load testing servers and canary servers can be converted to normal servers, effectively reducing resource waste.

[0083] The isolation testing process for the marker diffusion service provided in this application will be described in detail below with reference to the accompanying drawings.

[0084] Figure 2 The tag diffusion service isolation test architecture diagram provided in this application can be divided into four layers: access layer, service layer, strategy layer and storage layer.

[0085] The access layer is responsible for accepting requests, determining whether they are canary requests, load testing requests, or normal requests, and forwarding the requests to the corresponding servers. The service layer handles business logic. In the canary server, canary write requests are propagated based on the canary tag propagation list, expanding the canary tag from one tag to multiple tags, and then writing the canary tag to the strategy layer. In the load testing server, load testing write requests are propagated based on the load testing propagation list, and then written to the strategy layer. Furthermore, the table written to by load testing write requests is a shadow table, not a formal table, but the load testing data and the formal data use the same cache. The strategy layer mainly records the user's canary tag and load testing tag, primarily used for judging and forwarding canary and load testing requests. The storage layer is mainly divided into a cache and a database, with the database including shadow tables and formal tables.

[0086] The grayscale distribution list is configured within the application (and can be added or removed as needed), including user elements such as phone numbers, ID numbers, and card numbers. When a user request returns these fields, that user element needs to be distributed. The load testing distribution list is also configured within the application (and can be added or removed as needed), including user elements such as phone numbers, ID numbers, and card numbers. When a user request returns these fields, that user element needs to be distributed.

[0087] Figure 3 The service isolation and server switching flowchart provided for this application is as follows: Figure 3 As shown, implementing service isolation and routing at the access layer, and converting gray-scale servers into normal servers and stress test servers into normal servers, requires joint control from the access layer and the service layer.

[0088] Two switches are configured for canary release requests: a canary release isolation switch and a canary release verification switch. If the canary release isolation switch is on, all requests will not be routed to the canary release server, and the canary release server will not accept any requests. If the canary release isolation switch is off and the canary release verification switch is on, then canary release requests will be accepted; if the canary release verification switch is off, then all requests will be accepted. This logic enables the canary release server to transition into a normal server.

[0089] Compared to canary deployments, load testing requests also have two switches: a load testing isolation switch and a load testing switching switch. When the load testing isolation switch is on, load testing requests are directly rejected, and other requests are not routed to the load testing server. If the load testing isolation switch is off and the load testing switching switch is on, the load testing server only accepts load testing requests; if the load testing switching switch is off, normal requests can be accepted. Here, unlike canary deployments, the load testing switching switch, in addition to acting on the access layer, also needs to control the dynamic switching of database tables at the service layer, completing the mutual switching between shadow tables and official tables. Before switching, the load testing isolation switch needs to be used to prevent the load testing server from accepting requests. Furthermore, the routing and forwarding of load testing requests differs from canary deployments. Load testing write requests are always routed to the load testing server, but the routing of read requests depends on whether the load testing flag has expired. If it has expired, it is routed to the load testing server; otherwise, it can be routed to all servers.

[0090] Figure 4 The grayscale and pressure-test marker diffusion flowchart provided for this application is as follows: Figure 4 As shown, in addition to handling normal business logic, the grayscale server also needs to mark user elements (user ID, mobile phone number, ID number, etc.) of grayscale users in grayscale write requests. This is called grayscale mark diffusion. Subsequent requests containing these user elements will be forwarded to the grayscale server as grayscale requests, thus linking all user actions. For example, in mobile phone number registration, if the mobile phone number matches the grayscale hash rule, it will be forwarded to the grayscale Biz. After normal business logic processing, the user elements such as mobile phone number, ID number, and user UID in the returned user information need to be marked with grayscale tags (strategy layer tags, such as uc_gray_spread:130xxxx9090, uc_gray_spread:340xxxxxxxx4460). Later, when querying users by mobile phone number, ID number, etc., the grayscale rule can also be matched, thus performing grayscale verification and linking all actions of the same user.

[0091] The load testing server writes load testing data to a business shadow table, isolated from production data, but sharing a common cache (data has expiration times, i.e., data is considered "hot" or "cold"; expired data in the cache needs to be written back from the database to the cache). In addition, the load testing server tags user elements (user ID, phone number, ID number, etc.) for load testing users; this is called load testing tag propagation. Subsequent load testing read requests containing these user elements will check if the load testing propagation tag has expired. If the tag has expired, the load testing read request will be routed to the load testing server, which will write the load testing user information back to the cache and rewrite the load testing propagation tag. Subsequent load testing read requests will then be rerouted to other servers. For example, when registering a user based on their mobile phone number, the load testing server will mark the user's mobile phone number, ID number, userid, and other user elements with load testing tags (strategy-level tags, such as uc_press_spread:180xxxx3520, uc_press_spread:130xxxxxxxx3346). When querying a user subsequently by mobile phone number or ID number, the server will first check whether the load testing spread tag in the cache has expired. If it has not expired, the request will be forwarded to all servers; otherwise, it will be forwarded to the load testing server to read the user information from the shadow table and write it back to the cache. The load testing tag will also be written back, and subsequent read requests will still be routed to all servers.

[0092] Figure 5 A schematic diagram of the marker diffusion service isolation test device provided in this application includes:

[0093] The determining module 51 is used to receive a data processing request and determine the request type of the data processing request based on the data processing request and the pre-saved grayscale diffusion marker, wherein each element of the same user includes the grayscale diffusion marker.

[0094] The testing module 52 is configured to: forward the data processing request to a grayscale server if the request type is a grayscale request; perform grayscale testing on the grayscale server according to the data processing request and write the grayscale test data into a formal table; forward the data processing request to a load testing server if the request type is a load testing request; perform load testing on the load testing server according to the data processing request and write the obtained load testing data into a shadow table; clean up the shadow table when load testing data cleanup is triggered; forward the data processing request to a normal server if the request type is a normal request; process the business normally on the normal server and write the obtained normal business data into a formal table.

[0095] The determining module 51 is specifically used to match the data processing request with fixed fields in the load testing strategy. If the match is successful, the request type of the data processing request is determined to be a load testing request. If the match is unsuccessful, the data processing request is matched with the grayscale test list and the grayscale diffusion marker respectively. If the match is successful, the request type of the data processing request is determined to be a grayscale request. If the match is unsuccessful, the request type of the data processing request is determined to be a normal request.

[0096] The device further includes:

[0097] The first storage module 53 is used to receive the first registration request and determine whether the first registration request is a grayscale request. If it is, the first registration request is forwarded to the grayscale server. In the grayscale server, the grayscale write request is marked and saved according to the grayscale mark diffusion list.

[0098] The test module 52 is specifically used to control the grayscale isolation switch to open, so that the grayscale server does not receive any requests; control the grayscale verification switch to open, and control the grayscale isolation switch to close, so that the grayscale server only receives grayscale requests and forwards the data processing requests to the grayscale server.

[0099] The test module 52 is specifically used to control the load test isolation switch to open, so that the load test server does not receive any requests; control the load test switching switch to open, and control the load test isolation switch to close, so that the load test server only receives load test requests and forwards the data processing requests to the load test server.

[0100] The test module 52 is specifically used to control the load test isolation switch to open, so that the load test server does not receive any requests; control the load test switching switch to open, and control the load test isolation switch to close, switch the database from the formal table to the shadow table, and write the load test data into the shadow table.

[0101] The test module 52 is also used to write the stress test data and the normal business data into the same cache.

[0102] The test module 52 is further configured to, if the load test request is a load test read request, determine whether the pre-saved load test diffusion flag has expired; if it has not expired, route the load test read request to any server; if it has expired, route the load test read request to the load test server, read the load test data from the shadow table and write it back to the cache, and rewrite the load test diffusion flag to the cache where the load test diffusion flag is pre-saved.

[0103] The device further includes:

[0104] The second storage module 54 is used to receive the second registration request and determine whether the second registration request is a load test request. If it is, the second registration request is forwarded to the load test server. In the load test server, the load test write request is marked with load test diffusion according to each element of the user in the load test mark diffusion list and then saved.

[0105] This application also provides an electronic device, such as Figure 6 As shown, it includes: processor 301, communication interface 302, memory 303 and communication bus 304, wherein processor 301, communication interface 302 and memory 303 communicate with each other through communication bus 304;

[0106] The memory 303 stores a computer program, which, when executed by the processor 301, causes the processor 301 to perform any of the above method steps.

[0107] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0108] Communication interface 302 is used for communication between the above-mentioned electronic device and other devices.

[0109] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0110] The processors mentioned above can be general-purpose processors, including central processing units, network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits, field-programmable gate arrays or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0111] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform any of the above method steps.

[0112] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0113] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for testing the isolation of labeled diffusion services, characterized in that, The method includes: Receive a data processing request, and determine the request type of the data processing request based on the data processing request and the pre-saved grayscale diffusion marker, wherein each element of the same user includes the grayscale diffusion marker; If the data processing request is a grayscale request, the data processing request is forwarded to the grayscale server; in the grayscale server, grayscale testing is performed according to the data processing request, and the grayscale test data is written into the official table. If the data processing request is a load testing request, the data processing request is forwarded to the load testing server; in the load testing server, load testing is performed according to the data processing request, and the obtained load testing data is written to the shadow table; when load testing data cleanup is triggered, the shadow table is cleaned up. If the data processing request is a normal request, the data processing request is forwarded to a normal server; the business is processed normally on the normal server, and the obtained normal business data is written into the formal table. The method further includes: If the load test request is a load test read request, determine whether the pre-saved load test diffusion flag has expired. If it has not expired, route the load test read request to any server; if it has expired, route the load test read request to the load test server, read the load test data from the shadow table and write it back to the cache, and rewrite the load test diffusion flag to the cache where the load test diffusion flag is pre-saved. The tag diffusion service isolation test architecture includes an access layer, a service layer, a policy layer, and a storage layer. The access layer is used to accept requests, determine whether they are gray-scale requests, load testing requests, or normal requests, and forward the requests to the corresponding servers; The service layer is used to handle business logic. In the canary server, canary write requests are spread according to the canary tag diffusion list. In this layer, the canary tags are diffused from one canary tag to multiple canary tags, and the canary tags are written to the strategy layer. In the load testing server, load testing write requests are spread according to the load testing diffusion list. In this layer, the load testing tags are diffused and written to the strategy layer. The strategy layer is used to record the user's grayscale markers and load test markers, and to make judgments and forward the grayscale and load test results. The storage layer is divided into cache and database, with the database including shadow tables and formal tables.

2. The method as described in claim 1, characterized in that, The step of determining the request type of the data processing request based on the data processing request and the pre-saved grayscale diffusion markers includes: The data processing request is matched with a fixed field in the load testing strategy. If the match is successful, the request type of the data processing request is determined to be a load testing request. If the match is unsuccessful, the data processing request is matched with the grayscale test list and the grayscale diffusion flag respectively. If the match is successful, the request type of the data processing request is determined to be a grayscale request. If the match is unsuccessful, the request type of the data processing request is determined to be a normal request.

3. The method as described in claim 1, characterized in that, The process of pre-saving grayscale diffusion markers includes: The system receives a first registration request and determines whether the first registration request is a grayscale request. If it is, the system forwards the first registration request to the grayscale server. In the grayscale server, the grayscale write request performs grayscale diffusion marking and saves the various elements of the user in the grayscale marking diffusion list.

4. The method as described in claim 1, characterized in that, The step of forwarding the data processing request to the grayscale server includes: Turn on the grayscale isolation switch to prevent the grayscale server from receiving any requests; turn on the grayscale verification switch and turn off the grayscale isolation switch to prevent the grayscale server from receiving only grayscale requests and forwarding the data processing requests to the grayscale server.

5. The method as described in claim 1, characterized in that, The step of forwarding the data processing request to the load testing server includes: Turn on the load test isolation switch to prevent the load test server from receiving any requests; turn on the load test switching switch and turn off the load test isolation switch to prevent the load test server from receiving load test requests and forwarding the data processing requests to the load test server.

6. The method as described in claim 1, characterized in that, The step of writing the stress test data into the shadow table includes: Turn on the load test isolation switch to prevent the load test server from receiving any requests; turn on the load test switching switch and turn off the load test isolation switch to switch the database from a formal table to a shadow table and write the load test data into the shadow table.

7. The method as described in claim 1, characterized in that, The method further includes: The load test data and the normal business data are written to the same cache.

8. The method as described in claim 1, characterized in that, The process of pre-saving pressure test diffusion markers includes: The system receives a second registration request and determines whether it is a load testing request. If so, it forwards the second registration request to the load testing server. In the load testing server, the load testing write request performs load testing diffusion marking and saves the various elements of the user in the load testing mark diffusion list.

9. A marker diffusion service isolation test apparatus, characterized in that, The device includes: A determination module is used to receive a data processing request and determine the request type of the data processing request based on the data processing request and a pre-saved grayscale diffusion mark, wherein each element of the same user includes the grayscale diffusion mark; The testing module is configured to: forward the data processing request to a gray-scale server if the request type is a gray-scale request; perform gray-scale testing on the gray-scale server based on the data processing request and write the gray-scale test data into a formal table; forward the data processing request to a load testing server if the request type is a load testing request; perform load testing on the load testing server based on the data processing request and write the obtained load testing data into a shadow table; clean up the shadow table when load testing data cleanup is triggered; and forward the data processing request to a normal server if the request type is a normal request; process the business normally on the normal server and write the obtained normal business data into a formal table. The testing module is further configured to determine whether the pre-saved load testing diffusion flag has expired if the load testing request is a load testing read request. If it has not expired, the load testing read request is routed to any server. If it has expired, the load testing read request is routed to the load testing server, the load testing data is read from the shadow table and written back to the cache, and the load testing diffusion flag is rewritten back to the cache where the load testing diffusion flag is pre-saved. The tag diffusion service isolation test architecture includes an access layer, a service layer, a policy layer, and a storage layer. The access layer is used to accept requests, determine whether they are gray-scale requests, load testing requests, or normal requests, and forward the requests to the corresponding servers; The service layer is used to handle business logic. In the canary server, canary write requests are spread according to the canary tag diffusion list. In this layer, the canary tags are diffused from one canary tag to multiple canary tags, and the canary tags are written to the strategy layer. In the load testing server, load testing write requests are spread according to the load testing diffusion list. In this layer, the load testing tags are diffused and written to the strategy layer. The strategy layer is used to record the user's grayscale markers and load test markers, and to make judgments and forward the grayscale and load test results. The storage layer is divided into cache and database, with the database including shadow tables and formal tables.

10. The apparatus as claimed in claim 9, characterized in that, The determining module is specifically used to match the data processing request with fixed fields in the load testing strategy. If the match is successful, the request type of the data processing request is determined to be a load testing request. If the match is unsuccessful, the data processing request is matched with the grayscale test list and the grayscale diffusion marker respectively. If the match is successful, the request type of the data processing request is determined to be a grayscale request. If the match fails, the request type of the data processing request is determined to be a normal request.

11. The apparatus as claimed in claim 9, characterized in that, The device further includes: The first storage module is used to receive the first registration request and determine whether the first registration request is a grayscale request. If it is, the first registration request is forwarded to the grayscale server. In the grayscale server, the grayscale write request is grayscale diffused and stored according to the various elements of the user in the grayscale mark diffusion list.

12. The apparatus as claimed in claim 9, characterized in that, The testing module is specifically used to control the grayscale isolation switch to open, so that the grayscale server does not receive any requests; control the grayscale verification switch to open, and control the grayscale isolation switch to close, so that the grayscale server only receives grayscale requests and forwards the data processing requests to the grayscale server.

13. The apparatus as claimed in claim 9, characterized in that, The test module is specifically used to control the load test isolation switch to open, so that the load test server does not receive any requests; control the load test switching switch to open, and control the load test isolation switch to close, so that the load test server only receives load test requests and forwards the data processing requests to the load test server.

14. The apparatus as claimed in claim 9, characterized in that, The test module is specifically used to control the load test isolation switch to open, so that the load test server does not receive any requests; control the load test switching switch to open, and control the load test isolation switch to close, switching the database from a formal table to a shadow table, and writing the load test data into the shadow table.

15. The apparatus as claimed in claim 9, characterized in that, The testing module is also used to write the load test data and the normal business data into the same cache.

16. The apparatus as claimed in claim 9, characterized in that, The device further includes: The second storage module is used to receive the second registration request and determine whether the second registration request is a load test request. If it is, the second registration request is forwarded to the load test server. In the load test server, the load test write request is marked with load test diffusion tags according to the various elements of the user in the load test tag diffusion list and then stored.

17. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-8.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-8.

Images