Nginx+KV db進(jìn)行AB灰度測(cè)試
之前聽(tīng)過(guò)淘寶用nginx的一些場(chǎng)景，其中AB的灰度測(cè)試可能適用場(chǎng)景會(huì)比較普遍，當(dāng)然大會(huì)上，并沒(méi)有詳細(xì)討論實(shí)現(xiàn)。
大概需求是： 網(wǎng)站類業(yè)務(wù)在更新new feature時(shí)，并不想讓全量用戶看到，可以針對(duì)地區(qū)性用戶開(kāi)放此feature。大概構(gòu)思了一個(gè)方式，使用 nginx+redis/memcache+IP庫(kù)實(shí)現(xiàn)，簡(jiǎn)單的流程圖如下：
當(dāng)然其中的new feature server和normal server不必要一定得是物理上的服務(wù)器，可以是任意邏輯上分開(kāi)的服務(wù)和http URI
所用的模塊是 ngx-lua-module, 以及一個(gè)基于ngx-lua寫(xiě)的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)求到來(lái)時(shí)，從cache內(nèi)以remote_addr(如果是用XFF頭，則對(duì)XFF做一次處理后獲取到real ip)作為key從cache內(nèi)做一次get，判斷此req應(yīng)該的轉(zhuǎn)發(fā)；
這里有一個(gè)問(wèn)題是：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)方法還沒(méi)想到)， 復(fù)雜度會(huì)有所增加，個(gè)人偏向直接使用IP作為key，只要保證了IP的一定準(zhǔn)確性，數(shù)據(jù)大小問(wèn)題不大，現(xiàn)在遍地都是32G，64G內(nèi)存的緩存。
若使用ip作為key，一個(gè)折中的辦法是每次進(jìn)行ABtest的時(shí)候，flush緩存，只保存指定地區(qū)的ip數(shù)據(jù)即可，ngx在做get的時(shí)候，如果沒(méi)有返回，則認(rèn)為此req是到normal server的.
管理平臺(tái)方面，只需要做個(gè)簡(jiǎn)單的批量set緩存的功能就可以了，至于UI么，就看你給誰(shuí)用了，自己用嘛，UI丑陋點(diǎn)就丑陋點(diǎn)了
性能和可用性方面：
增加了一次緩存的連接和get操作，理論上此開(kāi)銷應(yīng)該是很小的，ngx-lua實(shí)現(xiàn)的lua-resty-memcached有不少人做過(guò)測(cè)試，性能非?？捎^.
可用性方面會(huì)增加一個(gè)當(dāng)緩存斷線的風(fēng)險(xiǎn)點(diǎn)，通過(guò)settimeout，將緩存超時(shí)限制到一個(gè)較小的時(shí)間，影響較小，另外ABtest的方案也不應(yīng)該常年累月的在線上，只有在有需求時(shí)，才需要這套系統(tǒng)吧，因此可用性方面對(duì)全局影響應(yīng)該是較小的，相比新的feature上線時(shí)影響全部用戶的風(fēng)險(xiǎn)，這個(gè)冒險(xiǎn)還是值得的。
上述暫時(shí)只是個(gè)人的思路，而且也還沒(méi)上線使用，實(shí)現(xiàn)方面只完成了nginx獲取key來(lái)判斷req轉(zhuǎn)發(fā)的驗(yàn)證，針對(duì)此方式也未做過(guò)詳細(xì)壓力測(cè)試，拋磚引玉，有好的方式歡迎討論.
