運維&測試人員必讀 | 微服務架構下應用灰度部署策略

應用上線，對開發者而言是階段性工做的結束，可對運維和測試人員來講，這只是挑戰的開始。作過運維的朋友都知道，無論在發佈前作過多麼完備的自動化和人工測試，在發佈時或多或少都會面臨一些問題：

• 生產環境中，微服務集羣的某個實例出現問題，如何提早避免這種狀況，在不下線的狀況如何將其進行屏蔽；

  
  

• 因爲業務的快速迭代性，微服務集羣下的實例發佈不一樣版本。如何根據版本管理策略進行路由，提供給下游微服務區別調用，達到多版本灰度訪問控制；

  
  

• 對於測試負責人，有哪些工具能夠支持他對微服務作 A/B 測試。

根據墨菲定律，可能會出錯的版本發佈必定會出錯。那麼，在沒法百分百避免版本升級故障的狀況下，須要經過一種平滑的方式進行可控版本的發佈，把故障影響控制在能夠接受的範圍內，並能夠快速回退，這也就是咱們今天要談的主題——灰度發佈。

灰度發佈，是指在黑與白之間，可以平滑過渡的一種發佈方式。

通俗來講，即讓產品的迭代可以按照不一樣的灰度策略對新版本進行線上環境的測試，灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠對新版本進行測試、發現和調整問題，以保證其影響度。

本文將會和你們分享 KubeSphere 基於 Istio 提供的藍綠部署、金絲雀發佈、流量鏡像等三種主流灰度策略，但願能夠對你們的工做有所幫助。

藍綠部署

藍綠髮布提供了一種零宕機的部署方式，在保留舊版本的同時部署新版本，將兩個版本同時在線，新版本和舊版本是相互熱備的，經過切換路由權重 (weight) 的方式（非 0 即 100）實現應用的不一樣版本上線或者下線，若是有問題能夠快速地回滾到老版本。

金絲雀發佈

金絲雀部署和藍綠有點像，可是它更加規避風險。你能夠階段性的進行，而不用一次性從藍色版本切換到綠色版本。

採用金絲雀部署，會在生產環境運行的服務中引一部分實際流量對一個新版本進行測試，測試新版本的性能和表現，而後從這部分的新版本中快速獲取用戶反饋。

流量鏡像

流量鏡像功能一般用於在生產環境進行測試，是將生產流量鏡像拷貝到測試集羣或者新的版本中，在引導用戶的真實流量以前對新版本進行測試，旨在有效地下降新版本上線的風險。

流量鏡像可用於如下場景：

驗證新版本：能夠實時對比鏡像流量與生產流量的輸出結果。

測試：生產實例的真實流量可用於集羣測試。

隔離測試數據庫：與數據處理相關的業務，可以使用空的數據存儲並加載測試數據，針對該數據進行鏡像流量操做，實現測試數據的隔離。

從以上不一樣策略來看，要實現一套灰度發佈流程，須要應用程序和運維流程對該發佈過程進行支持，工做量和難度的挑戰是很是大的。

咱們建議你們經過 KubeSphere 來完成此工做， KubeSphere 基於 Istio 搭建的三種灰度策略，使得運維和測試人員無需修改應用的服務代碼，便可實現灰度、流量治理、Tracing、流量監控、調用鏈等服務治理功能，爲企業的運維和測試人員節約大量成本。

再好的策略也不是萬能的，部署了這些策略並不意味着百分百成功，所以部署後的工做負載監控必不可少，如何設置工做負載級別的告警策略、添加告警規則、通知規則等操做及實踐，咱們將會在下一篇文章和你們分享，敬請期待。

7 月 25 日，咱們特邀業內技術專家爲你們定製了一場『容器&微服務架構實踐』論壇，精選出 5 場精彩演講，從微服務改造、DevOps、服務監測分析、容器遷移及真實的用戶實踐出發，讓全部參會者能系統化深刻學習微服務以及容器相關技術，少走彎路。 準備好了嗎？趕忙掃碼報名吧！

當即報名