Gray-scale flow verification method, device, equipment, storage medium and program product

Abstract

The application discloses a gray-scale traffic verification method and device, equipment, a storage medium and a program product, and relates to the technical field of communication. The method comprises the following steps: receiving to-be-published traffic sent by an upstream service; publishing the to-be-published traffic to a downstream service based on a pre-registered gray-scale message queue instance and a preset instance calling relationship, and receiving gray-scale traffic publishing results sent by the downstream service; and performing gray-scale traffic verification according to the gray-scale traffic publishing results to obtain gray-scale traffic verification results. The gray-scale registration module based on registration discovery is used to give gray-scale, formal and even isolation general capabilities to instances with different calling relationships, the problem that an existing gray-scale scheme cannot divide formal instances and gray-scale instances from the perspective of basic instances is solved, high-level abstraction of gray-scale instances and formal instances is achieved, and dynamic change or even isolation of instance labels can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a gray traffic verification method and device, equipment, storage medium and program product. BACKGROUND

[0002] Nowadays, an advanced gray scheme considers the whole-link gray function of the whole business scene, and based on the conventional micro-service calling, the whole-link flow of gray traffic can be realized.

[0003] In other methods, the whole-link gray function of the message queue is involved, and in this method, a gray environment and a formal environment are provided, and independent instances are deployed in the corresponding environment to generate a first message through a message producer of a first application instance, the first message includes a gray attribute field, the gray attribute field is included in a field indicating a message custom attribute, and the value of the gray attribute field is used to indicate that the first message belongs to a gray message, and the first application instance is an application instance running in the gray environment in the target calling link.

[0004] The above methods concretize the message queue calling or the micro-service calling, and cannot divide the formal instance and the gray instance from the fundamental instance, so that the dynamic change or even isolation of the instance label cannot be achieved.

[0005] The above content is only used to assist in understanding the technical solutions of the present application, and does not represent the acknowledgement of the above content as prior art. SUMMARY

[0006] The main purpose of the present application is to provide a gray traffic verification method, device, equipment, storage medium and program product, which aims to solve the technical problem that the existing gray scheme cannot divide the formal instance and the gray instance from the fundamental instance.

[0007] To achieve the above purpose, the present application provides a gray traffic verification method, which comprises:

[0008] Receiving the to-be-published traffic sent by an upstream service;

[0009] Based on the pre-registered gray message queue instance and the preset instance calling relationship, the to-be-published traffic is published to a downstream service, and the gray traffic publishing result sent by the downstream service is received, the gray message queue instance is generated by registering the preset fundamental message queue instance by the preset gray registration module;

[0010] According to the gray traffic publishing result, the gray traffic verification is carried out to obtain the gray traffic verification result.

[0011] In an embodiment, the instance invocation relationship is a hypertext transfer protocol-based invocation relationship, the gray message queue instance is a first gray message queue instance, the downstream service includes a downstream consumer, the gray traffic publishing result is a first gray traffic publishing result, and the step of publishing the to-be-published traffic to the downstream service based on the pre-registered gray message queue instance and the preset instance invocation relationship and receiving a gray traffic publishing result sent by the downstream service includes:

[0012] Based on the hypertext transfer protocol-based invocation relationship, the instance flag data pre-generated from the preset registration center is obtained according to the first gray message queue instance;

[0013] According to the instance flag data, the downstream consumer instance consistent with the gray state of the first gray message queue instance is determined as a first consumer instance;

[0014] According to the instance flag data, a full-link gray routing request is generated;

[0015] The to-be-published traffic is published to the first consumer instance through the first gray message queue instance, the first gray traffic publishing result sent by the first consumer instance is received, and the full-link gray routing request is sent to the first consumer instance, so that the downstream service performs corresponding full-link gray routing.

[0016] In an embodiment, before the step of publishing the to-be-published traffic to the downstream service based on the pre-registered gray message queue instance and the preset instance invocation relationship and receiving a gray traffic publishing result sent by the downstream service, the method further includes:

[0017] When the instance invocation relationship is a hypertext transfer protocol-based invocation relationship, a gray message queue instance registration request is received;

[0018] According to the gray message queue instance registration request, the root message queue instance is set as the first gray message queue instance through a preset gray registration module;

[0019] According to the first gray message queue instance, the instance flag data is generated and sent to the registration center.

[0020] In an embodiment, the instance invocation relationship is an asynchronous invocation relationship, the instance of the gray message queue is a second instance of the gray message queue, the downstream service comprises a first gray environment consumer obtained in advance, the gray traffic publishing result is a second gray traffic publishing result, and the step of publishing the traffic to be published to the downstream service based on the pre-registered instance of the gray message queue and the preset instance invocation relationship and receiving the gray traffic publishing result sent by the downstream service comprises:

[0021] Based on the asynchronous invocation relationship, the traffic to be published is sent to the first gray environment consumer through the second instance of the gray message queue, and the second gray traffic publishing result sent by the first gray environment consumer is received.

[0022] In an embodiment, before the step of sending the traffic to be published to the first gray environment consumer through the second instance of the gray message queue based on the asynchronous invocation relationship and receiving the second gray traffic publishing result sent by the first gray environment consumer, the method further comprises:

[0023] When the instance invocation relationship is an asynchronous invocation relationship, a consumer capability change request is received.

[0024] According to the consumer capability change request, the capability of the first formal environment consumer in the downstream service is changed through a preset registration center, and the first gray environment consumer is obtained.

[0025] In an embodiment, the downstream service comprises a second gray environment consumer, and after the step of performing gray traffic verification based on the gray traffic publishing result and obtaining a gray traffic verification result, the method further comprises:

[0026] When the gray traffic verification result indicates that the gray traffic verification is successful, a consumer state change request is received.

[0027] According to the consumer state change request, the state of the second gray environment consumer is changed through a preset registration center, and a second formal environment consumer is obtained, so that the second formal environment consumer consumes formal traffic.

[0028] In addition, to achieve the above object, the application further provides a gray traffic verification device, which comprises:

[0029] A traffic receiving module is configured to receive traffic to be published sent by an upstream service.

[0030] The traffic publishing module is configured to publish the to-be-published traffic to a downstream service based on a pre-registered gray-scale message queue instance and a preset instance calling relationship, and receive a gray-scale traffic publishing result sent by the downstream service, wherein the gray-scale message queue instance is generated by registering a preset root message queue instance by the preset gray-scale registration module;

[0031] The traffic verification module is configured to perform gray-scale traffic verification according to the gray-scale traffic publishing result, and obtain a gray-scale traffic verification result.

[0032] In addition, to achieve the above-mentioned purpose, the present application also provides a gray-scale traffic verification device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the gray-scale traffic verification method as described above.

[0033] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, which is a computer-readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the gray-scale traffic verification method as described above.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the gray-scale traffic verification method as described above.

[0035] The present application provides a gray-scale traffic verification method, which gives gray-scale, formal, and even isolated general capabilities to instances with different calling relationships based on a gray-scale registration module discovered by registration, solves the technical problem that existing gray-scale solutions cannot divide formal instances and gray-scale instances from the perspective of root instances, and achieves high-level abstraction of gray-scale instances and formal instances, and can realize dynamic change or even isolation of instance labels. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0038] Figure 1 A flowchart is provided for the gray-scale traffic verification method embodiment one of the present application;

[0039] Figure 2 A brief flowchart of the conversion of a consumer from a gray state to a formal state is provided for Embodiment One of the present application.

[0040] Figure 3 A flowchart is provided for Embodiment Two of the gray flow verification method of the present application.

[0041] Figure 4 A general gray capability module diagram is provided for Embodiment Two of the present application.

[0042] Figure 5 A message queue calling relationship diagram is provided for Embodiment Two of the present application.

[0043] Figure 6 A module structure diagram of the gray flow verification device of the present application is provided for Embodiment Two of the present application.

[0044] Figure 7 A device structure diagram of the hardware operating environment involved in the gray flow verification method of Embodiment Two of the present application is provided.

[0045] The object implementation, functional features and advantages of the present application will be further described with reference to the accompanying drawings in conjunction with the embodiments. DETAILED DESCRIPTION

[0046] It should be understood that the specific embodiments described herein are merely intended to explain the technical solutions of the present application and are not intended to limit the present application.

[0047] In order to better understand the technical solutions of the present application, the following will be described in detail in conjunction with the accompanying drawings and specific embodiments.

[0048] The main solution of the embodiments of the present application is:

[0049] Receiving the to-be-published traffic sent by the upstream service;

[0050] Based on the pre-registered gray message queue instance and the preset instance calling relationship, the to-be-published traffic is published to the downstream service, and the gray flow publishing result sent by the downstream service is received, wherein the gray message queue instance is generated by the preset gray registration module registering the preset root message queue instance;

[0051] According to the gray flow publishing result, the gray flow verification is performed to obtain the gray flow verification result.

[0052] In the prior art, the advanced gray scheme nowadays considers the gray function of the whole business scene full link, and based on the conventional microservice calling, the gray flow full link circulation can be realized.

[0053] In other methods, a full-link gray function of a message queue is involved. In the method, a gray environment and an official environment are provided, and independent instances are deployed in the corresponding environments. A first message is generated by a message producer of a first application instance, the first message includes a gray attribute field, the gray attribute field is included in a field indicating a message custom attribute, and the value of the gray attribute field is used to indicate that the first message belongs to a gray message. The first application instance is an application instance running in the gray environment in a target call link.

[0054] The above methods have the following problems:

[0055] First, the message queue call or microservice call is concretized, and it is impossible to divide the official instance and the gray instance from the perspective of the root instance, so that the dynamic change or even isolation of the instance label cannot be achieved.

[0056] Second, the official environment and the gray environment are completely independent, and the official environment and the gray environment need to be deployed. During the change process, the configuration needs to be modified, the service needs to be restarted, and the like, which may affect the consumption capacity of the environment.

[0057] The present application provides a solution. By using a gray registration module based on registration discovery, a general capability of gray, official, and even isolation of instances with different call relationships is given, the technical problem that the existing gray scheme cannot divide the official instance and the gray instance from the perspective of the root instance is solved, and high-level abstraction of the gray instance and the official instance is achieved. The dynamic change or even isolation of the instance label can be achieved.

[0058] It should be noted that the execution subject of the present embodiment can be a computing service device with data processing, network communication, and program running functions, such as a tablet computer, a personal computer, a mobile phone, or the like, or an electronic device, a gray traffic verification system, or the like that can implement the above functions. In the following, the gray traffic verification system is taken as an example to describe the present embodiment and each of the following embodiments.

[0059] Based on this, the present embodiment provides a gray traffic verification method. Referring to Figure 1 , Figure 1 The flowchart of the first embodiment of the gray traffic verification method of the present application is shown in FIG. 1.

[0060] In the present embodiment, the gray traffic verification method includes steps S10-S30:

[0061] Step S10, receiving the to-be-published traffic sent by an upstream service;

[0062] It should be noted that the upstream service refers to a module or service responsible for generating or providing data in the system, and the to-be-published traffic refers to traffic data that has not been verified and is ready to be published.

[0063] Step S20, based on the pre-registered gray-scale message queue instance and the preset instance call relationship, the traffic to be published is published to the downstream service, and the gray-scale traffic publishing result sent by the downstream service is received, and the gray-scale message queue instance is generated by the preset gray-scale registration module to the preset basic message queue instance;

[0064] Step S30, according to the gray-scale traffic publishing result, the gray-scale traffic verification is carried out, and the gray-scale traffic verification result is obtained.

[0065] The gray-scale traffic verification system is based on the pre-registered gray-scale message queue instance and the preset instance call relationship, adopts polling, weight distribution and other strategies, and publishes the traffic to be published to the downstream service, and receives the gray-scale traffic publishing result sent by the downstream service. Then the system will verify the previous gray-scale traffic publishing result to evaluate the performance and stability of the new function or version, and obtain the gray-scale traffic verification result. Through verification, it can be ensured that the publication of traffic will not have negative impact on user experience.

[0066] It should be noted that the gray-scale message queue instance is generated by the preset gray-scale registration module to the preset basic message queue instance, and the gray-scale message queue instance is a specific version of the service instance, which is used to gradually introduce new functions or repair bugs. The instance call relationship is used to define the interaction and dependency relationship between different service instances.

[0067] In a possible implementation, the downstream service includes a second gray-scale environment consumer, and after step S30, steps S401-S402 can be further included:

[0068] Step S401, when the gray-scale traffic verification result is expressed as gray-scale traffic verification success, a consumer state change request is received;

[0069] Step S402, through the preset registration center, according to the consumer state change request, the state of the second gray-scale environment consumer is changed, and a second formal environment consumer is obtained, so that the second formal environment consumer consumes formal traffic.

[0070] When the gray-scale traffic verification result is expressed as gray-scale traffic verification success, the gray-scale traffic verification system receives a consumer state change request from a related component or team, indicating that the current consumer state needs to be switched from the gray-scale environment to the formal consumer state. Then through the preset registration center, according to the consumer state change request, the state of the second gray-scale environment consumer is changed, the state of the corresponding consumer is changed from "gray-scale environment" to "formal environment", and a second formal environment consumer is obtained, so that the second formal environment consumer consumes formal traffic.

[0071] It's important to note that a consumer status change request is a system-issued request that notifies relevant components to change a consumer's status from a phased environment to a live environment. The registry is a service discovery and management component responsible for maintaining service instance status information and supporting dynamic registration and deregistration of services. It plays a central role in consumer status changes.

[0072] For example, referring to Figure 2 , Figure 2 This is a schematic diagram of a simplified process for a consumer to transition from a grayscale status to a formal status, as provided in Example 1 of the present application.

[0073] Specifically, the conventional full-link grayscale solution requires a strict distinction between the official environment and the grayscale environment. At the same time, the change process requires setting the corresponding environment configuration and restarting the service. This process increases the risk of service unavailability.

[0074] This embodiment utilizes the general capabilities of the grayscale registration module and has the ability to smoothly convert grayscale environment instances directly into formal environment instances. In this way, after the grayscale verification is completed, it can be directly converted into the formal environment, reducing configuration modifications and changes in service instance status.

[0075] After the user completes the grayscale traffic verification, the status of the message queue consumer is modified through the registration center. If it is a message queue associated with a topic, the topic of the grayscale instance is updated and the consumer role is changed from grayscale to official. In this way, when the official traffic enters, the producer will write the request or message content to the consumer message queue, and then consume the official traffic through the consumer.

[0076] This implementation centrally manages consumer information through a registration center, ensuring that all services have timely access to the latest consumer status and capability configurations. This allows for real-time response to traffic changes and dynamic adjustment of consumer capabilities through a pre-set registration center, ensuring high system performance during peak periods and improving overall service reliability and flexibility. This provides a one-click transition from grayscale to production, converting verified grayscale instances into production instances. This allows for a smooth transition between grayscale and production, resolving the issue of a disconnect between production and grayscale environments, which can lead to significant operational costs.

[0077] This embodiment provides a grayscale traffic verification method. Through a grayscale registration module based on registration discovery, it gives instances with different calling relationships the general ability to grayscale, formalize, and even isolate. This solves the technical problem that existing grayscale solutions cannot divide formal instances and grayscale instances from the perspective of fundamental instances. It achieves a high-level abstraction of grayscale instances and formal instances, and can realize dynamic changes and even isolation of instance labels.

[0078] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 3 The instance call relationship is a call relationship based on the Hypertext Transfer Protocol, the grayscale message queue instance is a first grayscale message queue instance, the downstream service includes a downstream consumer, the grayscale traffic publishing result is a first grayscale traffic publishing result, and step S20 includes steps S2011 to S2014:

[0079] Step S2011: Based on the call relationship based on the Hypertext Transfer Protocol and according to the first grayscale message queue instance, obtaining pre-generated instance identification data from a preset registration center;

[0080] Step S2012: determining, based on the instance flag data, a downstream consumer instance that is consistent with the grayscale state of the first grayscale message queue instance as the first consumer instance;

[0081] Step S2013: Generate a full-link grayscale routing request based on the instance flag data;

[0082] Step S2014: Publish the traffic to be published to the first consumer instance through the first grayscale message queue instance, receive the first grayscale traffic publishing result sent by the first consumer instance, and send the full-link grayscale routing request to the first consumer instance, so that the downstream service can perform corresponding full-link grayscale routing.

[0083] The grayscale traffic verification system is based on a call relationship based on the Hypertext Transfer Protocol. According to the first grayscale message queue instance, it obtains pre-generated instance flag data from the preset registration center, and then parses the instance flag data obtained from the registration center to extract relevant grayscale status information. The grayscale status of the first grayscale message queue instance is compared with the status of all downstream consumer instances, and instances with consistent status are screened out to obtain the first consumer instance. Then, based on the instance flag data, a full-link grayscale routing request is generated, and then the traffic to be released is released to the first consumer instance through the first grayscale message queue instance, and the first grayscale traffic release result sent by the first consumer instance is received, which may include key indicators such as response time, error rate, and throughput, which are used to evaluate the effect and stability of the grayscale release, and the full-link grayscale routing request is sent to the first consumer instance to enable the downstream service to perform corresponding full-link grayscale routing to ensure that the downstream service can handle the traffic according to the set routing rules.

[0084] It should be noted that HTTP is an abbreviation of Hypertext Transfer Protocol, which is a protocol for transmitting data over a network, especially between a client (such as a browser) and a server. TTP defines the format of requests and responses, allowing users to access and interact with web resources. Instance flag data is an identifier related to the first gray message queue instance, containing the current state and other metadata. Downstream consumers refer to downstream service instances that receive and process upstream service traffic. Full-link gray routing requests contain complete routing information to ensure that traffic can be forwarded correctly.

[0085] In a feasible implementation, step S20 can further include steps S501-S503:

[0086] Step S501, when the instance invocation relationship is a hypertext transfer protocol-based invocation relationship, a gray message queue instance registration request is received.

[0087] Step S502, according to the gray message queue instance registration request, the root message queue instance is registered as the first gray message queue instance through a preset gray registration module.

[0088] Step S503, according to the first gray message queue instance, the instance flag data is generated and sent to the registration center.

[0089] When the instance invocation relationship is a hypertext transfer protocol-based invocation relationship, the gray traffic verification system receives a gray message queue instance registration request, then according to the gray message queue instance registration request, the root message queue instance is registered as the first gray message queue instance through a preset gray registration module, and finally according to the characteristics of the first gray message queue instance (such as instance ID, version number, state, etc.), the instance flag data is generated and sent to the registration center.

[0090] It should be noted that the gray registration module is a module for processing and managing instance registration requests, responsible for updating the state of the instance to the system. The instance flag data can include instance ID, version number, state information, registration timestamp, etc.

[0091] For example, refer to Figure 4 , Figure 4 The general gray capability module schematic diagram provided for Embodiment Two of the present application.

[0092] Specifically, the gray registration module provides a general gray capability interface and implements the gray capability registration sending, independent configuration and instance isolation capability of the registration discovery. Services with different invocation relationships only need to extend the gray capability interface to realize the gray routing capability of different invocation relationships.

[0093] The HTTP-based calling relationship is simple, and only needs to register the instance as formal or gray. Since the module itself supports full-link calling capability, when routing downstream, only the instance consistent with the current instance gray state is selected for routing according to the instance mark in the registration center. In addition, the necessary gray mark is set to the HTTP request header when each request is routed, so that the downstream service can continue to perform the same full-link gray routing after receiving the request.

[0094] In the embodiment, the dynamic registration and state-aware mechanism solves the flexibility problem in traffic management, ensures that the system can adapt to different loads and demand changes, marks the newly registered instance as the first gray message queue instance, ensures that the system can clearly identify different instances, and realizes information sharing between multiple components by generating instance mark data and sending it to the registration center, thereby improving the collaborative working ability of the system. Therefore, an efficient instance registration and management framework is formed, which improves the flexibility, real-time performance and reliability of the system, and lays a solid foundation for subsequent traffic management and gray release.

[0095] In another possible implementation, the instance calling relationship is an asynchronous calling relationship, the gray message queue instance is a second gray message queue instance, the downstream service includes a pre-obtained first gray environment consumer, and the gray traffic release result is a second gray traffic release result. Step S20 can further include step S202:

[0096] In step S202, based on the asynchronous calling relationship, the to-be-released traffic is sent to the first gray environment consumer through the second gray message queue instance, and the second gray traffic release result sent by the first gray environment consumer is received.

[0097] The gray traffic verification system allocates the to-be-released traffic from the second gray message queue instance to the first gray environment consumer through the asynchronous calling relationship, and receives the second gray traffic release result sent by the first gray environment consumer.

[0098] It should be noted that the asynchronous calling relationship is a calling mechanism that allows the sender to continue other operations without waiting for the receiver to complete processing, which can improve the responsiveness and concurrent processing capability of the system, and is suitable for high-traffic scenarios.

[0099] In this embodiment, through the asynchronous calling relationship, the problem of traffic conflict in high concurrency is avoided, ensuring that the traffic between different versions can be processed independently, reducing the impact on the existing system, improving the utilization efficiency of system resources by reasonably distributing traffic to different consumer instances, and reducing performance problems caused by resource overload. Therefore, the asynchronous calling and precise traffic control are effectively combined, not only improving the response ability of the system, but also strengthening risk management and function verification, ensuring efficient and safe release of new functions.

[0100] In another possible implementation, before step S202, steps S601-S602 can also be included:

[0101] Step S601, when the instance calling relationship is an asynchronous calling relationship, receiving a consumer capability change request;

[0102] Step S602, according to the consumer capability change request, changing the capability of the first formal environment consumer in the downstream service through a preset registration center to obtain the first gray environment consumer.

[0103] When the instance calling relationship is an asynchronous calling relationship, the gray traffic verification system receives a consumer capability change request, and then changes the capability of the first formal environment consumer in the downstream service through a preset registration center according to the consumer capability change request to obtain the first gray environment consumer, ensuring that the first formal environment consumer can be adjusted according to the new traffic demand to maintain service performance and availability, thereby generating the first gray environment consumer for testing.

[0104] It should be noted that the consumer capability change request is a signal or message indicating that a certain consumer instance needs to increase or decrease its processing capability, which may involve adjustments in the number of instances, thread number, memory limit, etc.

[0105] Exemplarily, with reference to Figure 5 , Figure 5 The message queue calling relationship diagram provided for Embodiment Two of the present application.

[0106] Specifically, under the capability of the gray registration module, the message queue of the asynchronous calling relationship can also quickly realize the calling capability of the whole link. The message queue producer can regard the downstream consumer as a service provider and change the capability of the consumer by controlling the service, changing the formal environment consumer to the gray environment consumer, or even isolating the consumer. This greatly enhances the capability of the service instance and can more finely control the roles and states of different instances.

[0107] In this embodiment, as the system scale expands, the management of consumers becomes more and more complex. By changing the capabilities of the registry center, the consumer management process is simplified, the operation and maintenance complexity is reduced, and when a service failure occurs, the consumer capabilities can be quickly adjusted to avoid affecting the entire system, improving the fault tolerance and fault recovery speed of the system. In this way, dynamic and flexible consumer capability management can be achieved, improving the adaptability and efficiency of the system, while solving a series of technical problems such as traffic fluctuation, capability lag, system complexity management, and fault recovery, ensuring the stability and reliability of the system in a high-concurrency environment.

[0108] In this embodiment, by precisely matching consumer instances, the problem of uneven traffic distribution is avoided, ensuring that each consumer receives appropriate traffic according to its capabilities, enabling gray release, and through full-link routing requests, new functions can be gradually rolled out, reducing the impact on the entire platform if a problem occurs. Real-time data acquisition by the registry center enables the system to quickly adapt to changes in business requirements, reducing downtime or performance degradation due to environmental changes. In this way, not only is the flexibility and response speed of the system enhanced, but the safety of traffic management and function release is also optimized, which helps to improve the stability of overall services and user experience.

[0109] It should be noted that the above examples are only for understanding the present application and do not constitute a limitation on the gray traffic verification method of the present application. Further simple transformations based on this technical concept are within the scope of protection of the present application.

[0110] The present application also provides a gray traffic verification device, please refer to Figure 6 , the gray traffic verification device comprises:

[0111] The traffic receiving module 10 is configured to receive the to-be-released traffic sent by the upstream service;

[0112] The traffic release module 20 is configured to release the to-be-released traffic to the downstream service based on the pre-registered gray message queue instance and the preset instance invocation relationship, and receive the gray traffic release result sent by the downstream service, wherein the gray message queue instance is generated by registering the preset root message queue instance by the preset gray registration module;

[0113] The traffic verification module 30 is configured to perform gray traffic verification according to the gray traffic release result to obtain a gray traffic verification result.

[0114] Optionally, the instance invocation relationship is a hypertext transfer protocol-based invocation relationship, the gray message queue instance is a first gray message queue instance, the downstream service includes a downstream consumer, the gray traffic release result is a first gray traffic release result, and the traffic release module 20 is further configured to:

[0115] Based on the call relationship based on the Hypertext Transfer Protocol, and according to the first grayscale message queue instance, obtaining pre-generated instance flag data from a preset registration center;

[0116] Determine, according to the instance flag data, a downstream consumer instance that is consistent with the grayscale state of the first grayscale message queue instance as the first consumer instance;

[0117] Generate a full-link grayscale routing request based on the instance flag data;

[0118] Through the first grayscale message queue instance, the traffic to be published is published to the first consumer instance, and the first grayscale traffic publishing result sent by the first consumer instance is received, and the full-link grayscale routing request is sent to the first consumer instance, so that the downstream service performs corresponding full-link grayscale routing.

[0119] Optionally, before the step of publishing the traffic to be published to the downstream service based on the pre-registered grayscale message queue instance and the preset instance call relationship, and receiving the grayscale traffic publishing result sent by the downstream service, the step further includes:

[0120] When the instance call relationship is a call relationship based on the Hypertext Transfer Protocol, receiving a grayscale message queue instance registration request;

[0121] By using a preset grayscale registration module, according to the grayscale message queue instance registration request, the root message queue instance is changed to the first grayscale message queue instance;

[0122] According to the first grayscale message queue instance, the instance flag data is generated and sent to the registration center.

[0123] Optionally, the instance call relationship is an asynchronous call relationship, the grayscale message queue instance is a second grayscale message queue instance, the downstream service includes a pre-obtained first grayscale environment consumer, the grayscale traffic publishing result is a second grayscale traffic publishing result, and the traffic publishing module 20 is further used to:

[0124] Based on the asynchronous call relationship, the traffic to be published is sent to the first grayscale environment consumer through the second grayscale message queue instance, and the second grayscale traffic publishing result sent by the first grayscale environment consumer is received.

[0125] Optionally, before the step of sending the traffic to be published to the first grayscale environment consumer through the second grayscale message queue instance based on the asynchronous call relationship and receiving the second grayscale traffic publishing result sent by the first grayscale environment consumer, the step further includes:

[0126] When the instance call relationship is an asynchronous call relationship, receiving a consumer capability change request;

[0127] According to the consumer capability change request, the capability of the first formal environment consumer in the downstream service is changed through a preset registration center to obtain the first grayscale environment consumer.

[0128] Optionally, the downstream service includes a second grayscale environment consumer, and after the step of performing grayscale traffic verification according to the grayscale traffic publishing result and obtaining the grayscale traffic verification result, the step further includes:

[0129] When the grayscale traffic verification result indicates that the grayscale traffic verification is successful, receiving a consumer status change request;

[0130] Through a preset registration center, according to the consumer status change request, the status of the second grayscale environment consumer is changed to obtain a second formal environment consumer, so that the second formal environment consumer consumes formal traffic.

[0131] The grayscale flow verification device provided in this application, which employs the grayscale flow verification method of the aforementioned embodiment, can resolve the technical issue that existing grayscale solutions cannot distinguish between formal instances and grayscale instances from the perspective of fundamental instances. Compared to the prior art, the beneficial effects of the grayscale flow verification device provided in this application are the same as those of the grayscale flow verification method provided in the aforementioned embodiment, and the other technical features of the grayscale flow verification device are the same as those disclosed in the aforementioned embodiment method, and are not further described here.

[0132] The present application provides a grayscale traffic verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the grayscale traffic verification method in the above-mentioned embodiment one.

[0133] Reference below Figure 7, which shows a schematic diagram of the structure of a grayscale flow verification device suitable for implementing the embodiments of the present application. The grayscale flow verification device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., as well as fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The grayscale flow verification device shown is merely an example and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

[0134] like Figure 7 As shown, the grayscale flow verification device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the grayscale flow verification device. The processing device 1001, ROM 1002, and RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, hard disk, etc.; and a communication device 1009. Communication device 1009 can allow the grayscale flow verification device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a grayscale flow verification device with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems can be implemented or provided instead.

[0135] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0136] The grayscale flow verification device provided in this application utilizes the grayscale flow verification method described in the aforementioned embodiment, resolving the technical issue with existing grayscale solutions that fail to distinguish formal instances from grayscale instances from the perspective of fundamental instances. Compared to the prior art, the grayscale flow verification device provided in this application achieves the same beneficial effects as the grayscale flow verification method described in the aforementioned embodiment. Other technical features of the grayscale flow verification device are the same as those disclosed in the aforementioned embodiment and are not further elaborated upon here.

[0137] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0138] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0139] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, a computer program) stored thereon, and the computer-readable program instructions are used to execute the grayscale flow verification method in the above-mentioned embodiment.

[0140] The computer readable storage medium provided in the application may be, for example, a U disk, but is not limited to an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination of the above. More specific examples of the computer readable storage medium may include, but are not limited to, an electric connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the embodiment, the computer readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted by any suitable medium, including but not limited to an electric wire, an optical cable, an RF (Radio Frequency), and the like, or any suitable combination of the above.

[0141] The computer readable storage medium described above may be contained in the gray traffic verification device, or may exist separately without being assembled into the gray traffic verification device.

[0142] The computer readable storage medium described above carries one or more programs, which, when executed by the gray traffic verification device, cause the gray traffic verification device to:

[0143] receive the to-be-published traffic sent by the upstream service;

[0144] publish the to-be-published traffic to the downstream service based on a pre-registered gray message queue instance and a preset instance calling relationship, and receive a gray traffic publishing result sent by the downstream service, the gray message queue instance being generated by registering a preset root message queue instance by a preset gray registration module;

[0145] perform gray traffic verification according to the gray traffic publishing result to obtain a gray traffic verification result.

[0146] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the module, program segment or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, as well as the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or can be implemented using a combination of dedicated hardware and computer instructions.

[0148] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0149] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the grayscale traffic verification method described above. This computer-readable storage medium can address the technical issue of existing grayscale solutions that cannot distinguish between formal instances and grayscale instances from the perspective of fundamental instances. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the grayscale traffic verification method provided in the above-mentioned embodiment, and are not further elaborated here.

[0150] The application further provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the gray traffic verification method as described above.

[0151] The computer program product provided by the application can solve the technical problem that the existing gray scheme cannot fundamentally distinguish between formal instances and gray instances. Compared with the prior art, the computer program product provided by the application has the same beneficial effects as the gray traffic verification method provided by the above-mentioned embodiments, and will not be described here.

[0152] The above-mentioned embodiments are only part of the embodiments of the application, and do not limit the patent scope of the application. Any equivalent structural transformation, direct / indirect application in other related technical fields, or the like made by using the content of the specification and drawings within the technical concept of the application is included in the patent protection scope of the application.

Claims

1. A grayscale traffic verification method, characterized in that: The method comprises: Receive traffic to be published from upstream services; Based on the pre-registered grayscale message queue instance and the preset instance call relationship, the traffic to be published is published to the downstream service, and the grayscale traffic publishing result sent by the downstream service is received. The grayscale message queue instance is generated by registering the preset root message queue instance by the preset grayscale registration module; Grayscale traffic verification is performed according to the grayscale traffic publishing result to obtain a grayscale traffic verification result.

2. The method according to claim 1, wherein The instance call relationship is a call relationship based on the Hypertext Transfer Protocol, the grayscale message queue instance is a first grayscale message queue instance, the downstream service includes a downstream consumer, and the grayscale traffic publishing result is a first grayscale traffic publishing result. The steps of publishing the to-be-published traffic to the downstream service based on the pre-registered grayscale message queue instance and the preset instance call relationship, and receiving the grayscale traffic publishing result sent by the downstream service include: Based on the call relationship based on the Hypertext Transfer Protocol, and according to the first grayscale message queue instance, obtaining pre-generated instance flag data from a preset registration center; Determine, according to the instance flag data, a downstream consumer instance that is consistent with the grayscale state of the first grayscale message queue instance as the first consumer instance; Generate a full-link grayscale routing request based on the instance flag data; Through the first grayscale message queue instance, the traffic to be published is published to the first consumer instance, and the first grayscale traffic publishing result sent by the first consumer instance is received, and the full-link grayscale routing request is sent to the first consumer instance, so that the downstream service performs corresponding full-link grayscale routing.

3. The method according to claim 2, wherein Before the step of publishing the traffic to be published to the downstream service based on the pre-registered grayscale message queue instance and the preset instance call relationship, and receiving the grayscale traffic publishing result sent by the downstream service, the method further includes: When the instance call relationship is a call relationship based on the Hypertext Transfer Protocol, receiving a grayscale message queue instance registration request; By using a preset grayscale registration module, according to the grayscale message queue instance registration request, the root message queue instance is changed to the first grayscale message queue instance; According to the first grayscale message queue instance, the instance flag data is generated and sent to the registration center.

4. The method according to claim 1, wherein The instance call relationship is an asynchronous call relationship, the grayscale message queue instance is a second grayscale message queue instance, the downstream service includes a pre-acquired first grayscale environment consumer, the grayscale traffic publishing result is a second grayscale traffic publishing result, and the steps of publishing the to-be-published traffic to the downstream service based on the pre-registered grayscale message queue instance and the preset instance call relationship, and receiving the grayscale traffic publishing result sent by the downstream service include: Based on the asynchronous call relationship, the traffic to be published is sent to the first grayscale environment consumer through the second grayscale message queue instance, and the second grayscale traffic publishing result sent by the first grayscale environment consumer is received.

5. The method according to claim 4, wherein Before the step of sending the to-be-published traffic to the first grayscale environment consumer through the second grayscale message queue instance based on the asynchronous call relationship and receiving the second grayscale traffic publishing result sent by the first grayscale environment consumer, the method further includes: When the instance call relationship is an asynchronous call relationship, receiving a consumer capability change request; According to the consumer capability change request, the capability of the first formal environment consumer in the downstream service is changed through a preset registration center to obtain the first grayscale environment consumer.

6. The method according to claim 1, wherein The downstream service includes a second grayscale environment consumer. After the step of performing grayscale traffic verification according to the grayscale traffic publishing result and obtaining the grayscale traffic verification result, the method further includes: When the grayscale traffic verification result indicates that the grayscale traffic verification is successful, receiving a consumer status change request; Through a preset registration center, according to the consumer status change request, the status of the second grayscale environment consumer is changed to obtain a second formal environment consumer, so that the second formal environment consumer consumes formal traffic.

7. A grayscale flow verification device, characterized in that: The device comprises: Traffic receiving module, used to receive the traffic to be published sent by the upstream service; A traffic publishing module is used to publish the traffic to be published to downstream services based on a pre-registered grayscale message queue instance and a preset instance call relationship, and receive the grayscale traffic publishing result sent by the downstream service. The grayscale message queue instance is generated by registering a preset root message queue instance with a preset grayscale registration module; The traffic verification module is used to perform grayscale traffic verification based on the grayscale traffic publishing result to obtain a grayscale traffic verification result.

8. A grayscale flow verification device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the grayscale flow verification method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the grayscale flow verification method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the grayscale flow verification method according to any one of claims 1 to 6 are implemented.

Images