A full-link grayscale publishing method, device and storage medium

Abstract

The present invention proposes a full-link grayscale publishing method, device and storage medium, wherein the method comprises: when the service is started, registering with a registration center according to environment variables and configuration information, and writing grayscale label information as metadata to the registration center; when the user's HTTP request reaches an API gateway, the API gateway performs coloring processing on the request according to the grayscale rule configuration information; obtaining the corresponding upstream service instance from the registration center, screening out the target service instance, and forwarding the request to the target service instance; the API gateway monitors the status of the grayscale service in real time, and if the status is normal, automatically increases the traffic allocation ratio according to the grayscale rule configuration, otherwise, stops the traffic coloring of the service, transfers all its requests to the main version, and ends the grayscale publishing. Through this method, the scale of grayscale users can be accurately controlled, and this method supports grayscale publishing for services specified in the link, thereby making the grayscale publishing capability more flexible.

Description

Technical Field

[0001] The present invention proposes a full-link grayscale publishing method, device and storage medium, and relates to the field of computer technology. Background Art

[0002] The conventional grayscale release process in a traditional non-containerized environment is to deploy the new version to the pre-production environment for full testing, deploy the new version to a portion of the servers in the production environment (such as 10%), update the load balancer configuration, direct a portion of the traffic to the new version, monitor the performance of the new version in real time (such as response time, error rate), collect feedback and usage data from early users, and gradually increase the traffic weight of the new version (such as from 10% to 25%, and then to 50%) if the monitoring results and user feedback are good. If problems are found, immediately reduce the traffic of the new version, or even roll back to the old version. When the new version has been fully verified and the performance and user feedback meet expectations, gradually or all at once upgrade the production version to the new version, monitor the switching process, and end the grayscale release after ensuring that there are no major problems.

[0003] The traditional grayscale release method cannot achieve grayscale control of north-south traffic. Ribbon can only select instances for east-west traffic according to grayscale labels, and cannot control north-south traffic. There is no automated grayscale traffic control strategy, and the traffic ratio needs to be manually modified and configured, and the selection of grayscale users cannot be finely controlled. It is impossible to perform grayscale release for specified services. The current solutions generally enable grayscale capabilities uniformly, and cannot perform grayscale release for specified services in the link. For applications that are not part of the Spring Cloud technology stack, this technical solution cannot be used to achieve grayscale release. Containerization technology is not used. After the grayscale is completed, the version upgrade needs to apply for an upgrade time window and update after downtime, which is costly. Summary of the invention

[0004] The present invention provides a full-link grayscale publishing method, device and storage medium to solve the above-mentioned problems:

[0005] The present invention proposes a full-link grayscale publishing method, the method comprising:

[0006] When the service starts, it registers with the registration center based on the environment variables and configuration information, and writes the grayscale label information into the registration center as metadata;

[0007] When the user's HTTP request reaches the API gateway, the API gateway performs coloring on the request according to the grayscale rule configuration information;

[0008] According to the grayscale rules and the colored HTTP request, the corresponding upstream service instance is obtained from the registration center, the target service instance is screened out, and the request is forwarded to the target service instance;

[0009] The API gateway monitors the status of the grayscale service in real time. If the service status is normal, the traffic allocation ratio is automatically increased according to the grayscale rule model. Otherwise, the traffic coloring of the service is stopped, all its requests are transferred to the main version, and the grayscale release is ended.

[0010] After the grayscale traffic continues to increase to the specified scale, if the service status is normal and meets the online requirements, the grayscale version verification is successful, you can manually update the main version image to the latest version, and then take the grayscale version offline, and the grayscale release is completed.

[0011] Furthermore, when the user's HTTP request reaches the API gateway, the API gateway processes the coloring according to the grayscale rule configuration information, including:

[0012] The user's HTTP request arrives at the API gateway, and the HTTP request includes cookies, headers, and query parameters;

[0013] The API gateway parses the user's HTTP request and extracts information from the user's HTTP request;

[0014] The API gateway has built-in pre-defined grayscale rules, which are a series of conditional expressions that describe requests that are considered as part of the grayscale test;

[0015] The API gateway matches the extracted information with the grayscale rules. If the extracted information complies with the grayscale rules, the request for the extracted information is regarded as a grayscale request.

[0016] The API Gateway adds a grayscale flag to requests that are considered grayscale requests.

[0017] Furthermore, the API gateway has built-in pre-defined grayscale rules, which are a series of conditional expressions, including: user ID, IP address, request path, request header and request parameters.

[0018] Furthermore, the request with the grayscale mark is sent to the corresponding backend service.

[0019] Furthermore, according to the grayscale rules and the colored HTTP requests, the corresponding upstream service instances are obtained from the registration center, and the target service instances are screened out, including:

[0020] If the upstream service is not configured with a grayscale rule, the primary version instance of the upstream service is directly queried from the registration center, and then one of the instances is selected and returned based on the load balancing strategy;

[0021] If the upstream service has configured grayscale rules, query all instances of the upstream service with grayscale labels from the registration center, and then select one of the instances based on the load balancing strategy and return it;

[0022] When the backend service receives a grayscale request and the upstream service has a grayscale label, the request will be forwarded to the service instance with the grayscale label.

[0023] Furthermore, if the backend service receives a grayscale request and the upstream service has a grayscale label, the request will be forwarded to the service instance with the grayscale label, including:

[0024] The grayscale version of backend service B continues to request upstream service C, but upstream service C does not have a grayscale version, so it continues to request the main version of backend service C.

[0025] The backend service C has a grayscale version, and the grayscale rule only configures service B. The request will still request the main version of service C.

[0026] Furthermore, one of the instances is selected and returned according to the load balancing strategy, including:

[0027] In the actual environment, the strategy is deployed to enable traffic distribution based on the grayscale rule model. The grayscale rule model is:

[0028] ;

[0029] in, represents the proportion of traffic allocated to the grayscale version, P(t) represents the proportion of traffic allocated to the grayscale version at time t, E(t) represents the error rate observed at time t, T(t) represents the average response time observed at time t, H(t) represents the historical performance index, which is calculated based on the average error rate and response time of the past n time intervals, and S e and S t represents the target thresholds for error rate and response time, α, β, and γ represent adjustment coefficients;

[0030] ;

[0031] Where n represents the time range of historical data, and i is a variable representing the time point currently processed in the summation operation;

[0032] When a request reaches the API gateway or load balancer, it first decides whether to route the request to the grayscale version based on the ratio P(t+1);

[0033] If the route is to the grayscale version, select an instance from the set of instances that meet the grayscale conditions and make the selection based on the load balancing mechanism (for example, using polling or the least connection strategy). If the route is not to the grayscale version, fall back the request to the preset stable version.

[0034] Furthermore, a terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that when the processor executes the computer program, the steps of the full-link grayscale publishing method based on a container and a registration center are implemented.

[0035] Furthermore, a computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the full-link grayscale publishing method based on a container and a registration center.

[0036] The beneficial effects of the present invention include: supporting grayscale control of north-south traffic, realizing traffic coloring on the API gateway, and being transparent to users; supporting automated grayscale traffic control strategies, configuring grayscale traffic control strategies on the API gateway, supporting obtaining data from cookies, headers, and query parameters, setting matching rules, and being able to accurately control the scale of grayscale users; supporting grayscale publishing for services specified in the link, thereby making the grayscale publishing capability more flexible; the technical implementation is independent of the language, and SDKs in multiple languages ​​are provided, which can be used out of the box after being integrated with the project; combining containerization technology with a registration center can effectively reduce the operation and maintenance costs of grayscale publishing of the entire link, without the need for downtime or upgrade windows, while supporting grayscale publishing, multi-active, and disaster recovery capabilities across data centers. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a flow chart of a full-link grayscale publishing method described in the present invention;

[0038] Figure 2 A schematic diagram of a full-link grayscale publishing method described in the present invention. DETAILED DESCRIPTION

[0039] In order to more clearly understand the above-mentioned purpose, features and advantages of the present invention, the present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0040] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. The embodiments described are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0042] For an embodiment of the present invention, please refer to Figure 1 and Figure 2 , a full-link grayscale publishing method, the method comprising:

[0043] When the service starts, it registers with the registration center based on the environment variables and configuration information, and writes the grayscale label information into the registration center as metadata;

[0044] When the user's HTTP request reaches the API gateway, the API gateway performs coloring on the request according to the grayscale rule configuration information;

[0045] According to the grayscale rules and the colored HTTP request, the corresponding upstream service instance is obtained from the registration center, the target service instance is screened out, and the request is forwarded to the target service instance;

[0046] The API gateway monitors the status of the grayscale service in real time. If the service status is normal, the traffic allocation ratio is automatically increased according to the grayscale rule model. Otherwise, the traffic coloring of the service is stopped, all its requests are transferred to the main version, and the grayscale release is ended.

[0047] After the grayscale traffic continues to increase to the specified scale, if the service status is normal and meets the online requirements, the grayscale version verification is successful, you can manually update the main version image to the latest version, and then take the grayscale version offline, and the grayscale release is completed.

[0048] The API gateway calculates the service error rate within a certain time window in the past in real time and compares it with the preset threshold. If the service error rate does not exceed the preset threshold, the service is judged to be normal. If the service error rate exceeds the preset threshold, the service is judged to be abnormal.

[0049] The working principle and effect of the above technical solution are as follows: service registration, when the service is started, it will automatically register with the service registration center according to the environment variables and configuration information, and attach grayscale labels as metadata in the registration information. These grayscale labels can identify the version of the service and other grayscale-related attributes to facilitate subsequent traffic management and selection; request coloring processing, after receiving the HTTP request, the API gateway will color the request according to the preset grayscale rules. This processing is mainly to assign labels to the request, which determine which service version the request will be sent to, and can be based on user characteristics, geographic location or other logic; service instance screening, the gateway queries the registration center to obtain the corresponding service instance according to the request and grayscale rules after coloring. The registration center will return a list of service instances with corresponding grayscale labels, and the API gateway will select the appropriate instance from it to forward the request; real-time monitoring and traffic adjustment, the API gateway monitors the status and performance of the grayscale service instance in real time. If the service performance is normal, the proportion of traffic allocated to the grayscale version will be automatically increased according to the grayscale rules. If a problem is detected, the grayscale coloring of the traffic will be stopped and the request will be redirected to the main version; grayscale traffic management, the grayscale traffic will continue to increase until the set test scale is reached. If the service status remains normal throughout the process and meets all the requirements for going online, the grayscale version verification is successful, and the main version can be manually updated to the latest image, and the grayscale version can be offline to end the grayscale release. It supports grayscale control of north-south traffic, implements traffic coloring on the API gateway, and is transparent to users; it supports automated grayscale traffic control policies, configures grayscale traffic control policies on the API gateway, supports obtaining data from cookies, headers, and query parameters, sets matching rules, and can accurately control the scale of grayscale users; it supports grayscale release for specified services in the link, making grayscale release capabilities more flexible; the technical implementation is language-independent, and SDKs in multiple languages ​​are provided. After integration with the project, it is ready to use out of the box; combining containerization technology with the registration center can effectively reduce the operation and maintenance costs of grayscale releases across the entire link, without the need for downtime or upgrade windows, while supporting grayscale releases, multi-active, and disaster recovery capabilities across data centers.

[0050] An embodiment of the present invention is a full-link grayscale publishing method. When a user's HTTP request reaches an API gateway, the API gateway processes the coloring according to grayscale rule configuration information, including:

[0051] The user's HTTP request arrives at the API gateway, and the HTTP request includes cookies, headers, and query parameters;

[0052] The API gateway parses the user's HTTP request and extracts information from the user's HTTP request;

[0053] The API gateway has built-in pre-defined grayscale rules, which are a series of conditional expressions that describe requests that are considered as part of the grayscale test;

[0054] The API gateway matches the extracted information with the grayscale rules. If the extracted information complies with the grayscale rules, the request for the extracted information is regarded as a grayscale request.

[0055] The API Gateway adds a grayscale flag to requests that are considered grayscale requests.

[0056] The working principle and effect of the above technical solution are as follows: the request arrives at the API gateway. When the HTTP request initiated by the user arrives at the API gateway, the gateway first receives the complete request data including cookies, headers and query parameters; request parsing. The API gateway parses the received HTTP request and extracts key information from it, such as user ID, geographic location, device type, etc., which may be hidden in cookies, HTTP headers or query parameters; grayscale rule matching. The API gateway has a built-in pre-defined grayscale rule set. These rules are a series of conditional expressions used to determine which requests should participate in grayscale testing. Grayscale rules may be defined based on various factors, such as user characteristics, request source, timestamp, etc.; identify grayscale requests. Once the API gateway determines that the current request meets the grayscale conditions according to the grayscale rules, it will mark a grayscale identifier for the request, which is usually achieved by modifying the request header or adding specific parameters to the request; request forwarding. Requests with grayscale identifiers will be routed to the corresponding grayscale service version, while non-grayscale requests will be routed to the main service version. Such routing decisions are controlled by the API gateway to ensure that qualified requests can correctly access the grayscale test version. Precise traffic control: Through fine-grained grayscale rules, the API gateway can precisely control the traffic entering the grayscale test. This precise control not only helps to safely test new features in the actual production environment, but also can test specific user groups or request types to improve the effectiveness and reliability of the test; risk isolation: limit the risk of new versions or features to a small number of users or requests to prevent possible problems from affecting a large user group. This isolation mechanism makes problem diagnosis and rapid rollback easier to manage and improves the stability of the overall service; real-time data-driven decision-making: based on real-time traffic and user behavior data, the grayscale strategy can be dynamically adjusted to make grayscale testing more flexible and responsive to market changes. In addition, the collected data can be used to analyze user behavior to further optimize products and services; increase user satisfaction Grayscale testing can more safely test and optimize new features or improvements, thereby continuously providing value-added services or product improvements without reducing user experience, thereby increasing user satisfaction and loyalty; grayscale release makes resource use more efficient because it only launches and tests new features for part of the traffic. At the same time, quickly locating and fixing problems reduces potential losses and cost expenditures, and improves overall operational efficiency. This technical solution can achieve efficient and accurate traffic allocation and management through intelligent grayscale rules and the efficient processing capabilities of API gateways, providing strong technical support for grayscale testing, thereby optimizing the testing process, improving user experience, and maintaining product stability and security.

[0057] One embodiment of the present invention is a full-link grayscale publishing method, wherein the API gateway has built-in pre-defined grayscale rules, and the grayscale rules are a series of conditional expressions, and the conditional expressions include: user ID, IP address, request path, request header and request parameters.

[0058] The working principle and effect of the above technical solution are as follows: Grayscale rule definition, the API gateway has a series of predefined grayscale rules built in. These rules consist of conditional expressions that describe which requests are considered part of the grayscale test; when an HTTP request reaches the API gateway, the gateway parses the key information in the request (such as Cookies, Headers, Query parameters, etc.), which is used to match the conditional expressions of the grayscale rules; the API gateway evaluates whether each request meets the predefined grayscale rules based on the extracted information. If a request meets one or more conditional expressions, the request is identified as a grayscale request; traffic that is judged by the grayscale rules and identified as a grayscale request will be directed to the specified service version (grayscale version), which may contain new features or improvements. Traffic that is not identified as a grayscale request will be routed to the regular service version.

[0059] Fine-grained control: Grayscale rules defined by conditional expressions allow for fine-grained segmentation and control of traffic, which ensures that only requests that meet specific conditions are routed to the grayscale environment, allowing new features or improvements to be tested more accurately. Risk minimization: Since grayscale testing only affects a small number of users who meet specific conditions, the potential risks introduced by the new version are limited to a smaller range, which helps identify and resolve problems before full deployment. Real-time feedback and rapid iteration: An important advantage of grayscale testing is that it can provide fast user feedback and real-time data, which allows the development team to quickly adjust and optimize new features based on actual usage and accelerate the iteration cycle. Personalized user experience: Grayscale rules can be set based on multiple factors such as user geographic location, device type, user behavior, etc., so that different user groups can experience targeted new features or optimizations, which helps to better meet the personalized needs of users. Through grayscale testing, organizations can release new versions more safely and effectively, enhancing the stability and reliability of services. This approach can effectively reduce the overall downtime of the system and improve the overall user satisfaction with the service. Grayscale testing can effectively introduce new products to the market by finely controlling who can access new features or changes, while minimizing interference with existing user experience. This strategy is an integral part of modern software development, especially as continuous deployment and rapid iteration become increasingly important.

[0060] An embodiment of the present invention is a full-link grayscale publishing method, in which a request with a grayscale identifier is sent to a corresponding backend service.

[0061] An embodiment of the present invention is a full-link grayscale publishing method, which obtains corresponding upstream service instances from a registration center according to grayscale rules and colored HTTP requests, and screens out target service instances, including:

[0062] If the upstream service is not configured with a grayscale rule, the primary version instance of the upstream service is directly queried from the registration center, and then one of the instances is selected and returned based on the load balancing strategy;

[0063] If the upstream service has configured grayscale rules, query all instances of the upstream service with grayscale labels from the registration center, and then select one of the instances based on the load balancing strategy and return it;

[0064] When the backend service receives a grayscale request and the upstream service has a grayscale label, the request will be forwarded to the service instance with the grayscale label.

[0065] The working principle and effect of the above technical solution are as follows: identification processing, when the API gateway determines that a request meets the grayscale test conditions according to the built-in grayscale rules, a specific grayscale identification will be added to the request. This identification is usually a specific HTTP header or modifies the existing header to reflect its grayscale status; grayscale routing logic, the API gateway is configured with grayscale routing logic to identify requests with grayscale identification, and send these requests to the corresponding backend services according to predefined routing rules. These backend services are generally services that have deployed new functions or new versions; service distribution, after the grayscale backend service receives these requests marked as grayscale, it will process these requests and return a response; since these backend services may contain new functions or improvements that have not been widely released, grayscale requests can test the performance of these new features in a real-time environment. Control risks. By deploying new changes only to the backend grayscale service instead of all users, the risk coverage when problems occur can be effectively controlled. If there is a problem with the grayscale version, it will only affect a small number of users without affecting the stability of the entire system. The grayscale environment allows new features to be tested in the actual user environment, and developers can quickly iterate products based on user feedback and system performance. This fast feedback loop is a key part of modern agile development and continuous integration / continuous deployment (CI / CD) practices. For most users, their experience will not be affected by new features or changes being tested. Grayscale testing ensures that only a selected part of users are using new features, thereby minimizing the interference of new updates on mainstream user experience. Through grayscale testing, resources can be managed more effectively. For example, it can ensure that only necessary resources are allocated to grayscale services, thereby optimizing resource usage and costs. Enhanced decision-making capabilities: Provide actual data to support decision-making. The data collected using grayscale testing can help decision makers understand the acceptance of new features and where optimization may be needed. Such a data-driven decision-making process can significantly improve product success rate and market response speed. Grayscale testing is a powerful strategy that allows for detailed control of the testing and promotion process of new features in a real operating environment. Through effective identification and routing mechanisms, the smooth rollout of new features can be ensured while maintaining the overall stability and reliability of the system.

[0066] In one embodiment of the present invention, a full-link grayscale publishing method is provided. When a backend service receives a grayscale request and an upstream service has a grayscale label, the request is forwarded to a service instance with the grayscale label, including:

[0067] The grayscale version of backend service B continues to request upstream service C, but upstream service C does not have a grayscale version, so it continues to request the main version of backend service C.

[0068] The backend service C has a grayscale version, but the grayscale rule only configures service B. Therefore, the request will still request the main version of service C.

[0069] The working principle and effect of the above technical solution are as follows: grayscale request flow and inter-service dependency. In a distributed system, after the backend service B receives a request labeled with grayscale by the API gateway, it may need to further call the upstream service C to complete the processing of the request. At this time, the grayscale support between services becomes the key; although service B has grayscale version support and is selected to process grayscale requests, the situation of service C may be different. If service C is not configured to support grayscale, or the grayscale rule does not specifically include service C, then the request from service B will be routed to the main version of service C; after the grayscale version of service B processes the request, it needs to further request service C. However, due to the configuration of service C and the grayscale rule setting, even if the request source is the grayscale version of service B, the request will eventually be sent to the main version of service C. This setup allows for flexible grayscale testing within a specific service (such as service B) without having to upgrade all services to support grayscale testing, which is very effective in controlling the scope and impact of testing and reducing overall risk; since service C does not have a grayscale version or grayscale configuration, the stability and reliability of its main version when providing services will not be affected by changes that may be introduced by grayscale testing, which helps to ensure the stable operation of core services or key dependent services; not requiring all services to have grayscale versions can simplify the configuration and management of grayscale testing. In some cases, only some services' support for new features is the focus of testing, not the entire system;

[0070] This approach effectively isolates potential risks, because any problems caused by the grayscale version will not spread to services that are not configured with grayscale (such as service C), and any problems caused by grayscale testing are limited to the configured grayscale services, which helps to quickly locate and solve problems; through such a design, the system can gradually test and deploy new features without completely changing all services. This strategy allows the business to explore and experiment with new features or optimizations while keeping the core parts of the system stable. This strategy is particularly valuable for environments that rely on stability and need to gradually introduce new technologies.

[0071] An embodiment of the present invention is a full-link grayscale publishing method, which selects one of the instances to return according to a load balancing strategy, including:

[0072] In the actual environment, the strategy is deployed to enable traffic distribution based on the grayscale rule model. The grayscale rule model is:

[0073] ;

[0074] Where P(t) represents the proportion of traffic allocated to the grayscale version at time t, E(t) represents the error rate observed at time t, T(t) represents the average response time observed at time t, H(t) represents the historical performance index, which is calculated based on the average error rate and response time of the past n time intervals, and S e and S t represents the target thresholds for error rate and response time, α, β, and γ represent adjustment coefficients;

[0075] ;

[0076] Where n represents the time range of historical data, and i is a variable representing the time point currently processed in the summation operation;

[0077] When a request reaches the API gateway or load balancer, it first decides whether to route the request to the grayscale version based on the ratio P(t+1);

[0078] If routing to the grayscale version, select an instance from the set of instances that meet the grayscale conditions and make the selection based on the load balancing mechanism (for example, using polling or least connection strategy).

[0079] The working principle and effect of the above technical solution are as follows: the calculation method of the traffic distribution algorithm (calculation of P(t+1)) uses the formula P(t+1) = P(t) × (1 + α(1 - E(t) / Se) + β(1 - T(t) / St) + γ(1 - H(t))) to dynamically adjust the traffic ratio. The formula takes into account the current error rate E(t), the average response time T(t) and the past historical performance H(t) to optimize the traffic distribution; by comparing the difference between the actual error rate and the target error rate Se, the traffic ratio is adjusted; by comparing the ratio of the actual response time to the target response time St, corresponding adjustments are made; by analyzing the error rate and response time in the historical data, the traffic distribution of the gray version is adjusted; when the request arrives at the API gateway or load balancer, based on the latest calculated P(t+1), it is determined whether the request should be routed to the gray version; if it is routed to the gray version, a suitable instance is selected from the service instances that meet the gray conditions to process the request according to the load balancing strategy (such as polling, weight distribution, least connection, etc.).

[0080] Dynamic adjustment and optimization, adaptive load adjustment, dynamically adjust traffic based on real-time and historical performance data. This method allows the system to optimize the traffic distribution of the gray version based on current and past performance, which is more intelligent and adaptive; prevent overload, by reducing the flow to the gray version with poor performance, it can prevent service overload caused by version problems; Limited impact scope: errors and performance issues only affect a limited user group, reducing the risk of launching new features; progressive deployment: gradually increase the traffic to the grayscale version, and only increase the traffic share it carries when the grayscale version is stable and performing well; instant feedback adjustment: the system design allows traffic allocation to be adjusted based on real-time performance feedback, helping to quickly identify and correct potential problem points; continuous performance evaluation: historical performance considerations ensure that not only instant data but also long-term trends affect the traffic of the grayscale version; optimize user experience and minimize interference, because grayscale traffic can be optimized and allocated based on real-time data, which can minimize the problems that users may encounter due to the launch of the new version; service quality assurance: continuous monitoring and adjustment ensure that service quality is always guaranteed, even in the new function testing phase; this strategy of dynamically adjusting grayscale traffic based on performance indicators not only enhances deployment flexibility, but also enhances the stability and security of the service, while ensuring the continuity and stability of user experience during the testing and verification of new functions.

[0081] One embodiment of the present invention is a terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the full-link grayscale publishing method when executing the computer program.

[0082] One embodiment of the present invention is a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps of the full-link grayscale publishing method based on a container and a registration center are implemented.

[0083] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A full-link grayscale publishing method, characterized in that: The method comprises: When the service starts, it registers with the registry based on environment variables and configurations, and writes the grayscale label as metadata; When an HTTP request reaches the API gateway, the request is marked according to the grayscale rule configuration information, and the target service instance is filtered in combination with the instance metadata of the registration center, including: If the upstream service is not configured with a grayscale rule, an instance is selected from the primary version instance of the registration center according to the load balancing strategy and returned; If the upstream service is configured with grayscale rules, an instance is selected from all instances with grayscale labels in the registry according to the load balancing strategy and returned, including: Select one of the instances to return according to the load balancing strategy, including: deploying the strategy in the actual environment, and enabling traffic distribution based on the grayscale rule model, where the grayscale rule model is: ； in, represents the proportion of traffic allocated to the grayscale version, P(t) represents the proportion of traffic allocated to the grayscale version at time t, E(t) represents the error rate observed at time t, T(t) represents the average response time observed at time t, H(t) represents the historical performance index, which is calculated based on the average error rate and response time of the past n time intervals, and S e and S t represents the target thresholds for error rate and response time, α, β, and γ represent adjustment coefficients; ； Where n represents the time range of historical data, and i is a variable representing the time point currently processed in the summation operation; Routes the request to the grayscale instance set or falls back to the main version based on the calculation results; When the grayscale instance processes a request, the API gateway monitors the service status in real time: when the indicators are normal, the grayscale traffic ratio is automatically increased according to the model; if an abnormality is detected, the coloring is stopped immediately and the entire volume is switched back to the main version; When the grayscale traffic reaches the preset scale and passes the verification, the main version image is updated to the grayscale version and the grayscale environment is offline.

2. According to claim 1, a full-link grayscale publishing method is characterized in that: When the user's HTTP request reaches the API gateway, the API gateway processes the coloring according to the grayscale rule configuration information, including: The user's HTTP request arrives at the API gateway, and the HTTP request includes cookies, headers, and query parameters; The API gateway parses the user's HTTP request and extracts information from the user's HTTP request; The API gateway has built-in pre-defined grayscale rules, which are a series of conditional expressions that describe requests that are considered as part of the grayscale test; The API gateway matches the extracted information with the grayscale rules. If the extracted information complies with the grayscale rules, the request for the extracted information is regarded as a grayscale request. The API Gateway adds a grayscale flag to requests that are considered grayscale requests.

3. According to claim 2, a full-link grayscale publishing method is characterized in that: The API gateway has built-in pre-defined grayscale rules, which are a series of conditional expressions. The conditional expressions include: user ID, IP address, request path, request header, and request parameters.

4. According to claim 2, a full-link grayscale publishing method is characterized in that: Requests with grayscale tags are sent to the corresponding backend services.

5. According to claim 1, a full-link grayscale publishing method is characterized in that: When the backend service receives a grayscale request and the upstream service has a grayscale label, the request will be forwarded to the service instance with the grayscale label, including: The grayscale version of backend service B continues to request upstream service C, but upstream service C does not have a grayscale version, so it continues to request the main version of backend service C. The backend service C has a grayscale version, and the grayscale rule only configures service B. The request will still request the main version of service C.

6. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the full-link grayscale publishing method as described in any one of claims 1 to 5 are implemented.

7. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the full-link grayscale publishing method as described in any one of claims 1 to 5 are implemented.

Images