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

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

蠻力發(fā)布

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

發(fā)布前

發(fā)布后

優(yōu)勢和適用場合

/*
	優(yōu)勢：
  	簡單成本低
  不足：
  	服務(wù)中斷用戶受影響，出了問題回退也慢
  適用場合：
 	  開發(fā)測試環(huán)境
  非關(guān)鍵應(yīng)用（用戶影響面小）
  	初創(chuàng)公司什么都缺，找夜深人靜用戶訪問量小的時(shí)間干
*/

流量模式

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

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

發(fā)布前

先發(fā)一臺金絲雀

全部發(fā)完

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

金絲雀發(fā)布一般先發(fā) 1 臺，或者一個(gè)小比例，例如 2% 的服務(wù)器，主要做流量驗(yàn)證用，也稱為金絲雀 (Canary) 測試（國內(nèi)常稱灰度測試）。以前曠工開礦下礦洞前，先會(huì)放一只金絲雀進(jìn)去探是否有有毒氣體，看金絲雀能否活下來，金絲雀發(fā)布由此得名。
簡單的金絲雀測試一般通過手工測試驗(yàn)證，復(fù)雜的金絲雀測試需要比較完善的監(jiān)控基礎(chǔ)設(shè)施配合，通過監(jiān)控指標(biāo)反饋，觀察金絲雀的健康狀況，作為后續(xù)發(fā)布或回退的依據(jù)。
如果金絲測試通過，則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，發(fā)布失敗。
優(yōu)勢和適用場合
優(yōu)勢：
用戶體驗(yàn)影響小，金絲雀發(fā)布過程出現(xiàn)問題只影響少量用戶
不足：
發(fā)布自動(dòng)化程度不夠，發(fā)布期間可引發(fā)服務(wù)中斷
適用場合：
對新版本功能或性能缺乏足夠信心
用戶體驗(yàn)要求較高的網(wǎng)站業(yè)務(wù)場景
缺乏足夠的自動(dòng)化發(fā)布工具研發(fā)能力

流量模式

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

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

發(fā)布前

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

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

直到全部發(fā)完

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

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

流量模式

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

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

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

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

實(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í)間可長可短，觀察期過后確認(rèn)發(fā)布無問題，則可以回收藍(lán)組機(jī)器。
優(yōu)勢和適用場合
優(yōu)勢：
升級切換和回退速度非常快
不足：
切換是全量的，如果 V2 版本有問題，則對用戶體驗(yàn)有直接影響；
需要兩倍機(jī)器資源；
適用場合：
對用戶體驗(yàn)有一定容忍度的場景
機(jī)器資源有富余或者可以按需分配（AWS 云，或自建容器云）
暫不具備復(fù)雜滾動(dòng)發(fā)布工具研發(fā)能力；

流量模式

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

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

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

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

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

1.發(fā)布前先申請一批新服務(wù)器，數(shù)量一般和 V1 版本相同，將 V2 版本應(yīng)用發(fā)布到新服務(wù)器上。例如如果在 AWS 云上，則可以直接調(diào)用 API 申請一批新 VM，如果用容器云 Kubernetes，則可以直接啟動(dòng)一批新容器（使用 V2 版本容器鏡像）。
2.一般會(huì)先通過 LB 拉入 1 臺 V2 版本的機(jī)器，這臺機(jī)器也相當(dāng)于金絲雀，用于流量驗(yàn)證。
3.逐步按批次完成發(fā)布，每批只需要通過 LB 拉入 V2 版本，再拉出對應(yīng)數(shù)量的 V1 版本。批次之間留有觀察間隔，通過手工或監(jiān)控反饋確保沒有問題再繼續(xù)發(fā)布。
4.發(fā)布有問題回退很快，直接通過 LB 將流量切回 V1 即可。
5.完成發(fā)布后，一般 V1 版本要保留觀察以備萬一，比如留 1 天，1 天后沒有問題則回收 V1 機(jī)器資源。
優(yōu)勢和適用場合
優(yōu)勢：
用戶體驗(yàn)影響小；
升級切換和回退（rollback）速度比單服務(wù)器組滾動(dòng)發(fā)布要快，LB 切流量即可；
不足：
需要兩倍機(jī)器資源；
發(fā)布工具比較復(fù)雜，LB 需要流量切換能力
適用場合：
用戶體驗(yàn)不能中斷的網(wǎng)站業(yè)務(wù)場景
機(jī)器資源有富余或者可以按需分配（AWS 云，或自建容器云）
有一定的發(fā)布工具研發(fā)能力；

流量模式

其它發(fā)布方式

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

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

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

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

1.功能開關(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ā)布只是配置中心的一種使用場景，配置中心還能支持其它很多動(dòng)態(tài)配置場景。
2.功能開關(guān)服務(wù)一般提供客戶端 SDK，方便開發(fā)人員集成。在運(yùn)行期，客戶端 SDK 會(huì)同步最新的開關(guān)值，技術(shù)實(shí)現(xiàn)有推方式 (push)，也有拉方式 (pull)，或者推拉結(jié)合方式。
3.新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中，新功能隱藏在開關(guān)后面，如果開關(guān)沒有打開，則走老代碼邏輯，如果開關(guān)打開，則走新代碼邏輯。技術(shù)實(shí)現(xiàn)上可以理解為一個(gè)簡單的 if/else 邏輯。
4.應(yīng)用上線后，開關(guān)先不打開，然后運(yùn)維或研發(fā)人員通過開關(guān)中心打開新功能，經(jīng)過流量驗(yàn)證新功能沒有問題，則發(fā)布完成；如果有問題，則隨時(shí)可以通過開關(guān)中心切回老功能邏輯。
優(yōu)勢和適用場合
優(yōu)勢：
升級切換和回退速度非常快
相對于復(fù)雜的發(fā)布工具，實(shí)施比較簡單，成本相對低廉
研發(fā)能夠靈活定制發(fā)布邏輯，支持 DevOps 自助發(fā)布
不足：
切換是全量的，如果 V2 版本有問題，則對用戶體驗(yàn)有直接影響；
對代碼有侵入，代碼邏輯會(huì)變復(fù)雜，需要定期清理老版本邏輯，維護(hù)成本變高
適用場合：
對用戶體驗(yàn)有一定容忍度的場景
已有配置中心或開關(guān)中心服務(wù)
暫不具備研發(fā)復(fù)雜發(fā)布工具能力；

流量模式

A/B 測試

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

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

1.上圖中，原來 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 比對測試和觀察（主要通過用戶和監(jiān)控反饋），確保 V2 正常，則通過 LB 將全部流量切換到 V2。
2.基于 LB 方式實(shí)現(xiàn) A/B 測試，LB 需要能夠通過某種條件做流量路由，例如通過 client ip，設(shè)備類型，瀏覽器類型，甚至是定制的 HTTP Header 或查詢字符串。
3.高級的 A/B 測試需要專門的平臺支撐，wasabi附錄 6.6就是 intuit 開源的一個(gè)支持高級 A/B 測試的平臺，這類平臺可以細(xì)粒度到針對某類用戶做 A/B 測試，例如針對某個(gè)地區(qū)的用戶，某個(gè)年齡段的用戶，公司內(nèi)部用戶等等。舉了例子，假設(shè)一個(gè)關(guān)鍵業(yè)務(wù)的新功能上線，為了降低風(fēng)險(xiǎn)采用 A/B 測試，可以做到先只讓公司內(nèi)部員工能訪問到新功能，待新功能驗(yàn)證過，再全量放開給外部用戶使用。
4.功能開關(guān)和 A/B 測試有點(diǎn)相似，但功能開關(guān)一般是無狀態(tài)和全量的，無法做到針對某類特定用戶進(jìn)行測試，而 A/B 測試一般是有狀態(tài)的，能夠跟蹤事務(wù)和用戶級別的狀態(tài)，可以實(shí)現(xiàn)針對某類特定用戶進(jìn)行測試。
優(yōu)勢和適用場合
優(yōu)勢：
用戶體驗(yàn)影響小；
可以使用生產(chǎn)流量測試；
可以做到針對某類特定目標(biāo)用戶進(jìn)行測試；
不足：
搭建復(fù)雜度相對高，有一定技術(shù)門檻
適用場合：
核心關(guān)鍵業(yè)務(wù)，比如涉及資金的
具備一定的 A/B 測試平臺研發(fā)能力

流量模式

影子測試

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

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

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

流量模式

比較

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

結(jié)論和建議

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

蠻力發(fā)布一般是不建議采用的，除非是開發(fā)測試環(huán)境，用戶體驗(yàn)不敏感的非關(guān)鍵應(yīng)用，或者是創(chuàng)業(yè)期什么都缺時(shí)候的無奈之舉。

如果暫時(shí)還不具備研發(fā)較復(fù)雜的滾動(dòng)發(fā)布工具和配套智能 LB，則功能開關(guān)是一種不錯(cuò)的輕量級發(fā)布技術(shù)，投入相對較小的成本，可以讓研發(fā)人員靈活定制發(fā)布邏輯。

金絲雀發(fā)布通過少量新版本服務(wù)器接收生產(chǎn)流量的方式去驗(yàn)證新版本，可以顯著降低風(fēng)險(xiǎn)。金絲雀發(fā)布適用于大部分場景，一般成長型公司就可以采用。

對于達(dá)到一定業(yè)務(wù)體量的公司，考慮到用戶體驗(yàn)對業(yè)務(wù)的關(guān)鍵性，則需要投入研發(fā)資源開發(fā)支持滾動(dòng)式發(fā)布的工具和配套的智能 LB，實(shí)現(xiàn)自動(dòng)化和零停機(jī)的發(fā)布。滾動(dòng)式發(fā)布一般和金絲雀發(fā)布配合，先發(fā)一臺金絲雀去驗(yàn)證流量，再按批次增量發(fā)布。

隨著輕量級虛擬化（例如容器）的普及，雙服務(wù)器組發(fā)布方式具有更快的發(fā)布和回退速度，是值得投入的高級發(fā)布技術(shù)。藍(lán)綠部署僅適用于雙服務(wù)器組，滾動(dòng)式發(fā)布既可以在單服務(wù)器組上實(shí)現(xiàn)，也可以在雙服務(wù)器組上實(shí)現(xiàn)。

對于涉及關(guān)鍵核心業(yè)務(wù)的新功能上線，采用 A/B 測試，可以顯著降低發(fā)布風(fēng)險(xiǎn)，A/B 測試是唯一一種支持針對特定用戶組進(jìn)行生產(chǎn)測試的高級發(fā)布技術(shù)。當(dāng)然 A/B 測試的投入不低，建議有一定研發(fā)能力的組織采用。

對于關(guān)鍵核心業(yè)務(wù)的遷移重構(gòu)，為確保萬無一失，最后的一個(gè)大招是影子測試，影子測試對生產(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ù)場景需要采用功能開關(guān)發(fā)布，還有一些業(yè)務(wù)線則可能采用高級的 A/B 測試發(fā)布手段。

總結(jié)

以上是生活随笔為你收集整理的服务发布方法(蓝绿,灰度,金丝雀)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。