摘要
爲了達到“在產品發佈過程中，通過及時有效的發現和控制新引入線上缺陷的影響範圍，保護用戶體驗，提升上線質量”的目的，我們在吸收和借鑑Facebook灰度發佈等技術的基礎上，探索出符合產品線現狀的“分級發佈”方案，並在移動貼吧產品線的實施中驗證和改良。本文主要介紹貼吧分級發佈的背景、方案、實施過程、實施效果和後續展望。
一、 背景
作爲貼吧這樣上億PV的產品線，一旦有bug遺留到線上，影響的將是成千上萬的用戶，對產品形象有很大的傷害；對工程師來說，在各種高優先級的修復項目間疲於奔命，也在一定程度上挫傷士氣，降低了效率。
那麼有沒有一種方法可以讓我們“在既有的開發測試水平下，更快發現線下測試難以找出的bug，以有效控制產品缺陷的影響範圍，提高產品質量呢？”
名詞解釋：
分級發佈：在本文中是指把產品發佈過程劃分爲多個級別，每個級別限制一定的流量和用戶範圍，並在每個級別對產品進行部署和驗證的迭代過程。
TIP: Test In Product，即對線上產品進行驗證（功能、性能等），本文特製對發佈過程中的線上產品進行驗證。
二、 需求和目標
2.1. 需求概述
目前大部分產品線的發佈方式是：一股腦把所有代碼發佈到線上機器集羣，然後再由QA進行線上驗證。其實代碼也是分節點逐步部署的，但RD、QA都無法把請求命中到部署新模塊的機器進行驗證，RD通常只是在期間觀察下錯誤日誌，而這種方法很難有效發現線上bug，因此分節點發布其實對於控制質量風險也沒有什麼意義。
爲了能對發佈的代碼做到心裏有底，工程師們希望找到一種方法，能夠在產品沒有完全發佈前進行有效驗證，驗證服務正常後再擴大部署的範圍。
我們下文的“分級發佈“方案，既是脫胎於這麼樸素的需求。
2.2. 需求詳述
在對Facebook灰度發佈等業界比較領先的發佈方案進行了深度調研之後，結合自身的特點，我們擬定了貼吧“分級發佈“的需求。
從上文可以看出，要做到分級發佈，有兩個關鍵的過程：
1、 首先要能做到新產品可以分成多級逐步發佈到線上
2、 然後就是對於新發布的產品，能夠在線上進行及時有效的驗證
分級發佈在移動貼吧產品線實施的需求如下所示：
1、 分級流程：發佈過程分爲對內發佈、小流量發佈、全流量發佈三級
2、 分流層次：只通過Webserver實現PHP UI層次的分流
3、 機器維度：對內1臺UI機器，小流量1組x臺UI機器；對WAPUI單機羣劃分
4、 流量維度：對內發佈環境只有內部流量，小流量環境爲內部流量+線上流量
5、 時間窗口：作爲發佈驗證的必要條件，需要在相鄰兩級之間有約10分鐘的暫停時間；爲了不影響上線效率，C級項目總髮布時間需要在半小時左右
6、 質量保證應用：以線上自動化和監控爲主，人工check爲輔
三、 貼吧分級發佈方案
從質量保證角度出發，和傳統的線下測試相比，分級發佈帶來了什麼呢？
分級發佈就像放慢鏡頭一樣，把以往一次性的發佈過程拉長了，系統地切分成了多個階段，每個階段控制了發佈的範圍，並可以單獨進行驗證。
拉長的發佈時間，爲發現和消滅bug帶來了可能性；
而分級發佈的過程，還帶來了：
l 真實的環境：真實線上環境的功能驗證（自動化、手工）
l 真實的流量：真實流量下的性能監控
l 真實的用戶：核心用戶衆測（因爲管理成本及時間週期暫未採用）
這些特性是線下測試無法獲得的寶貴資源，也因爲缺乏這些資源，即使擁有非常有經驗的研發和測試工程師，也不能完美的控制線上缺陷。
3.1. 總體架構
要實現分級發佈，需要多個平臺和系統的配合，如下圖所示：
1) 上線平臺：實現新代碼的分級部署
2) TIP平臺：部署完成後，驅動線上測試工具，驗證每級服務是否正常
3) 分流系統：對測試流量和線上流量進行正確分流
對每個級別的發佈流程可以描述爲：
1) 首先通過上線平臺將新代碼發佈到某一級機器集羣
2) 然後通知TIP平臺部署完畢
3) TIP平臺驅動測試系統和監控系統對新服務進行線上驗證
4) 測試流量通過分流系統正確命中新部署服務
5) 工程師根據TIP平臺收集的報表進行決策並反饋給上線平臺
6) 上線平臺根據反饋決定是否進入下一級發佈
從技術實現上，主要需要解決流控基礎設施（分流系統）和平臺交互兩大部分的問題：
3.2. 分流系統
分流層是實現分級發佈“流量可控”這一目標最重要的基礎設施。貼吧的解決方案是在Nginx中通過擴展開發實現分流，判斷條件如下圖所示：
1) 內網IP+pub_env=1（自定義cookie）的請求會強制命中對內環境
2) 內網IP+pub_env=2的請求會強制命中小流量環境
3) 普通線上流量基於一致性分流規則分流到小流量環境和其他線上環境
3.3. 平臺交互
主要指上線平臺和TIP平臺之間的交互，迭代進行部署、驗證的過程，如下圖所示：
四、 方案實施
4.1. 關鍵任務
要實現分級發佈，需要多個部門的緊密合作，任務表可劃分爲三個層次，如下所示：
1) 基礎設施：通過Nginx和頁面的改造，實現分流系統，作爲分級發佈的基礎
2) 平臺支持：上線平臺和TIP平臺開發，實現分級部署和驗證反饋
3) 應用層：線上測試體系和發佈流程建設
4.2. 實施收益
完成一期的開發工作之後，分級發佈在移動貼吧試行三週（5.7~5.25），印證了分級發佈對質量提升的確有立竿見影的作用，簡述如下：
l 結果維度：
n 觸發2次小流量回滾（1次因爲性能，1次因爲功能）
n 觸發1次對內環境回滾（功能問題）
l 過程維度：
n 對內發佈階段發現3個功能問題，1個編譯腳本問題
n 小流量發佈階段發現1次性能問題
n 其中1個功能問題屬線下漏測；其餘功能、性能問題需在線上真實環境、真實流量下才能發現
五、 關鍵技術
實施分級發佈，涉及角色衆多也需要大量的開發工作，本節對部分關鍵技術進行闡述，希望對計劃實施分級發佈的其他產品線提供一些幫助。
1、 運維節點劃分 & 跨機房訪問
在線上部署爲雙機房的情況下，若把UI集羣劃分爲：對內、小流量、全流量jx，全流量tc四個節點；那麼這種只保留一個小流量節點的方案，違背了運維的一個重要原則——不要跨機房訪問！當某個機房宕掉需要切機房的時候會出現白頁。
考慮到雙機房冗餘及切機房服務的操作，正確的節點劃分應保證每個機房有一個小流量節點，如下所示：
2、 一致性分流 & 負載均衡
分級發佈拉長了上線的時間，我們必須保證在發佈過程中UI層異構期間，用戶的一致性體驗是不受影響的：
1) 在發佈過程中，用戶不會一會兒訪問到新產品，一會兒訪問到老產品
2) 當新產品有缺陷時，只會影響到少量相對穩定的用戶羣，而不會波及所有用戶
需要滿足用戶訪問一致性，意味着不能再在Webserver層使用隨機分流；而Webserver層的分流策略在滿足用戶訪問一致性的同時，也必須考慮負載均衡。以Nginx的ip-hash策略爲例，雖然能夠保證用戶一致性，但卻可能造成UI層負載不均衡（某些大型機構的出口IP含有大量請求）。
綜合考慮一致性和負載均衡，應選擇類似baiduid這樣具備更加離散特徵的cookie項來做分流。
3、 配置入庫 & 一鍵部署
因爲OP的分級發佈部署平臺是以一鍵部署爲基礎的，所以產品線要做到分級發佈，一個重要的前提就是被部署的模塊（對貼吧來說是PHP UI模塊）能夠被一鍵部署；而要做到一鍵部署，就要先做到配置模板入庫，然後在部署過程中將模板變量替換爲真實的線上配置。這對於一些比較複雜的產品線來說，可能需要較大的改造代價，當然，對於已經實現持續集成上線的產品線，這就不是一個問題了。
4、 平臺支持
在產品線的基礎改造完成後，線上部署平臺和TIP平臺的實現和穩定運行，對於整個方案的實施，就有着至關重要的作用了。前者專注於分級部署和回滾；後者管理整個發佈過程，並對TIP（Test In Product）提供支持。
5、 線上自動化
爲了能夠自動驗證線上服務，需要把自動化case遷移到線上運行，並結合cookie的使用以令驗證流量命中到正確的線上環境。
與在線下測試環境中運行自動化case相比，有一些特別需要注意的地方：
1) 設置cookie才能命中新發布代碼的線上機器，case結束後需要取消cookie
2) 頻繁登陸會被pass封禁
3) 規避antispam，驗證碼等問題
4) 線上提交流量對case驗證及穩定性的影響
運行效率：可以考慮利 用分佈式系統等方案提升自動化的運行效率
by Chenjie&Zhouren&Zhulei