服務公升級機制
在專案敏捷開發的過程中，不可避免需要快速、安全的更新應用，目前比較流行的幾種部署方案有: 滾動發布、灰度發布/金絲雀發布和藍綠部署。
滾動發布（目前某銀行內部生產環境交易系統的發布方式）：
一般是取出乙個或者多個伺服器停止服務，執行更新，並重新將其投入使用。周而復始，直到集群中所有的例項都更新成新版本。
這種部署方式相對於藍綠部署，更加節約資源——它不需要執行兩個集群、兩倍的例項數。我們可以部分部署，例如每次只取出集群的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 值可以為單個值或者字串列表
客戶場景的灰度發布
說明：
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布入門
我們的產品是個比較典型的網際網路產品，產品公升級採用 小步快跑 的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦...