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