概述
線上項目發布一般有以下幾種方案：
停機發布藍綠部署滾動部署灰度發布停機發布 這種發布一般在夜裡或者進行大版本升級的時候發布，因為需要停機，所以現在大家都在研究 Devops 方案。
藍綠部署需要準備兩個相同的環境。一個環境新版本，一個環境舊版本，通過負載均衡進行切換與回滾，目的是為了減少服務停止時間。
滾動部署就是在升級過程中，並不一下子啟動所有新版本，是先啟動一臺新版本，再停止一臺老版本，然後再啟動一臺新版本，再停止一臺老版本，直到升級完成。基於 k8s 的升級方案默認就是滾動部署。
灰度發布也叫金絲雀發布，灰度發布中，常常按照用戶設置路由權重，例如 90%的用戶維持使用老版本，10%的用戶嘗鮮新版本。不同版本應用共存，經常與 A/B 測試一起使用，用於測試選擇多種方案。
上邊介紹的幾種發布方案，主要是引出我們接下來介紹的 spring-cloud-gateway 動態路由，我們可以基於動態路由、負載均衡和策略加載去實現灰度發布。當然現在有很多開源的框架可以實現灰度發布，這裡只是研究學習。
動態路由
spring-cloud-gateway 默認將路由加載在內存中。具體可以參見 InMemoryRouteDefinitionRepository 類的實現。
這裡我們基於 Redis 實現動態路由。基礎項目見 spring-cloud-gateway 簡介
1. 將 actuator 的端點暴露出來
2. redis 配置
3. 將原內存路由持久化到 redis
4. 重寫動態路由服務
5. 對外暴露接口
測試
測試前刪除我們配置的靜態路由，因為靜態路由和 redis 動態路由同時存在時取併集。
1.訪問 ocalhost:2000/actuator/gateway/routes , 可以看到只有默認路由。
這個時候訪問 192.168.124.5:2000/idc-provider1/provider1/1 根據結果可以推測能正確路由到 provider1， 測試結果一致。
2.創建 provider1路由，將路徑設置為 /p1/**，測試是否生效。
POST請求 localhost:2000/gateway/add
查看 redis 存儲，或者請求
localhost:2000/actuator/gateway/routes
, 都可以看到配置成功。
訪問
curl localhost:2000/p1/provider1/1
結果輸出 2001，與期望一致。
由此可見動態路由已經生效。
結語
本文到此結束。感興趣的小夥伴後續可以通過加載配置文件，基於權重進行灰度。