灰度部署、滾動部署與藍綠部署

前言

最近在進行單元化建設方面的的工做，其中涉及服務分組和藍綠髮布相關的概念，在這裏總結一下了解到的相關知識。

版本更新策略

功能開關

在應用邏輯裏內置功能開關，經過開關的打開關閉來決定執行新舊邏輯，無需路由機制支持，開發人員能夠靈活的控制程序的表現。這種方式須要動態配置中心的支持，目前業界已經有比較完善的解決方案，好比Apollo、spring cloud config等等。具體的方式相似這樣：

if Config.SwitchOn {
    //new logic
} else {
    //old logic
}
複製代碼

功能開關的方式雖然簡單直觀，可是隨着版本的更新須要常常清理過時配置，維護成本比較高。

灰度部署/金絲雀部署

灰度部署是指先更新一小部分服務器好比2%，而後對應用進行測試驗證。若是驗證經過，則繼續更新剩餘部分的服務器，不然進行回滾。灰度部署的好處就是影響面小，出現問題時只會影響很小一部分用戶，適合對新功能信心不足或是對服務可用性要求比較高的場景。

滾動部署

滾動部署更像是灰度部署的加強版，當新版本通過灰度驗證經過以後，咱們逐漸增大灰度部署的範圍，直到所有的服務器都更行到新版本。在部署過程當中須要支持平滑切換，即先把服務器從負載均衡列表中摘除；此外滾動發佈一般是分批次的，好比第一批10%，第二批30%，第三批100%等等。

滾動部署相比灰度部署，須要自動化部署工具以及完善的路由機制支持，這樣才能保證用戶體驗足夠平滑；此外滾動部署比起灰度部署的發佈和回滾時間也會更長。

藍綠部署

藍綠部署技術是指同時維護兩套相同的生產環境，咱們能夠稱之爲藍色環境和綠色環境，而只有一個顏色的環境負責提供完整的服務，另外一個環境則徹底空閒。當咱們須要部署新版本的服務時，咱們先在空閒的環境進行部署和驗證，當驗證完畢後，經過操做路由將客戶端流量切換至新版本的環境，而原先的環境則變爲空閒環境，依次循環交替。

要實現藍綠部署，須要幾個額外支持：

1. 完善的、操做成本低的路由控制機制，運維人員能夠動態地進行流量切換
2. 冗餘資源，任意時刻其中一個環境的資源是閒置的。固然咱們能夠把閒置的環境做爲預發驗證環境，或者把刪除一部分空閒環境的資源，等下次發佈時再擴充資源

藍綠部署的好處：

1. 能夠下降停機時間，咱們的生產環境幾乎沒有停機時間，切換在很短的時間內便可完成
2. 能夠快速回滾，當新功能不符合預期是咱們只須要將流量切換回上一個版本的環境便可
3. 能夠提升災備能力，當一個環境出現問題時咱們能夠迅速切換到另外一個可用的環境。實際上每次發佈都至關於進行了一次災備切換

藍綠部署的不足：

1. 資源利用率不足，由於通常的資源是閒置的
2. 當流量切換完畢以後，可能在後端仍有業務邏輯沒有處理完畢，須要額外的機制保證。你能夠在設計時就保證兩個環境能夠同時處理事務，這樣就不須要考慮這個問題了；也能夠在切換流量前先將服務設置爲「只讀模式」，流量切換完畢再回到「讀寫模式」等等。
3. 新舊版本可能會涉及數據庫表結構的變化，這時咱們須要額外的數據庫兼容措施。當切換到新的環境發生問題時，可能會由於新的邏輯致使數據差別。要解決這種問題能夠將數據庫重構與應用發佈分開：先進行數據庫重構以保證新舊版本兼容，數據庫重構完畢後再進行應用發佈。

其餘概念

單服務器組合雙服務器組

前面提到的藍綠部署須要兩個環境，實際上就至關於雙服務器組。二灰度部署和滾動部署也能夠用於雙服務器組。好比雙服務器組中的灰度部署就是在藍綠環境切換時不是一刀切，而是先切換一小部分到新環境，驗證經過後再全量切換到新環境；而滾動部署在雙服務器組中就是分批次切換到新環境。

服務器組

在進行服務器組劃分時，能夠有不一樣程度的劃分：根據數據中心劃分，好比A機房爲一組、B機房爲一組；根據邏輯分組劃分，好比A、B機房的一半機器分爲一組、剩下的另外一半機器分爲一組。不管如何分組，請求在服務之間傳遞時都是須要識別某個機器的分組標識的，好比在註冊中心中服務實例的元數據裏須要有相似"group=group1"這樣的標識，這樣客戶端或者代理節點在進行路由時才能識別服務端實例所在的分組。

路由機制

前面提到的各類部署策略，實際上都須要不一樣程度的路由機制支持。對於HTTP服務可使用代理節點的方式，在域名解析過程當中分發到不一樣的下游節點；RPC服務則須要實現配套的路由機制了。