理解“金絲雀發(fā)布”定義
金絲雀發(fā)布在國內(nèi)也經(jīng)常被叫做灰度發(fā)布。下文將使用”金絲雀發(fā)布“這一術(shù)語座柱。
金絲雀發(fā)布是發(fā)布模式的一種迷帜。“發(fā)布”是什么意思色洞？發(fā)布：即宣布戏锹，發(fā)表。有向外公開的意思火诸。
說到“發(fā)布”锦针，就不得不說“部署”。不少人將“發(fā)布”與“部署”兩個概念混淆置蜀。
“部署”又是什么意思奈搜？在軟件工程領(lǐng)域，“部署”指的是將（編譯）打包好的程序發(fā)送到目標服務(wù)器上盯荤，并啟動執(zhí)行馋吗。
就是說，部署了秋秤，并不一定代表著向用戶發(fā)布宏粤。
如果把軟件產(chǎn)品比喻成一舞臺劇。部署是將舞臺提前布置好灼卢，但是幕布是拉上的绍哎。而發(fā)布則是把觀眾放進劇場，然后拉開幕布鞋真。注意：只有真正“拉開幕布”蛇摸，才稱為發(fā)布。
那金絲雀發(fā)布又是什么灿巧？接著剛剛說的比喻赶袄，指的是你并不是一次性將所有的觀眾都放進劇場。只是有條件的讓一部分人進場并拉開幕布抠藕。你可以通過這些觀眾對于舞臺劇的評價對舞臺劇進行調(diào)整改進饿肺。最后，再選擇合適的時機向所有的人開放消費盾似。
回到技術(shù)領(lǐng)域敬辣。金絲雀發(fā)布就是你已經(jīng)將程序部署到生產(chǎn)環(huán)境了，然后根據(jù)流量比例零院、用戶ID溉跃、用戶地域、用戶類型等不同維度的條件告抄，允許用戶使用部署到生產(chǎn)環(huán)境上的程序上的功能撰茎。這個過程中，你可以觀察這些”特權(quán)“用戶的數(shù)據(jù)打洼，以判斷你是否需要對功能進行改進龄糊。當(dāng)數(shù)據(jù)足以支撐全量發(fā)布時，就可以進行全量發(fā)布募疮。
這就是我們文章開頭強調(diào)的：金絲雀發(fā)布是發(fā)布模式的一種炫惩。以下是根據(jù)流量比例進行金絲雀發(fā)布的圖示（來自flagger.app）:
Flagger是一種基于K8s的發(fā)布控制器。能以較低的成本實現(xiàn)金絲雀發(fā)布阿浓。本例中他嚷，它啟動一個V2版本的程序的實例，并”放行“5%的用戶請求進入V2版本的實例芭毙。
選擇金絲雀發(fā)布的目的
你不能假設(shè)你的軟件產(chǎn)品全量發(fā)布即成功
因為軟件產(chǎn)品一次性全量發(fā)布后筋蓖，你并不能確保它一定受大眾喜愛，所以稿蹲，一步步的試探用戶的喜好的軟件產(chǎn)品發(fā)布策略成為必然選擇扭勉。
比起一次性全量發(fā)布，金絲雀是一種演進式的發(fā)布模式苛聘，也可以說是一種業(yè)務(wù)級別的決策涂炎。
說到”目的“，就不得不說與金絲雀發(fā)布容易混淆的”藍綠部署“设哗。
與”藍綠部署“的關(guān)系
藍綠部署也是一種發(fā)布模式唱捣。如下圖。它的部署方式與金絲雀發(fā)布的部署方式幾乎一樣网梢。
藍綠部署與金絲雀發(fā)布之間存在兩個區(qū)別震缭。主要區(qū)別是”目的“。藍綠部署的發(fā)布模式的目的是更安全的部署战虏，金絲雀發(fā)布的目的是演進式的發(fā)布拣宰。
次要區(qū)別是決策維度的不同党涕。藍綠部署是技術(shù)維度的決策，而金絲雀是業(yè)務(wù)維度的決策巡社。
如下圖展示的是藍綠部署的決策過程膛堤。如果V2版本的實例在生產(chǎn)環(huán)境經(jīng)過多種驗證方式驗證過，即可把流量全部切到V2版本晌该。在驗證期間會保留V1實例肥荔，以保證可以隨時回滾。
另朝群，至于為什么是叫藍綠部署（Blue-Green Deployments）而不是藍綠發(fā)布燕耿。個人認為是因為從一開始藍綠部署的出發(fā)點是零停機（Zero Downtime），而不是演進式的發(fā)布姜胖。當(dāng)然誉帅，從名稱上也體現(xiàn)了在藍綠部署和金絲雀發(fā)布在”決策維度“上的區(qū)別。
參考Martin Fowler關(guān)于藍綠部署的文章：https://martinfowler.com/bliki/BlueGreenDeployment.html
與”滾動更新“的關(guān)系
容易與金絲雀發(fā)布混淆的谭期，還有”滾動更新“堵第。它是一種將軟件程序從一個版本平滑的升級到另一個的版本部署技術(shù)。如下圖隧出。屬于技術(shù)決策踏志。與業(yè)務(wù)無關(guān)。與金絲雀發(fā)布不是同一個維度的東西胀瞪。
動態(tài)圖來自：https://www.bluematador.com/blog/kubernetes-deployments-rolling-update-configuration
該如何實現(xiàn)一套金絲雀發(fā)布系統(tǒng)/平臺
在厘清與金絲雀相關(guān)的各種概念定義之后针余，我們從設(shè)計者的角度思考金絲雀發(fā)布：如果讓你設(shè)計一個金絲雀發(fā)布系統(tǒng)或者平臺，你該如何實現(xiàn)凄诞？
筆者認為它至少要實現(xiàn)三個接口：
- 版本的實例控制接口：即啟動/停止新版本實例的接口圆雁；
- 流量的路由控制接口：將指定流量路由至指定版本實例的接口；
- 指標收集接口：以上兩個控制接口需要有數(shù)據(jù)依據(jù)才能進行控制帆谍，所以伪朽，需要收集程序的指標數(shù)據(jù)。
這三個接口與具體實現(xiàn)應(yīng)該是無關(guān)的汛蝙。比如你可以通過Prometheus實現(xiàn)指標的收集接口烈涮，也可以通過AWS的CloudWatch。
同時窖剑，金絲雀發(fā)布系統(tǒng)還需要一些用戶體驗性相關(guān)的功能坚洽，比如出現(xiàn)回滾時進行通知、滾動更新前進行人工審批西土、滾動更新的步驟大小等等讶舰。
開源的金絲雀發(fā)布系統(tǒng)
金絲雀發(fā)布系統(tǒng)所需的接口后，我們發(fā)現(xiàn)，由于Service Mesh技術(shù)的興起跳昼，讓金絲雀發(fā)布的實現(xiàn)變得容易了很多般甲。
因為Service Mesh技術(shù)天生就支持以上三個接口。所以庐舟，行業(yè)里一下就出現(xiàn)一些輕量級的發(fā)布系統(tǒng)欣除，比如Argo Rollouts和Flagger。我們可以通過以下表格進行對比：
Flagger的三個接口的實現(xiàn)更豐富挪略，幾乎完勝Argo Rollouts。Argo Rollouts除了UI滔岳，幾乎沒有優(yōu)勢杠娱。
采用金絲雀發(fā)布的前提
雖說金絲雀的好處是看得見的，但是并不代表谱煤，你的每一次發(fā)布都能使用它摊求。我們需要清楚的認識到，執(zhí)行金絲雀發(fā)布的過程中刘离，程序存在一個中間狀態(tài)：就是兩個版本同時存在室叉，有時甚至是多個版本。在生產(chǎn)環(huán)境硫惕，如果你的程序無法同時運行兩個版本茧痕，你就不能采用金絲雀發(fā)布。這個風(fēng)險需要開發(fā)在開發(fā)過程就確定的恼除。
所以踪旷，我們認為采用金絲雀發(fā)布的前提是：開發(fā)人員開發(fā)出來的程序必須有同時運行多個版本的能力。
而這一能力豁辉，對程序員本身的能力也有要求令野。比如它要求程序員在設(shè)計接口和DB schema時考慮向前兼容。在程序員能力不足時徽级，也無法采用金絲雀發(fā)布气破。
后記
金絲雀發(fā)布的概念的理解程度，決定了團隊是否能采用金絲雀發(fā)布餐抢，也決定了金絲雀發(fā)布系統(tǒng)的設(shè)計现使。
開源的金絲雀系統(tǒng)傾向于基于標準化的Kubernates平臺，大概率是因為它更標準弹澎，更容易實現(xiàn)朴下。而大多企業(yè)的金絲雀系統(tǒng)可能與企業(yè)內(nèi)部系統(tǒng)耦合嚴重，無法開源苦蒿。
