Nginx implements front-end grayscale release

Preface

In front-end development, grayscale release is an important strategy that allows us to gradually launch new features or updates without affecting all users. Through grayscale release, we can test the stability and performance of the new version while collecting user feedback. Today, we will explore how to use Nginx to achieve grayscale publishing.

1. Weight-based traffic allocation

Weight-based grayscale publishing is one of the most common ways. By adjusting the weight of different versions of services, control the allocation ratio of traffic. For example, suppose our online mall has two versions of payment systems, one is the old version (V1) and the other is the new version (V2). We expect the new version to receive only 20% of request traffic in the initial stage, and the remaining 80% of requests continue to be processed by the old version. The configuration of Nginx can be as follows:

upstream payment_system {
    server  weight=80;
    server  weight=20;
}

In this configuration, 80% of traffic will be directed to the old version of payment system (V1), and 20% of traffic will be directed to the new version of payment system (V2). As the new version gradually stabilizes, we can gradually increase the weight of the new version and eventually switch all traffic to the new version.

2. Cookie-based diversion

Sometimes, we want to decide whether the user is connected to the new version based on their identities. At this time, users-based grayscale publishing can be achieved through browser cookies. For example, we set a cookie in the app called is_gray to mark whether the user participates in the new version of grayscale testing.

server {
    listen 80;
    server_name ;
    location / {
        if ($http_cookie ~* "is_gray=1") {
            proxy_pass ;
        }
        proxy_pass ;
    }
}

In the above configuration, if the user's cookie has a flag of is_gray=1, Nginx will route the user's request to the new version of the service (V2); otherwise, the user's request will continue to access the old version of the service (V1). This approach is suitable for targeted testing and user grouping.

3. Diversion based on request header

We can also implement grayscale publishing based on request headers. For example, it is determined whether to route the request to a grayscale environment based on the user ID in the request. This can be achieved through Nginx's Lua module and Redis.

server {
    listen 80;
    server_name ;
    location / {
        access_by_lua_block {
            local redis = require ""
            local red = redis:new()
            local ok, err = red:connect("redis_host", redis_port)
            if not ok then
                (, "failed to connect to Redis: ", err)
                (500)
            end
            local user_id = .get_headers()["X-User-ID"]
            local is_gray = red:get("gray:" .. user_id)
            if is_gray == "1" then
                 = "gray_backend"
            end
        }
        proxy_pass http://backend;
    }
}

In the example above, we connect to Redis and determine whether to route the request to the grayscale environment based on the user ID in the request. Variables are used to dynamically set up the upstream address, thereby realizing routing in the grayscale environment.

4. Diversion based on request parameters

We can also implement grayscale publishing based on request parameters. For example, it is determined which version to route to based on a parameter value in the request.

server {
    listen 80;
    server_name ;
    location / {
        set $group "default";
        if ($query_string ~* "thirdPolicystatus=1") {
            set $group new_version;
        }
        if ($query_string ~* "thirdPolicystatus=2") {
            set $group old_version;
        }
        proxy_pass http://$group;
    }
}

In the above configuration, we decide which version to route to based on the value of the request parameter thirdPolicystatus. If the parameter value is 1, it will be routed to the new version; if the parameter value is 2, it will be routed to the old version.

Summarize

Through Nginx, we can flexibly implement grayscale releases and control the traffic ratio of new versions, so as to gradually launch new features or updates without affecting all users. I hope this article can help you correctly realize grayscale release in your project and provide users with a better experience.

This is the end of this article about Nginx's front-end grayscale release. For more related content on Nginx's front-end grayscale release, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!