首頁 > 行業新聞 > 詳情

藍綠發布、滾動發布、灰度發布等部署方案對比與總結

來源:倚博科技   時間:2018年5月6日

在項目迭代的過程中,不可避免需要進行項目上線。上線對應著部署或者重新部署,部署對應著修改,修改則意味著風險。

目前有很多用于部署的技術,有的簡單,有的復雜,有的得停機,有的不需要停機即可完成部署。本文將對目前常用的部署方案做一個簡單的總結。

藍綠發布(Blue/Green Deployment)

1. 定義

藍綠部署是不停老版本,部署新版本然后進行測試。確認OK后將流量切到新版本,然后老版本同時也升級到新版本。

2. 特點

藍綠部署無需停機,并且風險較小。

3. 部署過程

  • 部署版本 1 的應用(初始的狀態)

所有外部請求的流量都打到這個版本上。

  • 部署版本 2 的應用

版本 2 的代碼與版本 1 不同(新功能、Bug修復等)。

  • 將流量從版本 1 切換到版本 2。

  • 如版本 2 測試正常,就刪除版本 1 正在使用的資源(例如實例),從此正式用版本 2。

4. 小結

從過程不難發現,在部署的過程中,我們的應用始終在線。并且新版本上線的過程中,并沒有修改老版本的任何內容,在部署期間,老版本的狀態不受影響,這樣風險很小。并且只要老版本的資源不被刪除,理論上,我們可以在任何時間回滾到老版本。

5. 藍綠發布的注意事項

當你切換到藍色環境時,需要妥當處理未完成的業務和新的業務。如果你的數據庫后端無法處理,會是一個比較麻煩的問題。

  • 可能會出現需要同時處理微服務架構應用和傳統架構應用的情況,如果在藍綠部署中協調不好這兩者,還是有可能會導致服務停止。
  • 需要提前考慮數據庫與應用部署同步遷移/回滾的問題。
  • 藍綠部署需要有基礎設施支持。
  • 在非隔離基礎架構( VM 、 Docker 等)上執行藍綠部署,藍色環境和綠色環境有被摧毀的風險。

6. 優勢和不足

  • 優勢

升級切換和回退速度非常快。

  • 不足

切換是全量的,如果 V2 版本有問題,則對用戶體驗有直接影響。
需要兩倍機器資源。

7. 適用場合

  • 對用戶體驗有一定容忍度的場景。
  • 機器資源有富余或者可以按需分配(AWS 云,或自建容器云)。

灰度發布

1. 定義

灰度發布是指在黑與白之間,能夠平滑過渡的一種發布方式。AB Test 就是一種灰度發布方式,讓一部分用戶繼續用 A,一部分用戶開始用 B,如果用戶對 B 沒有什么反對意見,那么逐步擴大范圍,把所有用戶都遷移到 B 上面來。灰度發布可以保證整體系統的穩定,在初始灰度的時候就可以發現、調整問題,以保證其影響度。

灰度發布結構圖

2. A/B Testing

A/B 測試是用來測試應用功能表現的方法,例如可用性、受歡迎程度、可見性等等。 A/B 測試通常用在應用的前端上,不過當然需要后端來支持。

A/B 測試與藍綠部署的區別在于, A/B 測試目的在于通過科學的實驗設計、采樣樣本代表性、流量分割與小流量測試等方式來獲得具有代表性的實驗結論,并確信該結論在推廣到全部流量可信;藍綠部署的目的是安全穩定地發布新版本應用,并在必要時回滾。

3. 金絲雀發布

我們平常所說的金絲雀部署也是灰度發布的一種方式,在原有版本可用的情況下,同時部署一個新版本應用作為「金絲雀」服務器來測試新版本的性能和表現,以保障整體系統穩定的情況下,盡早發現、調整問題。

礦井中的金絲雀:17 世紀,英國礦井工人發現,金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯,金絲雀也會停止歌唱;當瓦斯含量超過一定限度時,雖然魯鈍的人類毫無察覺,金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下,工人們每次下井都會帶上一只金絲雀作為瓦斯檢測指標,以便在危險狀況下緊急撤離。

灰度發布/金絲雀發布由以下幾個步驟組成:

  • 準備好部署各個階段的工件,包括:構建工件,測試腳本,配置文件和部署清單文件。
  • 從負載均衡列表中移除掉「金絲雀」服務器。
  • 升級「金絲雀」應用(排掉原有流量并進行部署)。
  • 對應用進行自動化測試。
  • 將「金絲雀」服務器重新添加到負載均衡列表中(連通性和健康檢查)。
  • 如果「金絲雀」在線使用測試成功,升級剩余的其他服務器(否則就回滾)。

除此之外灰度發布還可以設置路由權重,動態調整不同的權重來進行新老版本的驗證。

4. 優勢和不足

  • 優勢

用戶體驗影響小,灰度發布過程出現問題只影響少量用戶。

  • 不足

發布自動化程度不夠,發布期間可引發服務中斷。

滾動發布(Rolling Update Deployment)

在金絲雀發布基礎上的進一步優化改進,是一種自動化程度較高的發布方式,用戶體驗比較平滑,是目前成熟型技術組織所采用的主流發布方式。

1. 定義

滾動發布:一般是取出一個或者多個服務器停止服務,執行更新,并重新將其投入使用。周而復始,直到集群中所有的實例都更新成新版本。

2. 特點

這種部署方式相對于藍綠部署,更加節約資源——它不需要運行兩個集群、兩倍的實例數。我們可以部分部署,例如每次只取出集群的 20% 進行升級。

3. 部署過程

  • 滾動式發布一般先發 1 臺,或者一個小比例,如 2% 服務器,主要做流量驗證用,類似金絲雀 (Canary) 測試。
  • 滾動式發布需要比較復雜的發布工具和智能 LB,支持平滑的版本替換和流量拉入拉出。
  • 每次發布時,先將老版本 V1 流量從 LB 上摘除,然后清除老版本,發新版本 V2,再將 LB 流量接入新版本。這樣可以盡量保證用戶體驗不受影響。
  • 一次滾動式發布一般由若干個發布批次組成,每批的數量一般是可以配置的(可以通過發布模板定義)。例如第一批 1 臺(金絲雀),第二批 10%,第三批 50%,第四批 100%。每個批次之間留觀察間隔,通過手工驗證或監控反饋確保沒有問題再發下一批次,所以總體上滾動式發布過程是比較緩慢的 (其中金絲雀的時間一般會比后續批次更長,比如金絲雀 10 分鐘,后續間隔 2 分鐘)。
  • 回退是發布的逆過程,將新版本流量從 LB 上摘除,清除新版本,發老版本,再將 LB 流量接入老版本。和發布過程一樣,回退過程一般也比較慢的。

4. 優勢和不足

  • 優勢

用戶體驗影響小,體驗較平滑。

  • 不足

發布和回退時間比較緩慢。
發布工具比較復雜,LB 需要平滑的流量摘除和拉入能力。

其它發布方式

上述都是偏傳統的發布方式,能覆蓋大部分應用發布場景。針對一些關鍵新功能的上線發布,或者一些特定的場景,還有一些特殊的發布方式。

功能開關發布

利用代碼中的功能開關(Feature Flag/Toggle/Switch)來控制發布邏輯,一般不需要復雜的發布工具和智能 LB 配合,是一種相對比較低成本和簡單的發布方式。這種方式也是支持現代 DevOps 理念,研發人員可以靈活定制和自助完成的發布方式。功能開關的原理如下圖所示:

1. 部署過程

  • 功能開關發布需要一個配置中心或者開關中心這樣的服務支持,例如攜程的 Apollo 配置中心或者開源的 FF4J,這些都支持開關發布。業界還有專門的功能開關 SaaS 服務,例如 LaunchDarkly。通過配置中心,運維或研發人員可以在運行期動態配置功能開關的值。當然,功能開關發布只是配置中心的一種使用場景,配置中心還能支持其它很多動態配置場景。
  • 功能開關服務一般提供客戶端 SDK,方便開發人員集成。在運行期,客戶端 SDK 會同步最新的開關值,技術實現有推方式 (push),也有拉方式 (pull),或者推拉結合方式。
  • 新功能(V2 new feature)和老功能(V1 old feature)住在同一套代碼中,新功能隱藏在開關后面,如果開關沒有打開,則走老代碼邏輯,如果開關打開,則走新代碼邏輯。技術實現上可以理解為一個簡單的 if/else 邏輯。
  • 應用上線后,開關先不打開,然后運維或研發人員通過開關中心打開新功能,經過流量驗證新功能沒有問題,則發布完成;如果有問題,則隨時可以通過開關中心切回老功能邏輯。

2. 優勢和不足

  • 優勢

升級切換和回退速度非常快。
相對于復雜的發布工具,實施比較簡單,成本相對低廉。
研發能夠靈活定制發布邏輯,支持 DevOps 自助發布。

  • 不足

切換是全量的,如果 V2 版本有問題,則對用戶體驗有直接影響。
對代碼有侵入,代碼邏輯會變復雜,需要定期清理老版本邏輯,維護成本變高。

影子測試

對于一些涉及核心業務的遺留系統的升級改造,為了確保萬無一失,有一種稱為影子測試的大招,采用比較復雜的流量復制、回放和比對技術實現。下面是影子測試的一個樣例架構圖:

1. 部署過程

影子測試一般適用于遺留系統的等價重構遷移,例如 .net 轉 Java,或者 SQLServer 數據庫升級為 MySQL 數據庫,且外部依賴不能太多,否則需要開發很多 mock,測試部署成本會很高,且比對測試更加復雜和不穩定。

  • 目標實現老的 legacy 服務遷移升級到新的 experimental 服務。
  • 測試開始前,需要在測試環境部署一份 legacy 服務和 experimental 服務,同時將生產數據庫復制兩份到測試環境。同時需要將生產請求日志收集起來,一般可以通過 kafka 隊列收集,然后通過類似 goreplay 這樣的工具,消費 kafka 里頭的請求日志,復制回放,將請求分發到 legacy 服務和 experimental 服務,收到響應后進行比對,如果所有響應比對成功,則可以認為 legacy 服務和 experimental 服務在功能邏輯上是等價的;如果有響應比對失敗,則認為兩者在功能邏輯上不等價,需要修復 experimental 并重新進行影子測試,直到全部比對成功。根據系統復雜度和關鍵性不同,比對測試時間短的可能需要幾周,長的可達半年之久。
  • 影子測試因為旁路在獨立測試環境中進行,可以對生產流量完全無影響。

2. 優勢和不足

  • 優勢

對生產用戶體驗完全無影響。
可以使用生產真實流量進行測試(復制比對)。

  • 不足

搭建復雜度很高,技術門檻高,數據庫的導出復制是難點。
外部依賴不能太多,否則測試部署成本很高,且比對測試更加復雜和不穩定。

黑豹之月彩金 云南11选5基本走势图 乐彩合买可靠吗 腾讯分分彩开奖结果 内蒙古11选5预测软件 裂变原创赚钱教学 28加拿大 456棋牌app qq分分彩是合法彩票吗 福建11选5 有没有读书好的赚钱分享平台 迪拜五分彩走势图 股票涨跌最简单公式 时时彩开奖号大小单双质合统计 江苏11选5有什么规律么 想在股市里赚钱 体彩陕西十一选五开奖结果