API-based dual-routing gateway gray release microservice method and system

Abstract

The present application relates to the technical field of gray release, and particularly relates to a method and system for gray release of micro services based on API dual routing gateways, which first collects recent logs of a stable system as samples, obtains a gray release window candidate list and traffic migration weight based on the samples by using a sliding window algorithm, formulates a gray release gateway routing rule, enters a release window, combines a dynamically adjusted load balancer traffic weight and an online Http request cache area to complete traffic migration between dual gateways, dynamically updates the gateway routing rule when the gateway traffic is reduced to zero, uses a transition routing rule in a smooth transition stage and starts rollback event monitoring, rolls back to a stable service as soon as a rollback event occurs, and if the smooth transition stage ends without a rollback event, formally releases the gray routing rule, and the gray release is successful. The present application has high automation degree in the gray release process, is simple and convenient, safe and reliable, and has no user perception in the release process, and improves user experience.

Description

Technical Field

[0001] This invention relates to the field of canary deployment technology, and more specifically to a method and system for canary deployment of microservices based on an API dual-routing gateway. Background Technology

[0002] In microservice system architectures, critical infrastructure services with massive business volumes typically employ redundant hot backup technology for deployment due to their high availability and stability requirements. System service version upgrades are an essential part of system maintenance. In this architecture, canary releases usually involve an intermediate API gateway. After upgrading routing rules on this gateway, the API gateway in the existing stable system is replaced by modifying the reverse proxy and traffic weights in the Nginx configuration. However, this technology carries the following risks during canary releases:

[0003] (1) Traffic migration is carried out during peak service periods. During this period, all load will be applied to the primary or backup service, reducing the system service capacity by half. There is a risk that the system may experience slow response to user requests or even crash due to overload.

[0004] (2) During the canary release process, there is a risk that online HTTP requests may be abnormally interrupted due to dynamic updates of the reverse proxy API gateway IP or port and API gateway routing rules in the Nginx configuration;

[0005] (3) Manually writing properties, yaml and other configuration files to configure API gateway routing rules is prone to errors, and restarting the API gateway is time-consuming and inefficient;

[0006] (4) There is a waste of resources, as the intermediate API gateway is only used during canary releases. Summary of the Invention

[0007] To address the above requirements and existing technical deficiencies, this invention proposes a method and system for canary deployment of microservices based on an API dual-routing gateway. This method eliminates the need for an intermediate API gateway or restarting the API gateway, provides a method for calculating the canary deployment window, tightly integrates window parameters with traffic migration parameters, employs dynamic traffic migration and dynamic gateway routing rule update technologies to avoid abnormal interruptions, and further reduces the risk of canary deployment through rollback event monitoring.

[0008] To achieve the objectives of this invention, the technical solution adopted is: a method for canary deployment of microservices based on an API dual-routing gateway, the method comprising:

[0009] 1) Calculate the canary release window sequence and traffic migration weight based on the collected API call log sample data;

[0010] 2) Enter the gray release window, dynamically adjust the traffic weight, realize the migration of traffic between gateway A and gateway B. When the traffic on the gateway is zero, dynamically update the gateway routing rules, dynamically update gateway A to the gray version transition routing rule AB, and update gateway B to the stable version transition routing rule AB, and enter the gray release smooth transition stage.

[0011] 3) After the smooth transition of canary release begins, enter the canary release window according to the window selection strategy. By dynamically adjusting the traffic weight, traffic is transferred from the stable service to the canary service. Start the rollback event listener. If the rollback event is detected, enter the canary release rollback stage.

[0012] 4) The smooth transition period of the canary release ends, no rollback event is detected, and the canary release enters the formal stage.

[0013] As an optimized solution of this invention, during the rollback phase of a canary release, before entering the canary release window, dynamic traffic migration is immediately performed. All traffic on gateway A is transferred to gateway B, and all client requests are routed to the stable service. At the same time, the routing rules of gateway A are dynamically updated to the stable version. Following a time-priority strategy, the system selects and waits to enter the canary release window. After another dynamic traffic migration, all traffic on gateway B is migrated to gateway A, and the routing rules of gateway B are dynamically updated to the stable version. Finally, dynamic traffic migration is performed, achieving traffic balance on gateway A and gateway B. The gateway routing rule configuration is updated, the rollback event log is recorded, and the canary release fails.

[0014] As an optimized solution of the present invention, the calculation of the grayscale release window sequence includes:

[0015] Calculate the publishing window width: Query the API call log sample data to obtain the maximum response time Tresp_max_ms that meets the requirements of HTTP response status code 200 and URI is service A or B. Round it to get Tresp_max_s. The smallest integer that is greater than or equal to Tresp_max_s*2 and can be divided by 24*3600 is taken as the publishing window width Twindow.

[0016] Define the window calculation unit: start time start_time, end time end_time, average response time rt, total throughput Qps = gateway A throughput Qpsa + gateway B throughput Qpsb, through throughput Qpsz_pass = gateway A through throughput Qpsa_pass + gateway B through throughput Qpsb_pass, rejection throughput Qps_block = gateway A rejection throughput Qpsa_block + gateway B rejection throughput Qpsb_block, success throughput Qps_succ = gateway A success throughput Qpsa_succ + gateway B success throughput Qpsb_succ, exception throughput Qps_exception = gateway A exception throughput Qpsa_exception + gateway B exception throughput Qpsb_exception, success rate succ_rate = Qps_succ / Qps;

[0017] Define the publishing window unit: start time, end time, average response time, and whether the publishing window is secure;

[0018] Based on API call log sample data, starting from zero, the window is positioned according to the sliding step size and window width, and the throughput (total throughput Qps, through throughput Qpsz_pass, etc.) is statistically analyzed within the time period of the window calculation unit. The success rate and average response time are then calculated.

[0019] For each window calculation unit that completes the time priority factor (time_priority_factor), the window calculation unit with the highest success rate is added to the grayscale release window sequence.

[0020] As an optimization of the present invention, calculating traffic migration weights includes:

[0021] Get the maximum throughput Qps_max. If Qps_max is greater than the traffic migration weight, then the traffic migration weight = Qps_max.

[0022] Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway A is Qpsa_max. If Qpsa_max is greater than the maximum safe throughput of gateway A window, then the maximum safe throughput of gateway A window = Qpsa_max.

[0023] Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway B is Qpsb_max. If Qpsb_max is greater than the maximum safe throughput of gateway B window, then the maximum safe throughput of gateway B window = Qpsb_max.

[0024] Traverse the grayscale release window sequence, and set the window with a total throughput (Qps) not greater than the maximum safe throughput of gateway A and gateway B windows as a safe release window;

[0025] Traffic migration weight = traffic migration weight + integer, which is the smallest integer that makes the traffic migration weight an even multiple of the smoothness of the gray release. The even multiple is to achieve an even distribution of traffic during the transition period.

[0026] As an optimized solution of the present invention, the window selection strategy includes: time priority and security priority;

[0027] Time-priority strategy: Iterate through the sequence of grayscale release windows, and select the window whose start time is greater than the current time and whose average response time plus the time from the current time is the smallest.

[0028] Security-first strategy: Traverse the sequence of grayscale release windows, select the window whose start time is greater than the current time, has the shortest time remaining from the current time, and is marked as a safe release window.

[0029] As an optimization of the present invention, the load balancer configuration file is edited, the weight of gateway A is set to traffic migration weight, the weight of gateway B is set to 1, and then the file is dynamically loaded.

[0030] The API gateway defines a global filter for online HTTP requests and monitors the Redis online HTTP request cache. When a new HTTP request arrives at the API gateway, it is stored in the online HTTP request cache. When the HTTP response is returned, the HTTP request is deleted from the online HTTP request cache. When the online HTTP request cache is empty, the traffic migration from gateway B to gateway A is complete. The same logic applies to the migration of traffic from gateway A to gateway B.

[0031] As an optimized solution of the present invention, after dynamic traffic migration, all traffic from gateway B is migrated to gateway A, including:

[0032] Nginx load balancing uses a weighted approach. Only the weight values ​​of gateways A and B in the load balancer configuration file need to be modified. When all traffic is migrated from gateway B to gateway A, the load balancer configuration file is edited to set the weight of gateway A to the traffic migration weight and the weight of gateway B to 1. Then the file is dynamically loaded.

[0033] The API gateway defines a global filter for online HTTP requests and monitors the Redis online HTTP request cache. When a new HTTP request arrives at the API gateway, it is stored in the online HTTP request cache. When the HTTP response is returned, the HTTP request is deleted from the online HTTP request cache. When the online HTTP request cache is empty, the traffic migration from gateway B to gateway A is complete.

[0034] As an optimization of the present invention, gateway routing rules are categorized by version and applicable gateway as follows:

[0035] Stable routing rule A and gray-scale routing rule A are only applicable to gateway A; stable routing rule B and gray-scale routing rule B are only applicable to gateway B; transitional routing rules are applicable to both gateway A and gateway B, including stable transitional routing rule AB and gray-scale transitional routing rule AB.

[0036] Configure the gateway for transitional routing rules AB. HTTP requests arriving at the gateway will be evenly routed to services A and B. Before starting the canary release service, the gateway routing rules are loaded into the Redis cache.

[0037] As an optimization of this invention, dynamically updating gateway routing rules includes: after the canary release configuration management module completes the routing rule configuration, it saves it in the database routing rule table. The main fields are: gateway name, service ID, URI, assertion, filter, version number, and version status. Before starting canary release, the canary version routing rules and the stable version routing rules are loaded into the Redis cache. After the canary release module starts, it sends an update routing rule message to the API gateway through a message mechanism according to the current canary release stage. The API gateway retrieves the routing rules from the corresponding Redis cache according to the routing rule version number and routing rule type in the message and dynamically updates them to the API gateway memory.

[0038] As an optimized solution of the present invention, upon entering the canary release smooth transition phase, the stable service is gradually and smoothly transitioned to the canary service according to the canary release smoothness parameter (set). This includes: when entering the canary release smooth transition period, the current traffic weight of gateway A is the initial value of 1, and the current traffic weight of gateway B is the traffic migration weight; after each canary release smooth transition period, the traffic weights of gateways A and B on the load balancing component are dynamically updated, with the current traffic weight of gateway B = current traffic weight of gateway B - canary release smoothness, and the current traffic weight of gateway A = traffic migration weight - current traffic weight of gateway B; when the current traffic weight of gateway B = 0, the current traffic weight of gateway B is set to 1, and the current traffic weight of gateway A is set to the traffic migration weight.

[0039] To achieve the objectives of this invention, the technical solution adopted is: a system based on an API dual-route gateway canary deployment microservice method, comprising gateway A, gateway B, load balancer, Redis memory cache, microservice monitoring component, canary deployment configuration management module, and canary deployment module; gateway A and gateway B are both API gateways;

[0040] By dynamically adjusting the traffic weights of the load balancer, traffic can be migrated between gateway A and gateway B.

[0041] Microservice monitoring component: Performs traffic control, service degradation and hotspot rule configuration on API gateway, and persists the configuration rules and runtime monitoring data to the database;

[0042] Redis memory cache includes: a routing rule cache for dynamic route updates by the gateway, a canary release configuration cache for the canary release module, an online request monitoring cache for traffic migration, and a log cache for rollback event listening and batch database insertion.

[0043] Canary Deployment Configuration Management Module: Used to configure routing rules and canary deployment module runtime parameters;

[0044] The canary release module, based on Redis caching and through its messaging mechanism, collaborates with the remaining modules to complete the four phases of canary release: release preparation phase, smooth transition phase, release rollback phase, and formal release phase.

[0045] This invention has the following positive effects: 1) This invention uses a sliding window algorithm to calculate the canary release window, focusing on recent system operation log data. The window size depends on the longest API call waiting time. Calculations are made using window calculation unit parameters, with the maximum window throughput used as the traffic transfer weight. Windows whose throughput is simultaneously less than the maximum safe throughput of gateways A and B are selected as safe release windows. This flexible release window selection strategy considers both the security and stability of the system during canary releases and emergency situations during canary releases, reducing the risk of slow user request response or even system crashes due to overload.

[0046] 2) This invention adopts a dynamic gateway routing and dynamic traffic migration mechanism, which can complete the loading and activation of configuration in milliseconds without restarting the gateway and load balancer, avoiding abnormal interruptions. The operation and maintenance personnel only need to complete the configuration of routing rules and canary release parameters in the canary release configuration module interface, and the remaining work is automatically completed by the canary release module. It is simple, safe, efficient, and cost-effective.

[0047] 3) This invention provides a method for online smooth upgrade of microservices. The canary release process is highly automated, simple, convenient, safe and reliable, and the user is unaware of the release process, thus improving the user experience. Attached Figure Description

[0048] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0049] Figure 1 This is a system architecture diagram illustrating the grayscale release implementation of an embodiment of the present invention;

[0050] Figure 2This is a functional structure diagram of the grayscale publishing module according to an embodiment of the present invention;

[0051] Figure 3 This is a schematic diagram of the overall process of an embodiment of the present invention;

[0052] Figure 4 This is a schematic diagram of the four-stage process of grayscale deployment according to an embodiment of the present invention;

[0053] Figure 5 This is a schematic diagram illustrating traffic migration and routing rule changes during the canary deployment process according to an embodiment of the present invention;

[0054] Figure 6 This is a schematic diagram of inter-module messages in an embodiment of this application. Detailed Implementation

[0055] In order to better understand the above-mentioned objectives, features and advantages of the present invention, the following will provide a clear and complete description of the concept, specific structure and technical effects of the present invention in conjunction with the embodiments and accompanying drawings.

[0056] like Figure 1 As shown in the figure, the present invention discloses a microservice system based on API dual-route gateway canary deployment. As can be seen from the figure, the system consists of two identical API gateways and backend microservices. It adopts dual API gateways and dual service redundancy hot backup deployment, and the load traffic is evenly distributed to the two services. Its purpose is to achieve redundancy hot backup and enhance the stability and reliability of the system.

[0057] like Figure 2 The diagram shown is a functional architecture diagram of the invention's API-based dual-routing gateway canary deployment microservice system. The functions of each module in the diagram are explained in detail below:

[0058] 1) The load balancer uses Nginx, and the load balancing uses a weighted approach. During normal system operation, the API gateways have the same weight. When traffic is migrated, the weight of one gateway is reset to 1 (the minimum weight of Nginx), and the weight of the other gateway is reset to the traffic migration weight.

[0059] 2) The microservice monitoring component Sentinel-Dashboard performs flow control, degradation and hotspot rule configuration on the API gateway, completes the protection of backend microservice resources, and persists the configuration rules and monitoring data to the database;

[0060] 3) The memory cache uses Redis, the routing rule cache is used for the gateway to dynamically update routes, the canary release configuration cache is used for the canary release module, the online request monitoring area is used for traffic migration, the log cache is used for rollback event listening and batch storage, and Redis's publish-subscribe messaging mechanism is used for sending messages between modules.

[0061] 4) The canary release configuration management module is used to configure routing rules and canary release module running parameters. The configuration data is stored in the database. Before sending the start canary release message, the configuration data is loaded into the Redis cache. At the same time, the logs in the Redis cache are analyzed for anomalies and saved to the database.

[0062] 5) The API gateway uses the open-source Spring Cloud Gateway, including API Gateway A and API Gateway B. It handles HTTP request logs with normal responses (HttpStatus=200) by inheriting the global filter GlobalFilter, and integrates with Redis for online HTTP request monitoring. The Gateway's global exception handler (implemented through the ErrorWebExceptionHandler interface) handles HTTP request logs with abnormal responses (HttpStatus not equal to 200). A custom rate-limiting handler (implemented by implementing the BlockRequestHandler interface of the Sentinel package and utilizing GatewayCallbackManager) handles rate-limited HTTP request logs, defining a response status value greater than 600 and a response duration of 0. Unrate-limited HTTP requests first reach the API authentication filter, adding a UUID parameter to the request header as a unique identifier for each HTTP request log. Routing rules are dynamically loaded through the RouteDefinitionRepository interface.

[0063] 6) For example Figure 6 As shown, the canary release module, based on Redis caching, collaborates with other modules through its messaging mechanism to complete the four phases of canary release: release preparation phase, smooth transition phase, release rollback phase, and formal release phase.

[0064] Upon entering the release window, the traffic migration between the two gateways is completed by dynamically adjusting the load balancer traffic weight and the online HTTP request cache. When the gateway traffic drops to zero, the gateway routing rules are dynamically updated. During the smooth transition phase, transitional routing rules are used and rollback event listening is started. Once a rollback event occurs, the service is immediately rolled back to a stable service. If the smooth transition phase ends without a rollback event, the canary routing rules are officially released, and the canary release is successful.

[0065] like Figure 3 and Figure 4 As shown, the four-stage canary release process includes the following steps:

[0066] S01, Configure canary release parameters: Canary release configuration data is stored in MySQL. Create the following database tables in the database:

[0067] The routing rule table has the following fields: route ID, service ID, gateway name, URI, assertion rule, filter rule, version number, and version status (STABLE - stable version, DISABLE - historical version, UPDATE - canary release version).

[0068] Assertion rule table, fields: route ID, match request header, match path, match method, match URI parameter, match COOKIE, other common operations;

[0069] Filter rule table, fields: route ID, request / response header operation, path rewrite, redirection, path prefix operation, other common operations;

[0070] Gateway table, fields: publication number, gateway category (A or B), gateway name, IP, port, URI, traffic weight (initial value 1), routing rule type, maximum safe throughput for the window (default value 0).

[0071] The canary release table has the following fields: release sequence number, log collection period, canary release start time, canary release smoothness, canary release transition period, stable version of routing rules (stable version routing rules), canary version of routing rules (canary version routing rules), and canary release window selection strategy (window selection strategy): time priority or security priority; time priority factor, traffic migration weight (default value 0).

[0072] The smoothness of a canary release is a set value used during the canary release transition phase. For example, if the smoothness is set to 5, the traffic migration weight is calculated as 93, and 93 + 7 equals the final traffic migration weight of 100. During the canary release transition, after 10 traffic migrations, the weights of gateways A and B are both 50. At this point, the load on the stable and canary services is the same, allowing for real-time comparison of the performance of the old and new services. After 20 traffic migrations, the stable service has fully transitioned to the canary version. If the smoothness is set to 10, the transition time will be halved, demonstrating that a smaller smoothness value results in a smoother transition.

[0073] Each time an assertion rule table or filter rule table is added, deleted, modified, or saved, the fields in the updated record are assembled into a JSON string, and the assertion rule and filter rule fields in the routing rule table are synchronously updated through the associated field, route ID.

[0074] After the canary release configuration management module completes the above data configuration, it loads the data into the Redis cache before starting the canary release, and then sends a message through the Redis message mechanism to start the canary release service.

[0075] S02. After receiving the start message, the canary release module waits for the canary release start time to enter the release preparation stage. Based on the log collection time period parameter, it exports the recent dataset of the system API call log table and imports it into the log sample table Sample_Logs. The fields include: gateway name, URI (resource name), API call start time and end time (accurate to the second), request URL, response status HttpStatus, and response duration (unit: ms).

[0076] Configure the routing rules required for the canary release API gateway. Rule attributes include: service ID, gateway name, URI, assertion rules, filter rules, version number, and version status.

[0077] Configure dual gateways API Gateway A and API Gateway B: gateway name, IP address, port, URI, current traffic weight, current routing rule type, and maximum safe throughput for the window.

[0078] Configure canary release parameters: release sequence number, log collection period, canary release start time, canary release smoothness, canary release transition period, stable version of routing rules, canary version of routing rules, canary release window selection strategy: time priority or security priority, time priority factor, traffic migration weight (initial value 0).

[0079] S03, Calculate the gray-scale release window sequence and traffic migration weight based on sample data. Calculation process:

[0080] 1) Calculate the width of the publishing window;

[0081] Query the log sample table to obtain the maximum response time Tresp_max_ms (milliseconds) that satisfies the HTTP response status of 200 and the URI is service A or B. Divide Tresp_max_ms by 1000 and round up to get Tresp_max_s (seconds). Take the smallest integer that is greater than or equal to Tresp_max_s*2 and is divisible by 24*3600 as the window width Twindow.

[0082] 2) Window Compute Unit, type WindowComputeUnit struct {

[0083] start_time start time

[0084] end_time (End Time)

[0085] rt (average response time)

[0086] Total Qps throughput

[0087] Qpsa Gateway A Throughput

[0088] Qpsb gateway B throughput

[0089] Qps_pass throughput

[0090] Qpsa_pass gateway A via throughput

[0091] Qpsb_pass gateway B via throughput

[0092] Qps_block rejection throughput

[0093] Qpsa_block gateway A rejects throughput

[0094] Qpsb_block gateway B rejects throughput

[0095] Qps_succ success throughput

[0096] Qpsa_succ gateway A successful throughput

[0097] Qpsa_succ gateway B successful throughput

[0098] Qps_exception abnormal throughput

[0099] Qpsa_exception Gateway A abnormal throughput

[0100] Qpsb_exception Gateway B abnormal throughput

[0101] succ_rate success rate

[0102] }

[0103] The start and end times of the window calculation unit are determined based on the start time, sliding step size and sliding window width. The throughput of each statistical window calculation unit within the time period is queried in the log sample table.

[0104] Qps = Select sum(*) from Sample_Logs where API call start time>= start_time and API call start time<= end_time;

[0105] Qpsa = Select sum(*) from Sample_Logs where API call start time >= start_time and API call start time <= end_time and Gateway name = name of gateway A;

[0106] Qpsb = Qps - Qpsa;

[0107] Qps_block = Select sum(*) from Sample_Logs where API call start time >= start_time and API call start time <= end_time and HttpStatus > 600;

[0108] Qpsa_block = Select sum(*) from Sample_Logs where API call start time >= start_time and API call start time <= end_time and HttpStatus > 600 and Gateway name = Name of Gateway A;

[0109] Qpsb_block = Qps_block - Qpsa_block;

[0110] Qps_succ = Select sum(*) from Sample_Logs where API call start time >= start_time and API call start time <= end_time and HttpStatus = 200;

[0111] Qpsa_succ = Select sum(*) from Sample_Logs where API call start time >= start_time and API call start time <= end_time and HttpStatus = 200 and gateway name = name of gateway A;

[0112] Qpsb_succ = Qps_succ - Qpsa_succ;

[0113] Qps_pass = Qps - Qps_block;

[0114] Qps_exception = Qps_pass - Qps_succ;

[0115] Success rate succ_rate = Qps_succ / Qps (when Qps=0, succ_rate=1);

[0116] Total response time = Select sum(rt) from Sample_Logs where API call start time >= start_time and API call start time <= end_time;

[0117] Average response time = Total response time / Qps;

[0118] 3) Calculate traffic migration weights and generate a candidate list for canary release windows.

[0119] Define a grayscale release window unit, type WindowReleaseUnit struct {

[0120] start_time start time

[0121] end_time (End Time)

[0122] rt (average response time)

[0123] Is safeWin a secure window publishing method?

[0124] }

[0125] Starting from zero, after each window of time_priority_factor calculation is completed, the following operations are performed:

[0126] Add the window calculation unit with the highest success rate to the release window candidate list (grayscale release window sequence);

[0127] Get the maximum throughput Qps_max. If Qps_max is greater than the traffic migration weight, then the traffic migration weight = Qps_max.

[0128] Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway A is Qpsa_max. If Qpsa_max is greater than the maximum safe throughput of gateway A window, then the maximum safe throughput of gateway A window = Qpsa_max.

[0129] Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway B is Qpsb_max. If Qpsb_max is greater than the maximum safe throughput of gateway B window, then the maximum safe throughput of gateway B window = Qpsb_max.

[0130] Repeat the above steps until the sliding window terminates at a time greater than 23:59:59.

[0131] 4) Calculate traffic migration weights and generate a candidate list for canary release windows;

[0132] Iterate through the list of candidate publishing windows, and set the window with a total throughput (Qps) not greater than the maximum secure throughput of windows A and B of gateways as the secure publishing window;

[0133] Traffic migration weight = traffic migration weight + integer, which is the smallest integer that makes the traffic migration weight an even multiple of the smoothness of the gray-scale release.

[0134] S11, the canary release enters the smooth transition phase. According to the window selection strategy, the canary release window is entered, and all traffic is migrated to gateway A. The routing rules of gateway B are updated to the stable transition routing rules AB, so that all HTTP requests arriving at gateway B are evenly routed to stable services A and B.

[0135] The window selection strategies include: time priority and security priority.

[0136] Time-priority strategy: Iterate through the list of candidate windows for gray-scale release, and select the window whose start time is greater than the current time and whose average response time plus the time since the current time is the smallest;

[0137] Security-first strategy: Iterate through the list of candidate windows for grayscale release, select the window whose start time is greater than the current time, has the shortest time remaining since the current time, and is marked as a safe release window.

[0138] like Figure 5 The routing rule type applicable to gateway A can be A or AB, and the routing rule type applicable to gateway B can be B or AB. Type AB is used as a smooth transition routing rule.

[0139] Routing rules are categorized by version (stable and gray-scale) and by route (A, B, and AB). Gateway A can be configured with either routing rule A or AB, and gateway B can be configured with either routing rule B or AB. If the gateway is configured with routing rule A, all HTTP requests arriving at the gateway will be routed to service A; if the gateway is configured with routing rule B, all HTTP requests arriving at the gateway will be routed to service B; if the gateway is configured with routing rule AB, HTTP requests arriving at the gateway can be routed to either service A or service B.

[0140] The process of dynamically updating gateway routing rules is as follows:

[0141] 1) Create a hash key-value structure in Redis cache as a routing rule cache area. The key structure is: route type: route version. The field uses the route ID, and the value uses the relevant fields in the routing rule table to form a JSON string. Thus, the routing rule cache has: RR01-A:Stable-Version, RR02-B:Stable-Version, RR03-AB:Stable-Version, RR04-A:Gray-Version, RR05-B:Gray-Version, RR06-AB:Gray-Version;

[0142] 2) Using Redis publish-subscribe mode, the canary publishing module acts as the publisher to send message updates to routing rules. The message body format is: LRR:RR01:gateway name. When the gateway receives the message as a subscriber, it matches the message body with its own gateway name. If the match is successful, the routing rules are updated, and the corresponding routing rule cache is obtained by parsing the message body.

[0143] 3) The gateway reads the value-routing rule JSON string from all fields in the HashMap of the Redis routing rule cache. After parsing the JSON, it constructs a RouteDefinition object and then dynamically updates the RouteDefinition object to the gateway memory by implementing the Delete and Save methods in the RouteDefinitionRepository interface.

[0144] Before dynamically updating gateway routing rules, traffic migration must be performed, and the process is as follows:

[0145] 1) Using Nginx reverse proxy gateways A and B, the load balancing algorithm uses weights, as follows: upstreambackend {

[0146] server gateway-a-address:port weight=1;

[0147] server gateway-b-address:port weight=1;

[0148] }

[0149] Write a Linux script file, use tools SED / AWK and regular expressions to modify the weights of gateways A and B in the Nginx configuration file, test the configuration file using the nginx-t command before dynamically loading the configuration file, and test the dynamic loading of the configuration file using the nginx-s reload command.

[0150] 2) If all traffic is migrated to the Nginx configuration of gateway B, the following configuration will be used:

[0151] upstream backend {

[0152] server gateway-a-address:port weight=1;

[0153] server gateway-b-address:port weight=w;

[0154] }

[0155] W: Traffic migration weight, ensuring that all new HTTP requests within the canary release window are routed to gateway B. After dynamically loading the Nginx configuration file, it starts listening to the Redis online HTTP request cache. The process is as follows:

[0156] 1) Create online HTTP request caches for gateways A and B using Redis List type, with KEY: cache-online-a and cache-online-b, and VALUE: {uuid, start time, end time, gateway name, URL, URI, requestMethod, HttpStatus, HttpSchema, duration};

[0157] 2) HTTP requests subject to rate limiting have a start time equal to their end time and a duration of zero; these are directly added to the online HTTP request cache. HTTP requests not subject to rate limiting first reach the API authentication and authorization global filter. Upon successful authentication, a UUID is added to the request header, and the request is forwarded to other filters. HTTP requests then reach the log global filter. The HTTP request header retrieves the parameters UUID, requestMethod, URL, URI, and HTTPSchema. The start time is set to the current time, the end time to the current time plus the maximum response time, the HttpStatus is set to zero, and the duration is set to the maximum response time. These requests are then added to the online HTTP request cache. HTTP requests that fail authentication have a start time equal to the end time, a duration of zero, and an HttpStatus of 700; these requests are directly added to the online HTTP request cache.

[0158] 3) HTTP requests that fail rate limiting or authentication are added to the online HTTP request cache and immediately a log message is sent to the canary release configuration management module for processing. HTTP requests that return a normal response body are added to the detailed log cache with the UUID and response body, and the HttpStatus, termination time, and duration in the online HTTP request cache are updated. A log message is then sent to the canary release configuration management module for processing. HTTP requests that encounter errors are handled by the gateway's global error handling filter, and after updating the online HTTP request cache, a log message is sent to the canary release configuration management module for processing.

[0159] 4) When the canary release configuration management module receives the log message, it iterates through the corresponding online HTTP request Redis cache queue according to the gateway category in the message, retrieves HTTP request logs with HttpStatus not equal to zero in batches and clears them from the cache. If the HTTP request Redis cache queue is empty at this time, it sends a traffic migration success message to notify the canary release module. The online HTTP request cache logs are stored in MySQL, and the detailed logs are stored in MongoDB.

[0160] S12, then migrate all traffic to gateway B, update the routing rules of gateway A to the gray-scale transitional routing rules AB, so that all HTTP requests arriving at gateway A are evenly routed to gray-scale services A and B, and start the rollback event listener.

[0161] S13, gradually reduce the traffic weight of gateway B and increase the traffic weight of gateway A until all traffic reaches gateway A, so that API call requests are gradually transferred to the canary service. The process is as follows:

[0162] When entering the smooth transition period of canary release, the current traffic weight of gateway A is the initial value of 1, and the current traffic weight of gateway B is the traffic migration weight.

[0163] After each gray-scale release transition period, the traffic weights of gateways A and B on the load balancing component are dynamically updated. The current traffic weight of gateway B = the current traffic weight of gateway B - the gray-scale release smoothness, and the current traffic weight of gateway A = the traffic migration weight - the current traffic weight of gateway B.

[0164] When the current traffic weight of gateway B is 0, set the current traffic weight of gateway B to 1, and the current traffic weight of gateway A to the traffic migration weight. At this time, all traffic is transferred to the gray-scale service.

[0165] The rollback event listener includes:

[0166] System error: The API gateway global exception handler caught the HTTP 5XX response status, which indicated that the server could not complete the client request;

[0167] Logical error: Analyze the error code in the HTTP response body and return the error message;

[0168] Performance degradation: During the canary release transition period, when gateways A and B have equal weights, statistically analyze whether the ratio of rate limiting and degradation occurrences in the logs of gateways A and B during this phase is significant. The rollback event listening process is as follows:

[0169] Before the smooth transition, all HTTP requests arrive at gateway B and are routed to stable services A and B. The canary release module sends a rollback event listener message to notify the canary release configuration management module to perform anomaly analysis on the API call logs on gateway A.

[0170] The canary release configuration management module begins to analyze the online HTTP request cache-online-a. For example, if an error such as HttpStatus=503 is detected, a rollback message is immediately sent to notify the canary release module to perform a rollback operation.

[0171] For responses with HttpStatus=200 that return normally, further analysis of the response body logs reveals logical errors.

[0172] Once the canary release module receives a rollback message, it sends a stop rollback event listener message to the canary release configuration management module, thus entering the canary release rollback phase. The canary release rollback phase includes:

[0173] S31, before entering the release window, immediately performs dynamic traffic migration, transferring all traffic on gateway A to gateway B, routing all client HTTP requests to the stable service, and dynamically updating the routing rules of gateway A to the stable version.

[0174] S32 selects and waits to enter the gray-scale release window according to the time priority strategy. After dynamic traffic migration, all traffic of gateway B is migrated to gateway A. The routing rules of gateway B are dynamically updated to the stable version. Dynamic traffic migration is performed again, and traffic is evenly distributed to gateway A and B.

[0175] S33, Update database gateway routing rule configuration, change rule version grayscale status to unavailable status, record rollback event log, grayscale release failed.

[0176] Before the smooth transition of canary release ends, if the canary release module has not received a rollback message, it will send a stop rollback event listener message to the canary release configuration management module, thus entering the formal phase of canary release. The process includes:

[0177] S21, based on the window selection strategy, wait to enter the gray release window, all traffic is migrated to gateway B, gateway A's routing rules are updated to the gray version, so that all requests arriving at gateway A are routed to gray service A;

[0178] S22, then migrate all traffic to gateway A, and update the routing rules of gateway B to the gray version, so that all requests arriving at gateway B are routed to gray service B;

[0179] S23, restore the traffic weights of gateways A and B to the initial value of 1, and the HTTP request traffic is evenly distributed to gateways A and B;

[0180] S24, Update the database gateway routing rule configuration, change the routing rule version from stable to historical, change the gray-scale status to stable, clear the Redis cache data, and the gray-scale release is successful.

[0181] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for canary deployment of microservices based on API dual-routing gateway, characterized in that, The method includes: 1) Calculate the canary release window sequence and traffic migration weight based on the collected API call log sample data; 2) Enter the gray release window, dynamically adjust the traffic weight, realize the migration of traffic between gateway A and gateway B. When the traffic on the gateway is zero, dynamically update the gateway routing rules, dynamically update gateway A to the gray version transition routing rule AB, and update gateway B to the stable version transition routing rule AB, and enter the gray release smooth transition stage. 3) After the smooth transition of canary release begins, enter the canary release window according to the window selection strategy. By dynamically adjusting the traffic weight, traffic is transferred from the stable service to the canary service. Start the rollback event listener. If the rollback event is detected, enter the canary release rollback stage. 4) The smooth transition period of the canary release ends, no rollback event is detected, and the canary release enters the formal stage; During the rollback phase of a canary release, before entering the canary release window, dynamic traffic migration is immediately performed. All traffic on gateway A is transferred to gateway B, and all client requests are routed to the stable service. At the same time, the routing rules on gateway A are dynamically updated to the stable version. Then, following a time-priority strategy, the system selects and waits to enter the canary release window. After another dynamic traffic migration, all traffic on gateway B is migrated to gateway A, and the routing rules on gateway B are dynamically updated to the stable version. Finally, dynamic traffic migration is performed to achieve traffic balance between gateway A and gateway B. The gateway routing rule configuration is updated, the rollback event log is recorded, and the canary release fails. Calculating traffic migration weights includes: Get the maximum throughput Qps_max. If Qps_max is greater than the traffic migration weight, then the traffic migration weight = Qps_max. Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway A is Qpsa_max. If Qpsa_max is greater than the maximum safe throughput of gateway A window, then the maximum safe throughput of gateway A window = Qpsa_max. Among all window calculation units where the success rate succ_rate=1, the maximum throughput of gateway B is Qpsb_max. If Qpsb_max is greater than the maximum safe throughput of gateway B window, then the maximum safe throughput of gateway B window = Qpsb_max. Traverse the grayscale release window sequence, and set the window with a total throughput (Qps) not greater than the maximum safe throughput of gateway A and gateway B windows as a safe release window; Traffic migration weight = traffic migration weight + integer, which is the smallest integer that makes the traffic migration weight an even multiple of the smoothness of the gray-scale release.

2. The method for canary deployment of microservices based on API dual-routing gateway according to claim 1, characterized in that, The calculation of the grayscale release window sequence includes: Calculate the publishing window width: Query the API call log sample data to obtain the maximum response time Tresp_max_ms that meets the requirements of HTTP response status code 200 and URI is service A or B. Round it to get Tresp_max_s. The smallest integer that is greater than or equal to Tresp_max_s*2 and can be divided by 24*3600 is taken as the publishing window width Twindow. Define the publishing window calculation unit: start time start_time, end time end_time, average response time rt, total throughput Qps = gateway A throughput Qpsa + gateway B throughput Qpsb, through throughput Qpsz_pass = gateway A through throughput Qpsa_pass + gateway B through throughput Qpsb_pass, rejection throughput Qps_block = gateway A rejection throughput Qpsa_block + gateway B rejection throughput Qpsb_block, success throughput Qps_succ = gateway A success throughput Qpsa_succ + gateway B success throughput Qpsb_succ, exception throughput Qps_exception = gateway A exception throughput Qpsa_exception + gateway B exception throughput Qpsb_exception, success rate succ_rate = Qps_succ / Qps; Define the publishing window unit: start time, end time, average response time, and whether the publishing window is secure; Based on API call log sample data, starting from zero, the window is positioned according to the sliding step size and the publishing window width, and the throughput of each time period within the window calculation unit is statistically analyzed. The success rate and average response time are then calculated. For each window calculation unit that completes the time priority factor (time_priority_factor), the window calculation unit with the highest success rate is added to the grayscale release window sequence.

3. The method for canary deployment of microservices based on API dual-routing gateway according to claim 2, characterized in that, Window selection strategies include: time priority and security priority; Time-priority strategy: Iterate through the sequence of grayscale release windows, and select the window whose start time is greater than the current time and whose average response time plus the time from the current time is the smallest. Security-first strategy: Traverse the sequence of grayscale release windows, select the window whose start time is greater than the current time, has the shortest time remaining from the current time, and is marked as a safe release window.

4. The method for canary deployment of microservices based on API dual-routing gateway according to claim 3, characterized in that, After dynamic traffic migration, all traffic from gateway B is migrated to gateway A, including: Edit the load balancer configuration file, set the weight of gateway A to traffic migration weight, set the weight of gateway B to 1, and then dynamically load the file; The API gateway defines a global filter for online HTTP requests and monitors the Redis online HTTP request cache. When a new HTTP request arrives at the API gateway, it is stored in the online HTTP request cache. When the HTTP response is returned, the HTTP request is deleted from the online HTTP request cache. When the online HTTP request cache is empty, the traffic migration from gateway B to gateway A is complete.

5. The method for canary deployment of microservices based on API dual-routing gateway according to claim 4, characterized in that, The gateway routing rules are categorized by version and applicable gateway: Stable routing rule A and gray-scale routing rule A are only applicable to gateway A; stable routing rule B and gray-scale routing rule B are only applicable to gateway B; transitional routing rules are applicable to both gateway A and gateway B, including stable transitional routing rule AB and gray-scale transitional routing rule AB. Configure the gateway for transitional routing rules AB. HTTP requests arriving at the gateway will be evenly routed to services A and B. Before starting the canary release service, the gateway routing rules are loaded into the Redis cache.

6. The method for canary deployment of microservices based on API dual-routing gateway according to claim 5, characterized in that, Dynamically update gateway routing rules, including: After the routing rules are configured, they are saved in the database routing rule table. The main fields are: gateway name, service ID, URI, assertion, filter, version number and version status. Depending on the canary release stage, update routing rule messages are sent to the API gateway through a message mechanism. The API gateway retrieves the routing rules from the corresponding Redis cache based on the routing rule version number and routing rule type in the message and dynamically updates them to the API gateway memory.

7. A method for canary deployment of microservices based on API dual-routing gateway according to claim 6, characterized in that, Entering the smooth transition phase of canary release, the stable service is gradually and smoothly transitioned to canary service based on the canary release smoothness parameters. This includes: when entering the canary release smooth transition period, the current traffic weight of gateway A is the initial value of 1, and the current traffic weight of gateway B is the traffic migration weight; after each canary release smooth transition period, the traffic weights of gateways A and B on the load balancing component are dynamically updated. The current traffic weight of gateway B = the current traffic weight of gateway B - the canary release smoothness, and the current traffic weight of gateway A = the traffic migration weight - the current traffic weight of gateway B; when the current traffic weight of gateway B = 0, the current traffic weight of gateway B is set to 1, and the current traffic weight of gateway A is set to the traffic migration weight.

8. A system employing the API dual-routing gateway canary deployment microservice method as described in claim 1, characterized in that, It includes Gateway A, Gateway B, load balancer, Redis memory cache, microservice monitoring component, canary release configuration management module and canary release module; both Gateway A and Gateway B are API gateways; By dynamically adjusting the traffic weights of the load balancer, traffic can be migrated between gateway A and gateway B. Microservice monitoring component: Performs traffic control, service degradation and hotspot rule configuration for API gateway, and persists the configuration rules and runtime monitoring data to the database; Redis memory cache includes: a routing rule cache for dynamic route updates by the gateway, a canary release configuration cache for the canary release module, an online request monitoring cache for traffic migration, and a log cache for rollback event listening and batch database insertion. Canary Deployment Configuration Management Module: Used to configure routing rules and canary deployment module runtime parameters; The canary release module, based on Redis caching and through its messaging mechanism, collaborates with the remaining modules to complete the four phases of canary release: release preparation phase, smooth transition phase, release rollback phase, and formal release phase.

Images