服務升級機制
在項目敏捷開發的過程中，不可避免需要快速、安全的更新應用，目前比較流行的幾種部署方案有: 滾動發佈、灰度發佈/金絲雀發佈和藍綠部署。
-
滾動發佈（目前中信銀行內部生產環境交易系統的發佈方式）：
一般是取出一個或者多個服務器停止服務，執行更新，並重新將其投入使用。周而復始，直到集羣中所有的實例都更新成新版本。
這種部署方式相對於藍綠部署，更加節約資源——它不需要運行兩個集羣、兩倍的實例數。我們可以部分部署，例如每次只取出集羣的20%進行升級。
這種方式也有很多缺點，例如：
-
沒有一個確定OK的環境。使用藍綠部署，我們能夠清晰地知道老版本是OK的，而使用滾動發佈，我們無法確定。
-
修改了現有的環境。
-
如果需要回滾，比較麻煩。舉個例子，在某一次發佈中，我們需要更新100個實例，每次更新10個實例，每次部署需要5分鐘。當滾動發佈到第80個實例時，才發現問題，需要回滾。此時，脾氣不好的運維人員很可能想掀桌子，因爲回滾是一個痛苦，並且漫長的過程。
-
有的時候，我們還可能對系統進行動態伸縮，如果部署期間，系統自動擴容/縮容了，我們還需判斷到底哪個節點使用的是哪個代碼。儘管有一些自動化的運維工具，但是依然令人心驚膽戰。
並不是說滾動發佈不好，滾動發佈也有它非常合適的場景。
-
-
灰度發佈（又名金絲雀發佈）
是指在黑與白之間，能夠平滑過渡的一種發佈方式。 在其上可以進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，如果用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把所有用戶都遷移到B上面來。–維基百科
灰度發佈中，常常按照用戶設置路由權重，例如90%的用戶維持使用老版本，10%的用戶嚐鮮新版本。不同版本應用共存，經常與A/B測試一起使用，用於測試選擇多種方案。這裏舉一個灰度發佈比較典型的例子：
我們希望上線一個PLMP系統的新的功能，需要修改dlp-personal服務，但是隻有我們自己的用戶liweiwu驗證通過後才能給所有用戶使用。
-
線上正在運行服務 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的轉發規則
- 結束流程。