在軟件上線以前,不可避免地要對軟件的正確性、可靠性進行測試,又最好不要停機維護、不要影響用戶體驗,而且在新版本出現問題的時候可以及時回退。因此,須要有一套完整的部署方案,灰度發佈、滾動發佈、藍綠部署都是常見的手段,而A/B測試則是對用戶體驗進行調查的測試手段,這裏一併學習。html
灰度發佈又叫作金絲雀發佈,之前礦工下礦洞前,會放一隻金絲雀去試探是否有瓦斯(金絲雀對瓦斯很敏感),映射到這裏就是先發布一小部分來試探總體是否可以正常運行,若是能正常運行則進行徹底部署的發佈方式,目前仍然是很多成長型技術組織的主流發佈方式。數據庫
(1)當前版本爲V1,替換服務器集羣中的一小部分(好比1臺)爲新版本V2。服務器
(2)若是正常運行,則把剩餘V1版本所有升級爲V2;若是運行失敗,全部服務器回退到V1。架構
(1)流量趨勢圖負載均衡
綠色爲舊流量,黃色爲新流量。微服務
(2)優勢工具
用戶體驗影響小,發佈過程當中出現問題隻影響一部分用戶。學習
可以動態指定新版本流量測試
(3)缺點spa
自動化程度不夠,發佈期間可能會引起服務中斷。
滾動發佈(Rolling Update Deployment)是在灰度發佈上的改進,先發布一小部分,而後逐步增長新版本的數量,直到服務器都升級爲新版本。自動化程度較高,用戶體驗平滑,是目前成熟型技術組織所採用的主流發佈方式。
(1)先發布小比例新版本,相似金絲雀。
(2)若是驗證成功,按照必定比例替換新版本,直到全部版本都升級爲新版本,例如1臺,10%,50%,100%。
(3)一旦失敗,將全部新版本應用替換回舊版本應用。
(1)流量趨勢圖
綠色爲舊流量,黃色爲新流量。
(2)優勢
用戶體驗影響小,體驗平滑。
(3)缺點
發佈和回退時間緩慢。
發佈工具複雜,NLB須要平滑的流量摘除和拉入能力。
沒法動態控制流量
藍綠部署(Blue Green Deployment)是一種能夠保證系統在不間斷提供服務的狀況下上線的部署方式,它以可預測的方式發佈應用,減小發布過程當中服務中止的時間。
(1)準備兩個相同的應用運行環境,命名爲藍色環境、綠色環境,剛開始,藍色環境和綠色環境都運行着相同的應用版本V1,只有藍色環境對外提供服務。
(2)咱們開發了一個新版本V2,那麼放到綠色環境上進行反覆的測試、修改、驗證,肯定達到上線標準後,利用負載均衡器/反向代理/路由等手段將對外服務切換爲綠色環境。
(3)一段時間後,若是發生故障,那麼迅速切換回藍色環境V1;若是運行沒有異常,那麼藍色環境更新版本到V2,版本再次一致。
(4)當須要開發下一個版本V3,重複前面的步驟,藍色綠色相互切換相互備份。
(1)流量趨勢圖
綠色爲舊流量,黃色爲新流量。
(2)特色
藍色綠色環境相同,但硬件能夠不一樣,例如藍色和綠色環境分別是兩臺獨立的機器。
藍色綠色環境都會在上線版本、舊版本(用於回滾)和新版本(用於上線前測試)之間循環。
如何保證數據庫的事務在切換、回退過程當中不受影響是很重要的事情,通常來講能夠在切換過程當中設置爲「只讀」,或者設計回饋機制,將事務同時反饋到兩個環境。
(3)優勢
不停機更新。
遇到問題能及時回退到正確版本。
(4)缺點
須要的硬件成本和軟件服務倍增了。
數據庫同步很是困難。
若是須要同時處理「微服務架構應用」和「傳統架構應用」,當協調很差的時候仍是可能出現服務中止的。
在非隔離基礎架構(VM、Docker)上執行藍綠部署,藍綠色環境都有被摧毀的可能。
藍綠髮布就是雙服務器發佈中的蠻力發佈法(強行切換),而利用相同的雙服務器發佈模式能夠進行灰度、滾動發佈。
前面的全部都是發佈方法,旨在發現bug、隱患。
測試方法則是效果測試,關注的是舊版本和新版本的效果好壞,好比流量轉化率、用戶體驗等等。
A/B測試指的是同時上線V1和V2版本,根據必定條件將流量分別導入V1和V2版本,收集感興趣的數據,來對比產品功能的效果。
影子測試主要用於語言切換,好比從JAVA項目遷移到.NET項目,準備兩個徹底相同的環境,將流量同時導入兩個環境,比對輸出的響應,來判斷是否邏輯等價。
這種測試可能須要幾周,也可能長達半年。
部署方式 | 零停機 | 生產流量測試 | 機器成本 | 回退速度 | 對用戶的影響 | 複雜度 |
---|---|---|---|---|---|---|
灰度發佈 | ? | √ | 低 | 慢 | 通常 | 低 |
滾動發佈 | √ | √ | 低 | 慢 | 低 | 低 |
雙服務器組——藍綠 | √ | × | 高 | 快 | 通常 | 通常 |
雙服務器組——灰度 | √ | √ | 高 | 快 | 小 | 通常 |
雙服務器組——滾動 | √ | √ | 高 | 快 | 小 | 通常 |
二、《藍綠部署、金絲雀發佈(灰度發佈)、A/B測試的準肯定義》