灰度發布，已經不是乙個很新的概念了．乙個產品，如果需要快速迭代開發上線，又要保證質量，保證剛上線的系統，一旦出現問題那麼可以很快的控制影響面，就需要設計一套灰度發布系統．
灰度發布系統的作用在於，可以根據自己的配置，來將使用者的流量導到新上線的系統上，來快速驗證新的功能修改，而一旦出問題，也可以馬上的恢復，簡單的說，就是一套a/btest系統．
它大抵的架構，應該是類似這樣的：
其中分為幾個部分：
接入層，接入客戶端請求，根據下發的配置將符合條件的請求**到新舊系統上．
配置管理後台，這個後台可以配置不同的**策略給接入層．
新舊兩種處理客戶端請求的業務伺服器．
關於接入策略的設計上，從協議層來說，需要從一開始就設計是根據哪些引數來進行**的，而且這些引數最好跟具體的協議體內容分開，這樣減少接入層對協議的解析．舉個例子，如果客戶端的請求是走http協議的，那麼將這些引數放在header部分就好了，接入層不需要去具體解析body部分的資料就拿到了**策略需要的引數．當然，放在header中的資料，因為沒有了加密性，又是需要考慮的另乙個問題．
當然，最簡單粗暴的**策略，可以根據客戶端ip位址來做，這是比較粗略的乙個劃分策略．
同樣的，新舊伺服器要對新舊客戶端的協議相容，也是能做到灰度發布的根本，如何設計乙個擴充套件性好的應用協議，這一點就不在這裡考慮了．
接下來，還需要滿足如果管理後台下發了新的**策略，接入層應該是可以馬上感知到然後切換到這個新的策略來的．有好些不同的做法．假如接入層是nginx這樣的伺服器，使用者只是在上面寫了自己的nginx模組來實現策略的**，那麼可能還需要在每台接入伺服器上部署乙個agent的服務，主要用於：
接收管理後台下發的策略，更新nginx配置，然後優雅重啟nginx服務．
定時檢查本台機器的nginx服務的狀態，進行上報．
如果接入層不是nginx這樣的服務，那麼也可以做乙個pub-sub模型的訂閱者，用zk或者redis都可以，訂閱管理後台下發的服務進行處理即可．
上週寫完灰度發布系統相關的博文之後，有朋友表示灰度系統的實現太過簡單了，因為我目前接觸的系統確實比較簡單，很多複雜的東西沒有考慮周全，如果更大型的業務系統，涉及到的服務更多，還有如果摻雜著資料的遷移，就更複雜了．這裡就把當時討論的內容提取出來，主要的貢獻者為滴滴的沈佳偉．
１．呼叫鏈上有多個業務服務的場景
考慮這樣乙個業務場景，假設對外提供了服務ａ給客戶端訪問，服務ａ後面會呼叫服務ｂ，ｃ，ｄ，此時需要上線乙個功能，這個功能涉及到了服務ａ，ｃ的修改，但是服務ｂ，ｄ不需要變動，換言之，我們的意圖是，如果乙個客戶端請求，走到了新的灰度服務ａ，那麼最終這個請求也應該走到這次和ａ一起灰度的服務ｃ上．
這裡的處理策略，可以給客戶端請求進行tag打標記的方式，比如經由新版本服務ａ處理的請求，全部打上tag a，而在服務ｃ上，也有接入層進行**，它**的策略之一就是根據根據這個tag來進行**，這個系統如下圖所示：
上圖中，請求首先走到了舊版本的服務ａ上，該服務沒有對請求打上tag，所以後續訪問的都是沒有配套灰度的舊版本ｃ服務．
上圖中，請求首先走到了新版本需要灰度的服務ａ上，在經過該服務處理後，給請求打上了tag ａ，由於帶上了tag，後續訪問的都是配套灰度的ｃ服務．
簡單的總結下，涉及到乙個呼叫鏈路上某幾個服務需要灰度的情況，可以通過tag的方式，將走灰度服務的請求匯集到一起來，如果乙個請求走到了乙個灰度路徑上，就打上乙個tag，這樣只有有這個tag的請求才能走到這條鏈路上後續也需要一起灰度的服務上．至於如何給請求打tag，如果是ｈｔｔｐ協議，那就很簡單了，也是加header的方式，否則需要在設計協議的時候就考慮協議的擴充套件性支援這個操作．
２. 涉及到資料的灰度服務
假設灰度的服務，需要使用到資料庫，如果灰度前後資料庫的字段保持不變，那麼新舊兩套系統使用同一套資料庫就可以了．
如果前後資料不一致，需要處理的情況就比較複雜，分為以下幾種情況．
在部分灰度的情況下，有部分請求到舊系統上，另一部分請求到了新的灰度系統上．走到舊系統的請求，還是照原樣處理．但是走到了新版灰度系統的請求，需要同時將請求**給舊系統上來對應的介面上修改舊系統的資料．如果走到新系統的請求查不到該使用者的資料，還需要首先同步乙份來新系統上．如果是事務性的請求，以寫入老系統成功來做為操作成功的標準．
在灰度系統已經全部接管了線上流量之後，為了安全起見，仍然需要對新老系統進行雙寫，步驟和前面一樣．
灰度完成與前面的全量灰度狀態不太一樣，區別在於前面的全量灰度狀態下，仍然不能肯定系統一定是沒有問題的，所以需要進行新舊系統的雙寫來保證資料可以在老系統上進行回滾．而在灰度完成狀態，此時認為這個新版本已經完全通過了驗證，無需再寫入舊系統了．但是此時可能存在部分在灰度期間沒有上線的使用者，此時需要做一次同步，從舊系統上將這部分資料同步過來．
可以看到，這三個狀態下，對新舊系統是否進行雙寫，做了嚴格的區分，目的只有乙個：一旦新上線的系統出現問題，可以馬上撤掉灰度系統，而這期間使用者的任何修改在舊系統上都是可以找到的．
Nginx實現系統灰度發布
在系統發布的時候，經常會遇到要停機發布的情況。大家經常會在凌晨去發布系統。這樣導致開發和測試的同時都很辛苦。那麼有沒有一種比較簡單 成本相對可以接受的方式來進行發布呢？在這裡，給大家推薦灰度發布的方式。灰度發布的方式很多，最簡單的操作方式是直接操作nginx的upstream來進行灰度發布。前提 至...
使用Nginx實現灰度發布
灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。ab test就是一種灰度發布方式，讓一部分使用者繼續用a，一部分使用者開始用b，如果使用者對b沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到b上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現 調整問題，以保證其影響度...
使用Nginx實現灰度發布
灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式。ab test就是一種灰度發布方式，讓一部分使用者繼續用a，一部分使用者開始用b，如果使用者對b沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到b上面來。灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現 調整問題，以保證其影響度...