接手訂單中臺(tái)半年后最讓我頭疼的其實(shí)不是業(yè)務(wù)服務(wù)怎么拆分而是每次排查問題都要重復(fù)看一遍各服務(wù)的鑒權(quán)邏輯、限流參數(shù)和日志格式。十幾個(gè)微服務(wù)大家各自維護(hù)一套安全規(guī)則登錄校驗(yàn)有的放在Controller有得放在中間件線上客戶報(bào)錯(cuò)時(shí)根本說不清是哪一層擋住的。后來我們把所有流量統(tǒng)一收到API網(wǎng)關(guān)MAI Gateway這套架構(gòu)才真正跑順。如果你也在微服務(wù)治理、分布式架構(gòu)或者大型系統(tǒng)改造的路上這篇文章應(yīng)該對(duì)你有用我會(huì)從概念講起把MAI Gateway的控制面、數(shù)據(jù)面、核心能力拆開再結(jié)合我實(shí)際部署和排障的經(jīng)歷把那些文檔里不會(huì)寫的坑也一并說了。1. 先把網(wǎng)關(guān)這件事說清楚從一次線上事故說起1.1 那次事故暴露出的治理缺口那是一個(gè)普通周二下午運(yùn)維同事在大群里喊了一句“生產(chǎn)環(huán)境訂單查詢接口開始超時(shí)了?！蔽翼樖执蜷_監(jiān)控發(fā)現(xiàn)訂單服務(wù)的P99延遲從200ms跳到了3.8s而服務(wù)端CPU負(fù)載并不高。查日志時(shí)才發(fā)現(xiàn)某個(gè)新上線的服務(wù)在本地測(cè)試時(shí)忘記關(guān)閉調(diào)試用的Mock鑒權(quán)導(dǎo)致所有請(qǐng)求在完全沒有校驗(yàn)身份的情況下進(jìn)入了業(yè)務(wù)邏輯層。更麻煩的是因?yàn)楦鲌F(tuán)隊(duì)對(duì)“什么算非法請(qǐng)求”的標(biāo)準(zhǔn)不統(tǒng)一有些服務(wù)直接信任內(nèi)網(wǎng)IP參數(shù)里塞一個(gè)X-User-Id: admin就能繞過去。這次事故的根因表面上是代碼問題實(shí)際上暴露的是整個(gè)架構(gòu)缺少一個(gè)統(tǒng)一的流量治理層。每個(gè)服務(wù)都在重復(fù)實(shí)現(xiàn)網(wǎng)關(guān)應(yīng)該做的事但實(shí)現(xiàn)的又不完整、不標(biāo)準(zhǔn)。鑒權(quán)規(guī)則散落在幾十個(gè)倉庫里限流參數(shù)靠各團(tuán)隊(duì)自己拍腦袋日志字段名五花八門。后來我花了兩個(gè)晚上把登錄、下單、支付三個(gè)核心鏈路梳理一遍發(fā)現(xiàn)光是“用戶身份從請(qǐng)求到后端服務(wù)之間如何傳遞”這件事就有五套不同做法。1.2 網(wǎng)關(guān)和反向代理、負(fù)載均衡不是一回事很多人容易把API網(wǎng)關(guān)和Nginx反代、負(fù)載均衡搞混我一開始也分不清楚。簡(jiǎn)單說Nginx反代解決的是“請(qǐng)求該轉(zhuǎn)到哪臺(tái)機(jī)器”負(fù)載均衡解決的是“多臺(tái)機(jī)器之間怎么分流量”而API網(wǎng)關(guān)解決的是“請(qǐng)求進(jìn)入系統(tǒng)前后橫切面策略怎么做”。我們可以用一個(gè)生活化的類比小區(qū)正門。門衛(wèi)網(wǎng)關(guān)負(fù)責(zé)檢查訪客身份、登記、攔下可疑包裹、替業(yè)主收快遞而電梯調(diào)度員負(fù)載均衡只負(fù)責(zé)把不同樓層的人分流送到對(duì)應(yīng)的樓層。沒有門衛(wèi)時(shí)每戶人家都要自己裝防盜門、自己核對(duì)來訪者身份效率低且不安全。MAI Gateway在我的系統(tǒng)里扮演的就是這個(gè)統(tǒng)一門衛(wèi)所有進(jìn)出的流量都從它這里過。它和Service Mesh的邊界也不一樣。Service Mesh是靠近微服務(wù)的東西向流量治理用Sidecar模式掛載在每個(gè)Pod旁邊管理服務(wù)到服務(wù)之間的通信API網(wǎng)關(guān)是南北向流量治理管理外部客戶端到服務(wù)集群之間的入口。兩者并不沖突甚至可以共存。2. MAI Gateway的總體架構(gòu)控制面與數(shù)據(jù)面分離2.1 為什么一定要拆控制面和數(shù)據(jù)面MAI Gateway在架構(gòu)上有一個(gè)核心決策把規(guī)則管理和請(qǐng)求轉(zhuǎn)發(fā)徹底拆成兩個(gè)平面?？刂泼尕?fù)責(zé)維護(hù)路由規(guī)則、限流規(guī)則、證書、黑白名單、灰度權(quán)重這些“策略”數(shù)據(jù)面負(fù)責(zé)執(zhí)行轉(zhuǎn)發(fā)、過濾、限流、記錄日志這些“動(dòng)作”。兩個(gè)平面之間通過一套配置訂閱機(jī)制通信我這邊用的是基于etcd的推送通道。這么設(shè)計(jì)最直接的好處是改動(dòng)策略不需要重啟網(wǎng)關(guān)進(jìn)程。以前用NginxLua時(shí)每改一次路由都要reload配置高峰期reload Nginx雖然不至于斷流量但總是讓人心里不踏實(shí)。拆成控制面后運(yùn)維在管理臺(tái)上保存一條新路由數(shù)據(jù)面幾秒內(nèi)就能拿到新規(guī)則實(shí)現(xiàn)熱切換整個(gè)過程用戶無感知。另一個(gè)好處是多環(huán)境復(fù)用開發(fā)、測(cè)試、生產(chǎn)的控制面可以共享同一套配置模板只是通過不同的環(huán)境標(biāo)簽做差異化覆蓋。2.2 數(shù)據(jù)面的三層結(jié)構(gòu)接入層、路由層、轉(zhuǎn)發(fā)層數(shù)據(jù)面我拆成了三個(gè)層次每一層的職責(zé)盡量單一。接入層處理的是協(xié)議和連接問題包括TLS終止、HTTP/1.1與HTTP/2的適配、WebSocket升級(jí)、最大Header大小限制等。接入層只做一件事把一條來自客戶端的連接變成網(wǎng)關(guān)內(nèi)部標(biāo)準(zhǔn)化的請(qǐng)求對(duì)象這個(gè)對(duì)象帶上了完整的Headers、Query參數(shù)、Body以及網(wǎng)關(guān)在接入階段解析出的客戶端IP、協(xié)議版本、證書指紋等信息。路由層拿這個(gè)標(biāo)準(zhǔn)化請(qǐng)求去做匹配判斷它該走哪個(gè)路由、命中哪組目標(biāo)服務(wù)、需要應(yīng)用哪些全局或路由級(jí)Filter。路由匹配不是簡(jiǎn)單的前綴匹配而是按優(yōu)先級(jí)從高到低依次評(píng)估。匹配條件可以是域名、路徑前綴、請(qǐng)求頭、Query參數(shù)、甚至一個(gè)可執(zhí)行的條件表達(dá)式。轉(zhuǎn)發(fā)層是最靠近后端服務(wù)的環(huán)節(jié)負(fù)責(zé)建立和上游服務(wù)之間的連接池執(zhí)行負(fù)載均衡、超時(shí)控制、重試、熔斷等操作。轉(zhuǎn)發(fā)層和路由層解耦之后我可以在不觸碰路由規(guī)則的前提下單獨(dú)調(diào)整連接池大小或者在線上臨時(shí)開啟一個(gè)針對(duì)特殊上游節(jié)點(diǎn)的熔斷閾值。2.3 插件擴(kuò)展機(jī)制把通用能力和業(yè)務(wù)能力隔開網(wǎng)關(guān)最忌諱的是把業(yè)務(wù)代碼全塞進(jìn)去。很多人一開始圖方便在網(wǎng)關(guān)里寫面向某個(gè)業(yè)務(wù)的特殊邏輯結(jié)果網(wǎng)關(guān)越做越重發(fā)布一次牽連所有服務(wù)。MAI Gateway用了一套基于SPI的Filter鏈機(jī)制讓每類橫切面能力都對(duì)應(yīng)一個(gè)獨(dú)立的Filter組件。public interface GatewayFilter { int order(); void doFilter(GatewayContext ctx, FilterChain chain) throws GatewayException; }每個(gè)Filter有明確執(zhí)行順序比如auth.jwt排在ratelimit前面ratelimit又排在metrics后面。新增一種能力時(shí)只需實(shí)現(xiàn)接口并在配置里聲明Filter名稱和參數(shù)不需要改網(wǎng)關(guān)主代碼。業(yè)務(wù)團(tuán)隊(duì)也能通過這個(gè)機(jī)制接入自己特有的校驗(yàn)邏輯但必須遵循同一套執(zhí)行模型不允許在Filter里做等待IO的同步調(diào)用否則會(huì)堵住網(wǎng)關(guān)的核心線程池。3. 六大核心能力逐個(gè)拆解不只是轉(zhuǎn)發(fā)請(qǐng)求3.1 路由與灰度發(fā)布的玩法路由管理是網(wǎng)關(guān)最基礎(chǔ)也最常用的能力。MAI Gateway的路由規(guī)則由多個(gè)條件組合而成我常用的配置格式類似這樣routes: - name: order-service-v2 match: host: api.example.com pathPrefix: /orders headers: x-tenant-id: 1024 featureTag: canary upstream: authority: order-service-v2 weight: 10這段配置的意思是當(dāng)請(qǐng)求來自api.example.com、路徑以/orders開頭、且攜帶x-tenant-id: 1024時(shí)按10%的權(quán)重流向order服務(wù)的v2版本其余90%流向v1?；叶劝l(fā)布根本不需要運(yùn)維同學(xué)手工切流量只要在管理臺(tái)上調(diào)整weight值即可。我在實(shí)際使用中體會(huì)到灰度路由的精確度比“按IP百分比”要可靠得多——按x-tenant-id或者用戶ID哈希分流同一個(gè)用戶在整個(gè)灰度周期內(nèi)始終訪問同一個(gè)版本不會(huì)出現(xiàn)用戶第一次請(qǐng)求在v2、第二次回到v1的狀態(tài)不一致問題。3.2 統(tǒng)一鑒權(quán)與安全收斂在沒有網(wǎng)關(guān)之前每個(gè)服務(wù)都要依賴SDK做JWT解析和用戶信息還原一旦JWT算法升級(jí)或增加字段所有服務(wù)都要跟著發(fā)版本。有了網(wǎng)關(guān)后鑒權(quán)邏輯統(tǒng)一收斂到了auth.jwt這個(gè)Filter里。網(wǎng)關(guān)解密并校驗(yàn)JWT后把解析出的用戶ID、角色、租戶信息寫進(jìn)轉(zhuǎn)發(fā)到后端的Header中。后端服務(wù)默認(rèn)信任網(wǎng)關(guān)傳來的這些Header就不再自行解析Token。這么做有一個(gè)非常重要的前提必須切斷外部請(qǐng)求直接訪問后端服務(wù)的路徑。如果內(nèi)網(wǎng)里其他服務(wù)依然能繞過網(wǎng)關(guān)直接調(diào)用業(yè)務(wù)服務(wù)那么“統(tǒng)一鑒權(quán)”就是一句空話。我的做法是給所有后端服務(wù)網(wǎng)絡(luò)策略加上限制只允許網(wǎng)關(guān)所在的安全組訪問。這就相當(dāng)于把小區(qū)正門修好了同時(shí)把旁邊的小門和圍墻缺口全部堵住。3.3 限流與熔斷的參數(shù)參考限流是最能體現(xiàn)網(wǎng)關(guān)價(jià)值的能力之一。我最初用固定窗口計(jì)數(shù)效果不好窗口邊界處會(huì)出現(xiàn)瞬時(shí)雙倍流量把數(shù)據(jù)庫打滿。換成令牌桶后明顯平滑多了。下面是我為訂單服務(wù)配置的一組參數(shù)ratelimits: - name: order-route-limit type: token-bucket capacity: 2000 refillRate: 1000 refillInterval: 1scapacity表示桶的最大容量也就是允許的突發(fā)流量上限r(nóng)efillRate表示每秒補(bǔ)充的令牌數(shù)。實(shí)際配置時(shí)還要考慮當(dāng)前機(jī)器的網(wǎng)卡帶寬和后端數(shù)據(jù)庫能力我踩過一個(gè)坑網(wǎng)關(guān)照貓畫虎配置了2000QPS的上限結(jié)果后端數(shù)據(jù)庫連接池?fù)尾蛔【W(wǎng)關(guān)側(cè)還沒觸發(fā)限流數(shù)據(jù)庫先倒了。所以限流參數(shù)的確定必須基于下游服務(wù)的實(shí)測(cè)水位而不是拍腦袋定一個(gè)好看的數(shù)字。熔斷方面MAI Gateway內(nèi)部維護(hù)了每個(gè)上游節(jié)點(diǎn)的滑動(dòng)窗口狀態(tài)。當(dāng)某節(jié)點(diǎn)在10秒窗口內(nèi)的錯(cuò)誤率超過15%時(shí)自動(dòng)熔斷30秒。釋放期間只放少量探測(cè)流量成功后才逐步恢復(fù)。這些參數(shù)我建議先從保守值開始跑穩(wěn)定后再逐步放寬。3.4 協(xié)議轉(zhuǎn)換與多端適配接口統(tǒng)一走HTTP/JSON很好但現(xiàn)實(shí)是總會(huì)有老系統(tǒng)、IoT設(shè)備、內(nèi)部RPC調(diào)用需要兼容。網(wǎng)關(guān)可以在接入層終止一種協(xié)議在轉(zhuǎn)發(fā)層再以另一種協(xié)議訪問后端。比如對(duì)外暴露HTTP接口網(wǎng)關(guān)內(nèi)部通過泛化調(diào)用轉(zhuǎn)為RPC協(xié)議發(fā)給后端。這個(gè)能力讓新老系統(tǒng)在迭代過渡期可以和平共處不會(huì)因?yàn)橐淮渭軜?gòu)升級(jí)就必須把所有接口全部翻新。3.5 可觀測(cè)性TraceId貫穿全鏈路網(wǎng)關(guān)是流量入口也是埋點(diǎn)的最佳位置。MAI Gateway會(huì)對(duì)每一個(gè)進(jìn)入的請(qǐng)求生成一個(gè)全局TraceId并通過Header透?jìng)鹘o后端服務(wù)。后端服務(wù)只要都遵循這個(gè)透?jìng)骷s定完整的調(diào)用鏈就能在監(jiān)控系統(tǒng)里串起來。我在日志字段里額外記錄了路由命中的routeName、上游選擇的階段、限流命中的規(guī)則名排查問題時(shí)非常管用。4. 部署落地和性能調(diào)優(yōu)的工程細(xì)節(jié)4.1 部署拓?fù)溥x型K8s多副本還是物理機(jī)獨(dú)立部署網(wǎng)關(guān)本身是無狀態(tài)服務(wù)所以天然適合水平擴(kuò)縮容。我在K8s里用Deployment部署了4個(gè)副本前面用負(fù)載均衡器做入口IP收斂。資源規(guī)格一般建議分配2核4Gi起步實(shí)際壓力測(cè)試時(shí)4個(gè)副本可以穩(wěn)定扛住約1.5萬QPS的純轉(zhuǎn)發(fā)流量瓶頸主要在網(wǎng)絡(luò)層和內(nèi)核連接表。我不建議把網(wǎng)關(guān)和業(yè)務(wù)容器混部在同一批節(jié)點(diǎn)上因?yàn)榫W(wǎng)關(guān)的CPU密集度和網(wǎng)絡(luò)中斷頻率都遠(yuǎn)高于普通業(yè)務(wù)服務(wù)混部容易互相干擾。獨(dú)立節(jié)點(diǎn)組、加親和性調(diào)度是更穩(wěn)妥的做法。網(wǎng)關(guān)節(jié)點(diǎn)之間不需要共享狀態(tài)限流計(jì)數(shù)器如果要做全局限流需要依賴Redis等外部存儲(chǔ)我為了性能暫時(shí)只做了單機(jī)限流全局限流留給Redis方案。4.2 線程模型與核心網(wǎng)絡(luò)參數(shù)MAI Gateway底層基于異步事件循環(huán)模型事件線程只負(fù)責(zé)解析、路由和轉(zhuǎn)發(fā)控制不在線程里做任何阻塞式IO。如果某個(gè)Filter里出現(xiàn)同步等待事件線程就會(huì)被拖住整個(gè)網(wǎng)關(guān)的吞吐量會(huì)跳水。所以我對(duì)業(yè)務(wù)側(cè)自定義Filter有一條硬性約束禁止在線程內(nèi)部做同步的HTTP調(diào)用或數(shù)據(jù)庫查詢必要場(chǎng)景通過異步回調(diào)方式處理。下面是幾個(gè)我在生產(chǎn)環(huán)境驗(yàn)證過比較合理的網(wǎng)絡(luò)參數(shù)參數(shù)建議值說明readTimeout30s客戶端讀取請(qǐng)求超時(shí)避免慢連接長期占資源writeTimeout30s網(wǎng)關(guān)下發(fā)響應(yīng)的超時(shí)時(shí)間idleTimeout90s空閑連接回收時(shí)間兼顧短連接與長連接場(chǎng)景upstreamConnPerHost64單個(gè)上游主機(jī)最大連接數(shù)過小易排隊(duì)過大會(huì)占用后端資源maxHeaderBytes16KB限制Header頭部大小防止異常數(shù)據(jù)包沖擊這些參數(shù)不是越大越好比如upstreamConnPerHost設(shè)成64如果后端服務(wù)線程池只有30個(gè)線程多余的連接反而在后端排隊(duì)。調(diào)優(yōu)時(shí)要前后端一起看而不是只盯網(wǎng)關(guān)側(cè)的指標(biāo)。4.3 配置熱更新與緩存一致性控制面更新路由后數(shù)據(jù)面通過訂閱機(jī)制收到最新配置但如果沒有合適的換裝策略熱更新也會(huì)出問題。我的做法是讓數(shù)據(jù)面維護(hù)兩份配置快照當(dāng)前生效版本和新版本在新Vec上構(gòu)建構(gòu)建成功后用原子指針切換。切換過程中已經(jīng)在途的請(qǐng)求繼續(xù)使用舊配置完成轉(zhuǎn)發(fā)新請(qǐng)求從切換瞬間開始使用新配置這樣就不會(huì)出現(xiàn)配置改了一半請(qǐng)求找不到路由的尷尬場(chǎng)景。緩存一致性是另一個(gè)容易被忽視的點(diǎn)。JWT公鑰、限流計(jì)數(shù)、路由表如果都做成本地緩存那么控制面某個(gè)字段變了數(shù)據(jù)面可能要等緩存過期才生效。我是給緩存加版本號(hào)配置變更時(shí)同時(shí)廣播版本號(hào)變化數(shù)據(jù)面發(fā)現(xiàn)版本不一致后主動(dòng)拉取全量配置避免長時(shí)間依賴臟數(shù)據(jù)。5. 上線一年實(shí)際踩過的坑排查鏈路完整復(fù)盤5.1 鏈路超時(shí)時(shí)間疊加網(wǎng)關(guān)沒延遲后端卻在等第一次上線后不久有同事反饋部分上傳接口會(huì)隨機(jī)超時(shí)。查網(wǎng)關(guān)日志發(fā)現(xiàn)請(qǐng)求在12s左右被網(wǎng)關(guān)主動(dòng)斷開。原因很典型客戶端設(shè)置了15s超時(shí)網(wǎng)關(guān)設(shè)置了12s讀超時(shí)業(yè)務(wù)服務(wù)又設(shè)置了10s處理超時(shí)三層超時(shí)疊加的結(jié)果是后端已經(jīng)處理到9.5s網(wǎng)關(guān)在第12s直接斷開客戶端拿不到任何響應(yīng)。排查鏈路是從監(jiān)控圖上看到“線程卡住但CLB連接正?！遍_始的最后定位在網(wǎng)關(guān)寫超時(shí)配置偏短。修復(fù)方案也很簡(jiǎn)單把網(wǎng)關(guān)超時(shí)值調(diào)成比后端最高的RT更寬并且所有組件的超時(shí)時(shí)間按“客戶端 網(wǎng)關(guān) 后端”的梯度設(shè)置。5.2 透?jìng)鱄eader引發(fā)的信任邊界問題網(wǎng)關(guān)統(tǒng)一鑒權(quán)后后端服務(wù)直接讀取網(wǎng)關(guān)透?jìng)鞯腦-User-Id和X-Role。聽起來挺方便但有一次安全掃描發(fā)現(xiàn)內(nèi)網(wǎng)某臺(tái)機(jī)器可以直接偽造這套Header訪問到業(yè)務(wù)服務(wù)。原因很直接網(wǎng)關(guān)只堵住了外部入口但內(nèi)網(wǎng)服務(wù)之間的互相調(diào)用也能帶上這些Header而后端沒有校驗(yàn)這些Header是否真的來自網(wǎng)關(guān)。這個(gè)問題讓我重新重視信任鏈設(shè)計(jì)。解決方案分兩步第一網(wǎng)關(guān)額外注入一個(gè)簽名Header內(nèi)網(wǎng)服務(wù)之間保留簽名校驗(yàn)?zāi)芰Φ诙木W(wǎng)絡(luò)策略層面限制業(yè)務(wù)服務(wù)只允許被網(wǎng)關(guān)調(diào)用和內(nèi)部其他服務(wù)調(diào)用內(nèi)部調(diào)用同樣需要經(jīng)過安全改造。網(wǎng)關(guān)注入Header是業(yè)務(wù)上的方便信任邊界的收緊必須同步做否則省了事就丟了安全。5.3 連接池耗盡與重試風(fēng)暴某次營銷活動(dòng)的大促中網(wǎng)關(guān)轉(zhuǎn)發(fā)層到商品服務(wù)某個(gè)節(jié)點(diǎn)的連接池被打滿出現(xiàn)大量排隊(duì)。同時(shí)重試策略碰到5xx錯(cuò)誤時(shí)自動(dòng)重試每請(qǐng)求最多重試3次。這兩個(gè)機(jī)制疊加后形成重試風(fēng)暴原本請(qǐng)求已經(jīng)超時(shí)重試又把這批請(qǐng)求原封不動(dòng)地打成三份進(jìn)一步擠占后端資源導(dǎo)致雪崩。修復(fù)思路分三方面重試只對(duì)冪等請(qǐng)求開放并且重試間隔要加隨機(jī)抖動(dòng)連接池打滿時(shí)快速失敗而不是無限排隊(duì)增加全局熔斷開關(guān)一旦某個(gè)上游的錯(cuò)誤率連續(xù)上升網(wǎng)關(guān)立刻停止往該節(jié)點(diǎn)發(fā)請(qǐng)求。這個(gè)坑給我最大的教訓(xùn)是重試和熔斷必須成對(duì)配置只有重試沒有熔斷反而是放大器。5.4 上報(bào)鏈路中的日志采樣與延遲網(wǎng)關(guān)吞吐量高時(shí)如果所有請(qǐng)求的完整日志都寫到磁盤IO會(huì)成為瓶頸。我第一次上線時(shí)直接在Filter里打印全部業(yè)務(wù)Header結(jié)果網(wǎng)關(guān)性能下降近四成。后來改成采樣日志正常請(qǐng)求按1%采樣錯(cuò)誤和超時(shí)請(qǐng)求100%記錄。TraceId和吞吐指標(biāo)不受影響。這個(gè)調(diào)整既保住了排查能力又把日志IO壓力降下來了很多。6. 網(wǎng)關(guān)在整個(gè)架構(gòu)演進(jìn)中的位置從單體到Mesh再到AI組裝6.1 單體架構(gòu)時(shí)代不需要網(wǎng)關(guān)很多老項(xiàng)目用單體應(yīng)用加一個(gè)Nginx就夠用那時(shí)候聊API網(wǎng)關(guān)確實(shí)是過度設(shè)計(jì)。單體內(nèi)部天然共享會(huì)話和權(quán)限模型流量入口單一Nginx負(fù)責(zé)靜態(tài)資源、SSL終止和簡(jiǎn)單負(fù)載均衡已經(jīng)綽綽有余。網(wǎng)關(guān)真正變得必要是在服務(wù)化拆分之后服務(wù)數(shù)量多了安全規(guī)則和流量策略需要一個(gè)集中決策點(diǎn)否則每拆分出一個(gè)服務(wù)就要重復(fù)做一遍鑒權(quán)和限流的適配。6.2 南北向與東西向流量治理的再次分工架構(gòu)走到微服務(wù)階段后大家發(fā)現(xiàn)南北向網(wǎng)關(guān)只治理了外部請(qǐng)求服務(wù)間的調(diào)用還是“打野”狀態(tài)。于是服務(wù)網(wǎng)格出現(xiàn)了把東西向流量治理下沉到了Sidecar。這時(shí)API網(wǎng)關(guān)的定位更清楚了它專注解決端到端的外部流量的策略入口網(wǎng)格解決服務(wù)間的策略分布。兩者配合時(shí)網(wǎng)關(guān)對(duì)外做協(xié)議適配和全局安全策略Mesh對(duì)內(nèi)做局部熔斷、重試和觀察。MAI Gateway正好處在這個(gè)銜接點(diǎn)上它既能獨(dú)立工作也能把內(nèi)部策略交由網(wǎng)格接管。6.3 AI Agent與組裝式應(yīng)用給網(wǎng)關(guān)帶來的新命題最近在探索AI Agent類的組裝式應(yīng)用時(shí)我發(fā)現(xiàn)網(wǎng)關(guān)的價(jià)值又多了一層。Agent通常要編排多個(gè)工具和多步對(duì)話每個(gè)工具API都需要獨(dú)立的限流、配額和調(diào)用審計(jì)。傳統(tǒng)網(wǎng)關(guān)的路由規(guī)則比較靜態(tài)但Agent API的調(diào)用鏈路更像是一場(chǎng)多跳的會(huì)話請(qǐng)求可能要先經(jīng)過模型網(wǎng)關(guān)再跳到業(yè)務(wù)工具最后再返回組合結(jié)果。這個(gè)時(shí)候網(wǎng)關(guān)的統(tǒng)一身份模型、配額控制和全鏈路TraceId能力正好契合了Agent場(chǎng)景下“多步驟一個(gè)最終用戶”的追蹤需求。我在實(shí)際調(diào)研中的體會(huì)是未來的網(wǎng)關(guān)可能不僅要管HTTP Request還要管事件、長連接甚至語義級(jí)別的路由但核心價(jià)值不會(huì)變——它始終是那個(gè)統(tǒng)一策略的匯聚點(diǎn)把安全和治理從業(yè)務(wù)代碼里徹底剝離開。我自己在使用MAI Gateway大半年后有一個(gè)很實(shí)際的建議給所有路由和Filter配置加上版本號(hào)并且每次變更都留審計(jì)。網(wǎng)關(guān)配置雖然執(zhí)行的是策略但策略錯(cuò)誤造成的破壞往往比業(yè)務(wù)Bug更大。版本號(hào)和審計(jì)不會(huì)直接提升性能卻能讓你在出問題時(shí)多一根救命稻草換句話說這一步省不了。