nginx灰度系統

灰度系統簡介

一般軟件開發都不是最終版本交付，而是有一個版本接著一個版本的迭代

新版本上線之前都會經過測試，但就算這樣，也不能保證上線沒有問題

所以，一般上線新版本代碼都是通過灰度系統

灰度系統可以將流量劃分成多份，一份走新版本代碼，一份走老版本代碼

而且灰度系統支持設置流量的比例，比如可以把走新版本代碼的流程設置為5%，沒有問題再放到10%，50%，直到全量

這樣可以把出現問題的影響降到最低

如果直接迭代新版本代碼，出現線上問題，就是大事故

而且灰度系統不止這一個用途，比如產品不確定某些改動是不是有效的，就要做AB實驗，也就是要把流量分成兩份，一份走A版本代碼，一份走B版本代碼

這樣的灰度系統如何實現呢？

其實很多都是用nginx實現的

nginx是一個反向代理的服務，用戶請求發送給它，由他轉發給具體的應用服務器

這一層也叫網關層

由他負責轉發請求給應用服務器，那自然就可以在這里控制流量的分配，哪些流量走版本A，哪些流量走版本B

通過nginx實現灰度系統

首先我們準備兩個版本的代碼：

npx nest new gray_test -p npm

更改下AppService:

然后修改一下運行端口：

將這個項目跑起來：

可以看到，運行在3001端口，返回了Hello World! 1111

再使用相同的方法新建一個項目，但是不修改文件內容

現在我們就有了兩個版本的nest代碼

接下來，使用nginx實現灰度，讓流量分成兩部分，走不同的代碼版本

我們先使用docker跑一個nginx鏡像，設置容器名為gray1，端口映射宿主機的82到容器內的80：

現在訪問本機的82端口就可以看到nginx界面了：

我們修改下nginx的配置文件/etc/nginx/conf.d,添加如下配置：

location ^~ /api {
    rewrite ^/api/(.*)$ /$1 break;
    proxy_pass http://192.168.1.6:3001;
}

這段配置就是加了一個路由，把/api開頭的請求轉發給 http://宿主機IP:3001這個服務，使用了rewrite把url重寫了，比如/api/xxx變成了 /xxx

當我們訪問 http://localhost:83/api/時，請求就被轉發到了3001端口:

現在我們不是直接訪問nest服務了，而是經歷了一層nginx反向代理或者說網關層:

我們可以在nginx這一層實現流量控制

在nginx中配置負載均衡是這樣的：

默認會輪詢把請求發給 upstream下的server;

而現在實現灰度系統則需要多組upstream:

upstream version1.0_server {
    server 192.168.1.6:3001;
}
 
upstream version2.0_server {
    server 192.168.1.6:3002;
}

upstream default {
    server 192.168.1.6:3001;
}

有版本1.0、版本2.0，默認的server。
然后需要根據某個條件來區分轉發給哪個服務

我們這里根據cookie來區分：

set $group "default";
if ($http_cookie ~* "version=1.0"){
    set $group version1.0_server;
}

if ($http_cookie ~* "version=2.0"){
    set $group version2.0_server;
}

location ^~ /api {
    rewrite ^/api/(.*)$ /$1 break;
    proxy_pass http://$group;
}

如果包含 version=1.0 的 cookie，那就走 version1.0_server 的服務，有 version=2.0 的 cookie 就走 version2.0_server 的服務，否則，走默認的。

這樣就實現了流量的劃分，也就是灰度的功能

然后重啟啟動下容器,然后訪問下：

可以看到流量走到了默認版本

然后帶上 version=2.0 的 cookie，走到的就是另一個版本的代碼：

如果帶上的是version=1.0，則訪問的是1.0版本的代碼：

這樣我們就實現了灰度功能

但現在還有一個問題：

什么時候設置這個cookie呢

其實公司內部一般都有灰度配置系統，可以配置不同的版本的比例，然后流量經過這個系統之后，就會返回 Set-Cookie 的 header，里面按照比例來分別設置不同的 cookie。

比如隨機數載 0 到 0.2 之間，就設置 version=2.0 的 cookie，否則，設置 version=1.0 的 cookie。

這也叫做流量染色。

完整的灰度流程是這樣的：

第一次請求的時候，會按照設定的比例隨機對流量染色，也就是設置不同 cookie。

再次訪問的時候會根據 cookie 來走到不同版本的代碼。

其中，后端代碼會根據 cookie 標識來請求不同的服務（或者同一個服務走不同的 if else），前端代碼可以根據 cookie 判斷走哪段邏輯。

這就實現了灰度功能，可以用來做 5% 10% 50% 100% 這樣逐步上線的灰度上線機制。

也可以用來做產品的 AB 實驗。

公司里都會用這樣的灰度系統。