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