[分佈式管理] 部署升級策略

在分佈式系統的世界裡，一個服務有多個實例，所以部署或是升級一個服務也會變得比較麻煩。今天我們討論服務部署的模式。一般來說，有如下幾種：

• 停機部署（Big Bang / Recreate）： 把現有版本的服務停機，然後部署新的版本。
• 藍綠部署（Blue/Green /Stage）：部署好新版本後，把流量從老服務那邊切過來。
• 滾動部署（Rolling Update / Ramped）： 一點一點地升級現有的服務。
• 灰度部署（Canary）：把一部分用戶切到新版本上來，然後看一下有沒有問題。如果沒有問題就繼續擴大升級，直到全部升級完成。
• AB 測試（A/B Testing）：同時上線兩個版本，然後做相關的比較。

停機部署

停機部署其實是最簡單粗暴的方式，就是簡單地把現有版本的服務停機，然後部署新的版本。有時候，我們不得不使用這樣的方式來部署或升級多個服務。比如，新版本中的服務使用到了和老版本完全不兼容的數據表設計。這個時候，我們對生產有兩個變更，一個是數據庫，另一個是服務，而且新老版本互不兼容，所以只能使用停機部署的方式。這種方式的優勢是，在部署過程中不會出現新老版本同時在線的情況，所有狀態完全一致。停機部署主要是為了新版本的一致性問題。這種方式的問題是會停機，對用戶的影響很大。所以，一般來說，這種部署方式需要事前掛公告，選擇一個用戶訪問少的時間段來做。

藍綠部署

藍綠部署與停機部署最大的不同是，其在生產線上部署相同數量的新服務，然後當新的服務測試確認 OK 後，把流量切到新的服務這邊來。藍綠部署比停機部署好的地方是，它無需停機。我們可以看到這種部署方式，就是我們說的預發環境。在我以前的金融公司裡，也經常用這種方式，生產線上有兩套相同的集群，一套是 Prod 是真實服務的，另一套是 Stage 是預發環境，發佈發 Stage，然後把流量切到 Stage 這邊，於是 Stage 就成了 Prod，而之前的 Prod 則成了 Stage。有點像換頁似的。這種方式的優點是沒有停機，實時發佈和升級，也避免有新舊版本同時在線的問題。但這種部署的問題就是有點浪費，因為需要使用雙倍的資源（不過，這只是在物理機時代，在雲計算時代沒事，因為虛擬機部署完就可以釋放了）。另外，如果我們的服務中有狀態，比如一些緩存什麼的，停機部署和藍綠部署都會有問題。

滾動部署

滾動部署策略是指通過逐個替換應用的所有實例，來緩慢發佈應用的一個新版本。通常過程如下：在負載調度後有個版本 A 的應用實例池，一個版本 B 的實例部署成功，可以響應請求時，該實例被加入到池中。然後，版本 A 的一個實例從池中刪除並下線。這種部署方式直接對現有的服務進行升級，雖然便於操作，而且在緩慢地更新的過程中，對於有狀態的服務也是比較友好的，狀態可以在更新中慢慢重建起來。但是，這種部署的問題也是比較多的。在發佈過程中，會出現新老兩個版本同時在線的情況，同一用戶的請求可能在新老版中切換而導致問題。我們的新版程序沒有在生產線上經過驗證就上線了。在整個過程中，生產環境處於一個新老更替的中間狀態，如果有問題要回滾就有點麻煩了。如果在升級過程中，需要做別的一些運維工作，我們還要判斷哪些結點是老版本的，哪些結點是新版本的。這太痛苦了。因為新老版本的代碼同時在線，所以其依賴的服務需要同時處理兩個版本的請求，這可能會帶來兼容性問題。而且，我們無法讓流量在新老版本中切換。

灰度部署（金絲雀）

灰度部署又叫金絲雀部署。其得名來源於礦井中的金絲雀。17 世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱。而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在採礦設備相對簡陋的條件下，工人們每次下井都會帶上一隻金絲雀作為 " 瓦斯檢測指標 "，以便在危險狀況下緊急撤離。灰度部署是指逐漸將生產環境流量從老版本切換到新版本。通常流量是按比例分配的。例如 90% 的請求流向老版本，10% 的請求流向新版本。然後沒有發現問題，就逐步擴大新版本上的流量，減少老版本上的流量。除了切流量外，對於多租戶的平臺，例如雲計算平臺，灰度部署也可以將一些新的版本先部署到一些用戶上，如果沒有問題，擴大部署，直到全部用戶。一般的策略是，從內部用戶開始，然後是一般用戶，最後是大客戶。這個技術大多數用於缺少足夠測試，或者缺少可靠測試，或者對新版本的穩定性缺乏信心的情況下。把一部分用戶切到新版上來，然後看一下有沒有問題。如果沒有問題就繼續擴大升級，直到全部升級完成。

AB 測試

AB 測試和藍綠部署或是金絲雀灰度部署完全是不一樣的。AB 測試是同時上線兩個版本，然後做相關的比較。它是用來測試應用功能表現的方法，例如可用性、受歡迎程度、可見性等。藍綠部署是為了不停機，灰度部署是對新版本的質量沒信心。而 AB 測試是對新版的功能沒信心。注意，一個是質量，一個是功能。比如，網站 UI 大改版，推薦算法的更新，流程的改變，我們不知道新的版本否會得到用戶青睞或是能得到更好的用戶體驗，我們需要收集一定的用戶數據才能知道。於是我們需要在生產線上發佈兩個版本，拉一部分用戶過來當小白鼠，然後通過科學的觀測得出來相關的結論。AB 測試旨在通過科學的實驗設計、採樣樣本代表性、流量分割與小流量測試等方式來獲得具有代表性的實驗結論，並確信該結論在推廣到全部流量時可信。我們可以看到 AB 測試，其包含了灰度發佈的功能。也就是說，我們的觀測如果只是觀測有沒有 bug，那就是灰度發佈了。當然，如果我們複雜一點，要觀測用戶的一些數據指標，這完全也可能做成自動化的，如果新版本數據好，就自動化地切一點流量過來，如果不行，就換一批用戶（樣本）再試試。對於灰度發佈或是 AB 測試可以使用下面的技術來選擇用戶。瀏覽器 cookie。查詢參數。地理位置。技術支持，如瀏覽器版本、屏幕尺寸、操作系統等。客戶端語言。

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

藍綠部署也不錯，但需要額外的資源。如果應用缺乏測試或者對軟件的功能和穩定性影響缺乏信心，那麼可以使用金絲雀部署或者 AB 測試發佈。如果業務需要根據地理位置、語言、操作系統或者瀏覽器特徵等參數來給一些特定的用戶測試，那麼可以採用 AB 測試技術。

閱讀更多 程序員王哥 的文章

關鍵字: 美好，一直在身邊 雲計算 數據庫