微服務架構從入門到精通(四)微服務部署

       在微服務、DevOps、Cloud-native、系統部署等的討論中,藍綠髮布、A/B 測試、灰度發佈、滾動發佈、紅黑部署等概念經常被提到,它們究竟是什麼呢?

一、藍綠髮布

1.1 什麼是藍綠髮布

    藍綠髮布,英文名Blue Green Deployment,是一種最常見的0 downtime部署的方式,可以保證系統在不間斷提供服務的情況下上線的部署方式。

    藍綠部署原理上很簡單,就是通過冗餘來解決問題。通常生產環境需要兩組配置(藍綠配置),一組是active的生產環境的配置(綠配置),一組是inactive的配置(藍綠配置)。用戶訪問的時候,只會讓用戶訪問active的服務器集羣。當藍色環境(inactive)部署新版本應用,並進行測試。如果測試沒問題,就可以把負載均衡器/反向代理/路由指向藍色環境了。隨後需要監測新版本應用,也就是version2 是否有故障和異常。如果運行良好,就可以刪除version1 使用的資源。如果運行出現了問題,可以通過負載均衡器指向快速回滾到綠色環境。

1.2 藍綠髮布的弱點

使用藍綠部署需要注意的一些細節包括:

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

2、有可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況,如果在藍綠部署中協調不好這兩者,還是有可能導致服務停止;

3、需要提前考慮數據庫與應用部署同步遷移/回滾的問題。

4、藍綠部署需要有基礎設施支持。

5、在非隔離基礎架構( VM 、 Docker 等)上執行藍綠部署,藍色環境和綠色環境有被摧毀的風險。

6、另外,這種方式不好的地方還在於冗餘產生的額外維護、配置的成本,以及服務器本身運行的開銷。

1.3 藍綠髮布適用的場景

1、不停止老版本,額外搞一套新版本,等測試發現新版本OK後,刪除老版本。

2、藍綠髮布是一種用於升級與更新的發佈策略,部署的最小維度是容器,而發佈的最小維度是應用。

3、藍綠髮布對於增量升級有比較好的支持,但是對於涉及數據表結構變更等等不可逆轉的升級,並不完全合適用藍綠髮布來實現,需要結合一些業務的邏輯以及數據遷移與回滾的策略纔可以完全滿足需求。

二、灰度發佈/金絲雀發佈

2.1 什麼是灰度發佈

    灰度發佈是指在黑與白之間,能夠平滑過渡的一種發佈方式。灰度發佈是增量發佈的一種類型,灰度發佈是在原有版本可用的情況下,同時部署一個新版本應用作爲“金絲雀”,測試新版本的性能和表現,以保障整體系統穩定的情況下,儘早發現、調整問題。

灰度發佈結構圖:

灰度發佈運行流程圖:

2.2 灰度發佈/金絲雀發佈的幾個步驟

1、準備好部署各個階段的工件,包括:構建工件,測試腳本,配置文件和部署清單文件。

2、從負載均衡列表中移除掉“金絲雀”服務器。

3、升級“金絲雀”應用(排掉原有流量並進行部署)。

4、對應用進行自動化測試。

5、將“金絲雀”服務器重新添加到負載均衡列表中(連通性和健康檢查)。

6、如果“金絲雀”在線使用測試成功,升級剩餘的其他服務器。(否則就回滾)

灰度發佈可以保證整體系統的穩定,在初始灰度的時候就可以發現、調整問題,以保證其影響度。

2.3 灰度發佈/金絲雀部署適用的場景

1、不停止老版本,額外搞一套新版本,不同版本應用共存。

2、灰度發佈中,常常按照用戶設置路由權重,例如90%的用戶維持使用老版本,10%的用戶嚐鮮新版本。

3、經常與A/B測試一起使用,用於測試選擇多種方案。AB test就是一種灰度發佈方式,讓一部分用戶繼續用A,一部分用戶開始用B,如果用戶對B沒有什麼反對意見,那麼逐步擴大範圍,把所有用戶都遷移到B上面來。

三、滾動發佈

3.1 什麼是滾動發佈

    滾動發佈(rolling update)同樣是一種可以保證系統在不間斷提供服務的情況下上線的部署方式。和藍綠部署不同的是,滾動部署對外提供服務的版本並不是非此即彼,而是在更細的粒度下平滑完成版本的升級。

3.2 滾動發佈的步驟

        一般是取出一個或者多個服務器停止服務,執行更新,並重新將其投入使用。周而復始,直到集羣中所有的實例都更新成新版本。這種部署方式相對於藍綠部署,更加節約資源——它不需要運行兩個集羣、兩倍的實例數。我們可以部分部署,例如每次只取出集羣的20%進行升級。

3.2 滾動發佈的缺點

這種方式也有很多缺點,

(1) 上線過程中,兩個版本同時對外提供服務,不容易定位問題,同時容易造成數據錯亂。

(2) 升級或回滾以節點爲粒度,操作相對複雜。

(3) 如果需要回滾,很困難。舉個例子,在某一次發佈中,我們需要更新100個實例,每次更新10個實例,每次部署需要5分鐘。當滾動發佈到第80個實例時,發現了問題,需要回滾。回滾是一個痛苦,並且漫長的過程。

    總之,並不是說滾動發佈不好,滾動發佈也有它非常合適的場景。

四、紅黑部署(Red-Black Deployment)

       這是Netflix採用的部署手段,Netflix的主要基礎設施是在AWS上,所以它利用AWS的特性,在部署新的版本時,通過AutoScaling Group用包含新版本應用的AMI的LaunchConfiguration創建新的服務器。測試不通過,找到問題原因後,直接幹掉新生成的服務器以及Autoscaling Group就可以,測試通過,則將ELB指向新的服務器集羣,然後銷燬掉舊的服務器集羣以及AutoScaling Group。紅黑部署的好處是服務始終在線,同時採用不可變部署的方式,也不像藍綠部署一樣得保持冗餘的服務始終在線。

五、影子部署

       影子部署是指在版本A旁邊發佈版本B,將版本A進來的請求同時分發到版本B,同時對生產環境流量無影響。這是測試新特徵在產品負載上表現的很好用的方式。當滿足上線要求後,則觸發發佈新應用。

    這個技術配置非常複雜,而且需要特殊條件,尤其是分出請求。例如一個購物車平臺,如果你想影子測試支付服務,你可能最終會是用戶爲他們的訂單支付兩次。這種情況下,可以通過創建一個仿真的服務來重複響應用戶的請求。


    部署應用有很多種方法,實際採用哪種方式取決於需求和預算。當發佈到開發或者模擬環境時,重建或者滾動部署是一個好選擇。當發佈到生產環境時,滾動部署或者藍綠部署通常是一個好選擇,但是新平臺的主流程測試是必須的。

    藍綠部署和影子部署對預算有更高的要求,因爲需要雙倍資源。如果應用缺乏測試或者對軟件的功能和穩定性影響缺乏信心,那麼可以使用金絲雀部署或者AB測試或者影子發佈。如果業務需要根據地理位置、語言、操作系統或者瀏覽器特徵等這樣參數來給一些特定的用戶測試,那麼可以採用AB測試技術。

    切記,影子發佈很複雜,且需要額外工作來模擬響應分支流量請求,當可變操作調用外部依賴時這是必須的,這個技術在升級新數據庫是非常有用,使用影子流量來監控負載下的系統性能。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章