金絲雀部署

一次把所有使用者轉移到新版本的主意會嚇壞一些使用者.如果出錯所有的使用者會受影響.舉而代之,我們試著逐步地增加流量至新版本並持續監督它,如果有問題事件,你可以退回百分百的請求至現行版本.

這就是熟知的金絲雀部署這名稱源自多年前一個被煤礦雇用技工,在現在安全感應器來臨前,礦工遇到的一般問題就是有毒氣體的累積.這些氣體不全然有味道.警告他們自己存在危險氣體中,礦工會帶一蘢金絲雀一起進入礦工.此外還有悅耳的叫聲金絲雀對於毒氣很有警覺如果金絲雀死了礦工在像金絲雀般死去之前也是時候就要出去

金絲雀部署就是這樣的比喻.逐步部署與監控扮演金絲雀的角色.如果在新版本偵測到問題.你有能力還原到前一個版本並避免潛在的災害

我們可以做一個更明顯的關於金絲雀部署

一個標準的金絲雀部署可以被基礎建設獨力掌握.如同你導一定比例的需求去你的新版本另一方面一個精明的金絲雀需要存在一個智能路由或功能切換的框架

智能路由和功能切換的框架

一個智能路由是軟體的一部分基於商業邏輯專門導需求去後端的端點.在Java世界一個廣泛的這類的軟體是Netflix的OSS Zuul.

舉例在智能路由你可以只導iOS使用者到新的部署,因為他們是現行版本有問題的用戶不需要冒風險中斷Android用戶.或是你只是想在新版本針對iOS使用者確認日誌訊息.

功能切換的框架允許你依設定選擇你代碼的哪部分能執行.Java規格中流行的框架如FF4J 和Togglz.

這切換通常是一個布林值儲存在外部資料源他們可以在線上動態依序變更切換

切換功能如同是否然後框架由外部設定來切換.這過度簡化的概念但這給你一個如何運作的概念

關於

功能切換一個有趣的事是你可以從一個版本發佈一個功能.在過去已發佈的版本你可以切換新功能給使用者.如果有問題你可以再切換回去對使用者隱藏此功能

功能切換也伴隨一些缺點請小心使用它們.新舊代碼會留在同一個資料庫直到你做一次清理.

在功能切換驗證會變特別困難因為知道切換當時的狀態會很棘手.如果你工作在一個規律的領域這也難稽核是否某些代碼正確的執行在量產環境