（著作權(quán)歸作者所有、本次轉(zhuǎn)載非商業(yè)用途、需要轉(zhuǎn)載請(qǐng)聯(lián)系作者。）

根據(jù) 2017 年的 DevOps 發(fā)展報(bào)告，高效能組織和低效能組織在軟件交付的效率上有數(shù)量級(jí)上的差異。技術(shù)組織的軟件交付能力是一種綜合能力，涉及眾多環(huán)節(jié)，其中發(fā)布是尤為重要的環(huán)節(jié)。

作為技術(shù)人員，大家可能聽說過“滾動(dòng)發(fā)布”和“藍(lán)綠發(fā)布”等術(shù)語，但是很多人并不清楚這些術(shù)語背后的原理。本文試圖總結(jié)當(dāng)前主流的發(fā)布策略，每個(gè)的優(yōu)劣，適用性，讓開發(fā)人員特別是架構(gòu)師對(duì)現(xiàn)代發(fā)布技術(shù)有一個(gè)更為清晰全面的認(rèn)識(shí)，讓大家能夠根據(jù)自己的企業(yè)上下文，對(duì)發(fā)布策略做出正確的選型和實(shí)踐。

一、單服務(wù)器組發(fā)布

先解釋下單服務(wù)器組的概念，早先我們機(jī)器資源比較緊張，不像現(xiàn)在云計(jì)算和虛擬化（包括容器技術(shù)）這么發(fā)達(dá)，所以應(yīng)用機(jī)器基本是預(yù)先靜態(tài)分配好的（一般由運(yùn)維負(fù)責(zé)分配），原來應(yīng)用 A 住在這 n 臺(tái)機(jī)器上，那么下次升級(jí)發(fā)布的應(yīng)用 A 也住在這 n 臺(tái)機(jī)器上，所以稱為單服務(wù)器組發(fā)布方式。

1.1 蠻力發(fā)布

如下圖所示，這種發(fā)布方式比較簡(jiǎn)單粗暴，有點(diǎn)像我們傳統(tǒng)的軟件升級(jí)方式，主要靠手工完成，先將老版本 V1 全部下掉，再將新版本發(fā)到機(jī)器上去。這種方式會(huì)引入服務(wù)中斷（停機(jī)），在開發(fā)測(cè)試環(huán)境是可行的，但對(duì)于生產(chǎn)環(huán)境發(fā)布，其會(huì)直接影響用戶的使用體驗(yàn)，這種方式一般是不建議的。

發(fā)布前示圖：

發(fā)布后示圖：

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 操作簡(jiǎn)單成本低

不足：

• 服務(wù)中斷用戶受影響，出了問題回退也慢

適用場(chǎng)合：

• 開發(fā)測(cè)試環(huán)境/非關(guān)鍵應(yīng)用（用戶影響面小）/初創(chuàng)公司什么都缺，找夜深人靜用戶訪問量小的時(shí)間干

流量模式示圖：

蠻力發(fā)布會(huì)引入服務(wù)中斷時(shí)間（圖片來自附錄 6.1）

1.2 金絲雀發(fā)布（單服務(wù)器組）

在蠻力發(fā)布基礎(chǔ)上的一種簡(jiǎn)單改進(jìn)發(fā)布方式，目前仍然是不少成長(zhǎng)型技術(shù)組織的主流發(fā)布方式。單服務(wù)器組下的金絲雀發(fā)布的簡(jiǎn)化步驟如下圖所示：

發(fā)布前示圖

先發(fā)一臺(tái)金絲雀（示圖）

全部發(fā)完

實(shí)踐要點(diǎn)：

• 金絲雀發(fā)布一般先發(fā) 1 臺(tái)，或者一個(gè)小比例，例如 2% 的服務(wù)器，主要做流量驗(yàn)證用，也稱為金絲雀 (Canary) 測(cè)試（國(guó)內(nèi)常稱灰度測(cè)試）。以前礦工開礦下礦洞前，先會(huì)放一只金絲雀進(jìn)去探是否有有毒氣體，看金絲雀能否活下來，金絲雀發(fā)布由此得名。簡(jiǎn)單的金絲雀測(cè)試一般通過手工測(cè)試驗(yàn)證，復(fù)雜的金絲雀測(cè)試需要比較完善的監(jiān)控基礎(chǔ)設(shè)施配合，通過監(jiān)控指標(biāo)反饋，觀察金絲雀的健康狀況，作為后續(xù)發(fā)布或回退的依據(jù)。
• 如果金絲測(cè)試通過，則把剩余的 V1 版本全部升級(jí)為 V2 版本。如果金絲雀測(cè)試失敗，則直接回退金絲雀，發(fā)布失敗。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 用戶體驗(yàn)影響小，金絲雀發(fā)布過程出現(xiàn)問題只影響少量用戶

不足：

• 發(fā)布自動(dòng)化程度不夠，發(fā)布期間可引發(fā)服務(wù)中斷

適用場(chǎng)合：

• 對(duì)新版本功能或性能缺乏足夠信心
• 用戶體驗(yàn)要求較高的網(wǎng)站業(yè)務(wù)場(chǎng)景
• 缺乏足夠的自動(dòng)化發(fā)布工具研發(fā)能力

 流量模式：

少量金絲雀先接受流量，再全量發(fā)布，圖片來自附錄 6.1

1.3 滾動(dòng)式發(fā)布（單服務(wù)器組）

在金絲雀發(fā)布基礎(chǔ)上的進(jìn)一步優(yōu)化改進(jìn)，是一種自動(dòng)化程度較高的發(fā)布方式，用戶體驗(yàn)比較平滑，是目前成熟型技術(shù)組織所采用的主流發(fā)布方式。單服務(wù)器組下的滾動(dòng)發(fā)布的簡(jiǎn)化步驟如下圖所示：

發(fā)布前

發(fā)布中，先發(fā)一臺(tái)金絲雀

發(fā)布中，再發(fā)若干臺(tái)

直到全部發(fā)完

實(shí)踐要點(diǎn)

• 滾動(dòng)式發(fā)布一般先發(fā) 1 臺(tái)，或者一個(gè)小比例，如 2% 服務(wù)器，主要做流量驗(yàn)證用，類似金絲雀 (Canary) 測(cè)試。
• 滾動(dòng)式發(fā)布需要比較復(fù)雜的發(fā)布工具和智能 LB，支持平滑的版本替換和流量拉入拉出。
• 每次發(fā)布時(shí)，先將老版本 V1 流量從 LB 上摘除，然后清除老版本，發(fā)新版本 V2，再將 LB 流量接入新版本。這樣可以盡量保證用戶體驗(yàn)不受影響。
• 一次滾動(dòng)式發(fā)布一般由若干個(gè)發(fā)布批次組成，每批的數(shù)量一般是可以配置的（可以通過發(fā)布模板定義）。例如第一批 1 臺(tái)（金絲雀），第二批 10%，第三批 50%，第四批 100%。每個(gè)批次之間留觀察間隔，通過手工驗(yàn)證或監(jiān)控反饋確保沒有問題再發(fā)下一批次，所以總體上滾動(dòng)式發(fā)布過程是比較緩慢的 (其中金絲雀的時(shí)間一般會(huì)比后續(xù)批次更長(zhǎng)，比如金絲雀 10 分鐘，后續(xù)間隔 2 分鐘)。
• 回退是發(fā)布的逆過程，將新版本流量從 LB 上摘除，清除新版本，發(fā)老版本，再將 LB 流量接入老版本。和發(fā)布過程一樣，回退過程一般也比較慢的。
• 滾動(dòng)式發(fā)布國(guó)外術(shù)語通常叫“Rolling Update Deployment”。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 用戶體驗(yàn)影響小，體驗(yàn)較平滑

不足：

• 發(fā)布和回退時(shí)間比較緩慢

發(fā)布工具比較復(fù)雜，LB 需要平滑的流量摘除和拉入能力

適用場(chǎng)合：

• 用戶體驗(yàn)不能中斷的網(wǎng)站業(yè)務(wù)場(chǎng)景
• 有一定的復(fù)雜發(fā)布工具研發(fā)能力；

流量模式

滾動(dòng)式發(fā)布，流量平滑過渡，圖片來自附錄 6.1

二、雙服務(wù)器組發(fā)布

隨著云計(jì)算和虛擬化技術(shù)的成熟，特別是容器等輕量級(jí)虛擬化技術(shù)的引入，計(jì)算資源受限和申請(qǐng)緩慢問題已經(jīng)逐步解決，可以做到彈性按需分配。為一次發(fā)布分配兩組服務(wù)器，一組運(yùn)行現(xiàn)有的 V1 老版本，一組運(yùn)行待上線的 V2 新版本，再通過 LB 切換流量方式完成發(fā)布，這就是所謂的雙服務(wù)器組發(fā)布方式。

2.1 藍(lán)綠發(fā)布（雙服務(wù)器組）

藍(lán)綠發(fā)布僅適用于雙服務(wù)器組發(fā)布，可以認(rèn)為是對(duì)蠻力發(fā)布的一種簡(jiǎn)單優(yōu)化發(fā)布方式。簡(jiǎn)化過程如下圖所示：

實(shí)踐要點(diǎn)

V1 版本稱為藍(lán)組，V2 版本稱為綠組，發(fā)布時(shí)通過 LB 一次性將流量從藍(lán)組直接切換到綠組，不經(jīng)過金絲雀和滾動(dòng)發(fā)布，藍(lán)綠發(fā)布由此得名；

出現(xiàn)問題回退也很直接，通過 LB 直接將流量切回藍(lán)組。

發(fā)布初步成功后，藍(lán)組機(jī)器一般不直接回收，而是留一個(gè)待觀察期，視具體情況觀察期的時(shí)間可長(zhǎng)可短，觀察期過后確認(rèn)發(fā)布無問題，則可以回收藍(lán)組機(jī)器。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 升級(jí)切換和回退速度非?？?/span>

不足：

• 切換是全量的，如果 V2 版本有問題，則對(duì)用戶體驗(yàn)有直接影響；
• 需要兩倍機(jī)器資源；

適用場(chǎng)合：

• 對(duì)用戶體驗(yàn)有一定容忍度的場(chǎng)景
• 機(jī)器資源有富余或者可以按需分配（AWS 云，或自建容器云）
• 暫不具備復(fù)雜滾動(dòng)發(fā)布工具研發(fā)能力；

流量模式

藍(lán)綠發(fā)布一次完成流程切換，圖片來自附錄 7.1

2.2 金絲雀發(fā)布（雙服務(wù)器組）

對(duì)藍(lán)綠部署的一種簡(jiǎn)單優(yōu)化，發(fā)布時(shí)先從綠組拉入 1 臺(tái)金絲雀，待金絲雀驗(yàn)證通過再發(fā)全量。對(duì)比藍(lán)綠發(fā)布，該發(fā)布方式的優(yōu)勢(shì)是有一個(gè)生產(chǎn)流量的金絲雀驗(yàn)證過程，可以減輕 V2 可能有問題的風(fēng)險(xiǎn)和影響面。簡(jiǎn)化發(fā)布過程如下圖所示：

2.3 滾動(dòng)式發(fā)布（雙服務(wù)器組）

滾動(dòng)式發(fā)布是對(duì)上面的藍(lán)綠和金絲雀發(fā)布的進(jìn)一步優(yōu)化，按批次增量滾動(dòng)發(fā)布，提供更平滑的用戶體驗(yàn)。

實(shí)踐要點(diǎn)

• 發(fā)布前先申請(qǐng)一批新服務(wù)器，數(shù)量一般和 V1 版本相同，將 V2 版本應(yīng)用發(fā)布到新服務(wù)器上。例如如果在 AWS 云上，則可以直接調(diào)用 API 申請(qǐng)一批新 VM，如果用容器云 Kubernetes，則可以直接啟動(dòng)一批新容器（使用 V2 版本容器鏡像）。
• 一般會(huì)先通過 LB 拉入 1 臺(tái) V2 版本的機(jī)器，這臺(tái)機(jī)器也相當(dāng)于金絲雀，用于流量驗(yàn)證。
• 逐步按批次完成發(fā)布，每批只需要通過 LB 拉入 V2 版本，再拉出對(duì)應(yīng)數(shù)量的 V1 版本。批次之間留有觀察間隔，通過手工或監(jiān)控反饋確保沒有問題再繼續(xù)發(fā)布。
• 發(fā)布有問題回退很快，直接通過 LB 將流量切回 V1 即可。
• 完成發(fā)布后，一般 V1 版本要保留觀察以備萬一，比如留 1 天，1 天后沒有問題則回收 V1 機(jī)器資源。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 用戶體驗(yàn)影響??；
• 升級(jí)切換和回退（rollback）速度比單服務(wù)器組滾動(dòng)發(fā)布要快，LB 切流量即可；

不足：

• 需要兩倍機(jī)器資源；
• 發(fā)布工具比較復(fù)雜，LB 需要流量切換能力

適用場(chǎng)合：

• 用戶體驗(yàn)不能中斷的網(wǎng)站業(yè)務(wù)場(chǎng)景
• 機(jī)器資源有富余或者可以按需分配（AWS 云，或自建容器云）
• 有一定的發(fā)布工具研發(fā)能力；

流量模式

滾動(dòng)式發(fā)布，流量平滑過渡，圖片來自附錄 6.1

三、其它發(fā)布方式

上述都是偏傳統(tǒng)的發(fā)布方式，能覆蓋大部分應(yīng)用發(fā)布場(chǎng)景。針對(duì)一些關(guān)鍵新功能的上線發(fā)布，或者一些特定的場(chǎng)景，還有一些特殊的發(fā)布方式。

3.1 功能開關(guān)發(fā)布

利用代碼中的功能開關(guān)（Feature Flag/Toggle/Switch）來控制發(fā)布邏輯，一般不需要復(fù)雜的發(fā)布工具和智能 LB 配合，是一種相對(duì)比較低成本和簡(jiǎn)單的發(fā)布方式。這種方式也是支持現(xiàn)代 DevOps 理念，研發(fā)人員可以靈活定制和自助完成的發(fā)布方式。

功能開關(guān)的原理如下圖所示：

功能開關(guān)發(fā)布，圖片來自附錄 6.2

實(shí)踐要點(diǎn)

• 功能開關(guān)發(fā)布需要一個(gè)配置中心或者開關(guān)中心這樣的服務(wù)支持，例如攜程的 Apollo 配置中心附錄 6.3，或者開源的 FF4J附錄 6.4，這些都支持開關(guān)發(fā)布，業(yè)界還有專門的功能開關(guān) SaaS 服務(wù)，例如 LaunchDarkly附錄 6.5。通過配置中心，運(yùn)維或研發(fā)人員可以在運(yùn)行期動(dòng)態(tài)配置功能開關(guān)的值。當(dāng)然，功能開關(guān)發(fā)布只是配置中心的一種使用場(chǎng)景，配置中心還能支持其它很多動(dòng)態(tài)配置場(chǎng)景。
• 功能開關(guān)服務(wù)一般提供客戶端 SDK，方便開發(fā)人員集成。在運(yùn)行期，客戶端 SDK 會(huì)同步最新的開關(guān)值，技術(shù)實(shí)現(xiàn)有推方式 (push)，也有拉方式 (pull)，或者推拉結(jié)合方式。
• 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關(guān)后面，如果開關(guān)沒有打開，則走老代碼邏輯，如果開關(guān)打開，則走新代碼邏輯。技術(shù)實(shí)現(xiàn)上可以理解為一個(gè)簡(jiǎn)單的 if/else 邏輯。
• 應(yīng)用上線后，開關(guān)先不打開，然后運(yùn)維或研發(fā)人員通過開關(guān)中心打開新功能，經(jīng)過流量驗(yàn)證新功能沒有問題，則發(fā)布完成；如果有問題，則隨時(shí)可以通過開關(guān)中心切回老功能邏輯。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 升級(jí)切換和回退速度非?？?/span>
• 相對(duì)于復(fù)雜的發(fā)布工具，實(shí)施比較簡(jiǎn)單，成本相對(duì)低廉
• 研發(fā)能夠靈活定制發(fā)布邏輯，支持 DevOps 自助發(fā)布

不足：

• 切換是全量的，如果 V2 版本有問題，則對(duì)用戶體驗(yàn)有直接影響；
• 對(duì)代碼有侵入，代碼邏輯會(huì)變復(fù)雜，需要定期清理老版本邏輯，維護(hù)成本變高

適用場(chǎng)合：

• 對(duì)用戶體驗(yàn)有一定容忍度的場(chǎng)景
• 已有配置中心或開關(guān)中心服務(wù)
• 暫不具備研發(fā)復(fù)雜發(fā)布工具能力；

 流量模式

通過功能開關(guān)一次完成流量切換，圖片來自附錄 6.1

3.2 A/B 測(cè)試

（附錄 7.10）原來主要用于產(chǎn)品功能的比對(duì)測(cè)試，收集用戶反饋和對(duì)比數(shù)據(jù)做產(chǎn)品功能設(shè)計(jì)的決策。實(shí)際上，A/B 測(cè)試也可以作為一種新功能發(fā)布技術(shù)。

下圖展示基于 LB 實(shí)現(xiàn)的一種 A/B 測(cè)試發(fā)布

實(shí)踐要點(diǎn)

• 上圖中，原來 PC 端和手機(jī)端都訪問老版本 V1 服務(wù)（也稱 A 組或控制組），當(dāng) V2 新版本（也稱 B 組或?qū)嶒?yàn)組）發(fā)布以后，為了驗(yàn)證 V2 的功能正確性，同時(shí)也為了避免 V2 有問題時(shí)影響所有用戶，先通過 LB 將手機(jī)端的流量切換到 V2 版本，經(jīng)過一段時(shí)間的 A/B 比對(duì)測(cè)試和觀察（主要通過用戶和監(jiān)控反饋），確保 V2 正常，則通過 LB 將全部流量切換到 V2。
• 基于 LB 方式實(shí)現(xiàn) A/B 測(cè)試，LB 需要能夠通過某種條件做流量路由，例如通過 client ip，設(shè)備類型，瀏覽器類型，甚至是定制的 HTTP Header 或查詢字符串。
• 高級(jí)的 A/B 測(cè)試需要專門的平臺(tái)支撐，wasabi附錄 6.6就是 intuit 開源的一個(gè)支持高級(jí) A/B 測(cè)試的平臺(tái)，這類平臺(tái)可以細(xì)粒度到針對(duì)某類用戶做 A/B 測(cè)試，例如針對(duì)某個(gè)地區(qū)的用戶，某個(gè)年齡段的用戶，公司內(nèi)部用戶等等。舉了例子，假設(shè)一個(gè)關(guān)鍵業(yè)務(wù)的新功能上線，為了降低風(fēng)險(xiǎn)采用 A/B 測(cè)試，可以做到先只讓公司內(nèi)部員工能訪問到新功能，待新功能驗(yàn)證過，再全量放開給外部用戶使用。
• 功能開關(guān)和 A/B 測(cè)試有點(diǎn)相似，但功能開關(guān)一般是無狀態(tài)和全量的，無法做到針對(duì)某類特定用戶進(jìn)行測(cè)試，而 A/B 測(cè)試一般是有狀態(tài)的，能夠跟蹤事務(wù)和用戶級(jí)別的狀態(tài)，可以實(shí)現(xiàn)針對(duì)某類特定用戶進(jìn)行測(cè)試。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 用戶體驗(yàn)影響小；
• 可以使用生產(chǎn)流量測(cè)試；
• 可以做到針對(duì)某類特定目標(biāo)用戶進(jìn)行測(cè)試；

不足：

• 搭建復(fù)雜度相對(duì)高，有一定技術(shù)門檻

適用場(chǎng)合：

• 核心關(guān)鍵業(yè)務(wù)，比如涉及資金的
• 具備一定的 A/B 測(cè)試平臺(tái)研發(fā)能力

流量模式

針對(duì)某類目標(biāo)用戶進(jìn)行 A/B 測(cè)試，圖片來自附錄 6.1

3.3 影子測(cè)試

對(duì)于一些涉及核心業(yè)務(wù)的遺留系統(tǒng)的升級(jí)改造，為了確保萬無一失，有一種稱為影子測(cè)試的大招，采用比較復(fù)雜的流量復(fù)制、回放和比對(duì)技術(shù)實(shí)現(xiàn)。

下面是影子測(cè)試的一個(gè)樣例架構(gòu)圖：

實(shí)踐要點(diǎn)

• 目標(biāo)實(shí)現(xiàn)老的 legacy 服務(wù)遷移升級(jí)到新的 experimental 服務(wù)。
• 測(cè)試開始前，需要在測(cè)試環(huán)境部署一份 legacy 服務(wù)和 experimental 服務(wù)，同時(shí)將生產(chǎn)數(shù)據(jù)庫(kù)復(fù)制兩份到測(cè)試環(huán)境。同時(shí)需要將生產(chǎn)請(qǐng)求日志收集起來，一般可以通過 kafka 隊(duì)列收集，然后通過類似 goreplay附錄 6.8這樣的工具，消費(fèi) kafka 里頭的請(qǐng)求日志，復(fù)制回放，將請(qǐng)求分發(fā)到 legacy 服務(wù)和 experimental 服務(wù)，收到響應(yīng)后進(jìn)行比對(duì)，如果所有響應(yīng)比對(duì)成功，則可以認(rèn)為 legacy 服務(wù)和 experimental 服務(wù)在功能邏輯上是等價(jià)的；如果有響應(yīng)比對(duì)失敗，則認(rèn)為兩者在功能邏輯上不等價(jià)，需要修復(fù) experimental 并重新進(jìn)行影子測(cè)試，直到全部比對(duì)成功。根據(jù)系統(tǒng)復(fù)雜度和關(guān)鍵性不同，比對(duì)測(cè)試時(shí)間短的可能需要幾周，長(zhǎng)的可達(dá)半年之久。
• 影子測(cè)試因?yàn)榕月吩讵?dú)立測(cè)試環(huán)境中進(jìn)行，可以對(duì)生產(chǎn)流量完全無影響。
• 影子測(cè)試一般適用于遺留系統(tǒng)的等價(jià)重構(gòu)遷移，例如.net 轉(zhuǎn) Java，或者 SQLServer 數(shù)據(jù)庫(kù)升級(jí)為 MySQL 數(shù)據(jù)庫(kù)，且外部依賴不能太多，否則需要開發(fā)很多 mock，測(cè)試部署成本會(huì)很高，且比對(duì)測(cè)試更加復(fù)雜和不穩(wěn)定。
• 當(dāng)當(dāng)網(wǎng)有一個(gè)比較成功的交易系統(tǒng).NET 轉(zhuǎn) Java 遷移項(xiàng)目附錄 6.9，采用了影子測(cè)試技術(shù)，值得參考借鑒。

優(yōu)勢(shì)和適用場(chǎng)合

優(yōu)勢(shì)：

• 對(duì)生產(chǎn)用戶體驗(yàn)完全無影響
• 可以使用生產(chǎn)真實(shí)流量進(jìn)行測(cè)試（復(fù)制比對(duì)）

不足：

• 搭建復(fù)雜度很高，技術(shù)門檻高，數(shù)據(jù)庫(kù)的導(dǎo)出復(fù)制是難點(diǎn)
• 外部依賴不能太多，否則測(cè)試部署成本很高，且比對(duì)測(cè)試更加復(fù)雜和不穩(wěn)定

適用場(chǎng)合：

• 核心關(guān)鍵業(yè)務(wù)，比如涉及資金的
• 具備一定影子測(cè)試平臺(tái)研發(fā)能力，包括流量復(fù)制、數(shù)據(jù)庫(kù)導(dǎo)出復(fù)制和分發(fā)比對(duì)系統(tǒng)。

流量模式

影子測(cè)試對(duì)生產(chǎn)流量無影響，圖片來自附錄 6.1

四、比較

下表對(duì)各種發(fā)布策略，從各個(gè)維度進(jìn)行綜合比較，供參考：

五、結(jié)論和建議

下面是對(duì)發(fā)布策略的一些選型建議，供不同階段公司參考：

• 蠻力發(fā)布一般是不建議采用的，除非是開發(fā)測(cè)試環(huán)境，用戶體驗(yàn)不敏感的非關(guān)鍵應(yīng)用，或者是創(chuàng)業(yè)期什么都缺時(shí)候的無奈之舉。
• 如果暫時(shí)還不具備研發(fā)較復(fù)雜的滾動(dòng)發(fā)布工具和配套智能 LB，則功能開關(guān)是一種不錯(cuò)的輕量級(jí)發(fā)布技術(shù)，投入相對(duì)較小的成本，可以讓研發(fā)人員靈活定制發(fā)布邏輯。
• 金絲雀發(fā)布通過少量新版本服務(wù)器接收生產(chǎn)流量的方式去驗(yàn)證新版本，可以顯著降低風(fēng)險(xiǎn)。金絲雀發(fā)布適用于大部分場(chǎng)景，一般成長(zhǎng)型公司就可以采用。
• 對(duì)于達(dá)到一定業(yè)務(wù)體量的公司，考慮到用戶體驗(yàn)對(duì)業(yè)務(wù)的關(guān)鍵性，則需要投入研發(fā)資源開發(fā)支持滾動(dòng)式發(fā)布的工具和配套的智能 LB，實(shí)現(xiàn)自動(dòng)化和零停機(jī)的發(fā)布。滾動(dòng)式發(fā)布一般和金絲雀發(fā)布配合，先發(fā)一臺(tái)金絲雀去驗(yàn)證流量，再按批次增量發(fā)布。
• 隨著輕量級(jí)虛擬化（例如容器）的普及，雙服務(wù)器組發(fā)布方式具有更快的發(fā)布和回退速度，是值得投入的高級(jí)發(fā)布技術(shù)。藍(lán)綠部署僅適用于雙服務(wù)器組，滾動(dòng)式發(fā)布既可以在單服務(wù)器組上實(shí)現(xiàn)，也可以在雙服務(wù)器組上實(shí)現(xiàn)。
• 對(duì)于涉及關(guān)鍵核心業(yè)務(wù)的新功能上線，采用 A/B 測(cè)試，可以顯著降低發(fā)布風(fēng)險(xiǎn)，A/B 測(cè)試是唯一一種支持針對(duì)特定用戶組進(jìn)行生產(chǎn)測(cè)試的高級(jí)發(fā)布技術(shù)。當(dāng)然 A/B 測(cè)試的投入不低，建議有一定研發(fā)能力的組織采用。
• 對(duì)于關(guān)鍵核心業(yè)務(wù)的遷移重構(gòu)，為確保萬無一失，最后的一個(gè)大招是影子測(cè)試，影子測(cè)試對(duì)生產(chǎn)流量和用戶完全無影響。當(dāng)然這個(gè)大招的投入成本和門檻都高，建議有足夠業(yè)務(wù)體量和研發(fā)能力的組織投入。
• 上述的各種發(fā)布策略并不是非此即彼的，一個(gè)公司常常會(huì)綜合采用多種發(fā)布技術(shù)作為互補(bǔ)，實(shí)現(xiàn)靈活的發(fā)布能力。例如主流的發(fā)布手段是金絲雀 + 滾動(dòng)式發(fā)布，某些業(yè)務(wù)線可能根據(jù)業(yè)務(wù)場(chǎng)景需要采用功能開關(guān)發(fā)布，還有一些業(yè)務(wù)線則可能采用高級(jí)的 A/B 測(cè)試發(fā)布手段。

六、附錄/參考：

https://github.com/ContainerSolutions/k8s-deployment-strategies

https://opensource.com/article/18/2/feature-flags-ring-deployment-model

https://github.com/ctripcorp/apollo

http://www.ff4j.org/

https://launchdarkly.com/

https://github.com/intuit/wasabi

https://blog.zenika.com/2017/04/19/migration-dun-legacy-avec-goreplay/

https://github.com/buger/goreplay

http://blog.shurenyun.com/untitled-9/

https://en.wikipedia.org/wiki/A/B_testing