灰度發(fā)布的定義

互聯(lián)網(wǎng)產(chǎn)品需要快速迭代開發(fā)上線，又要保證質(zhì)量，保證剛上線的系統(tǒng)，一旦出現(xiàn)問題可以很快控制影響面，就需要設計一套灰度發(fā)布系統(tǒng)。

灰度發(fā)布系統(tǒng)的作用，可以根據(jù)配置，將用戶的流量導到新上線的系統(tǒng)上，來快速驗證新的功能，而一旦出現(xiàn)問題，也可以馬上的修復，簡單的說，就是一套A/B Test系統(tǒng)。

灰度發(fā)布允許帶著bug上線，只要bug不是致命的，當然這個bug是不知道的情況下，如果知道就要很快的改掉

簡單灰度發(fā)布系統(tǒng)的設計

灰度簡單架構(gòu)如上圖所示，其中的必要組件如下：

1、策略的配置平臺，存放灰度的策略

2、灰度功能的執(zhí)行程序

3、注冊中心，注冊的服務攜帶ip/Port/name/version

有了上面三個組件，才算一個完整的灰度平臺

灰度的策略

灰度必須要有灰度策略，灰度策略常見的方式有以下幾種

1、基于Request Header進行流量切分

2、基于Cookie進行流量切分

3、基于請求參數(shù)進行流量切分

舉例：根據(jù)請求中攜帶的用戶uid進行取模，灰度的范圍是百分之一，那么uid取模的范圍就是100，模是0訪問新版服務，模是1~99的訪問老版服務。

灰度發(fā)布策略分為兩類，單策略和組合策略

單策略：比如按照用戶的uid、token、ip進行取模

組合策略：多個服務同時灰度，比如我有A/B/C三個服務，需要同時對A和C進行灰度，但是B不需要灰度，這個時候就需要一個tag字段，具體實現(xiàn)在下文詳述

灰度發(fā)布具體的執(zhí)行控制

在上面的簡單灰度發(fā)布系統(tǒng)架構(gòu)中我們了解到，灰度發(fā)布服務分為上游和下游服務，上游服務是具體的執(zhí)行灰度策略的程序，這個服務可以是nginx，也可以是微服務架構(gòu)中的網(wǎng)關(guān)層/業(yè)務邏輯層，下面我們就來分析一下不同的上游服務，如何落地

Nginx

如果上游服務是nginx，那么就需要nginx通過Lua擴展nginx實現(xiàn)灰度策略的配置和轉(zhuǎn)發(fā)，因為nginx本身并不具備灰度策略的執(zhí)行

通過lua擴展實現(xiàn)了灰度策略的執(zhí)行，但是問題又來了，nginx本身并不具備接收配置管理平臺的灰度策略，這個時候應該怎么辦呢？

解決方案：本地部署Agent（需要自己開發(fā)），接收服務配置管理平臺下發(fā)的灰度策略，更新nginx配置，優(yōu)雅重啟Nginx服務

網(wǎng)關(guān)層/業(yè)務邏輯層/數(shù)據(jù)訪問層

只需要集成配置管理平臺客戶端SDK，接收服務配置管理平臺下發(fā)的灰度策略，在通過集成的SDK進行灰度策略的執(zhí)行即可

灰度發(fā)布復雜場景

下面舉例兩個稍微復雜的灰度發(fā)布場景，灰度策略假設都按照uid取模灰度百分之一的用戶，看一下如何實現(xiàn)。

場景1：調(diào)用鏈上同時灰度多個服務

功能升級涉及到多個服務變動，網(wǎng)關(guān)層和數(shù)據(jù)訪問層灰度，業(yè)務邏輯層不變，這個時候應該如何進行灰度？

解決方案：

經(jīng)過新版本網(wǎng)關(guān)層的請求，全部打上tag T，在業(yè)務邏輯層根據(jù)tag T進行轉(zhuǎn)發(fā)， 標記Tag T的請求全部轉(zhuǎn)發(fā)到新版數(shù)據(jù)訪問層服務上，沒有tag T的請求全部轉(zhuǎn)發(fā)到老版數(shù)據(jù)訪問層上。

場景2：涉及數(shù)據(jù)的灰度服務

涉及到數(shù)據(jù)的灰度服務，一定會使用到數(shù)據(jù)庫，使用到數(shù)據(jù)庫就會涉及到你使用數(shù)據(jù)庫前后的表字段不一致，我老版本是A/B/C三個字段，新版本是A/B/C/D四個字段。這時新版的灰度，就不能往老版的數(shù)據(jù)庫進行修改了，這個時候就需要把數(shù)據(jù)copy一份出來做這個事情了

數(shù)據(jù)庫其實并沒有灰度的概念，這個時候我們只能把數(shù)據(jù)重新拷貝一份出來進行讀和寫，因為這時你的寫必須是全量的（雙寫），不能說90%的數(shù)據(jù)寫入到老版本，10%的數(shù)據(jù)寫入到新版本，因為這個時候你會發(fā)現(xiàn)兩個數(shù)據(jù)庫的數(shù)據(jù)都不是全量的。

離線全量復制數(shù)據(jù)的過程中一定會有數(shù)據(jù)丟失，這個時候就需要業(yè)務邏輯層寫一份數(shù)據(jù)到MQ中，等數(shù)據(jù)同步完成之后，新版的數(shù)據(jù)訪問層再將MQ的數(shù)據(jù)寫入到新版本的DB中，實現(xiàn)數(shù)據(jù)的一致性，這個也是引入MQ的主要目的。

灰度過程中需要對兩個數(shù)據(jù)庫的數(shù)據(jù)進行對比，觀察數(shù)據(jù)是否一致。這樣不管是灰度失敗，放棄新版DB，還是灰度成功切換到新版DB，數(shù)據(jù)都不會產(chǎn)生丟失。

如果您喜歡本文，歡迎點擊右上角，把文章分享到朋友圈~~
如果有想了解和學習的知識點或技術(shù)點，也可以留言給若飛安排分享

·END·

作者：kelgon

來源：https://www.toutiao.com/i6910008843955192323/

版權(quán)申明：內(nèi)容來源網(wǎng)絡，版權(quán)歸原創(chuàng)者所有。除非無法確認，我們都會標明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并表示歉意。謝謝!

必須掌握的 MySQL 優(yōu)化原理

MySQL 與 PostgreSQL 的對決！！