在互聯網軟件的生產過程中有一環是必不可少的，那便是部署、發布。通過把代碼部署在特定環境中，再對外向用戶發布新功能。早期的時候互聯網剛剛發展起來，涌入互聯網的網民還比較少，服務器資源也比較昂貴、緊張，這時候的發布一般就是把舊版本下掉，然后再部署新版本，在發布期間，服務不可用。這樣的體驗其實不太好，因為發布期間我在這個應用上無法進行任何操作。

但隨著互聯網的快速發展，尤其是云計算起來之后，服務器資源變得不再昂貴了，互聯網企業們也更加的看重用戶體驗，要求7*24小時不停服提供服務，于是發布的方式也在演變，典型的發布方式包含藍綠發布、滾動發布、灰度發布（金絲雀發布）。我們今天就來看看這些發布方式吧～

·藍綠發布

在藍綠發布中，部署服務的機器包含綠組機器、藍組機器。在新版本上線之前，先將舊版本的代碼部署在綠組機器上，然后把流量指向綠組機器，之后再把新版本代碼部署在藍組機器上，把指向綠組機器的流量再指回藍組，發布過程如果出現問題，則回滾綠組機器或藍組機器即可。在整個發布過程中，應用一直在對外提供服務，因此用戶是無感的。藍綠發布的缺點就是資源會有點浪費，在開始發布之前，需要申請出等量的機器進行服務部署。

比如我們去餐館吃飯，點了紅燒排骨、土豆牛腩、西紅柿蛋湯，先上了紅燒排骨。在上新的菜土豆牛腩時，傳統發布是直接把紅燒排骨下掉，換上土豆牛腩。藍綠發布則是保留紅燒排骨，并同時把土豆牛腩端上來，讓我們都去吃土豆牛腩的同時，再把紅燒排骨下掉。在整個就餐的過程中，藍綠方式讓我們一直保持有菜可吃。

·滾動發布

在滾動發布過程中，我們是把原有部署服務的機器挑選出來1臺或多臺機器在這些機器上部署新的版本，部署成功后，又挑剩下的機器繼續部署新版本，如此循環往復，直到所有的機器都部署了最新的版本。這種部署方式的好處首先是不需要申請新的服務資源、節省成本，其次是在發布過程中并非所有的用戶都會受影響、一定程度保障了用戶體驗。但是也存在一些缺點，如果發布過程出現了問題，回滾很麻煩，要逐臺找到機器并且回滾。

滾動發布的方式就像是我們在餐館吃飯時，上了紅燒排骨之后、又上土豆牛腩、西紅柿蛋湯，在整個上菜的過程中，有的人吃到的是紅燒排骨，有的人是土豆牛腩，直到服務員確認所有的土豆牛腩都上齊后，才會把紅燒排骨下掉。如果服務員上錯菜了，那就呵呵了，需要去找到上錯菜的桌子，一盤盤的撤下，用戶會很莫名其妙，服務員也會很辛苦。

·灰度發布

灰度發布也稱為金絲雀發布，是在互聯網中比較常用的一種發布方式，尤其是C端產品。ABtest就是一種灰度發布方式，在新產品上線之后，讓一部分用戶用A，剩下的用戶用B，如果用戶對A沒有什么反對意見，則把剩下的用戶都切換A版本。

在灰度發布中，我們先把要發布的代碼版本準備好，然后選擇一臺或一組服務器，切除掉流量（在負載均衡中把該臺或該組機器去掉），在該組機器部署新的版本，然后再在負載均衡中把該臺或該組機器加上，這時候就會有用戶訪問了，如果用戶使用都還不錯，則把剩下的機器按照剛剛的流程進行操作即可，直到線上的所有服務都是使用新版本。

灰度發布的方式就像是我們在餐館吃飯時，上了紅燒排骨之后，服務員先選擇某幾桌用戶把紅燒排骨下掉、上土豆牛腩看看用戶反饋，如果都吃的還不錯，就把剩下的所有餐桌的紅燒排骨下掉、換成土豆牛腩。

事實上，藍綠發布、滾動發布、灰度發布本質上還是一種部署行為，只不過是由于業務增加了對外周知用戶的環節，因此變成了發布。從部署這個角度看，它們不僅是在生產環境可用，在測試環境也可以使用。再從DevOps持續集成交付角度看，開發的代碼不斷集成到代碼庫，也需要不斷的部署在測試環境、生產環境中，因此它們仍然發揮著最大的價值。作為技術人員，可結合自己的企業情況，選擇最合適的發布策略～