一篇文章說盡全部軟件發佈

高效能組織和低效能組織在軟件交付的效率上有數量級上的差別。技術組織的軟件交付能力是一種綜合能力，涉及衆多環節，其中發佈是尤其重要的環節。——魯迅

                                                                   

 

 　　即便做爲非開發工程師，相信不少人也據說過「金絲雀發佈」、「滾動發佈」和「藍綠髮布」等術語。一個穩定、可控、靈活、用戶體驗良好的發佈流程是發佈流程的一個較爲理想狀態

　　老司機想經過一篇文字給各位分享一下常見的幾種發佈模式，讓開發或者非開發人員對軟件發佈一個更爲清晰全面的認識，讓你們可以根據本身的所在團隊的狀況，對發佈策略給出正確的實踐，必要時候參與討（si）論（bi）。

　　

一、 金絲雀發佈

 

金絲雀 (Canary) 測試。源於之前礦工下礦洞前，先會放一隻金絲雀進去探是否有有毒氣體，看金絲雀可否活下來，由此得名。

 

 

簡單的金絲雀測試通常經過手工測試驗證，複雜的金絲雀測試須要比較完善的監控基礎設施配合，經過監控指標反饋，觀察金絲雀的健康情況，做爲後續發佈或回退的依據。

 

金絲雀發佈，通常先把新版本發佈到單集羣1臺服務器，或者一個小比例，主要作流量驗證用。

若是金絲測試經過，則把剩餘的原有版本所有升級爲新版本。若是金絲雀測試失敗，則直接摘除金絲雀的流量，宣佈發佈失敗。

    

金絲雀發佈，簡單可控不粗暴！初創型公司比較適合。

 

二、 一羣金絲雀發佈

 

單服務器集羣滾動發佈，老司機給起個名字叫「一羣金絲雀發佈」。

單服務器集羣滾動發佈，在金絲雀發佈基礎上的進一步優化改進，是一種自動化程度較高的發佈方式，用戶體驗比較平滑，是目前成熟型技術組織所採用的主流發佈方式。

前提：滾動發佈須要比較複雜的發佈工具和智能 LB，支持平滑的版本替換和流量拉入拉出

 

單服務器集羣滾動發佈實踐起來這樣的：

1. 先發 1 臺，或者一個小比例，主要作流量驗證用，是否是很像金絲雀 (Canary) 測試；

2. 每次發佈時，先將老版本流量從LB上摘除，清除老版本，發佈新版本，再將LB流量接入新版本；

3. 滾動式發佈每次操做通常由若干個批次組成，每批的數量通常是能夠預設的（使用發佈模板設定）。例如：第一批2%，第二批10%，第三批50%，第四批100%。每批上線之間留觀察間隔，經過人工驗證或監控反饋確保沒有問題，再發下一批次。因此整體上滾動式發佈過程是可控的 (其中第一批的時間通常會比以後的批次更長)；

4. 回退過程：將新版本流量從LB上摘除，清除新版本，替換上老版本發佈，再將LB 流量接入老版本。和發佈過程同樣，回退過程通常也比較可控的；

 

滾動發佈學名叫 Rolling Update Deployment。

在老司機看來，像是先放一隻金絲雀，看看沒問題？再放10只金絲雀，還沒問題？再放N只… 直到整個礦井充滿了金絲雀…

 

上面說的是單服務器集羣的滾動發佈，後面會講多服務器集羣的滾動發佈。

 

    以上說的都是單服務器集羣的發佈模式，下面講講雙組服務器集羣的發佈模式。

    

    非單集羣發佈的，都須要LB（Load Balance）進行流量引導和負載均衡調控來實現。

    如下提到的LB，僅僅指代Load Balance（負載均衡），不要有其餘聯想…

三、 藍綠髮布

 

藍綠髮布，爲一次發佈分配兩組服務器，一組運行現有的老版本，一組運行待上線的新版本，再經過LB切換流量方式完成發佈，這就是所謂的雙服務器組發佈方式，俗稱「藍綠髮布」。

 

藍綠髮布實踐起來，簡單粗暴！

1. 老版本稱爲藍組，新版本稱爲綠組，發佈時經過LB一次性將流量從藍組直接切換到綠組，不通過金絲雀和滾動發佈；

2. 出現問題回退，直接經過LB將流量切回藍組；

發佈初步成功後，藍組機器通常不直接回收，而是留一個待觀察期，視具體狀況觀察期的時間可長可短，觀察期事後確認發佈無問題，則能夠回收藍組機器。

 

藍綠髮布，適合簡單粗暴的服務器土豪，畢竟須要準備雙倍的服務器/容器資源。

簡單粗暴，其實也意味着對用戶體會很明顯。

四、 功能開關發佈

 

若是土豪擁有了技術，能夠在代碼層面上作文章。那麼就是另外一種發佈方式：功能開關發佈。

說得通俗一點兒，至關於在功能上作了一個if … else … ，固然實際比這個複雜得多。

五、 紅藍金絲雀發佈

 

配合金絲雀發佈，可讓藍綠髮布不那麼簡單粗暴，可以更精益！

紅藍金絲雀發佈，是對藍綠髮布的一種簡單優化。發佈時先從綠組拉入 1 臺金絲雀，待金絲雀驗證經過再發全量。對比藍綠髮布，該發佈方式的優點是有一個生產流量的金絲雀驗證過程，能夠減輕新版本可能有問題的風險和影響面。

    紅藍金絲雀發佈，若是有問題回退很快，直接經過LB將流量切回老版本便可。

    完成發佈後，通常老版本版本要保留觀察以備萬一，好比留1~2天，後沒有問題則回收老版本服務器、容器資源。

 

六、 進階的發佈模式--A/B發佈

 

A/B發佈，跟A/B測試殊途同歸，相似於升級版的功能切換髮布。

配合LB，控制流量。移動端的流量進A集羣，PC端的流量進B集羣。

 

A/B發佈實踐起來分兩種：

1. 簡單配置：

純基於LB實現A/B試，LB須要可以經過條件作流量路由。例如：經過 client IP，設備類型、瀏覽器類型、甚至是定製的HTTP Header或查詢字符串。

2. 高級定製：

高級的A/B測試須要專門的平臺支撐，這類平臺能夠細粒度到針對某類用戶作 A/B 測試。不在本文討論之列。

 

功能開關發佈和A/B發佈看起來相似，但前者通常是無狀態和全量的，而A/B發佈通常是有狀態的，可以跟蹤事務和用戶級別的狀態能夠實現針對某類特定用戶的。

 

一句話，功能開關發佈是成衣，A/B發佈是高定款。

 

七、 技術大咖才能操做的--影子發佈

 

設想如下場景：

• 核心業務要技術轉型，可是服務不能停；

• 關鍵業務從.NET轉型JAVA，服務不能停；

• 現金業務後臺DB從Oracle轉到MySQL，服務不能停；

……

爲了確保萬無一失，有一種稱爲影子測試的大招，採用比較複雜的流量複製、回放和比對技術實現。

 

影子發佈，具體實踐有點兒複雜：

目標：實現老的遺留系統服務遷移升級到新的服務；

部署啓動前，須要在測試環境部署一份遺留系統服務和新的服務，將生產數據庫複製兩份到測試環境。

同時須要將生產請求導流出來一份，通常能夠經過消息隊列收集、導流。導流目標是將生產請求日誌，複製回放，分發到測試環境裏面的遺留系統服務和新的服務。

測試環境中的兩種服務，收到響應後進行比對，若是全部響應比對成功，則能夠認爲 遺留系統服務和新的服務在功能邏輯上是等價的。

若是有響應比對失敗，則認爲二者在功能邏輯上不等價，須要修復新的環境，並從新進行影子測試，直到所有比對成功。

 

根據系統複雜度和關鍵性不一樣，比對測試時間短的可能須要幾周，長的可達幾個月之久。

 

影子發佈最大的優點，由於旁路在獨立測試環境中進行，能夠對生產流量徹底無影響。

能完成影子發佈的，必須是研發、測試、運維三路大咖聯手才能完成。

 

八、 終極大招--LB發佈

 

最終極、最無敵、最強力、最有效、最無招勝有招…… LB發佈，即：老闆發佈！

老闆說怎麼發佈，我們就怎麼發佈…