部署釋出的幾種思路：運維司機們，您都理解對了嗎
阿新 • • 發佈：2018-12-23
文章背景
- 滾動部署、藍綠部署、灰度釋出/金絲雀釋出、A/B測試等名詞在講述“微服務”、“DevOps”，甚至更抽象的“Cloud-native”的交付時可能會有所涉及，學習這幾個名詞作為基礎打底；
- 有幾篇網路上瀏覽量較高的文章在這幾者的所謂“對比說明”中，槽點太多，故而有了本文作為概念層面的糾正。
我們先明確一個概念，這些名詞為兩類：部署 VS 分佈。
部署，針對環境而言；釋出則是一種策略，需要在業務層面理解，包含如何釋出、如何回滾、釋出那些功能、哪些使用者可以使用等等。
好了，先聊聊部署。
Blue/Green Deployment（藍綠部署）
從過去到現在，藍綠部署模式因為安全、可靠的實用特徵，在很多大企業中落了地。
步驟：
- 準備藍、綠兩個相同環境，藍色跑舊版。
- 部署v1（藍），此時v1成為外部請求流量的靶子。
- 部署v2（綠），此時v2狀態為“備用”（負載均衡的池裡把這些地址去掉），待v2啟動成功，則自動測試備用叢集的部署情況。
- v2（綠）狀態改成存貨，藍綠連線相同資料庫，進入了存活負載均衡池，隨後v1（藍）同樣操作。最終v2程式碼完成部署。
- 視情況進行資料庫遷移。
看似步驟麻煩，理解了還好。藍綠部署無需停機，風險相對較小。
不過藍綠部署在考慮到兩個環境的線上服務隨版本切換的特徵，版本一致性和資料的一致性保證非常重要。
另外，在非隔離基礎架構（VM、Docker等）上藍綠部署有一定毀滅性風險，不是高手要慎用。
滾動部署
滾動釋出，相對小眾的市場，一般是取出一個或者多個伺服器停止服務，執行更新，並重新將其投入使用。周而復始，直到叢集中所有的例項都更新成新版本。
之所以小眾，看缺點：
- 沒有一個環境確定ok，因為直接改了現有環境；
- 既然沒有環境確定ok，如果滾動釋出到了第90個例項，需要回滾……程式猿可能會摔鍵盤；
- 萬一部署期間系統自動做了動態伸縮，不好判斷哪個節點用了哪個程式碼。此時一款強大的自動化運維工具就派上用場了，but，有些運維部門沒有呢；
灰度釋出／金絲雀釋出
灰度釋出指版本在黑白之間平滑過渡，最傳神寫意的就是金絲雀部署。
“金絲雀部署”，在業界有兩種策略形式：
- 一種是部分伺服器升級到新的版本。這種形式的重點在於，接入閘道器要精確的匹配某個特徵的使用者（灰度）流量匯入到這批新版本叢集中；
- 另外一種是所有伺服器升級新的版本。這種形式的重點在於，接入閘道器要精確的匹配某個特徵的使用者（灰度）流量使用到新介面；
A/B Testing（AB測試）
A/B測試和藍綠部署是兩碼事，
A/B測試和藍綠部署是兩碼事，
A/B測試和藍綠部署是兩碼事，
重要的事情說三遍~
很多行業都有A/B測試的概念，A/B測試更像是使用者側的新舊版本機制，通過灰度一部分試驗客戶，使用A/B不同的效果，達到驗證不同版本在可用性、受歡迎程度、可見性等等實際表現上的對比。
A/B測試是推廣到全部流量可信新版前的科學驗證方式，facebook改版就用過這個方式；藍綠部署是直接釋出到可信新版。
A/B測試和藍綠部署可以同時使用，就像巢狀if，最後選定最受歡迎最靠譜的可信版本。
運維司機們，您看明白了嗎？
原文來自微信公眾號：DevOps研究院