服務灰度發佈設計

灰度發佈(又叫金絲雀發佈)是互聯網產品發佈經常使用的一種方式，顧名思義，就是在黑和白之間平滑過渡的一種產品產品發佈方式，產品發佈者根據某種規則，讓一部分用戶繼續使用原來的產品功能，另外一部分用戶逐漸啓用新功能。在過渡過程當中，可能還會對產品作進一步的完善，灰度發佈完成後，全部的用戶都將使用新的產品功能。[1]

在服務發佈的時候很難保證一點問題都不出，出問題在所不免，如何保證在出了問題的時候影響最小呢，灰度發佈就可讓咱們提早知道發佈是否有問題，先用小部分流量看看效果。

灰度發佈系統架構

1 配置中心配置，哪些服務進行灰度發佈，灰度發佈中的流量劃分

2 上游服務接收客戶端請求以後，根據配置中心的配置將請求轉發到新老服務中

3 註冊中心負責新老服務的註冊

4 下游服務負責處理用戶請求的業務服務系統

設計中的難點：灰度發佈系統中的協議設計

• 數據協議
  • 定長header
  • 變長body
  • 設計灰度發佈字段
    • uid
    • token
    • ip
    • tag
• 灰度發佈策略
  • 單策略
    • uid/token/ip
  • 基於上下文灰度發佈策略
    • 模塊AC同時灰度
    • tag

灰度發佈場景

只更新下游某服務

上游若是Nginx：

• 可以使用Openresty，Tengine等nginx擴展，能夠嵌入lua腳本，進行轉發
• 服務器配置agent進行動態更新nginx配置，好比consul + consul-template。

上游若是是RPC服務：

• 可集成配置管理平臺的客戶端SDK，實時更新服務端的配置，執行灰度發佈策略，判斷是否要開啓新版本服務。

下游服務：

• 新老服務通常都會註冊到服務註冊中心，服務通常都帶有本身的版本號。

同時灰度多個模塊

網關層與數據訪問層同時進行灰度發佈。

根據文中上面提到的協議字段中，給新來的流量進行打標籤，全部走到新網關的請求都打上tag，在業務邏輯層根據tag再次轉發到不一樣的數據訪問層。

• 全部通過新gateway的請求都有標籤
• 有標籤的請求在業務層都會轉發到新的數據訪問層

數據庫的灰度升級

好比SqlServer遷移到MySQL，或者數據庫字段修改。

• 首先數據全量複製，雙寫
• 再雙寫一段時間
• 去掉舊版本的DB，只寫新數據庫

客戶端灰度發佈

Android灰度發佈，不要一次性把包上架到應用市場，若是上架了就不受控制了，能夠經過本身的後臺接口，嘗試更新一批用戶，而後逐漸的增長用戶比例。等灰度發佈完畢以後，再提交到應用市場

IOS的App Store有灰度發佈機制，可是又比較嚴的規則。能夠提早終止發佈，可是已經更新的用戶則沒法降級。默認是7天進行所有的灰度升級。

最後

學習記錄

參考

• [1] 灰度發佈-百度百科
• AB測試和灰度發佈平臺架構設計和實踐
• Nepxion-Spring Cloud灰度發佈神器