Nginx+KV db怎么進(jìn)行AB灰度測(cè)試

Nginx+KV db怎么進(jìn)行AB灰度測(cè)試，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

之前聽過淘寶用nginx的一些場(chǎng)景，其中AB的灰度測(cè)試可能適用場(chǎng)景會(huì)比較普遍，當(dāng)然大會(huì)上，并沒有詳細(xì)討論實(shí)現(xiàn)。

大概需求是： 網(wǎng)站類業(yè)務(wù)在更新new feature時(shí)，并不想讓全量用戶看到，可以針對(duì)地區(qū)性用戶開放此feature。大概構(gòu)思了一個(gè)方式，使用 nginx+redis/memcache+IP庫實(shí)現(xiàn)，簡(jiǎn)單的流程圖如下：

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

所用的模塊是 ngx-lua-module, 以及一個(gè)基于ngx-lua寫的lib:  lua-resty-memcached或lua-resty-redis, 這里假設(shè)使用memcached作為ip數(shù)據(jù)的存儲(chǔ)，cache內(nèi)保存以ip作為key，以true(1)或false(0)作為value的數(shù)據(jù)，nginx在請(qǐng)求到來時(shí)，從cache內(nèi)以remote_addr(如果是用XFF頭，則對(duì)XFF做一次處理后獲取到real ip)作為key從cache內(nèi)做一次get，判斷此req應(yīng)該的轉(zhuǎn)發(fā)；

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

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

管理平臺(tái)方面，只需要做個(gè)簡(jiǎn)單的批量set緩存的功能就可以了，至于UI么，就看你給誰用了，自己用嘛，UI丑陋點(diǎn)就丑陋點(diǎn)了

性能和可用性方面：

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

可用性方面會(huì)增加一個(gè)當(dāng)緩存斷線的風(fēng)險(xiǎn)點(diǎn)，通過settimeout，將緩存超時(shí)限制到一個(gè)較小的時(shí)間，影響較小，另外ABtest的方案也不應(yīng)該常年累月的在線上，只有在有需求時(shí)，才需要這套系統(tǒng)吧，因此可用性方面對(duì)全局影響應(yīng)該是較小的，相比新的feature上線時(shí)影響全部用戶的風(fēng)險(xiǎn)，這個(gè)冒險(xiǎn)還是值得的。

上述暫時(shí)只是個(gè)人的思路，而且也還沒上線使用，實(shí)現(xiàn)方面只完成了nginx獲取key來判斷req轉(zhuǎn)發(fā)的驗(yàn)證。

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