接手這個項目的時候我第一反應(yīng)是路由嘛寫死在配置文件里不就行了。直到有一次線上有一個新服務(wù)要接入網(wǎng)關(guān)按老流程改完application.yml重新發(fā)布結(jié)果恰好趕上業(yè)務(wù)高峰網(wǎng)關(guān)重啟那幾十秒所有經(jīng)過網(wǎng)關(guān)的請求直接502。從那之后我就明白了網(wǎng)關(guān)路由如果只能靠重啟生效那它就是整個微服務(wù)架構(gòu)里最脆弱的一環(huán)。這也是我為什么花時間把Spring Cloud Gateway的動態(tài)路由徹底捋了一遍。這篇文章是SpringCloud實戰(zhàn)系列的第十三篇專注講清楚一件事怎么讓Gateway在不重啟的情況下把新路由、改路由、刪路由全部在線完成。內(nèi)容會覆蓋動態(tài)路由的動機(jī)、三條主流實現(xiàn)路線的對比、基于Nacos落地動態(tài)路由的核心代碼、路由刷新的底層機(jī)制以及我上線后踩過的一堆坑。適合已經(jīng)跑通Gateway基礎(chǔ)用法、想把網(wǎng)關(guān)做得更工程化的同學(xué)參考。1. 靜態(tài)路由的僵局一次配置變更引發(fā)的連鎖反應(yīng)1.1 網(wǎng)關(guān)路由配置的真實痛點Spring Cloud Gateway最基礎(chǔ)的用法是在application.yml里這樣寫spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/order/** filters: - StripPrefix1這本身沒什么問題小規(guī)模項目完全夠用。但一旦微服務(wù)數(shù)量上來了你會碰到幾個很現(xiàn)實的問題。第一改動成本高。只要新增一個服務(wù)、調(diào)整一個路徑前綴、修改一次超時時間都得改配置然后重啟網(wǎng)關(guān)。微服務(wù)架構(gòu)里服務(wù)是高頻變動的新服務(wù)上線、舊服務(wù)拆分、接口路徑調(diào)整都是家常便飯每次都要重啟網(wǎng)關(guān)整個系統(tǒng)的入口就跟著抖動一次。第二配置膨脹嚴(yán)重。幾十上百條路由堆在application.yml里誰改過什么、為什么改、什么時候改的完全沒法追溯。我見過最夸張的項目路由配置文件三千多行review的時候根本沒人敢動。第三環(huán)境隔離差。開發(fā)、測試、生產(chǎn)環(huán)境的網(wǎng)關(guān)配置往往有差異靠profile區(qū)分還行但一旦某些公共路由需要保持一致配置維護(hù)就跟復(fù)制粘貼一樣痛苦。第四發(fā)布窗口限制。網(wǎng)關(guān)屬于核心基礎(chǔ)組件重啟需要走變更流程、評估影響面、選低峰期發(fā)布。一個新服務(wù)想接入網(wǎng)關(guān)要等一次完整的發(fā)版窗口這在業(yè)務(wù)快速迭代的團(tuán)隊里非常難受。1.2 動態(tài)路由到底解決什么問題所謂動態(tài)路由核心就一句話路由規(guī)則的增刪改查不依賴應(yīng)用重啟而是在運行期通過外部配置源實時生效。它解決的問題可以拆成幾個層面接入效率新服務(wù)上線往配置中心寫一條路由網(wǎng)關(guān)秒級刷新不用排隊等發(fā)布配置治理路由集中放到配置中心或數(shù)據(jù)庫有版本管理、有操作審計、可以回滾網(wǎng)關(guān)穩(wěn)定性避免因路由變更而重啟網(wǎng)關(guān)保障入口流量持續(xù)可用灰度與應(yīng)急可以在線把某個服務(wù)摘掉、掛維護(hù)頁、切流量到新集群從業(yè)務(wù)價值來看動態(tài)路由最大的意義不是省了一次重啟而是讓網(wǎng)關(guān)從靜態(tài)基礎(chǔ)設(shè)施變成了可實時編排的流量入口。你可以在大促前臨時加一條分流規(guī)則也可以在服務(wù)異常時快速摘流量這種靈活性在復(fù)雜環(huán)境里幾乎是剛需。2. 動態(tài)路由的三條路線輪詢、推送與事件監(jiān)聽確定要做動態(tài)路由之后接下來的問題是怎么讓Gateway拿到最新的路由配置。我調(diào)研和試過的主流方案大致可以分成三條路線。每條路線的取舍都不一樣這里把對比展開講講。2.1 路線一數(shù)據(jù)庫存儲加定時輪詢這個方案的思想很樸素路由配置存到MySQL里網(wǎng)關(guān)起一個定時任務(wù)每隔幾秒查一次路由表發(fā)現(xiàn)變化就刷新內(nèi)存中的路由定義。優(yōu)點很直接——實現(xiàn)簡單不用引入額外中間件只要你項目里本來就有MySQL就能跑。而且數(shù)據(jù)庫天然支持復(fù)雜的查詢和管理界面運營同學(xué)可以直接通過管理后臺增刪改路由。但它的問題也很明顯。輪詢間隔不好設(shè)間隔太短數(shù)據(jù)庫壓力大、網(wǎng)關(guān)頻繁重建路由間隔太長路由變更生效太慢失去了動態(tài)的意義。另外每次全量拉取路由表再對比差異在路由數(shù)量大的時候?qū)?shù)據(jù)庫和網(wǎng)關(guān)都是一個不小的負(fù)擔(dān)。還有一個隱患多實例網(wǎng)關(guān)部署時每個實例的輪詢時間點不一樣會導(dǎo)致一段時間內(nèi)各實例路由不一致流量被分發(fā)到不同規(guī)則上去。這個方案適合對生效延遲不敏感分鐘級可接受、團(tuán)隊不想引入額外中間件的場景。但如果你的網(wǎng)關(guān)是多實例部署我建議謹(jǐn)慎考慮一致性會讓你很頭疼。2.2 路線二Redis發(fā)布訂閱加主動刷新為了解決輪詢的延遲和一致性問題有人把路由配置放Redis利用Redis的Pub/Sub機(jī)制做變更通知。網(wǎng)關(guān)啟動時把路由數(shù)據(jù)加載到內(nèi)存訂閱一個專門的channel管理端修改路由后往channel里發(fā)一條消息所有網(wǎng)關(guān)實例收到消息后重新從Redis拉取路由并刷新。這個方案的延遲可以做到毫秒級而且通過Redis的訂閱發(fā)布天然實現(xiàn)了一對多的廣播多實例網(wǎng)關(guān)能同時刷新比輪詢的一致性要好很多。但落地時要注意幾個細(xì)節(jié)Redis里的路由數(shù)據(jù)結(jié)構(gòu)需要自己設(shè)計相當(dāng)于把配置中心的一部分功能搬到了Redis里Pub/Sub消息是即發(fā)即棄的如果網(wǎng)關(guān)實例剛好在消息發(fā)出時斷連或重啟這條變更通知就丟了得靠啟動時全量加載機(jī)制來兜底Redis的持久化和配置版本管理能力弱操作審計之類的功能需要自己另做2.3 路線三配置中心監(jiān)聽加事件驅(qū)動這就是我最終采用并會詳細(xì)展開的方案。思路是路由配置放在Nacos或Apollo配置中心里網(wǎng)關(guān)通過監(jiān)聽配置變更事件觸發(fā)RouteDefinitionRepository的更新邏輯最終由Gateway內(nèi)部的事件機(jī)制完成路由重建。這個方案的優(yōu)勢在于Nacos本身就承擔(dān)了配置管理的職責(zé)版本管理、回滾、權(quán)限控制、操作審計開箱即用監(jiān)聽機(jī)制是服務(wù)端主動推送生效延遲低且Nacos客戶端有重連和補(bǔ)償邏輯比Redis Pub/Sub可靠配置的變更歷史可以追溯哪條路由什么時候被誰改過一清二楚三條路線對比下來我的建議是如果你的團(tuán)隊已經(jīng)在用Nacos或Apollo做配置中心直接走第三條路線如果沒有配置中心從零搭建的話可以考慮Redis方案數(shù)據(jù)庫輪詢只作為兜底或過渡方案。3. Nacos落地動態(tài)路由從監(jiān)聽配置到刷新內(nèi)存路由表3.1 前置準(zhǔn)備與依賴引入我的項目里Nacos本來就在承擔(dān)配置中心和注冊中心的職責(zé)所以動態(tài)路由直接復(fù)用了這套設(shè)施沒有新增組件。網(wǎng)關(guān)服務(wù)需要引入以下依賴!-- Spring Cloud Gateway 核心 -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-gateway/artifactId /dependency !-- Nacos 配置中心 -- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency !-- Nacos 服務(wù)發(fā)現(xiàn) -- dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency版本上我用的是Spring Cloud 2021.0.x搭配Spring Cloud Alibaba 2021.x對應(yīng)Nacos Client 2.x。不同版本之間API有差異老項目如果用的是Spring Cloud Greenwich或Hoxton代碼可能需要微調(diào)下文我會標(biāo)注出來。3.2 路由數(shù)據(jù)模型設(shè)計動態(tài)路由的第一步是要確定路由配置在Nacos里以什么格式存放。我采用的是JSON數(shù)組格式一個路由一個JSON對象結(jié)構(gòu)對齊Spring Cloud Gateway的RouteDefinition模型[ { id: order-service-route, uri: lb://order-service, predicates: [ { name: Path, args: { pattern: /order/** } } ], filters: [ { name: StripPrefix, args: { parts: 1 } } ], metadata: { source: nacos, owner: middleware-team }, order: 0 } ]為什么直接對齊RouteDefinition模型因為Gateway內(nèi)部的RouteDefinition就是長這樣我拿到JSON后直接做反序列化省去了字段映射的麻煩。Nacos里對應(yīng)的Data ID我命名為gateway-routes.jsonGroup用DEFAULT_GROUP配置文件類型選JSON。這里有個設(shè)計取舍想提一下你也可以把路由配置放在YAML里用spring.cloud.gateway.routes這個key然后通過RefreshScope配合PropertiesRouteDefinitionLocator實現(xiàn)動態(tài)刷新。但這種方式有個局限——它本質(zhì)上是讓Spring容器重新綁定配置屬性如果配置內(nèi)容較大刷新時容易出幺蛾子而且對路由的增刪操作要通過比對前后配置來實現(xiàn)邏輯不夠干凈。直接維護(hù)RouteDefinition列表的方式更可控推薦優(yōu)先考慮。3.3 核心代碼路由加載與監(jiān)聽我寫了一個DynamicRouteService負(fù)責(zé)從Nacos拉取路由配置、把配置轉(zhuǎn)換成RouteDefinition、注冊到Gateway并在配置變更時完成更新。核心邏輯如下Component public class DynamicRouteService implements ApplicationEventPublisherAware { private static final Logger log LoggerFactory.getLogger(DynamicRouteService.class); public static final String DATA_ID gateway-routes.json; public static final String GROUP DEFAULT_GROUP; private final RouteDefinitionWriter routeDefinitionWriter; private final RouteDefinitionLocator routeDefinitionLocator; private ApplicationEventPublisher applicationEventPublisher; Autowired public DynamicRouteService(RouteDefinitionWriter routeDefinitionWriter, RouteDefinitionLocator routeDefinitionLocator) { this.routeDefinitionWriter routeDefinitionWriter; this.routeDefinitionLocator routeDefinitionLocator; } Override public void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) { this.applicationEventPublisher applicationEventPublisher; } /** * 全量刷新路由先清空舊路由再批量添加新路由 */ public void refreshRoutes(ListRouteDefinition definitions) { // 1. 獲取當(dāng)前所有已加載的路由定義 ListRouteDefinition existing routeDefinitionLocator.getRouteDefinitions() .collectList().block(); if (existing ! null !existing.isEmpty()) { existing.forEach(routeDefinition - { try { routeDefinitionWriter.delete(Mono.just(routeDefinition.getId())).subscribe(); } catch (Exception e) { log.error(刪除路由失敗, id{}, routeDefinition.getId(), e); } }); } // 2. 批量添加新路由 definitions.forEach(definition - { try { routeDefinitionWriter.save(Mono.just(definition)).subscribe(); } catch (Exception e) { log.error(保存路由失敗, id{}, definition.getId(), e); } }); // 3. 發(fā)布路由刷新事件觸發(fā)RouteRefreshListener重建路由 this.applicationEventPublisher.publishEvent(new RefreshRoutesEvent(this)); log.info(動態(tài)路由刷新完成, 共 {} 條路由, definitions.size()); } /** * 增量更新單條路由 */ public void updateRoute(RouteDefinition definition) { try { routeDefinitionWriter.delete(Mono.just(definition.getId())).subscribe(); routeDefinitionWriter.save(Mono.just(definition)).subscribe(); this.applicationEventPublisher.publishEvent(new RefreshRoutesEvent(this)); log.info(路由增量更新完成, id{}, definition.getId()); } catch (Exception e) { log.error(更新路由失敗, id{}, definition.getId(), e); } } /** * 刪除單條路由 */ public void deleteRoute(String id) { try { routeDefinitionWriter.delete(Mono.just(id)).subscribe(); this.applicationEventPublisher.publishEvent(new RefreshRoutesEvent(this)); log.info(路由刪除完成, id{}, id); } catch (Exception e) { log.error(刪除路由失敗, id{}, id, e); } } }然后寫一個NacosRouteConfigWatcher在網(wǎng)關(guān)啟動完成后從Nacos拉取配置并注冊監(jiān)聽器Component public class NacosRouteConfigWatcher implements ApplicationRunner, InitializingBean { private static final Logger log LoggerFactory.getLogger(NacosRouteConfigWatcher.class); private final DynamicRouteService dynamicRouteService; private final ObjectMapper objectMapper; Autowired private NacosConfigManager nacosConfigManager; Autowired private NacosConfigProperties nacosConfigProperties; public NacosRouteConfigWatcher(DynamicRouteService dynamicRouteService, ObjectMapper objectMapper) { this.dynamicRouteService dynamicRouteService; this.objectMapper objectMapper; } Override public void run(ApplicationArguments args) { initAndWatch(); } private void initAndWatch() { try { // 1. 先獲取配置確保網(wǎng)關(guān)啟動時路由就位 ConfigService configService nacosConfigManager.getConfigService(); String config configService.getConfig(DynamicRouteService.DATA_ID, DynamicRouteService.GROUP, 60000); if (StringUtils.hasText(config)) { parseAndApply(config); } // 2. 訂閱配置變更事件 Listener listener new Listener() { Override public void receiveConfigInfo(String configInfo) { log.info(檢測到Nacos路由配置變更, 開始刷新); parseAndApply(configInfo); } Override public Executor getExecutor() { return Executors.newSingleThreadExecutor(r - { Thread t new Thread(r, nacos-route-listener); t.setDaemon(true); return t; }); } }; configService.addListener(DynamicRouteService.DATA_ID, DynamicRouteService.GROUP, listener); log.info(Nacos動態(tài)路由監(jiān)聽器注冊完成); } catch (Exception e) { log.error(初始化Nacos動態(tài)路由監(jiān)聽器失敗, e); } } private void parseAndApply(String config) { try { ListRouteDefinition definitions objectMapper.readValue(config, new TypeReferenceListRouteDefinition() {}); if (definitions null || definitions.isEmpty()) { log.warn(路由配置為空, 跳過刷新); return; } dynamicRouteService.refreshRoutes(definitions); } catch (JsonProcessingException e) { log.error(路由配置解析失敗, 內(nèi)容{}, config, e); } } }這里有一個很關(guān)鍵的點監(jiān)聽器里的ConfigService不能直接用NacosConfigManager.getConfigService()在構(gòu)造時獲取因為Nacos配置中心的初始化可能還沒完成。所以我用InitializingBean或者ApplicationRunner延遲到Spring容器啟動后期再注冊監(jiān)聽器確保ConfigService可用。這是我踩過的第一個坑后面會詳細(xì)說。3.4 為什么選擇全量刷新而不是增量更新我在代碼里默認(rèn)實現(xiàn)了refreshRoutes全量刷新同時保留了updateRoute和deleteRoute的增量接口。實際生產(chǎn)環(huán)境中我首選全量刷新。理由有三點第一配置中心里的內(nèi)容就是一個完整的路由表全量刷新邏輯最簡單不容易出錯。增量更新需要對比前后差異這個對比邏輯本身就有bug的容身之地。第二網(wǎng)關(guān)的路由表通常不會特別大幾十條到上百條的量級全量刷新的耗時在毫秒級到十毫秒級完全可以接受。第三全量刷新天然冪等重復(fù)執(zhí)行不會產(chǎn)生臟數(shù)據(jù)。增量更新如果出現(xiàn)一次失敗網(wǎng)關(guān)內(nèi)就可能殘留一條錯誤的路由。當(dāng)然全量刷新也有它的副作用清空再重建的間隙理論上路由表是空的。但因為整個刷新過程是在單線程里順序執(zhí)行delete和save加上最后publish的RefreshRoutesEvent是同一個事務(wù)上下文里觸發(fā)的實際影響窗口非常小。后面我會講到怎么用并行刷新和原子切換來進(jìn)一步縮小這個窗口。4. 路由刷新機(jī)制拆解事件驅(qū)動下Gateway怎么重建路由4.1 Gateway的路由存儲結(jié)構(gòu)要理解動態(tài)路由為什么刷新一下就能生效得先搞清楚Spring Cloud Gateway內(nèi)部是怎么存路由的。Gateway里有兩個核心接口RouteDefinitionLocator負(fù)責(zé)加載路由定義。它返回的是RouteDefinition也就是配置解析后的原始對象RouteDefinitionWriter負(fù)責(zé)新增和刪除路由定義默認(rèn)情況下Gateway會組合多個RouteDefinitionLocator來加載路由包括從配置文件讀取的PropertiesRouteDefinitionLocator、從注冊中心服務(wù)發(fā)現(xiàn)的DiscoveryClientRouteDefinitionLocator等。路由定義加載之后RouteDefinitionRouteLocator會把這些RouteDefinition轉(zhuǎn)換成真正的Route對象放進(jìn)一個FluxRoute的緩存里。Route對象里包含了具體的斷言Predicate和過濾器Filter實例是真正參與請求匹配和轉(zhuǎn)發(fā)的對象。當(dāng)你通過RouteDefinitionWriter.save()新增或刪除一條路由定義后如果不做任何額外操作Gateway內(nèi)存里的Route緩存是不會自動更新的。這時候就需要RefreshRoutesEvent出場。4.2 RefreshRoutesEvent如何觸發(fā)路由重建看一下RouteRefreshListener的源碼邏輯不同版本略有差異但核心一致public class RouteRefreshListener implements ApplicationListenerRefreshRoutesEvent { Override public void onApplicationEvent(RefreshRoutesEvent event) { // 跳過未啟動的路由刷新 if (!this.gatewayProperties.isStartup()) { return; } // 清除路由緩存 routeDefinitionRouteLocator.reset(); } }reset()方法清空了RouteDefinitionRouteLocator內(nèi)部的緩存Map。這樣下一次請求進(jìn)來時RouteDefinitionRouteLocator發(fā)現(xiàn)緩存為空就會重新從所有RouteDefinitionLocator加載路由定義再走一遍RouteDefinition到Route的組裝過程。也就是說動態(tài)刷新的鏈路是這樣的Nacos配置變更 → ConfigService監(jiān)聽器觸發(fā) → DynamicRouteService.refreshRoutes() → RouteDefinitionWriter 刪除舊定義 保存新定義 → 發(fā)布 RefreshRoutesEvent → RouteRefreshListener.reset() → 清空 Route 緩存 → 下次請求重新加載路由定義并組裝 Route → 新路由生效這一整條鏈路里RouteDefinitionWriter和RefreshRoutesEvent是兩個關(guān)鍵的把手。前者負(fù)責(zé)改數(shù)據(jù)后者負(fù)責(zé)通知Gateway重新計算。4.3 刷新期間的性能問題與優(yōu)化搞清楚刷新機(jī)制之后你會發(fā)現(xiàn)一個問題reset()清空緩存后下一個請求觸發(fā)重新加載這個加載過程是同步阻塞的。如果路由數(shù)量很大或者路由斷言邏輯很復(fù)雜比如每個路由都要遠(yuǎn)程調(diào)用某個系統(tǒng)判斷流量重建時延會直接影響第一個請求的耗時。我在壓測里碰到過這個情況100條路由全量刷新后第一個請求的P99從正常的20ms直接飆到300ms。這個現(xiàn)象叫緩存擊穿式冷啟動本質(zhì)上是因為新路由還沒準(zhǔn)備好請求就已經(jīng)到了。解決方案有兩個方向方向一預(yù)熱。在發(fā)布刷新事件之前先手動觸發(fā)一次路由加載讓緩存先重建然后再發(fā)布事件。但Gateway沒有提供官方的預(yù)熱API實現(xiàn)起來相對麻煩。方向二控制刷新頻率和粒度。把路由按業(yè)務(wù)域拆成多個配置文件哪個域變了就刷新哪個域的配置避免全量刷新帶來的全局冷啟動。我最終采用的就是這個方案把公共路由和業(yè)務(wù)路由拆到不同Data ID下各自維護(hù)監(jiān)聽器。實測下來單次刷新涉及的路由數(shù)量從100降到20左右P99影響可以忽略不計。另外補(bǔ)充一個細(xì)節(jié)RouteDefinitionWriter的save和delete返回的都是MonoVoid我用的是subscribe()這意味著操作是異步觸發(fā)的。如果你在refreshRoutes方法里調(diào)完save立刻publishEvent理論上前面的寫操作可能還沒真正完成。穩(wěn)妥的做法是先把所有Mono收集起來等它們?nèi)客瓿珊笤侔l(fā)布刷新事件。寫法可以參考這樣public void refreshRoutes(ListRouteDefinition definitions) { // 刪除舊的 ListMonoVoid deleteMonos existing.stream() .map(rd - routeDefinitionWriter.delete(Mono.just(rd.getId()))) .collect(Collectors.toList()); // 保存新的 ListMonoVoid saveMonos definitions.stream() .map(rd - routeDefinitionWriter.save(Mono.just(rd))) .collect(Collectors.toList()); // 等待全部完成后發(fā)布事件 Flux.concat(Flux.fromIterable(deleteMonos), Flux.fromIterable(saveMonos)) .then() .doOnSuccess(v - applicationEventPublisher.publishEvent(new RefreshRoutesEvent(this))) .subscribe(); }這樣用Flux.concat串行執(zhí)行并等待完成再發(fā)事件能避免異步競態(tài)。這也是我在生產(chǎn)環(huán)境收到過路由刷新后部分請求匹配到舊路由的bug報告后做的修復(fù)。5. 上線三個月的踩坑實錄從路由不生效到雪崩邊緣5.1 坑一修改配置后路由紋絲不動這是我遇到的第一個問題。Nacos配置改了網(wǎng)關(guān)日志里也打印了檢測到Nacos路由配置變更但實際請求還是按老路由走新路由完全沒生效。排查了很長時間最后定位到兩個原因。第一個原因是RouteDefinitionRouteLocator和RefreshRoutesEvent的事件發(fā)布不在同一個線程里我第一版代碼用的是EventBus的異步監(jiān)聽導(dǎo)致reset()執(zhí)行時路由定義還沒寫完。前面4.3里講的Flux.concat方案就是為了解決這個競態(tài)問題。第二個原因更隱蔽Gateway內(nèi)部存在緩存一致性延遲。RouteDefinitionRouteLocator除了內(nèi)部的一個Map緩存外還通過CompositeRouteDefinitionLocator組合了多個RouteDefinitionLocator。其中DiscoveryClientRouteDefinitionLocator會定期從注冊中心拉取服務(wù)列表生成路由如果Nacos配置里的路由ID和注冊中心自動生成的路由ID沖突注冊中心那側(cè)的路由可能覆蓋掉配置中心的路由。解決方式是在Nacos路由配置里避免使用和注冊中心服務(wù)名相同的路由ID。5.2 坑二刪除路由后舊路由依然攔截請求另一個詭異的問題是我在Nacos里刪掉了一條路由網(wǎng)關(guān)日志顯示刪除成功但請求打到老路徑上依然有響應(yīng)。排查后發(fā)現(xiàn)問題出在RouteDefinitionRouteLocator的緩存重置機(jī)制上。reset()清空的是緩存Map但如果請求已經(jīng)被路由到下游服務(wù)連接還在保持中舊路由的自動恢復(fù)邏輯會讓連接繼續(xù)走完。更麻煩的是有些情況下Gateway從緩存里取Route對象時拿到的不是最新一次reset()后的版本。最終的修復(fù)方案是刪除路由后除了發(fā)布RefreshRoutesEvent還要主動調(diào)一次routeDefinitionLocator.getRouteDefinitions()來確認(rèn)當(dāng)前存活的路由定義并且對下游連接做主動斷開。同時給路由增加了metadata里的status字段刪除不是物理刪而是先置為disabled讓斷言不匹配再異步清理定義這樣能避免刪除瞬間仍有請求命中的窗口。5.3 坑三多實例網(wǎng)關(guān)刷新不同步生產(chǎn)環(huán)境的網(wǎng)關(guān)是多實例部署的Nacos配置變更后各實例的監(jiān)聽器幾乎同時觸發(fā)但每個實例執(zhí)行全量刷新的時間點有細(xì)微差異。如果正好有流量打到還沒刷新完成的實例上新路由就是404。這個問題的本質(zhì)是全量刷新不是原子的。后來我把refreshRoutes改成了先保存新路由再刪除舊路由順序調(diào)整后每個實例在任何時刻都至少擁有一個版本的路由表。再加上Nacos配置本身是帶版本號的我在配置內(nèi)容里加了一個version字段刷新時先比較版本號版本號相同就不重復(fù)刷新避免無意義的全量重建。5.4 坑四路由刷新引發(fā)下游雪崩這是最嚴(yán)重的一次事故。某天線上做全量路由刷新過程中Gateway發(fā)出了大量并發(fā)請求到下游的某個核心服務(wù)直接把那個服務(wù)的線程池打滿了引發(fā)連鎖故障。根因有兩層。第一層全量刷新時我做了并行刪除和保存刪掉舊路由后正在處理的請求如果還沒完成路由匹配會重新走一遍路由查找這個查找過程在緩存被清空后會變成同步加載多個請求同時觸發(fā)加載就會產(chǎn)生并發(fā)涌入。第二層我有一條路由的GlobalFilter里做了下游服務(wù)的批量調(diào)用路由刷新導(dǎo)致Filter被重建那些新Filter實例在Spring容器里的初始化邏輯又觸發(fā)了對下游的批量預(yù)熱請求。事后我做了三個調(diào)整刷新路由操作加了分布式鎖保證同一時間只有一個網(wǎng)關(guān)實例在做全量刷新路由加載改為分批進(jìn)行每批50條批次之間sleep 100ms防止一次性加載過多導(dǎo)致下游壓力梳理了自定義GlobalFilter的初始化邏輯把啟動時的批量預(yù)熱調(diào)用改成了惰性加載5.5 踩坑后的最終版配置規(guī)范經(jīng)過三個月的折騰我沉淀了一套自己的動態(tài)路由配置規(guī)范在這里直接分享出來維度規(guī)范配置存儲NacosData ID為gateway-routes.jsonGroup為DEFAULT_GROUP配置格式JSON數(shù)組對齊RouteDefinition模型拆分粒度公共路由和業(yè)務(wù)路由拆到不同Data ID減少全局刷新刷新方式全量為主、增量為輔串行執(zhí)行刪除和保存版本管理配置內(nèi)容帶version字段避免重復(fù)刷新冪等控制刷新前校驗配置CRC值無變化則跳過多實例協(xié)調(diào)刷新操作加分布式鎖避免并發(fā)刷新監(jiān)控告警監(jiān)聽配置刷新耗時和路由數(shù)量變化超出閾值告警回滾預(yù)案Nacos配置歷史保留30天快速回滾配置即可恢復(fù)舊路由這套規(guī)范的核心思路就一句話動態(tài)路由的價值在于快速響應(yīng)變化但越是靈活的東西越需要約束不然靈活性本身就變成了風(fēng)險源。6. 動態(tài)路由以外的兩個擴(kuò)展點路由動態(tài)化只是網(wǎng)關(guān)治理的第一步。跑通之后我順手把下面兩個能力也接入了同一個配置通道這里簡單提一下后續(xù)文章再展開。6.1 動態(tài)限流與熔斷配置路由能動態(tài)了那路由上的限流參數(shù)、熔斷閾值、重試策略理論上也可以動態(tài)化。我在DynamicRouteService里增加了一個擴(kuò)展字段extraConfig專門存放限流閾值、熔斷開關(guān)、超時時間等參數(shù)監(jiān)聽器解析時把這些參數(shù)同步到對應(yīng)的Filter配置中。這樣大促前調(diào)整限流閾值就不需要動代碼了。6.2 路由灰度與流量染色另外一個我比較看重的擴(kuò)展點是利用路由的metadata做灰度標(biāo)識。比如新版本服務(wù)上線后在Nacos里臨時改路由給versionv2的服務(wù)打個標(biāo)簽通過Weight斷言把5%的流量切過去驗證沒問題再逐步放量。整個過程完全不用重啟網(wǎng)關(guān)也不改服務(wù)端代碼灰度發(fā)布對運維來說非常友好。7. 一點個人體會動態(tài)路由這個功能代碼量不算大核心邏輯一百多行但真正把它用好靠的是對Gateway內(nèi)部機(jī)制的充分理解和對生產(chǎn)環(huán)境的敬畏。我剛開始的時候覺得不就是監(jiān)聽配置然后刷新嘛結(jié)果上線后連續(xù)被坑從路由不生效到雪崩每次都是血淚教訓(xùn)。如果你準(zhǔn)備在自己項目里落地動態(tài)路由我最后給三個建議第一先把Gateway的RouteDefinitionRouteLocator、RouteRefreshListener源碼讀一遍搞清楚緩存和刷新的完整鏈路再動手寫代碼能幫你避掉一大半的坑。第二一定要做正反向驗證。正向驗證改一條路由后能否秒級生效反向驗證刪一條路由后流量能否正常摘除。我在測試環(huán)境反復(fù)驗證了兩周才敢上生產(chǎn)。第三不要把動態(tài)路由做成萬能鑰匙。路由的頻繁變動本身說明你的服務(wù)治理可能有問題動態(tài)路由應(yīng)該服務(wù)于灰度、容災(zāi)和快速接入而不是掩蓋架構(gòu)設(shè)計的混亂。這套東西上線幾個月最大的感受就是網(wǎng)關(guān)終于不再是改一次配置提一次心吊膽的瓶頸了。后面我會繼續(xù)更新這個系列把網(wǎng)關(guān)限流、灰度、熔斷的實戰(zhàn)內(nèi)容整理出來希望對你有用。