轉：灰度發佈系統的實現

 

 

灰度發佈，已經不是一個很新的概念了．一個產品，若是須要快速迭代開發上線，又要保證質量，保證剛上線的系統，一旦出現問題那麼能夠很快的控制影響面，就須要設計一套灰度發佈系統．

灰度發佈系統的做用在於，能夠根據本身的配置，來將用戶的流量導到新上線的系統上，來快速驗證新的功能修改，而一旦出問題，也能夠立刻的恢復，簡單的說，就是一套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的方式，不然須要在設計協議的時候就考慮協議的擴展性支持這個操做．

２.　涉及到數據的灰度服務

假設灰度的服務，須要使用到數據庫，若是灰度先後數據庫的字段保持不變，那麼新舊兩套系統使用同一套數據庫就能夠了．

若是先後數據不一致，須要處理的狀況就比較複雜，分爲如下幾種狀況．

部分灰度

在部分灰度的狀況下，有部分請求到舊系統上，另外一部分請求到了新的灰度系統上．走到舊系統的請求，仍是照原樣處理．可是走到了新版灰度系統的請求，須要同時將請求轉發給舊系統上來對應的接口上修改舊系統的數據．若是走到新系統的請求查不到該用戶的數據，還須要首先同步一份來新系統上．若是是事務性的請求，以寫入老系統成功來作爲操做成功的標準．

所有灰度

在灰度系統已經所有接管了線上流量以後，爲了安全起見，仍然須要對新老系統進行雙寫，步驟和前面同樣．

灰度完成

灰度完成與前面的全量灰度狀態不太同樣，區別在於前面的全量灰度狀態下，仍然不能確定系統必定是沒有問題的，因此須要進行新舊系統的雙寫來保證數據能夠在老系統上進行回滾．而在灰度完成狀態，此時認爲這個新版本已經徹底經過了驗證，無需再寫入舊系統了．可是此時可能存在部分在灰度期間沒有上線的用戶，此時須要作一次同步，從舊系統上將這部分數據同步過來．

能夠看到，這三個狀態下，對新舊系統是否進行雙寫，作了嚴格的區分，目的只有一個：一旦新上線的系統出現問題，能夠立刻撤掉灰度系統，而這期間用戶的任何修改在舊系統上都是能夠找到的．————————————————版權聲明：本文爲CSDN博主「工程師WWW」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/weiwangchao_/article/details/52589615