灰度發布其實是業界術語“abtest”的另一種叫法，一般用於做新發布版本與老版本的對比測試。在yhd，灰度發布與abtest的主要區別在於：灰度發布按照某個比例隨機的將用戶分為兩類；而abtest按照某個屬性將用戶分為兩類（例如男女）。其他方面，兩者在實現上幾乎沒有區別。
原理
為了實現將用戶分為類，一般使用cookie實現；為了實現不同模塊之間獨立執行灰度發布功能，可選的方案有兩個：1. 每個模塊使用一個cookie，優點是靈活，缺點是擴展性差（cookie多了浪費帶寬，體驗差）；2. 使用相同的cookie，不同模塊通過判斷cookie的值決定某個用戶是否應該走灰度發布。方案二已經能滿足我們需求。
具體來說，每個用戶有一個名字為gray的cookie，類型是int，取值范圍[0,1000000); 每個模塊維護一個灰度區間的配置[start, offset], 當用戶的gray值落入這個區間時, 這個用戶在這個模塊上進入灰度版本. 由於不同的模塊可以維護不同灰度區間,從而實現模塊之間相互獨立.
[
特別修正： 方案中期望每個用戶使用一個cookie來代替，但由於cookie是基於域名和瀏覽器的，所以每個用戶訪問的每一個域名都有自己獨立的cookie，而且不同的瀏覽器也會有獨立的cookie。所有確切的描述灰度的粒度應該是：每個用戶在某個瀏覽器中對某個域名的訪問。這個粒度的差異有利有弊。好處是我們可以更精確的控制灰度的行為；壞處是我們不能對一個用戶的保持灰度的一致性，也就是難以做到讓一個用戶始終訪問灰度或非灰度的版本。]
另外, 由於網站的架構使得每個http請求會依次通過幾個邏輯分層: 靜態頁面緩存->haproxy->具體業務->基礎業務, 所以在灰度發布方案的實現上也是分層的, 每層都能獨立實現.
配置說明
場景: 假設現在前端front、detail兩個模塊要做灰度發布；應用層也是front、detail兩個模塊要灰度發布；服務層gss、gps兩個模塊要灰度發布。我們對squid、haproxy都做了修改：
- squid 灰度邏輯： 如果一個http請求被判定為灰度的，那么在緩存這個http請求時，在緩存的url后面加上“_gray”后綴；在查找緩存時，灰度的請求也是加上這個后綴然后再查找。這樣就能保證用戶請求的一個url，在squid中有灰度和非灰度的兩個緩存版本。squid的空間需要很可能要X2.
- haproxy灰度邏輯：haproxy的每個backend在邏輯上被分為灰度和非灰度兩個組，這兩個組獨立調度（相當於在每個backend中起了兩個子backend）。如果一個http請求被判定為灰度的，那么就走入灰度的子backend分配server，否則走非灰度的子backend分配backend）
下圖，從用戶訪問路徑的角度展示灰度發布的工作原理。不同顏色的線表示不同用戶的http請求的訪問路徑。
從模塊配置信息傳遞的角度看整個系統如何工作：
