在項目迭代的過程中露戒，不可避免需要上線椒功。上線對應著部署，或者重新部署智什；部署對應著修改,修改則意味著風險动漾。
1.藍綠發(fā)布(Blue/Green Deployment)
①定義
藍綠部署是不停老版本，部署新版本然后進行測試荠锭。確認OK后將流量切到新版本谦炬，然后老版本同時也升級到新版本。

②特點
藍綠部署無需停機节沦，并且風險較小键思。

③部署過程
部署版本V1的應用（初始的狀態(tài)）
所有外部請求的流量都打到這個版本上。

image.png

• 部署版本V2的應用
  版本V2的代碼與版本V1不同(新功能甫贯、Bug修復等)吼鳞。

• 將流量從版本1 切換到版本2

  
  
  image.png

• 如版本V2測試正常，就刪除版本V1正在使用的資源（例如實例）叫搁，從此正式用版本V2赔桌。

  
  
  image.png

④小結

從過程不難發(fā)現(xiàn)，在部署的過程中渴逻，我們的應用始終在線疾党。并且新版本上線的過程中，并沒有修改老版本的任何內容惨奕，在部署期間雪位，老版本的狀態(tài)不受影響，這樣風險很小梨撞。并且只要老版本的資源不被刪除雹洗，理論上，我們可以在任何時間回滾到老版本卧波。

⑤藍綠發(fā)布的注意事項

當你切換到藍色環(huán)境時时肿，需要妥當處理未完成的業(yè)務和新的業(yè)務。如果你的數(shù)據(jù)庫后端無法處理港粱，會是一個比較麻煩的問題螃成。
可能會出現(xiàn)需要同時處理微服務架構應用和傳統(tǒng)架構應用的情況，如果在藍綠部署中協(xié)調不好這兩者查坪，還是有可能會導致服務停止寸宏。
需要提前考慮數(shù)據(jù)庫與應用部署同步遷移/回滾的問題。
藍綠部署需要有基礎設施支持咪惠。
在非隔離基礎架構（ VM 击吱、 Docker 等）上執(zhí)行藍綠部署，藍色環(huán)境和綠色環(huán)境有被摧毀的風險遥昧。

⑥優(yōu)勢和不足

• 優(yōu)勢
  升級切換和回退速度非掣泊迹快朵纷。
• 不足
  切換是全量的，如果V2版本有問題永脓，則對用戶體驗有直接影響袍辞。需要兩倍機器資源。

⑦適用場合

對用戶體驗有一定容忍度的場景常摧。
機器資源有富余或者可以按需分配（AWS 云搅吁，或自建容器云）。

2.灰度發(fā)布

①灰度發(fā)布定義

灰度發(fā)布是指在黑與白之間落午，能夠平滑過渡的一種發(fā)布方式谎懦。AB Test 就是一種灰度發(fā)布方式，讓一部分用戶繼續(xù)用A溃斋，一部分用戶開始用B界拦，如果用戶對B沒有什么反對意見，那么逐步擴大范圍梗劫，把所有用戶都遷移到B上面來享甸。灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定梳侨，在初始灰度的時候就可以發(fā)現(xiàn)蛉威、調整問題，以保證其影響度走哺。

灰度發(fā)布結構圖

image.png

②A/B Testing

A/B測試是用來測試應用功能表現(xiàn)的方法蚯嫌，例如可用性、受歡迎程度割坠、可見性等等齐帚。 A/B測試通常用在應用的前端上妒牙，不過當然需要后端來支持彼哼。

image.png

A/B 測試與藍綠發(fā)布的區(qū)別在于， A/B 測試目的在于通過科學的實驗設計湘今、采樣樣本代表性敢朱、流量分割與小流量測試等方式來獲得具有代表性的實驗結論，并確信該結論在推廣到全部流量可信摩瞎；藍綠發(fā)布的目的是安全穩(wěn)定地發(fā)布新版本應用拴签，并在必要時回滾。
藍綠發(fā)布和金絲雀是發(fā)布策略旗们，目標是確保新上線的系統(tǒng)穩(wěn)定蚓哩，關注的是新系統(tǒng)的BUG、隱患上渴。
A/B測試是效果測試岸梨，同一時間有多個版本的服務對外服務喜颁，這些服務都是經過足夠測試，達到了上線標準的服務曹阔，有差異但是沒有新舊之分（它們上線時可能采用了藍綠發(fā)布的方式）半开。

③金絲雀發(fā)布（Canary Deployment）

我們平常所說的金絲雀部署也是灰度發(fā)布的一種方式，在原有版本可用的情況下赃份，同時部署一個新版本應用作為「金絲雀」服務器來測試新版本的性能和表現(xiàn)寂拆，以保障整體系統(tǒng)穩(wěn)定的情況下，盡早發(fā)現(xiàn)抓韩、調整問題纠永。

礦井中的金絲雀：17 世紀，英國礦井工人發(fā)現(xiàn)谒拴，金絲雀對瓦斯這種氣體十分敏感渺蒿。空氣中哪怕有極其微量的瓦斯彪薛，金絲雀也會停止歌唱茂装；當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺善延，金絲雀卻早已毒發(fā)身亡少态。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為瓦斯檢測指標易遣，以便在危險狀況下緊急撤離彼妻。

灰度發(fā)布／金絲雀發(fā)布由以下幾個步驟組成：

• 準備好部署各個階段的工件，包括：構建工件豆茫，測試腳本侨歉，配置文件和部署清單文件。
• 從負載均衡列表中移除掉「金絲雀」服務器揩魂。
• 升級「金絲雀」應用（排掉原有流量并進行部署）幽邓。
• 對應用進行自動化測試。
• 將「金絲雀」服務器重新添加到負載均衡列表中（連通性和健康檢查）火脉。
• 如果「金絲雀」在線使用測試成功牵舵，升級剩余的其他服務器（否則就回滾）。

除此之外灰度發(fā)布還可以設置路由權重倦挂，動態(tài)調整不同的權重來進行新老版本的驗證畸颅，例如Istio中就可以實現(xiàn)權重來進行新老版本的驗證發(fā)布。

image.png

④優(yōu)勢和不足

• 優(yōu)勢
  用戶體驗影響小方援，灰度發(fā)布過程出現(xiàn)問題只影響少量用戶没炒。
• 不足
  發(fā)布自動化程度不夠，發(fā)布期間可引發(fā)服務中斷犯戏。

3.滾動發(fā)布(Rolling Update Deployment)

在金絲雀發(fā)布基礎上的進一步優(yōu)化改進送火，是一種自動化程度較高的發(fā)布方式祖很，用戶體驗比較平滑，是目前成熟型技術組織所采用的主流發(fā)布方式漾脂。

①定義

滾動發(fā)布：一般是取出一個或者多個服務器停止服務假颇，執(zhí)行更新，并重新將其投入使用骨稿。周而復始笨鸡，直到集群中所有的實例都更新成新版本。

②特點

這種部署方式相對于藍綠部署坦冠，更加節(jié)約資源——它不需要運行兩個集群形耗、兩倍的實例數(shù)。我們可以部分部署辙浑，例如每次只取出集群的 20% 進行升級激涤。

③部署過程

• 滾動式發(fā)布一般先發(fā)1臺，或者一個小比例判呕，如2% 服務器倦踢，主要做流量驗證用，類似金絲雀 (Canary) 測試侠草。
• 滾動式發(fā)布需要比較復雜的發(fā)布工具和智能 LB辱挥，支持平滑的版本替換和流量拉入拉出。
• 每次發(fā)布時边涕，先將老版本V1流量從LB上摘除晤碘，然后清除老版本，發(fā)新版本V2功蜓，再將LB流量接入新版本园爷。這樣可以盡量保證用戶體驗不受影響。
• 一次滾動式發(fā)布一般由若干個發(fā)布批次組成式撼，每批的數(shù)量一般是可以配置的（可以通過發(fā)布模板定義）童社。例如第一批 1 臺（金絲雀），第二批 10%端衰，第三批 50%叠洗，第四批 100%。每個批次之間留觀察間隔旅东，通過手工驗證或監(jiān)控反饋確保沒有問題再發(fā)下一批次，所以總體上滾動式發(fā)布過程是比較緩慢的 (其中金絲雀的時間一般會比后續(xù)批次更長十艾，比如金絲雀 10 分鐘抵代，后續(xù)間隔 2 分鐘)。
• 回退是發(fā)布的逆過程忘嫉，將新版本流量從 LB 上摘除荤牍，清除新版本案腺，發(fā)老版本，再將 LB 流量接入老版本康吵。和發(fā)布過程一樣劈榨，回退過程一般也比較慢的。

④優(yōu)勢和不足

• 優(yōu)勢
  用戶體驗影響小晦嵌，體驗較平滑同辣。
• 不足
  -- 發(fā)布和回退時間比較緩慢。
  -- 發(fā)布工具比較復雜惭载，LB 需要平滑的流量摘除和拉入能力旱函。

4.功能開關發(fā)布

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

image.png

①部署過程

• 功能開關發(fā)布需要一個配置中心或者開關中心這樣的服務支持券腔，例如攜程的 Apollo配置中心或者開源的FF4J，這些都支持開關發(fā)布拘泞。業(yè)界還有專門的功能開關 SaaS 服務颅眶，例如 LaunchDarkly。通過配置中心田弥，運維或研發(fā)人員可以在運行期動態(tài)配置功能開關的值涛酗。當然，功能開關發(fā)布只是配置中心的一種使用場景偷厦，配置中心還能支持其它很多動態(tài)配置場景商叹。
• 功能開關服務一般提供客戶端 SDK，方便開發(fā)人員集成只泼。在運行期剖笙，客戶端 SDK 會同步最新的開關值，技術實現(xiàn)有推方式 (push)请唱，也有拉方式 (pull)弥咪，或者推拉結合方式。
• 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代碼中十绑，新功能隱藏在開關后面聚至，如果開關沒有打開，則走老代碼邏輯本橙，如果開關打開扳躬，則走新代碼邏輯。技術實現(xiàn)上可以理解為一個簡單的 if/else 邏輯。
• 應用上線后贷币，開關先不打開击胜，然后運維或研發(fā)人員通過開關中心打開新功能，經過流量驗證新功能沒有問題役纹，則發(fā)布完成偶摔；如果有問題，則隨時可以通過開關中心切回老功能邏輯促脉。

②優(yōu)勢和不足

• 優(yōu)勢
  升級切換和回退速度非吵秸快。
  相對于復雜的發(fā)布工具嘲叔，實施比較簡單亡呵，成本相對低廉。
  研發(fā)能夠靈活定制發(fā)布邏輯硫戈，支持 DevOps 自助發(fā)布锰什。
• 不足
  切換是全量的，如果 V2 版本有問題丁逝，則對用戶體驗有直接影響汁胆。
  對代碼有侵入，代碼邏輯會變復雜霜幼，需要定期清理老版本邏輯嫩码，維護成本變高。

參考：https://cloud.tencent.com/developer/article/1449209

轉載自：https://www.pingface.com/2020/05/deploymentstrategy.html