nginx實現簡單的A B測試（灰度發布）

灰度發布，現在是很多大專案的乙個標配運維特性，我們可以將乙個「新的版本**」發布到集群中的少數幾台（組）機器上，以便引入線上少量真實使用者進行測試，用於驗證產品改進的收益、小規模試錯等。nginx提供了「nginx_http_split_clients_module」、「nginx_stream_split_clients_module」，分別適用於http和tcp，可以幫助我們簡單實現這些功能，不過如果你需要高度自動化、自主化的特性，或許需要進行一定的擴充套件和改造。

split模組在0.8版本就已經有了，使用起來也非常簡單：

split_clients string $variable

此指令的上下文為http。

1、假如，我們的web專案中提供了2個html頁面，其中index_new.html為最新發布頁面，index.html為舊頁面，為了「避免新頁面有bug，而影響全站使用者」、「測試新頁面上體驗改進是否符合預期」，我們將index頁面的訪問流量中的10%**到新頁面上，剩餘90%繼續使用舊頁面。

split_clients "$_1qazxsw2" $variant 
server .html;
}

2、假如，我們的web專案中發布了新的功能，為了避免程式bug導致大規模異常，減少影響面，我們也可以使用spit做「切流量上線」；首先我們需要將線上的機器分為多個group，每個group中可以包含一定數量的server，簡單而言，就是乙個group就是乙個upstream；比如我們30臺機器，我們想切10%的流量發布新版本，那麼就將3臺機器組成乙個「灰度組」來發布新程式，其他機器繼續執行舊的web程式；當灰度組經過多日的觀察，確實沒有太大問題，我們則可以取消灰度組，全量上線發布。

split_clients "$_1qazxsw2" $group upstream gray_group upstream main_group server ;

}

上述配置檔案中，我們可以看到split模組的使用方式，「split_clients」指令接受2個引數，nginx將會根據第乙個引數的值使用murmurhash2演算法計算hashcode，hashcode值域為0~4294967295（即2<<31 - 1），通常第乙個引數是乙個動態值，比如使用者的ip、session_id等。10%是表示乙個區域，如果第乙個引數的hashcode值，在0 ~ 4294967295 *10%之間，則將「_new」賦值給$variant；20%表示第乙個引數的hashcode值，在4294967295 * (10% ~ 20%)區間時....依次輪推，"*"表示上述區間都沒有覆蓋的值域，將使用的值。

我們發現這種方式的灰度發布，其實流量匯入的比例並非嚴格。如果你的服務多次灰度發布，可能會導致某些ip總是在灰度區域，有時候我們需要調整spit第乙個引數的隨機數因子，本例中"$_1qazxsw2"，「_1qazxsw2」這個補充字串就是隨機因子，每次灰度發布，我們需要修改這個值以避免上一次灰度的ip再次進入灰度，當然這個操作也是沒有太大必要。

通常我們還有一些更加苛刻的要求，比如強制要求某個ip、使用者id進入灰度區域。那麼使用spit模組就顯得有些不太適應，要麼使用nginx的geo元件將相應的ip、uid新增到geo檔案中（還需要後端程式在cookie輸入相應的uid值，以便nginx獲取和判斷）。對於這種有很多「個性化」條件的，我們可以使用nginx + lua + redis （memcached）實現，其中lua作為指令碼語言來做條件判斷工具以及使用redis客戶端運算元據，redis用於儲存需要灰度的使用者資訊，此外可能還需要開發乙個後端程式來運營redis中的資料，比如將某個uid加入redis，lua從cookie中讀取uid並檢查redis中是否存在，如果存在則進入灰度區域。

nginx實現簡單的A B測試（灰度發布）

nginx通用優化以及ab測試

使用ab對Nginx進行壓力測試

ab壓力測試工具的簡單使用

nginx實現簡單的A B測試（灰度發布）

nginx通用優化以及ab測試

使用ab對Nginx進行壓力測試

ab壓力測試工具的簡單使用

相關推薦