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