Nginx+KV db怎么進行AB灰度測試

Nginx+KV db怎么進行AB灰度測試，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

之前聽過淘寶用nginx的一些場景，其中AB的灰度測試可能適用場景會比較普遍，當然大會上，并沒有詳細討論實現。

大概需求是： 網站類業務在更新new feature時，并不想讓全量用戶看到，可以針對地區性用戶開放此feature。大概構思了一個方式，使用 nginx+redis/memcache+IP庫實現，簡單的流程圖如下：

當然其中的new feature server和normal server不必要一定得是物理上的服務器，可以是任意邏輯上分開的服務和http URI

所用的模塊是 ngx-lua-module, 以及一個基于ngx-lua寫的lib:  lua-resty-memcached或lua-resty-redis, 這里假設使用memcached作為ip數據的存儲，cache內保存以ip作為key，以true(1)或false(0)作為value的數據，nginx在請求到來時，從cache內以remote_addr(如果是用XFF頭，則對XFF做一次處理后獲取到real ip)作為key從cache內做一次get，判斷此req應該的轉發；

這里有一個問題是：cache內是保存具體的IP形式的方式，還是以CIDR的超網形勢存儲，若直接使用IP作為key，數據量不容小視，而且IP信息的準確度得有一定的保證才行；若使用CIDR的方式，則在nginx端又會增加一次IP轉換CIDR以及對get到的CIDR做比較(具體實現方法還沒想到)， 復雜度會有所增加，個人偏向直接使用IP作為key，只要保證了IP的一定準確性，數據大小問題不大，現在遍地都是32G，64G內存的緩存。

若使用ip作為key，一個折中的辦法是每次進行ABtest的時候，flush緩存，只保存指定地區的ip數據即可，ngx在做get的時候，如果沒有返回，則認為此req是到normal server的.

管理平臺方面，只需要做個簡單的批量set緩存的功能就可以了，至于UI么，就看你給誰用了，自己用嘛，UI丑陋點就丑陋點了

性能和可用性方面：

增加了一次緩存的連接和get操作，理論上此開銷應該是很小的，ngx-lua實現的lua-resty-memcached有不少人做過測試，性能非常可觀.

可用性方面會增加一個當緩存斷線的風險點，通過settimeout，將緩存超時限制到一個較小的時間，影響較小，另外ABtest的方案也不應該常年累月的在線上，只有在有需求時，才需要這套系統吧，因此可用性方面對全局影響應該是較小的，相比新的feature上線時影響全部用戶的風險，這個冒險還是值得的。

上述暫時只是個人的思路，而且也還沒上線使用，實現方面只完成了nginx獲取key來判斷req轉發的驗證。

關于Nginx+KV db怎么進行AB灰度測試問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。