藍綠紅黑灰|經常使用的發佈方式

1 發佈之痛

相信每一個程序員都曾經經歷過，或正在經歷過發佈的痛苦，每一個發佈日的夜晚一般是燈火通明。在如今互聯網公司較高的發佈頻率之下更是放大了這種痛苦，多少正值青春年華的程序員爲此白了發、禿了頭！讓程序員經歷發佈痛苦的緣由有不少，其中之一就是發佈方式。
發佈形成系統故障影響系統可用性的最大緣由之一。所以大多數的公司會選擇在用戶量最小的深夜進行發佈，這就形成了每到發佈日就有一大堆黑眼圈的程序員熬夜坐等發佈，但其實有了一些好的發佈方式也許就沒必要如此。
我曾經帶過兩家公司，這兩家公司團隊的對於發佈時間的見解則孑然不一樣，第一家公司的老是擔憂發佈會對用用戶形成影響，所以每次發佈都會選擇深夜進行發佈。而另外一家公司則認爲應該在用戶流量最大的時候進行發佈，這樣系統問題則能夠儘早的暴露出來。形成這兩種的結果我分析有不少緣由。開發人員信心、交付質量、資源工具、發佈方式......咱們今天就來看看一些經常使用的發佈方式。

2 經常使用的發佈方式

2.1 蠻力發佈

顧名思義，這種方式簡單而粗暴！直接將新的版本覆蓋掉老的版本。其優勢就是簡單並且成本較低，但缺點一樣很明顯，就是發佈過程當中一般會致使服務中斷進而致使用戶受到影響，這種方式比較適應於開發環境或者測試環境或者是公司內部系統這種對可用性要求不高的場景，有些小的公司資源稀缺(服務器資源，基礎設施等)的時候也會採用這種方式。好比個人第一家公司一開始的規模較小的時候，一般會選擇一個夜深人靜、訪問量小的時候，悄悄地發佈。

2.2 金絲雀發佈

金絲雀發佈是灰度發佈的一種。灰度發佈是指在黑與白之間，可以平滑過渡的一種發佈方式。即在發佈過程當中一部分用戶繼續使用老版本，一部分用戶使用新版本，不斷地擴大新版本的訪問流量。最終實現老版本到新版本的過分。因爲金絲雀對瓦斯極其敏感，所以之前曠工開礦下礦洞前，先會放一隻金絲雀進去探是否有有毒氣體，看金絲雀可否活下來，金絲雀發佈由此得名。

發佈過程當中，先發一臺或者一小部分比例的機器做爲金絲雀，用於流量驗證。若是金絲雀驗證經過則把剩餘機器所有發掉。若是金絲雀驗證失敗，則直接回退金絲雀。金絲雀發佈的優點在於能夠用少許用戶來驗證新版本功能，這樣即便有問題所影響的也是很小的一部分客戶。若是對新版本功能或性能缺少足夠信心那麼就能夠採用這種方式。這種方式也有其缺點，金絲雀發佈本質上仍然是一次性的全量發佈，發佈過程當中用戶體驗並不平滑，有些隱藏深處的bug少許用戶可能並不能驗證出來問題，須要逐步擴大流量才能夠。

2.3 滾動發佈

滾動發佈是在金絲雀發佈基礎上進行改進的一種發佈方式。相比於金絲雀發佈，先發金絲雀，而後全發的方式，滾動發佈則是整個發佈過程當中按批次進行發佈。每一個批次拉入後均可做爲金絲雀進行驗證，這樣流量逐步放大直至結束。
這種方式的優勢就是對用戶的影響小，體驗平滑，但一樣也有不少缺點，首先就是發佈和回退時間慢，其次發佈工具複雜，負載均衡設備須要具備平滑的拉入拉出能力，通常公司並無資源投入研發這種複雜的發佈工具。再者
發佈過程當中新老版本同時運行，須要注意兼容性問題。

2.4 藍綠部署

藍綠部署，是採用兩個分開的集羣對軟件版本進行升級的一種方式。它的部署模型中包括一個藍色集羣 Group1 和一個綠色集羣 Group2，在沒有新版本上線的狀況下，兩個集羣上運行的版本是一致的，同時對外提供服務。
系統升級時，藍綠部署的流程是：

• 從負載均衡器列表中刪除集羣Group1，讓集羣 Group2 單獨提供服務。
• 在集羣 Group1 上部署新版本。
• 集羣 Group1 升級完畢後，把負載均衡列表所有指向 Group1，並刪除集羣 Group2 ，由 Group1 單獨提供服務。
• 在集羣 Group2 上部署完新版本後，再把它添加回負載均衡列表中。

這樣，就完成了兩個集羣上全部機器的版本升級。
藍綠部署的優勢是升級和回退速度很是快，缺點是全量升級，若是V2版本有問題，對用戶影響大再者因爲升級過程當中會服務器資源會減小一半，有可能產生服務器過載問題，所以這種發佈方式也不適用於在業務高峯期使用。

2.5 紅黑髮布

與藍綠部署相似，紅黑部署也是經過兩個集羣完成軟件版本的升級。當前提供服務的全部機器都運行在紅色集羣 Group1 中，當須要發佈新版本的時候，具體流程是這樣的：

• 先申請一個黑色集羣 Group2 ，在 Group2 上部署新版本的服務；
• 等到 Group2 升級完成後，咱們一次性地把負載均衡所有指向 Group2 ；
• 把 Group1 集羣從負載均衡列表中刪除，並釋放集羣 Group1 中全部機器。這

這樣就完成了一個版本的升級。能夠看到，與藍綠部署相比，紅黑部署得到了兩個收益：一是，簡化了流程；二是，避免了在升級的過程當中，因爲只有一半的服務器提供服務，而可能致使的系統過載問題。但一樣也存在全量升級對用戶的影響問題，也帶來了一個新的問題，就是發佈過程當中須要兩倍的服務器資源。

2.6 功能開關

這種發佈方式是利用代碼中的功能開關來控制發佈邏輯，是一種相對比較低成本和簡單的發佈方式。研發人員能夠靈活定製和自助完成的發佈方式。這種方式一般依賴於一個配置中心繫統，固然若是沒有，可使用簡單的配置文件。

應用上線後，開關先不打開，只待一聲令下，能夠全量打開開關，也能夠按照某種維度(公司ID，用戶ID等)分批打開開關進行流量驗證，若是有問題，則隨時關閉開關。
這種方式的優點在於升級切換和回退速度很是快，並且相對於複雜的發佈工具，成本較爲低廉。可是也有很大的不足之處，就是開關自己也是代碼，並且是與業務無關的代碼，對代碼的侵入性較高，也必須按期清理老版本的邏輯，使得維護成本增長。

3 小結

這篇文章介紹了目前經常使用的一些發佈方式，每種發佈方式各有其優缺點。但其實在真正實踐過程當中這些發佈方式每每是根據具體的狀況來結合使用的。主要能夠經過升級回退速度、成本、對用戶影響三個方面來考慮。 好比在我最開始的小型公司裏，公司業務小，服務器資源也不足，甚至連最基礎的負載均衡服務器都沒有，這個時候咱們的發佈一般是選擇一個流量小的時候進行蠻力發佈的，這個時候也許會對用戶形成短暫的影響，但那個時候的咱們是沒有人力物力財力......去搞後面那些複雜的方式的。 然後來的某廠裏有着充足的資源，咱們有着多服務器羣組，各類強大的發佈工具......，一般咱們是結合具體場景來選擇合適的發佈方式的。最經常使用的其中就是金絲雀發佈和滾動發佈。而在有些時候因爲集羣中的請求是隨機分發的你並不能保證同一個用戶的上一個請求和下一個請求還在同一個服務器上，這時若是舊的版本不能兼容新的版本的時候，若是是在業務流量低的時候，咱們會考慮採用藍綠部署的方式，若是在流量高峯期則會採用紅黑髮布的方式來避免服務器過載。 而針對一些特殊的功能也常常會採用滾動發佈+功能功能開關的方式。新版本發上去以後，逐步打開開關驗證。 總之，各類發佈方式的本質目的都是爲了提升咱們的發佈效率，保持系統可用性，減小對用戶的影響可以讓用戶平滑的過渡到新的版本。