1、灰度發(fā)版資料灰度發(fā)布，已經(jīng)不是一個(gè)很新的概念了一個(gè)產(chǎn)品，如果需要快速迭代開發(fā)上 線，又要保證質(zhì)量，保證剛上線的系統(tǒng)，一旦出現(xiàn)問題那么可以很快的控制影 響面，就需要設(shè)計(jì)一套灰度發(fā)布系統(tǒng).灰度發(fā)布系統(tǒng)的作用在于，可以根據(jù)自己的配置，來將用戶的流量導(dǎo)到新上線 的系統(tǒng)上，來快速驗(yàn)證新的功能修改，而一旦出問題，也可以馬上的恢復(fù)，簡(jiǎn) 單的說，就是一套A/BTest系統(tǒng).它大抵的架構(gòu)，應(yīng)該是類似這樣的：其中分為幾個(gè)部分：接入層，接入客戶端請(qǐng)求，根據(jù)下發(fā)的配置將符合條件的請(qǐng)求轉(zhuǎn)發(fā)到新 舊系統(tǒng)上.配置管理后臺(tái)，這個(gè)后臺(tái)可以配置不同的轉(zhuǎn)發(fā)策略給接入層.新舊兩種處理客戶端請(qǐng)求的業(yè)務(wù)服務(wù)器.關(guān)于接入策略的設(shè)計(jì)上，從協(xié)

2、議層來說，需要從一開始就設(shè)計(jì)是根據(jù)哪些參數(shù) 來進(jìn)行轉(zhuǎn)發(fā)的，而且這些參數(shù)最好跟具體的協(xié)議體內(nèi)容分開，這樣減少接入層 對(duì)協(xié)議的解析.舉個(gè)例子，如果客戶端的請(qǐng)求是走HTTP協(xié)議的，那么將這些參數(shù)放在HEADER部分就好了，接入層不需要去具體解析 body部分的數(shù)據(jù)就 拿到了轉(zhuǎn)發(fā)策略需要的參數(shù).當(dāng)然，放在 HEADER中的數(shù)據(jù)，因?yàn)闆]有了加 密性，又是需要考慮的另一個(gè)問題.當(dāng)然，最簡(jiǎn)單粗暴的轉(zhuǎn)發(fā)策略，可以根據(jù)客戶端ip地址來做，這是比較粗略的一個(gè)劃分策略.同樣的，新舊服務(wù)器要對(duì)新舊客戶端的協(xié)議兼容，也是能做到灰度發(fā)布的根 本，如何設(shè)計(jì)一個(gè)擴(kuò)展性好的應(yīng)用協(xié)議，這一點(diǎn)就不在這里考慮了.接下來，還需要滿足如

3、果管理后臺(tái)下發(fā)了新的轉(zhuǎn)發(fā)策略，接入層應(yīng)該是可以馬 上感知到然后切換到這個(gè)新的策略來的有好些不同的做法假如接入層是 Nginx這樣的服務(wù)器，使用者只是在上面寫了自己的Nginx模塊來實(shí)現(xiàn)策略的轉(zhuǎn)發(fā)，那么可能還需要在每臺(tái)接入服務(wù)器上部署一個(gè)Age nt的服務(wù)，主要用于：接收管理后臺(tái)下發(fā)的策略，更新 Nginx配置，然后優(yōu)雅重啟Nginx服 務(wù).定時(shí)檢查本臺(tái)機(jī)器的Nginx服務(wù)的狀態(tài)，進(jìn)行上報(bào).如果接入層不是Nginx這樣的服務(wù)，那么也可以做一個(gè) pub-sub模型的訂閱 者，用ZK或者Redis都可以，訂閱管理后臺(tái)下發(fā)的服務(wù)進(jìn)行處理即可.上周寫完灰度發(fā)布系統(tǒng)相關(guān)的博文之后，有朋友表示灰度系統(tǒng)的實(shí)現(xiàn)

4、太過簡(jiǎn)單 了，因?yàn)槲夷壳敖佑|的系統(tǒng)確實(shí)比較簡(jiǎn)單，很多復(fù)雜的東西沒有考慮周全，如 果更大型的業(yè)務(wù)系統(tǒng)，涉及到的服務(wù)更多，還有如果摻雜著數(shù)據(jù)的遷移，就更 復(fù)雜了.這里就把當(dāng)時(shí)討論的內(nèi)容提取出來，主要的貢獻(xiàn)者為滴滴的沈佳偉.1 .調(diào)用鏈上有多個(gè)業(yè)務(wù)服務(wù)的場(chǎng)景考慮這樣一個(gè)業(yè)務(wù)場(chǎng)景，假設(shè)對(duì)外提供了服務(wù)A給客戶端訪問，服務(wù)A后面會(huì) 調(diào)用服務(wù)B，C，D，此時(shí)需要上線一個(gè)功能，這個(gè)功能涉及到了服務(wù)A,C 的修改，但是服務(wù)B，D不需要變動(dòng)，換言之，我們的意圖是，如果一個(gè)客戶 端請(qǐng)求，走到了新的灰度服務(wù)A，那么最終這個(gè)請(qǐng)求也應(yīng)該走到這次和A起 灰度的服務(wù)C上.這里的處理策略，可以給客戶端請(qǐng)求進(jìn)行 tag打標(biāo)記的方

5、式，比如經(jīng)由新版本 服務(wù)A處理的請(qǐng)求，全部打上tag A，而在服務(wù)C上，也有接入層進(jìn)行轉(zhuǎn)發(fā)，它 轉(zhuǎn)發(fā)的策略之一就是根據(jù)根據(jù)這個(gè)tag來進(jìn)行轉(zhuǎn)發(fā)，這個(gè)系統(tǒng)如下圖所示：上圖中，請(qǐng)求首先走到了舊版本的服務(wù)A上，該服務(wù)沒有對(duì)請(qǐng)求打上tag，所以后續(xù)訪問的都是沒有配套灰度的舊版本C服務(wù).上圖中，請(qǐng)求首先走到了新版本需要灰度的服務(wù)A上，在經(jīng)過該服務(wù)處理后， 給請(qǐng)求打上了 tag A,由于帶上了 tag ,后續(xù)訪問的都是配套灰度的C服務(wù). 簡(jiǎn)單的總結(jié)下，涉及到一個(gè)調(diào)用鏈路上某幾個(gè)服務(wù)需要灰度的情況，可以通過 tag的方式，將走灰度服務(wù)的請(qǐng)求匯集到一起來，如果一個(gè)請(qǐng)求走到了一個(gè)灰 度路徑上，就打上一個(gè)tag，

6、這樣只有有這個(gè)tag的請(qǐng)求才能走到這條鏈路上后 續(xù)也需要一起灰度的服務(wù)上至于如何給請(qǐng)求打 tag，如果是HTTP協(xié)議， 那就很簡(jiǎn)單了，也是加Header的方式，否則需要在設(shè)計(jì)協(xié)議的時(shí)候就考慮協(xié) 議的擴(kuò)展性支持這個(gè)操作.2 .涉及到數(shù)據(jù)的灰度服務(wù)假設(shè)灰度的服務(wù)，需要使用到數(shù)據(jù)庫，如果灰度前后數(shù)據(jù)庫的字段保持不變， 那么新舊兩套系統(tǒng)使用同一套數(shù)據(jù)庫就可以了.如果前后數(shù)據(jù)不一致，需要處理的情況就比較復(fù)雜，分為以下幾種情況.?部分灰度雯尋廿在部分灰度的情況下，有部分請(qǐng)求到舊系統(tǒng)上，另一部分請(qǐng)求到了新的灰度系 統(tǒng)上走到舊系統(tǒng)的請(qǐng)求，還是照原樣處理但是走到了新版灰度系統(tǒng)的請(qǐng) 求，需要同時(shí)將請(qǐng)求轉(zhuǎn)發(fā)給舊系統(tǒng)上來對(duì)應(yīng)的接口上修改舊系統(tǒng)的數(shù)據(jù)如果 走到新系統(tǒng)的請(qǐng)求查不到該用戶的數(shù)據(jù)，還需要首先同步一份來新系統(tǒng)上如 果是事務(wù)性的請(qǐng)求，以寫入老系統(tǒng)成功來做為操作成功的標(biāo)準(zhǔn).?全部灰度在灰度系統(tǒng)已經(jīng)全部接管了線上流量之后，為了安全起見，仍然需要對(duì)新老系 統(tǒng)進(jìn)行雙寫，步驟和前面一樣.?灰度完成灰度完成與前面的全量灰度狀態(tài)不太一樣，區(qū)別在于前面的全量灰度狀態(tài)下， 仍然不能肯定系統(tǒng)一定是沒有問題的，所以需要進(jìn)行新舊系統(tǒng)的雙寫來保證數(shù) 據(jù)可以在老系統(tǒng)上進(jìn)行回滾而在灰度完成狀態(tài)，此時(shí)認(rèn)為這個(gè)新版本已經(jīng)完 全通過了驗(yàn)證，無需再寫入舊系統(tǒng)了但是此時(shí)可能存在部分在灰度期間沒有 上線的用戶，此時(shí)需要做一