一、前言
近期有一個項目，客戶方要求進行灰度發佈。分析了幾種方案，最終選擇nginx+lua方案。幾種方案各有優缺點，大家根據自己的業務場景選擇即可。
灰度發佈（又名金絲雀發佈）是指在黑與白之間，能夠平滑過渡的一種發佈方式。在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B 上面來。灰度發佈可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
二、實現思路
1、在代碼中進行控制
一套線上環境，代碼中做開關，對於不同的用戶走不同的邏輯。
2、在轉發層做
多套(隔離的)線上環境，接入層針對不同用戶轉發到不同的環境中。當然，如果不嚴格考慮原環境針對用戶的併發問題，可以不使用多套環境。比如原來是4臺機器集群，發佈時只發布一臺，設定規則某些用戶的請求轉發到這一臺，其他的用戶走原來的3臺（當然這對抗併發性是有影響的，要具體情況具體分析）。
兩套方案的優缺點：
在接入層使用的方式，第一是在nginx層實現（使用nginx+lua），第二是在網關層實現（spring-cloud-zuul）。第三是dubbo的灰度，項目中如果使用dubbo，有可能會需要dubbo服務的灰度實現。
我們的場景是要根據用戶，區域等多個緯度進行動態灰度。框架是使用的MVC架構的，所以最終採用nginx+lua方式。而要修改nginx，達到動態灰度，是要用C開發的。所以藉助了第三方庫。下面介紹兩個。
OpenResty：是一個基於 Nginx 與 Lua 的高性能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴展性極高的動態 Web 應用、Web 服務和動態網關
ABTestingGateway：是一個可以動態設置分流策略的灰度發佈系統，工作在7層，基於nginx和ngx-lua開發，使用 redis 作為分流策略數據庫，可以實現動態調度功能。
ABTestingGateway是在 nginx 轉發的框架內，在轉向 upstream 前，根據 用戶請求特徵 和 系統的分流策略 ，查找出目標upstream，進而實現分流。
閱讀更多 正經程序猿90 的文章
