《部署發布的幾種思路：運維司機們，您都理解對了嗎》要點：
本文介紹了部署發布的幾種思路：運維司機們，您都理解對了嗎，希望對您有用。如果有疑問，可以聯系我們。

文章背景

1. 滾動部署、藍綠部署、灰度發布/金絲雀發布、A/B測試等名詞在講述“微服務”、“DevOps”,甚至更抽象的“Cloud-native”的交付時可能會有所涉及,學習這幾個名詞作為基礎打底；
2. 有幾篇網絡上瀏覽量較高的文章在這幾者的所謂“對比說明”中,槽點太多,故而有了本文作為概念層面的糾正.

我們先明確一個概念,這些名詞為兩類：部署 VS 分布.

部署,針對環境而言；發布則是一種策略,需要在業務層面理解,包含如何發布、如何回滾、發布那些功能、哪些用戶可以使用等等.

好了,先聊聊部署.

Blue/Green Deployment(藍綠部署)

從過去到現在,藍綠部署模式因為安全、可靠的實用特征,在很多大企業中落了地.

步驟：

1. 準備藍、綠兩個相同環境,藍色跑舊版.
2. 部署v1(藍),此時v1成為外部請求流量的靶子.
3. 部署v2(綠),此時v2狀態為“備用”(負載均衡的池里把這些地址去掉),待v2啟動成功,則自動測試備用集群的部署情況.
4. v2(綠)狀態改成存貨,藍綠連接相同數據庫,進入了存活負載均衡池,隨后v1(藍)同樣操作.最終v2代碼完成部署.
5. 視情況進行數據庫遷移.

看似步驟麻煩,理解了還好.藍綠部署無需停機,風險相對較小.

不過藍綠部署在考慮到兩個環境的在線服務隨版本切換的特征,版本一致性和數據的一致性保證非常重要.

另外,在非隔離基礎架構(VM、Docker等)上藍綠部署有一定毀滅性風險,不是高手要慎用.

滾動部署

滾動發布,相對小眾的市場,一般是取出一個或者多個服務器停止服務,執行更新,并重新將其投入使用.周而復始,直到集群中所有的實例都更新成新版本.

之所以小眾,看缺點：

1. 沒有一個環境確定ok,因為直接改了現有環境；
2. 既然沒有環境確定ok,如果滾動發布到了第90個實例,需要回滾……程序猿可能會摔鍵盤；
3. 萬一部署期間系統自動做了動態伸縮,不好判斷哪個節點用了哪個代碼.此時一款強大的自動化運維工具就派上用場了,but,有些運維部門沒有呢；

灰度發布／金絲雀發布

灰度發布指版本在黑白之間平滑過渡,最傳神寫意的就是金絲雀部署.

“金絲雀部署”,在業界有兩種策略形式：

1. 一種是部分服務器升級到新的版本.這種形式的重點在于,接入網關要精確的匹配某個特征的用戶(灰度)流量導入到這批新版本集群中；
2. 另外一種是所有服務器升級新的版本.這種形式的重點在于,接入網關要精確的匹配某個特征的用戶(灰度)流量使用到新接口；

A/B Testing(AB測試)

A/B測試和藍綠部署是兩碼事,
A/B測試和藍綠部署是兩碼事,
A/B測試和藍綠部署是兩碼事,
重要的事情說三遍~

很多行業都有A/B測試的概念,A/B測試更像是用戶側的新舊版本機制,通過灰度一部分試驗客戶,使用A/B不同的效果,達到驗證不同版本在可用性、受歡迎程度、可見性等等實際表現上的對比.

A/B測試是推廣到全部流量可信新版前的科學驗證方式,facebook改版就用過這個方式；藍綠部署是直接發布到可信新版.

A/B測試和藍綠部署可以同時使用,就像嵌套if,最后選定最受歡迎最靠譜的可信版本.

運維司機們,您看明白了嗎?

原文來自微信公眾號：DevOps研究院

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4304.html