一些歷史

John Scott Haldane 于 1895 年提出，因為小型恒溫動物的呼吸交換比人類更快,礦井中的一氧化碳等有毒氣體或甲烷等窒息性氣體會先影響它們。

比如,同樣的一氧化碳濃度,老鼠會在幾分鐘內受到一氧化碳的影響，人類需要 20 倍的時間才會受到影響，于是 1896 年左右開始，老鼠被用作井下有毒氣體預警的物種。

一段時間后，人們發現金絲雀這種生物對于有毒氣體更加敏感。在 1900 年開始有記錄顯示，一些礦井開始把金絲雀作為井下有毒氣體的預警物種。

后來，人們為了能重復使用金絲雀，發明了一個用于金絲雀毒氣探測的專用籠子。籠子可以主動充氧，前方設有一個通氣孔，通氣孔可以通過密閉窗進行開啟和關閉。在需要金絲雀進行預警的時候,把通氣孔打開。如果籠子中的金絲雀被毒氣毒暈，關上通氣孔的窗口并讓籠子充滿氧氣。如果金絲雀如果沒有被毒死，就有可能活過來。

來源: https://en.wikipedia.org/wiki/Domestic_canary#/media/File:Revival_cage.jpg

因為科技的不斷發展，有毒氣體探測器被發明了出來。這種用生命來探測的方式開始逐步退出歷史舞臺。直到1986 年英國和美國完全停止使用金絲雀來作為預警生物使用。

金絲雀部署，這種部署方式的目標與邏輯和使用金絲雀來預警非常類似(通過開關通氣孔/流量的方式來控制危害與恢復能力)，我猜想可能大家也希望能紀念一下在 20 世紀為礦工獻出生命的金色小鳥們，所以這種方式被冠上了金絲雀的名稱。

了解了名字的來歷，我們開始來了解一下金絲雀部署到底是什么樣的。

基本定義

金絲雀部署是在將更改推廣到整個服務集群并使其對所有人可用之前，將更改推廣到一小部分用戶進行測試。并在測試過程中持續觀測被測試的服務各個維度的狀態，驗證新版本的健壯性、可用性、穩定性等。

當驗證結果達到期望目標后，可以逐步將新的版本部署到更多服務器，使更多用戶使用到它。

優勢

(1) 零下線時間與快速回滾:

在一系列的相關驗證和測試之后，如果新版本的軟件被認為不合適，則很容易回滾和控制影響范圍。

(2) 真實場景下的測試：

由于是直接將新版本部署到生產環境進行測試，所以能夠通過真實流量對新版本進行針對性的驗證。當然，需要對流量和用戶進行限制，來控制驗證的范圍和影響面。

(3) 較低的基礎設施成本:

因為金絲雀部署策略是通過一定規則,按規則對的請求進行要求的分流或路由(例如:用戶名、地區、年齡、隨機等)，所以只需要少量額外的基礎設施，就可以達到驗證的效果。對比藍綠部署策略,需要準備與生產環境同樣的一套基礎設施,部署成本顯然會高很多。

靈活的按需進行驗證相關版本、功能的正確性。

可以根據不同的特征和標識，對請求的流量進行多個維度分流和路由，以達到不同粒度不同特征的靈活驗證。

不是銀彈

雖然金絲雀部署能夠為大家的部署提供強力的支持和幫助。但是，軟件工程中是沒有銀彈的。金絲雀部署在很多場景也需要謹慎使用：

• 嚴格不允許出錯的系統，例如:醫療系統、消防系統等
• 需要部署的數據結構無法向下兼容已經當前版本數據結構

雖然阿里云的 MDS 能夠提供分流影子數據庫的能力。但是，正式用戶使用的話，依然會影響到實際的數據和行為體驗。所以，僅限于測試人員或內部用戶體驗使用才能發揮他的能力。

• 非自動化的金絲雀部署,既耗時又容易出現錯誤。所以，我們應該盡可能使用自動化的方式去使用它，而不是手動去維護分流策略和邏輯。
• 以及很多其他對于生產環境要求嚴格的場景，均不建議使用

接下來換個思維，讓我們來看看一些與細節無關的討論。

金絲雀發布 or 金絲雀部署?

在交流和口語中，大家習慣于將發布和部署混用。常常會看到類似于將藍綠部署、灰度發布(比起金絲雀大家更愿意用灰度)、滾動發布等名詞被列舉到一起，以表示他們都是發布版本的一些不同的方法。

下面我們開始來咬文嚼字。

發布:

[issue;release;deliver;distribute] 宣布,發表

例句:向全國發布新聞

部署:

1. [disposition;deployment]∶處理;料理

例句:炮兵的部署已標明在這張地圖上

2. [arrange;lay out]∶安排

例句:部署計劃

根據上面的兩個詞典釋義，我是這樣理解發布和部署的：

發布廣義上是指思想、觀點、文章和意見等通過報紙、書刊、網絡或者公眾演講等文字和演講的形式公之于眾，向外界傳輸消息的一種過程。放在計算機這個范疇中時，它是一種將某個特定的軟件放到大家能接觸到的一些地方，被動的讓大家去更新或者同步。比如：我把軟件的某個版本打包發布了。

部署廣義上是指安排或執行人力、計劃、任務等。放到計算機這個范疇,它是一種將特定軟件安裝或更新到對應的環境中,使其可以為用戶提供服務。比如：我把新版本部署到測試環境了，你測試一下。

根據上面的解釋，我認為用更準確的是金絲雀部署(Canary Deployment)。

與 A/B 測試的關系

剛開始對金絲雀部署了解時,發現許多地方將 A/B 測試與金絲雀部署混為一談,甚至有直接將這它們兩個當成一個東西來對待。實際上,在深入了解后,會發現它們之前確實是有聯系，不過還沒達到可以畫上等號的程度。

相同之處

他們之間的網絡流量處理邏輯非常相似，都是通過流量不同特征來決定，對流量進行服務的版本。

金絲雀部署可用作實現A/B 測試的技術基礎的一部分;但是不要將它們避免混為一談。

不同之處

他們兩者的目的是完全不同的，金絲雀部署被用來檢測問題和回歸功能，A/B 測試是一種來用來測試業務設計假設的方法。從二者的目標出發,他們測試的和觀測的方法是不一樣的。

金絲雀部署的通常是使用偏技術側觀測工具(APM、日志監控等)。技術/開發人員會對需要部署的新版本服務進行觀測。當觀測結果與預期相符，則技術人員可以進一步操作。否則，需要先解決問題，再部署和觀測，直到能夠達到預期，再進行下一步操作。

如果我們用同樣的方式和工具來希望對業務觀測，是無法得到準確結果的。甚至觀測的人員職能都不同。一般情況下，A/B 測試對觀測部分需要預先的觀測數據收集埋點。接著，對收集到的業務數據進行整理和統計，最終得出相關的數據分析結果和統計結果，以提供給業務人員對新業務進行分析和判斷。

最后,從更時間的角度來說，業務人員在收集足夠的數據以證明A/B 測試的顯著性可能需要數天時間，而技術人員希望金絲雀部署在幾分鐘或幾小時內完成。

聊了這么多實現無關的話題，接下來讓我們來一起看看，實現金絲雀部署有哪些辦法吧。

實現

實現結構

金絲雀部署的關鍵點有如下幾點:

• 網絡流量分流
• 分流策略管理
• 多應用間分流傳遞策略
• 數據兼容性處理

由上圖關鍵點我們可以通過下圖了解的更加明確:

下面我們從流程入手,看看金絲雀部署具體的執行過程是什么樣的。

具體流程

從流程入手，這樣很容易就能了解到金絲雀部署在不同階段，呈現出什么樣的特征，提供了什么樣的能力等。

• 正常階段: 當前環境中只有 1-n 個版本已驗證版本, 為所有的用戶提供服務

• 驗證階段：當前環境存在 2 到 n 個版本, 其中有一個已驗證版本, 為大部分用戶提供相對穩定服務, 剩下的 1 到 n-1 版本為需驗證版本, 為特定用戶(某些場景下隨機挑選)提供相對不穩定服務。同時,持續觀需驗證版本運行情況,以判斷該版本是需要進行部署,還是進行其他處理。

• 部署階段: 某個需驗證版本通過驗證后,此需驗證版本將被部署至計劃的服務集群占比。如果,還需進一步測試,則又回到驗證期進行驗證.直至,需驗證版本部署占比達到最終需要。往往會使用滾動部署的方式進行部署。

• 狀態流轉總覽

實現方式

這里提到的主要都是服務器端的實現方式。

我根據不同的實現方式將他們分為下列幾種類型：

• 基礎設施實現(IaaS)：比如通過阿里云 MDS 工具實現
• 平臺實現(PaaS):通過 K8S 的 Ingress 組件或 Istio 來實現
• 通過 Nginx 等中間件實現:直接在 Nginx 中通過腳本控制流量轉發規則
• ...

由于，金絲雀部署本身的實現細節與應用場景具有緊耦合特性。具體的實現方法就不在這里展開了。在使用過程中關注文中提到它的特性與注意事項(不是銀彈)以及具體的執行流程和結構來進行部署。我在這里做的更多的拋磚引玉，希望大家能有更多金絲雀部署的精彩內容和思考能一起來討論。

最后

來源：http://coachellavalleyweekly.com/canary-in-a-coal-mine/

20 世紀的某一天，昏暗的狹窄的礦井中。頭戴礦燈的礦工一手提著一個籠子，另一手并著腳努力的往前爬行，汗水裹著黑色的粉末在臉上往下流淌。美麗的鳥兒在搖搖晃晃的籠子中努力的保持著平衡，不知道迎接他僥幸逃脫后的陽光還是窒息的毒氣。