轉(zhuǎn)自百度QA
灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式韧骗。AB test就是一種灰度發(fā)布方式驱敲，讓一部分用戶繼續(xù)用A，一部分用戶開始用B宽闲，如果用戶對(duì)B沒有什么反對(duì)意見众眨，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來容诬∶淅妫灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)览徒、調(diào)整問題狈定，以保證其影響度。
為什么要灰度發(fā)布
1. ? ?互聯(lián)網(wǎng)服務(wù)變動(dòng)頻繁习蓬，發(fā)布周期短纽什。速度與質(zhì)量總是難以雙全。
2. ? ?灰度發(fā)布能降低發(fā)布風(fēng)險(xiǎn)躲叼，減少影響范圍芦缰。
3. ? ?降低對(duì)測試的依賴，減少線下自測的數(shù)據(jù)構(gòu)造成本枫慷。
4. ? ?方便集中監(jiān)控日志让蕾，全量發(fā)布由于各層負(fù)載均衡的作用，很難跟蹤一條完整的調(diào)用鏈路或听。
5. ? ?可以灰度測試帳號(hào)探孝，測試賬戶通過之后再灰度真實(shí)用戶帳號(hào)，進(jìn)一步降低發(fā)布的風(fēng)險(xiǎn)和影響誉裆。
6. ? ?方便回滾顿颅。
不能靠灰度發(fā)布解決的問題
需要強(qiáng)調(diào)的是：上文所說的“可以容忍的影響”必須是可恢復(fù)的，比如API無法調(diào)用一段時(shí)間足丢，但是修復(fù)之后粱腻，就可以成功調(diào)用绍填。而永久性地丟失或者破壞用戶數(shù)據(jù)（比如商品信息、訂單信息等）栖疑，則是不能容忍的讨永。因此，互聯(lián)網(wǎng)企業(yè)的架構(gòu)師有責(zé)任通過設(shè)計(jì)完善的后備措施（比如用戶數(shù)據(jù)的定期備份遇革、寫操作的業(yè)務(wù)流水日志等）卿闹，在生產(chǎn)系統(tǒng)錯(cuò)亂導(dǎo)致丟失用戶數(shù)據(jù)的情況下，仍能夠通過人工干預(yù)萝快，根據(jù)歷史記錄（備份數(shù)據(jù)锻霎、流水日志等），把丟失的用戶數(shù)據(jù)修復(fù)至不久之前（比如一小時(shí)前至一周前）的狀態(tài)揪漩。
TIPS： ?先灰度測試帳號(hào)的灰度策略旋恼，可以降低破壞或者丟失真實(shí)用戶的數(shù)據(jù)的風(fēng)險(xiǎn)。
期望達(dá)到什么效果
不管是那種變更奄容，我們都希望特定的請求能夠路由到我們的變更版本（灰度版本）冰更，以便觀察和驗(yàn)證。
灰度策略
其實(shí)就是什么的請求應(yīng)該路由到我們的灰度版本（灰度機(jī)器）上來昂勒。這個(gè)往往是業(yè)務(wù)強(qiáng)相關(guān)的蜀细。比如對(duì)于API來說，一般有如下幾個(gè)需求：
1. ? ?特定用戶（比如測試帳號(hào)）
2. ? ?特定的App（比如測試app或者合作App）
3. ? ?特定的模塊戈盈、接口（只有某些接口需要灰度奠衔，這種一般是API Container的修改，拿一些不是很重要的API做灰度測試塘娶。）
4. ? ?特定的機(jī)器（某些請求IP轉(zhuǎn)發(fā)到灰度機(jī)）
灰度方案探討
方案一：代碼級(jí)別通過對(duì)約定好的flag判斷归斤，動(dòng)態(tài)的進(jìn)行新老切換——Amazon的做法
實(shí)現(xiàn)：
在代碼中埋開關(guān)，做if-else判斷刁岸，對(duì)于需要灰度的機(jī)器脏里，設(shè)置開關(guān)為on，否則為off难捌。每次版本發(fā)布都是有兩個(gè)版本膝宁。
優(yōu)點(diǎn)
快速回滾，不需要重新發(fā)布和重啟系統(tǒng)根吁。
缺點(diǎn)
a.對(duì)代碼有傾入性。
b.分支邏輯合蔽，帶來復(fù)雜性击敌。
這種方式筆者曾經(jīng)應(yīng)用過，就是在阿里的時(shí)候把商品的數(shù)據(jù)庫從Oracle切換到MySql拴事，使用了一個(gè)狀態(tài)變量進(jìn)行控制沃斤。從而打到平滑遷移的效果圣蝎。
方案二：預(yù)發(fā)布機(jī)——Alibaba的做法
其實(shí)這個(gè)不是真正意義上的灰度。因?yàn)檫@個(gè)預(yù)先發(fā)布機(jī)器是內(nèi)部IP衡瓶，沒有對(duì)外服務(wù)的徘公。需要綁定域名進(jìn)行驗(yàn)證。但是數(shù)據(jù)是完全的線上哮针。所以本質(zhì)上是灰度某些特定用戶（可以訪問灰度機(jī)器的用戶关面，內(nèi)部測試用戶）的一種簡單做法。其實(shí)API這邊也有類似的做法十厢，就是我們的Gamma環(huán)境等太，而且我們還提供了Gamma機(jī)器的域名，方便外部合作用戶配合測試蛮放。
優(yōu)點(diǎn)
簡單
缺點(diǎn)
a.浪費(fèi)一臺(tái)機(jī)器（這個(gè)可以預(yù)先發(fā)布完成之后投入正式環(huán)境缩抡，預(yù)發(fā)布的時(shí)候從nginx摘除，不過需要運(yùn)維支持包颁。）
b.不夠靈活
c.只能針對(duì)接入層機(jī)器瞻想，IDL服務(wù)灰度需要另外考慮。
方案三:SET部署
1. 按照業(yè)務(wù)隔離部署
比如現(xiàn)在API Container的做法娩嚼，部署的粒度可以到API級(jí)別内边，前端根據(jù)nginx進(jìn)行轉(zhuǎn)發(fā)。比如：
a.微購物 API Container: api.weigou.qq.com
b. 拍拍 API Container：api.paipai.com
c.易迅 API Container: api.yixun.com
d.網(wǎng)購 API Container：api.buy.qq.com
上面是大業(yè)務(wù)級(jí)別的隔離部署待锈。還可以進(jìn)一步細(xì)化到模塊級(jí)別漠其，比如虛擬服務(wù)電商的API，是掛在拍拍下面的一個(gè)子業(yè)務(wù)模塊竿音，但是由于他們接入微信之后和屎，訪問量大增，為了避免影響拍拍其他業(yè)務(wù)春瞬，也為了避免受其他業(yè)務(wù)影響柴信，API這里是給他們單獨(dú)部署了兩臺(tái)機(jī)器，nginx配置一下就可以將針對(duì)虛擬的API訪問引流過來了：
虛擬API Container：http://api.paipai.com/v2/virbiz
這樣宽气，我們在發(fā)布一個(gè)版本的時(shí)候随常，可以先選擇業(yè)務(wù)量最小的易迅進(jìn)行發(fā)布，觀察沒有問題再全量其他平臺(tái)萄涯。
2. 按照用戶隔離部署
這個(gè)對(duì)于開放平臺(tái)來說不是很適合绪氛，不過對(duì)于SNS這種應(yīng)用場景就很合適了。比如QQ系統(tǒng)涝影，按照用戶號(hào)碼段分為若干個(gè)set枣察，每個(gè)set包含連續(xù)1億個(gè)號(hào)碼的用戶。假設(shè)現(xiàn)在最新的QQ號(hào)碼接近10億，則總共有10個(gè)set（Set 1到Set 10）序目。這樣每次可以選擇其中一個(gè)SET進(jìn)行發(fā)布臂痕，而且高位QQ往往是不是很重要的用戶，所以會(huì)先發(fā)布SET10猿涨。
優(yōu)點(diǎn)
隔離部署握童，各個(gè)業(yè)務(wù)線影響最小。自動(dòng)支持灰度發(fā)布叛赚。
缺點(diǎn)
a.灰度的粒度取決于隔離部署的粒度澡绩，一般會(huì)偏大。
b. 相對(duì)于集中部署比較浪費(fèi)機(jī)器红伦。
c.各個(gè)業(yè)務(wù)線版本可能不一致英古，不利于統(tǒng)一管理。
d.有一定的實(shí)現(xiàn)和部署成本昙读。
方案四:動(dòng)態(tài)路由
方法：
采用一個(gè)可以靈活配置的灰度策略召调，影響Load Balance的行為，讓其根據(jù)灰度策略蛮浑，返回灰度服務(wù)的IP和端口唠叛。
適合與后臺(tái)IDL的服務(wù)灰度。
優(yōu)點(diǎn):
靈活沮稚、可控艺沼。
缺點(diǎn):
a.現(xiàn)在的配置中心和L5本身沒有考慮指定路由策略，且不具有擴(kuò)展性蕴掏，需要在其外邊開發(fā)障般。
b.API的元數(shù)據(jù)來源比較分散，目前 API和IDL元數(shù)據(jù)盛杰，API等級(jí)和頻率限制 分布在不同的數(shù)據(jù)源挽荡，現(xiàn)在需要增加一個(gè) 灰度路由 數(shù)據(jù)源。
最終方案
1. ? ?API Container采用預(yù)發(fā)布機(jī)模式灰度
2. ? ?IDL服務(wù)采用動(dòng)態(tài)路由模式即供，不過只能支持uin或者IP來源定拟。因?yàn)闆]有appId的概念。
小編有話說：
灰度發(fā)布不僅是一種策略逗嫡，更是一種思想青自。互聯(lián)網(wǎng)產(chǎn)品有一個(gè)特點(diǎn)驱证，就是不停的升級(jí)延窜，升級(jí)，再升級(jí)雷滚。有些項(xiàng)目組需曾，基本上保持每周一次的發(fā)布頻率，系統(tǒng)升級(jí)總是伴隨著風(fēng)險(xiǎn)祈远，新舊版本兼容的風(fēng)險(xiǎn)呆万，用戶使用習(xí)慣突然改變而造成用戶流失的風(fēng)險(xiǎn)，系統(tǒng)down機(jī)的風(fēng)險(xiǎn).....
為了避免這些風(fēng)險(xiǎn)车份，很多產(chǎn)品都采用了灰度發(fā)布的策略谋减，其主要思想就是把影響集中到一個(gè)點(diǎn)，然后再發(fā)散到一個(gè)面扫沼，出現(xiàn)意外情況后很容易就回退出爹。
百度對(duì)外開放的移動(dòng)云測試平臺(tái)——MTC通過眾包模式，長期運(yùn)營10,000名考核認(rèn)證測試專員缎除，擁有不同地域严就、行業(yè)、年齡等屬性器罐，為廣大互聯(lián)網(wǎng)sir推出海量用戶測試梢为，隨時(shí)、隨地轰坊、快速招募目標(biāo)用戶铸董，用低成本完成基于真實(shí)用戶的灰度測試和反饋收集。
百度移動(dòng)云測試平臺(tái)-百度MTC肴沫，該平臺(tái)通過5年深厚的自動(dòng)化測試技術(shù)積累粟害，并創(chuàng)新性地將眾包模式融入App測試，為廣大開發(fā)者颤芬、測試者提供Bug探索悲幅、兼容測試、真機(jī)遠(yuǎn)程調(diào)試站蝠、安全漏洞掃描等測試服務(wù)
