如何理解灰度發佈

服務升級機制
  在項目敏捷開發的過程當中，不可避免須要快速、安全的更新應用，目前比較流行的幾種部署方案有: 滾動發佈、灰度發佈/金絲雀發佈和藍綠部署。

滾動發佈（目前某銀行內部生產環境交易系統的發佈方式）：

  通常是取出一個或者多個服務器中止服務，執行更新，並從新將其投入使用。周而復始，直到集羣中全部的實例都更新成新版本。

  這種部署方式相對於藍綠部署，更加節約資源——它不須要運行兩個集羣、兩倍的實例數。咱們能夠部分部署，例如每次只取出集羣的20%進行升級。

這種方式也有不少缺點，例如：

沒有一個肯定OK的環境。使用藍綠部署，咱們可以清晰地知道老版本是OK的，而使用滾動發佈，咱們沒法肯定。

修改了現有的環境。

若是須要回滾，比較麻煩。舉個例子，在某一次發佈中，咱們須要更新100個實例，每次更新10個實例，每次部署須要5分鐘。當滾動發佈到第80個實例時，才發現問題，須要回滾。此時，脾氣很差的運維人員極可能想掀桌子，由於回滾是一個痛苦，而且漫長的過程。

有的時候，咱們還可能對系統進行動態伸縮，若是部署期間，系統自動擴容/縮容了，咱們還需判斷到底哪一個節點使用的是哪一個代碼。儘管有一些自動化的運維工具，可是依然使人心驚膽戰。

並非說滾動發佈很差，滾動發佈也有它很是合適的場景。

灰度發佈（又名金絲雀發佈）

 

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

 

是指在黑與白之間，可以平滑過渡的一種發佈方式。 在其上能夠進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。–維基百科

  灰度發佈中，經常按照用戶設置路由權重，例如90%的用戶維持使用老版本，10%的用戶嚐鮮新版本。不一樣版本應用共存，常常與A/B測試一塊兒使用，用於測試選擇多種方案。這裏舉一個灰度發佈比較典型的例子：

  咱們但願上線一個PLMP系統的新的功能，須要修改dlp-personal服務，可是隻有咱們本身的用戶limoumou驗證經過後才能給全部用戶使用。

線上正在運行服務 dlp-personal-A，新部署一個服務 dlp-personal-B，使用新版本的Image和ConfigMap

去負載均衡器頁面修改轉發規則，新增 header 轉發規則將 token=liweiwu 的流量分配給 dlp-personal-B，剩餘流量給 dlp-personal-A

登陸 liweiwu 用戶進行相關測試，發現問題進行修改並更新 dlp-personal-B 的Image和ConfigMap，直至驗證經過

修改 dlp-personal-A 的Image和ConfigMap與 dlp-personal-B 一致

刪除負載均衡器上的轉發規則，全部流量指向服務 dlp-personal-A

刪除服務 dlp-personal-B

Blue/Green Deployment（藍綠部署）

藍綠部署無需停機，而且風險較小。

舊版本的應用（一開始的狀態）

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

部署新版的應用

新版本的Image或ConfigMap和舊版本不一樣

將流量所有從舊切換到新版本上。

測試

如新版本測試正常，就刪除舊版本正在使用的資源（例如實例），今後正式用新版本。

從過程不難發現，在部署的過程當中，咱們的應用始終在線。而且，新版本上線的過程當中，並無修改老版本的任何內容，在部署期間，老版本的狀態不受影響。這樣風險很小，而且，只要老版本的資源不被刪除，理論上，咱們能夠在任什麼時候間回滾到老版本。可是須要指出的是，這種方式會佔有更多的資源。

我司的灰度發佈
發佈策略的設定由規則和權重分配組成。具體功能描述以下：

 

 

圖 1 灰度發佈的策略和規則

規則集：

轉發規則和服務分離

每一個 policy 分爲兩部分，第一部分爲匹配規則集合部分，第二部分爲權重部分，每一個請求當知足第一部分的匹配規則後按照第二部分的權重將流量轉發到多個服務，若是權重部分只有一個服務則百分之百轉發到一個服務。

一條 policy 中能夠有多個規則，規則之間是 and 關係

不一樣 policy 之間存在優先級，請求匹配了第一個 policy 則不會再匹配第二個 policy

我司的藍綠髮布
  藍綠部署能夠做爲灰度發佈權重規則的一種特殊形式，經過調整兩個服務的請求量比例來控制線上是藍版本仍是綠版本。經過設置權重 X 爲 100 或者 0 來達到藍綠切換。

 

 

目前支持的策略集合
域名分配：

域名值能夠是單個域名或者一個域名列表

權重分配：

A 服務分配 X% 流量，B 服務分配剩餘 （1-X）% 流量

URL 分配：

URL 值能夠是一個單獨字符串，或者一個字符串列表，或者正則表達式

IP 分配：

    源 IP 屬於某一指定 IP 集合的流量分配給服務 A，其他流量分配給服務 B，能夠爲單個 IP，IP 列表或者 IP 範圍

URL param 分配：

    根據 url 某一個參數值的範圍進行分配，例如 url 包含參數 uid=1 的流量分配給服務 A，其他流量分配給服務 B，param 值能夠爲單個值或者字符串列表

Header 分配：

    根據某一 header 值的範圍進行分配，例如 header 包含 agent=chrome 流量分配給服務 A，其他流量分配給服務 B，header 值能夠爲單個值或者字符串列表

客戶場景的灰度發佈

 

 

說明：

應用管理員提交本身應用的灰度發佈 雙人複覈工單。
複覈人員，審批經過。
應用管理員在工單列表裏找到審批經過的工單，頁面中點擊繼續，進入應用更新的頁面，提交後當即更新應用。回到雙人複覈工單頁面。
應用管理員在工單列表裏找到剛剛操做的工單，頁面中點擊繼續，進入ALB的設置頁面，提交修改後，立刻更新ALB。
測試新的應用（項目組一塊兒確認，由複覈人員確認是否無誤）
如確認版本無誤，由應用管理員在雙人複覈工單列表裏找到剛剛操做的工單，頁面中點擊繼續，最後一次更新應用；如版本有誤，由應用管理員在雙人複覈工單列表裏找到剛剛操做的工單，頁面中點擊繼續，回到第3步。
刪除ALB的轉發規則
結束流程。

 

 

 

 

————————————————原文連接：https://blog.csdn.net/xialingming/article/details/83348382