灰度釋出、藍綠髮布、滾動釋出
灰度釋出、藍綠髮布、滾動釋出
在專案迭代的過程中，不可避免需要“上線”。上線對應著部署，或者重新部署；部署對應著修改；修改則意味著風險。目前有很多部署釋出的技術，總結如下：
藍綠髮布
藍綠部署中，一共有兩套系統：一套是正在提供服務的系統，標記為“綠色”；另一套是準備釋出的系統，標記為“藍色”。兩套系統都是功能完善的，並且正在執行的系統，只是系統版本和對外服務情況不同。正在對外提供服務的老系統是綠色系統，新部署的系統是藍色系統
藍色系統不對外提供服務，用於做釋出前測試，測試過程中發現任何問題，可以直接在藍色系統上修改，不干擾使用者正在使用的系統。
藍色系統經過反覆的測試、修改、驗證，確定達到上線標準之後，直接將使用者切換到藍色系統，切換後的一段時間內，，依舊是藍綠兩套系統共存，但是使用者訪問的已經是藍色系統，這段時間內觀察藍色系統（新系統）工作狀態，如果出現問題，直接切換回綠色系統。
當確信對外提供服務的藍色系統工作正常，不對外提供服務的綠色系統已經不再需要的時候，藍色系統正式稱為對外提供服務系統，稱為新的綠色系統。原先的綠色系統可以銷燬，將資源釋放出來。用於部署下一個藍色系統。
藍綠髮布特點
- 藍綠部署的目的是減少釋出時的中斷時間、能夠快速撤回釋出
- 兩套系統沒有耦合的時候才能百分百保證不干擾
藍綠髮布注意事項
藍綠部署只是上線策略中的一種，它不是可以應對所有情況的萬能方案。藍綠部署能夠簡單快捷實施的前提假設是目標系統是非常內聚的，如果目標系統相當複雜，那麼如何切換，兩套系統的資料是否需要以及如何同步等，都需要仔細考慮。
當切換到藍色環境時，需要妥當處理未完成的業務和新的業務。如果資料庫後端無法處理，會是一個比較麻煩的問題。
- 可能會出現需要同時處理“微服務架構應用”和“傳統架構應用”的情況，如果在藍綠部署中協調不好這兩者，可能會導致服務停止；
- 需要提前考慮資料庫與應用部署同步遷移/回滾的問題
- 藍綠部署需要有基礎設施支援
- 在非隔離基礎架構（VM、Docker等）上執行藍綠部署，藍色環境和綠色環境有被摧毀的風險
滾動釋出
一般是取出一個或多個伺服器停止服務，執行更新，並重新將其投入使用。周而復始，直到叢集中所有的例項都更新成新版本。
釋出流程：
相對於藍綠部署需要一套完備的機器，滾動釋出只需要一臺機器（可能是多臺），我們只需要將部分功能部署在這臺機器上，然後去替換正在執行的機器，如上圖，將更新後的功能部署在Server1上，然後Server1去替換正在執行的Server，替換下來的物理機又可以繼續部署Server2的新版本，然後去替換正在工作的Server2，以此類推，直到替換完所有的伺服器，至此，服務更新完成。
滾動釋出特點
- 這種部署方式相對於藍綠部署，更加節省資源——它不需要執行兩個叢集、兩倍的例項數。可以部分部署，例如每次只取出叢集的20%進行升級。
- 回滾困難
滾動釋出注意事項
- 滾動釋出沒有一個確定可行的環境。使用藍綠部署，可以清晰地知道老版本是可行的，而使用滾動升級，無法確定。
- 修改了現有的環境
- 回滾困難。例如，在某一次釋出中，我們需要更新100個例項，每次更新10個例項，每次部署需要5分鐘。當滾動釋出到第80個例項時，發現了問題，需要回滾，這個回滾確實一個痛苦且漫長的過程。
- 如果部署期間，系統自動擴縮容了，那麼還需要判斷到底哪個節點使用的是哪個程式碼。儘管有一些自動化的運維工具，但依然令人心驚膽戰。
- 由於是逐步更新，那麼我們在上線程式碼的時候，就會短暫出現新老版本不一致的情況，如果對上線要求較高的場景，那麼就需要考慮如何做好相容的問題。
灰度釋出
灰度釋出，也叫金絲雀釋出，是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度，而日常提到的金絲雀部署也是灰度釋出的一種方式。
具體到伺服器，實際操作中還可以做更多控制，譬如說，給最初更新的10臺伺服器設定較低的權重，控制傳送給這10臺伺服器的請求數，然後逐漸提高權重、增加請求數。一種平滑過渡的思路，這個控制叫做：流量切分。
17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在採礦裝置相對簡陋的條件下，工人們每次下井都會帶上一隻金絲雀作為“瓦斯探測指標”，以便在危險狀況下緊急撤離。
灰度釋出過程
- 準備好部署各個階段的工作，包括：構建工件、測試指令碼、配置檔案和部署清單檔案
- 將“金絲雀”伺服器部署到伺服器中，測試
- 從負載均衡列表中移除掉“金絲雀”伺服器
- 升級“金絲雀”應用（排掉原有流量並進行部署）
- 對應用進行自動化測試
- 將“金絲雀”伺服器重新新增到負載均衡列表中（連通性和健康檢查）
- 如果“金絲雀”線上使用測試成功，升級剩餘的其他伺服器（否則就回滾）
A/B測試
A/B測試和藍綠髮布、滾動釋出以及金絲雀釋出，完全是兩回事
藍綠髮布、滾動升級和金絲雀都是釋出策略，目標是確保新上線的系統穩定，關注的是新系統的BUG、隱患。
A/B測試是效果測試，同一時間有多個版本的服務對外服務，這些服務都是經過足夠測試，達到了上線標準的服務，有差異但是沒有新舊之分（它們上線時可能採用了藍綠部署的方式）
A/B測試關注的是不同版本的服務的實際效果，譬如說轉化率、訂單情況等
A/B測試時，線上同時執行多個版本的服務，這些服務通常會有一些體驗上的差異，譬如說頁面樣式、顏色、操作流程不同等。相關人員通過分析各個版本服務的實際效果，選出效果最好的版本。