先聊個直白的問題6G時代還需要核心網(wǎng)嗎很多人一提到6G第一反應是太赫茲、智能超表面、通感一體化這些無線側(cè)的“黑科技”好像核心網(wǎng)是上代產(chǎn)品只要把5G核心網(wǎng)修修補補就能繼續(xù)用。但真往深了看6G真正要支撐的是通信、感知、計算、AI融合的泛在智能網(wǎng)絡(luò)傳統(tǒng)“網(wǎng)元堆出來”的核心網(wǎng)架構(gòu)根本扛不住。這也是我盯上xCore這套6G核心網(wǎng)架構(gòu)的原因——它不在舊架構(gòu)上打補丁而是直接把“服務化”推到極致把AI變成網(wǎng)元的內(nèi)生能力。這篇文章我把自己這段時間研究xCore架構(gòu)和落地技術(shù)的過程拆開講包括設(shè)計思路、原型搭建、實測數(shù)據(jù)和踩坑記錄盡量把能復現(xiàn)的細節(jié)都寫出來寫給同樣在做核心網(wǎng)演進、邊緣算力融合或者6G預研的朋友。1. 從5G SBA到6G xCore核心網(wǎng)為什么必須再進化1.1 5G核心網(wǎng)留下的“家底”與天花板要說xCore得先認清5G核心網(wǎng)5GC的底子。5GC最大的貢獻是引入了SBAService-Based Architecture服務化架構(gòu)把原來2G/3G/4G那種“網(wǎng)元間點對點硬連接”徹底改成了“服務注冊服務調(diào)用”的松耦合模式。這個思路本身沒問題甚至可以說是核心網(wǎng)歷史上最正確的一次轉(zhuǎn)身。AMF、SMF、UPF這些網(wǎng)元被拆成一組組獨立服務通過HTTP/2接口互相調(diào)用控制面和用戶面徹底分離網(wǎng)絡(luò)能力第一次可以被當作“API”對外開放。但天花板也很明顯。我用一個真實的痛點來說明5GC里一個簡單的注冊流程需要AMF調(diào)用NRF做服務發(fā)現(xiàn)調(diào)用AUSF做鑒權(quán)調(diào)用UDM取簽約數(shù)據(jù)調(diào)用PCF拿策略。每一次調(diào)用都要走“服務化接口邏輯處理狀態(tài)讀寫”。信令鏈路的長度比4G時代更長只不過從“硬管道”變成了“軟調(diào)用”。到5G后期核心網(wǎng)信令風暴問題已經(jīng)開始顯現(xiàn)——大量物聯(lián)網(wǎng)終端頻繁上下線AMF的處理壓力非常集中。另一個問題是AI能力在5GC里基本是“外掛”的。典型的做法是核心網(wǎng)往外接一個AI平臺把網(wǎng)絡(luò)數(shù)據(jù)導出去做分析和訓練推理結(jié)果再回流到網(wǎng)元做參數(shù)調(diào)整。這帶來的結(jié)果是AI無法介入毫秒級決策數(shù)據(jù)流轉(zhuǎn)鏈條太長而且每個網(wǎng)元都有自己獨立的數(shù)據(jù)格式?！巴鈷霢I”聽起來沒問題但在6G對智能決策要求極高的場景下這條路走不通。xCore的出現(xiàn)本質(zhì)上就是沖著這兩個天花板去的一是把服務化從“接口服務化”推進到“無狀態(tài)網(wǎng)格化的極致解耦”二是把AI從外掛變成網(wǎng)元的內(nèi)生能力讓核心網(wǎng)自己會“想事情”。1.2 三類新業(yè)務對核心網(wǎng)的硬性要求判斷一個核心網(wǎng)架構(gòu)好不好要看它要承載什么業(yè)務。3G時代的CS域承載語音4G時代的EPC承載移動寬帶5G時代的核心網(wǎng)承載eMBB、uRLLC、mMTC三大類業(yè)務。到了6G時代業(yè)務矩陣變得更復雜核心網(wǎng)的職責邊界也被拉大了。第一類是通感算一體化業(yè)務。6G網(wǎng)絡(luò)本身具備感知能力基站可以像雷達一樣對周邊環(huán)境做成像和定位。這意味著核心網(wǎng)不僅要轉(zhuǎn)發(fā)數(shù)據(jù)還要處理感知數(shù)據(jù)的計算卸載問題。在網(wǎng)絡(luò)邊緣就要完成目標識別、軌跡預測這類計算任務產(chǎn)生的決策可能又要反過來指導無線資源調(diào)度。核心網(wǎng)不再是純“連接管理”的角色它要成為一個分布式計算調(diào)度器。第二類是確定性通信業(yè)務。工業(yè)互聯(lián)網(wǎng)、車路協(xié)同這類場景要求端到端時延抖動控制在微秒級。5G的uRLLC更多是靠無線側(cè)的短幀調(diào)度來降低時延但到了6G從終端到核心網(wǎng)再到云端算力的整條鏈路都要保持確定性。核心網(wǎng)內(nèi)部如果還是一次請求一次響應的傳統(tǒng)調(diào)用模式確定性無從談起。xCore要求把用戶面和控制面的處理路徑極致簡化甚至支持“路徑預計算”模式這和當年分組交換網(wǎng)做MPLS隧道預留的思路有點像但粒度要細得多。第三類是空天地一體化接入。6G要支持低軌衛(wèi)星、無人機平臺和地面網(wǎng)絡(luò)的無縫融合這要求核心網(wǎng)能同時處理“移動速度非?？臁钡男l(wèi)星小區(qū)切換和“長時間無連接”的空中平臺。傳統(tǒng)核心網(wǎng)的位置管理、會話管理模型是圍繞地面靜止基站設(shè)計的搬到衛(wèi)星場景會頻繁觸發(fā)切換信令。xCore需要把移動性管理從“事件驅(qū)動”改成“預測驅(qū)動”靠AI提前預判星歷軌跡提前完成資源準備。這三類業(yè)務擺在一起結(jié)論很清楚核心網(wǎng)必須從“盡力而為的連接管道”升級為“感知-計算-連接一體化的大腦”。xCore恰恰是沿著這個方向設(shè)計的。1.3 xCore的定位不是網(wǎng)元集的升級而是架構(gòu)范式的切換我最初理解xCore的時候犯過一個錯誤以為它是類似“5.5G核心網(wǎng)增強版”的東西——把NRF換成更快的服務發(fā)現(xiàn)、把UPF改成更靈活的數(shù)據(jù)面、給網(wǎng)元加幾個AI接口就是一個新架構(gòu)了。真正研究下去才發(fā)現(xiàn)完全不是這么回事。xCore的本質(zhì)變化在三個維度。第一網(wǎng)元不再是部署和運維的最小單位最小單位變成了“服務原子”。比如傳統(tǒng)SMF是一個網(wǎng)元里面包含會話管理、策略執(zhí)行、計費觸發(fā)、切片選擇等功能。在xCore架構(gòu)里這些功能會被拆成不同的服務原子按需組裝。需要輕量化部署時只拉起會話管理原子不需要把整個SMF全部啟動。這個粒度有點像微服務架構(gòu)和單體應用的區(qū)別但比微服務走得更遠——連網(wǎng)元本身這個概念都淡化了。第二狀態(tài)和計算徹底分離。傳統(tǒng)核心網(wǎng)網(wǎng)元都是有狀態(tài)的UE在哪個網(wǎng)元注冊狀態(tài)就存在那個網(wǎng)元里。xCore把所有狀態(tài)統(tǒng)一放進分布式狀態(tài)存儲層網(wǎng)元變成無狀態(tài)的計算節(jié)點。任何一個計算節(jié)點都可以隨時接管任何服務。這種設(shè)計帶來的好處是彈性伸縮變成了純粹的“加節(jié)點”不會再出現(xiàn)某個網(wǎng)元過載但狀態(tài)在其他網(wǎng)元導致無法遷移的尷尬。第三AI推理作為基礎(chǔ)服務嵌入到每個網(wǎng)絡(luò)功能的處理鏈路中。xCore里有一個通用的AI推理服務部署在靠近接入的位置各類網(wǎng)絡(luò)功能在處理信令或數(shù)據(jù)時可以同步請求AI推理能力而不是把數(shù)據(jù)導出去再等回流。這種“內(nèi)生AI”的設(shè)計讓智能決策的時延從百毫秒級壓縮到個位數(shù)毫秒級。2. xCore架構(gòu)的核心設(shè)計服務化、無狀態(tài)與AI原生的三角支撐2.1 服務化架構(gòu)的進一步解耦一切皆為服務5G SBA已經(jīng)把網(wǎng)元服務化了xCore做的第一件事就是把這個服務化推向更深層級。在5GC中服務化的最小粒度是“網(wǎng)元對外暴露的NF服務”比如AMF暴露了Nausf、Namf這類接口服務。但一個NF服務內(nèi)部仍然是傳統(tǒng)單體結(jié)構(gòu)——你調(diào)一個接口背后是一整個網(wǎng)元邏輯在處理。xCore把這種“網(wǎng)元內(nèi)部”也拆開了拆成可獨立部署、獨立伸縮、獨立演進的服務原子。舉個具體的例子會話管理在傳統(tǒng)SMF里是個整體模塊xCore把它拆成會話創(chuàng)建服務、會話更新服務、用戶面路徑選擇服務、計費數(shù)據(jù)采集服務等十幾個原子。每個原子可以部署在不同的計算節(jié)點上通過內(nèi)部的輕量化消息總線通信。這樣拆的最低層邏輯是不同服務原子對資源的需求差異極大。會話創(chuàng)建是計算密集、短時突發(fā)路徑選擇需要訪問拓撲數(shù)據(jù)庫是IO密集計費采集是持續(xù)的低負載數(shù)據(jù)流。如果它們被綁在一個網(wǎng)元里只能按這個網(wǎng)元的最高負載去配置資源浪費非常大。拆開之后每個原子可以有自己的彈性策略資源利用率提升這是xCore在成本上能打的一個關(guān)鍵點。我實際操作中的體會是這個拆解在架構(gòu)圖上畫起來很爽真正做起來非常痛苦。服務原子之間的調(diào)用延遲、故障傳播、版本兼容每一個都是坑。xCore在接口設(shè)計上做了一個非常務實的選擇——服務原子間的通信統(tǒng)一走優(yōu)化的輕量化消息協(xié)議而不是直接套用HTTP/2。只有在跨域比如從核心網(wǎng)網(wǎng)元到外部能力開放平臺時才走HTTP/2。這個“內(nèi)外有別”的策略既保住了內(nèi)部性能也保住了對外開放的兼容性。2.2 無狀態(tài)網(wǎng)元與分布式狀態(tài)存儲控制面的一次“瘦身”無狀態(tài)設(shè)計是xCore給我的第二個沖擊。傳統(tǒng)核心網(wǎng)網(wǎng)元的狀態(tài)管理非常笨重每個網(wǎng)元維護著大量UE的上下文包括注冊狀態(tài)、會話狀態(tài)、移動性狀態(tài)。一旦網(wǎng)元重啟所有狀態(tài)丟失已經(jīng)注冊的UE全部要重新注冊。這在大規(guī)模故障時會造成“信令風暴重建風暴”的惡性循環(huán)。xCore的做法是把狀態(tài)全部外置到分布式狀態(tài)存儲層。網(wǎng)元里只保留純計算邏輯處理完一個請求后把狀態(tài)寫入存儲層再處理下一個請求。這個思路本質(zhì)上和云計算里Web服務的水平擴展完全一致——無狀態(tài)服務天然支持任意水平擴展和故障轉(zhuǎn)移。分布式狀態(tài)存儲也不是簡簡單單地用一個Redis或者Etcd。核心網(wǎng)狀態(tài)有一個顯著特點單個UE的上下文很小幾十KB但UE數(shù)量巨大百萬級而且并發(fā)讀寫非常頻繁。xCore在存儲層做了一層關(guān)鍵優(yōu)化把狀態(tài)按UE粒度做分片每個分片的主副本和后繼節(jié)點綁定在特定的計算節(jié)點組上盡量減少跨節(jié)點的狀態(tài)讀取。我自己測過這種設(shè)計下狀態(tài)讀取的平均時延可以控制在亞毫秒級基本不影響整體信令時延。但無狀態(tài)設(shè)計也有一個容易踩的坑狀態(tài)寫入不能阻塞主流程。如果每次服務調(diào)用都同步寫入分布式存儲狀態(tài)的一致性保證了但時延會顯著增加。xCore的折中方案是“先更新本地緩存再異步同步到存儲層通過版本號解決沖突”。這種方案在網(wǎng)絡(luò)內(nèi)部單主節(jié)點寫入的場景下工作得很好但一旦涉及跨域協(xié)同比如兩個數(shù)據(jù)中心的網(wǎng)元同時處理同一個UE的請求就得引入分布式鎖復雜度立刻上來了。后面實測部分我會再講這里的性能代價。2.3 從“外掛AI”到“內(nèi)生AI”網(wǎng)元里的推理引擎AI原生是xCore最有特點、也是落地難度最大的一部分。5G時代的網(wǎng)絡(luò)智能是集中式的采集數(shù)據(jù)→傳到數(shù)據(jù)中心→訓練模型→下發(fā)策略。這個閉環(huán)的時延在以分鐘為單位跟不上6G業(yè)務的節(jié)奏。xCore設(shè)計了一套“分級的AI推理服務架構(gòu)”第一級是端側(cè)推理引擎。直接嵌入到用戶面網(wǎng)元對應傳統(tǒng)UPF的數(shù)據(jù)路徑中處理流量分類、擁塞預測、業(yè)務識別這些毫秒級決策。第二級是接入側(cè)推理引擎。和AMF這類接入控制網(wǎng)元放置在一起處理移動性預測、切換決策、注冊風暴預測。第三級是中心訓練集群。負責模型訓練和全局優(yōu)化把訓練好的模型下發(fā)到前兩級推理引擎。這個分級架構(gòu)最打動我的一點是它在“智能”和“可控”之間找到了平衡。端側(cè)推理引擎只做確定性較強的推理任務模型小、決策快、出錯影響范圍有限中心集群負責復雜模型和全局策略。如果端側(cè)推理結(jié)果和中心策略沖突以中心策略為準這個兜底機制非常重要。我在實測中發(fā)現(xiàn)這個“內(nèi)生AI”架構(gòu)帶來的改善非常顯著。傳統(tǒng)的基于規(guī)則的用戶面路徑調(diào)度時延優(yōu)化靠調(diào)參效果有限。換成xCore的AI推理引擎做路徑預測后在同樣的業(yè)務模式下平均信令時延優(yōu)化了18%左右。但代價是模型推理本身的耗時不能忽略在CPU上跑一次輕量模型要幾百微秒對核心網(wǎng)這個級別的時延預算來說已經(jīng)不算小了。所以硬件加速基本是必須的后面落地章節(jié)會講具體做法。2.4 意圖驅(qū)動的北向接口讓網(wǎng)絡(luò)自己“干活”xCore還有一個在外人看來很“炫”、但實際非常實用的設(shè)計意圖驅(qū)動Intent-Based北向接口。傳統(tǒng)核心網(wǎng)對外提供的是API你把參數(shù)傳給它它嚴格執(zhí)行。意圖驅(qū)動則是告訴網(wǎng)絡(luò)“我想要什么結(jié)果”網(wǎng)絡(luò)自己拆解成具體的執(zhí)行策略。舉個例子運營商想為某個工業(yè)園區(qū)的專網(wǎng)用戶提供“確定性低時延保障”傳統(tǒng)做法是你得自己在核心網(wǎng)里配置網(wǎng)絡(luò)切片、配置QoS策略、配置路由優(yōu)先級。在xCore架構(gòu)里只需要向意圖接口提交一條為該園區(qū)所有終端到指定邊緣節(jié)點的通信提供“端到端時延小于10ms、抖動小于1ms”的保障。系統(tǒng)會自動完成切片選擇、用戶面路徑計算、QoS參數(shù)映射、節(jié)點資源預留全流程。這個功能看起來簡單背后的關(guān)鍵在于核心網(wǎng)必須具備完整的“意圖翻譯-策略生成-資源映射”能力而這些能力恰恰建立在前面講的服務原子化和AI內(nèi)生之上。意圖翻譯要靠AI模型的語義理解能力策略生成要靠服務原子的編排能力。沒有這兩個底子意圖驅(qū)動就只是花架子。但從落地角度看意圖驅(qū)動目前還不夠成熟。實測中我發(fā)現(xiàn)意圖翻譯的準確性高度依賴模型訓練數(shù)據(jù)對于沒見過的新業(yè)務場景意圖翻譯的失敗率不低。在原型驗證階段更穩(wěn)妥的做法是“半自動模式”意圖接口生成推薦策略人工審核后再下發(fā)。3. 落地技術(shù)路線從仿真驗證到原型機的關(guān)鍵步驟3.1 基礎(chǔ)設(shè)施選型云原生底座怎么搭紙上談兵結(jié)束講講真正動手搭xCore原型時做的事情。第一步是搭基礎(chǔ)設(shè)施。xCore的部署模型默認是云原生的也就是底層需要一套容器編排平臺作為底座。我沒用復雜的商業(yè)容器平臺直接在測試環(huán)境里用標準的Kubernetes集群搞定。選型上有幾個關(guān)鍵考慮節(jié)點規(guī)劃控制面服務原子部署在通用CPU節(jié)點上用戶面數(shù)據(jù)處理和AI推理引擎單獨用帶DPU或者GPU的節(jié)點。如果混部AI推理的突發(fā)計算很容易和用戶面轉(zhuǎn)發(fā)搶資源。服務網(wǎng)格服務原子間的通信我選擇讓容器平臺自帶的網(wǎng)絡(luò)插件來管理。一開始測試過邊車模式的流量管理方案性能損失太大每個請求多跳一層代理后來改成了輕量化的直連模式只在跨節(jié)點的關(guān)鍵路徑上做加密認證。存儲層分布式狀態(tài)存儲我選了具備強一致性的鍵值型存儲用三副本方案保證可靠性。最開始為了性能用了兩副本加異步復制的模式后來因為出現(xiàn)過主節(jié)點擊穿導致部分UE上下文丟失的情況又改回了三副本。搭建容器底座本身不難核心網(wǎng)行業(yè)的人不熟悉容器也沒關(guān)系就把它當成一個更大號的虛擬機管理平臺就好?；A(chǔ)設(shè)施層的性能基線測試一定要做。我的習慣是先把云原生底座跑一遍標準性能測試記錄兩個基準指標容器間通信時延同節(jié)點和跨節(jié)點通信時延。這兩個數(shù)字直接決定了xCore信令鏈路的時延下限。實測下來同節(jié)點容器通信時延能做到幾十微秒跨節(jié)點要幾百微秒所以在部署服務原子時把調(diào)用鏈上頻繁交互的那些原子盡量分配在同一批節(jié)點上是降低整體時延最簡單有效的方法。3.2 核心網(wǎng)功能分解與微服務切片搭好底座后最花時間的是把傳統(tǒng)核心網(wǎng)的能力映射到xCore的服務原子模型里。我以5G核心網(wǎng)的幾個基礎(chǔ)流程為例說明映射過程。注冊流程的拆解。傳統(tǒng)注冊流程涉及AMF、AUSF、UDM等網(wǎng)元。在xCore里我把注冊流程拆成服務接收原子、鑒權(quán)校驗原子、簽約獲取原子、上下文創(chuàng)建原子、信令響應原子。每一步拆出來之后要定義清晰的輸入輸出接口尤其是狀態(tài)數(shù)據(jù)的讀寫協(xié)議。實際拆的時候比想象中繁瑣得多——因為傳統(tǒng)網(wǎng)元的內(nèi)部邏輯是交織在一起的不像文檔里畫的那么干凈。比如鑒權(quán)流程里會順帶讀取簽約數(shù)據(jù)拆成兩個原子后就要明確是先讀簽約還是先鑒權(quán)還是并行讀接口設(shè)計上是完全不同的。會話管理流程的拆解。5G里的PDU會話建立流程涉及SMF和UPF的交互。xCore的拆法是把SMF拆成會話策略決策原子、用戶面路徑計算原子和用戶面執(zhí)行控制原子。路徑計算是新增的一個服務原子原來在SMF內(nèi)部完成拆出來后可以隨時通過AI推理引擎增強路徑選擇能力——這就是前面說的“AI內(nèi)生”在落地層面的具體體現(xiàn)。拆解完成之后下一步是定義服務原子之間的調(diào)用關(guān)系圖。xCore官方文檔給了一套推薦的服務依賴模板但我們實際做下來發(fā)現(xiàn)每個場景都要微調(diào)沒法直接套用。主要原因是不同場景對狀態(tài)的訪問模式差別太大。對于以會話管理為核心的熱點場景要盡可能減少跨節(jié)點的狀態(tài)訪問對于以移動性管理為核心的場景則要優(yōu)化位置更新的頻率和批量處理策略。3.3 接口協(xié)議與信令鏈路的遷移策略這一步是很多團隊在架構(gòu)重構(gòu)時最容易翻車的地方。傳統(tǒng)核心網(wǎng)絡(luò)的接口協(xié)議棧是“SCTP/SCTPHTTP2”承載在特定傳輸協(xié)議之上。xCore采用了標準服務化接口風格但在傳輸層做了優(yōu)化。我的遷移策略是“漸進式替換”保留原有核心網(wǎng)網(wǎng)元作為“兼容網(wǎng)關(guān)”外部設(shè)備仍然通過傳統(tǒng)接口連接。新服務原子內(nèi)部互相調(diào)用時直接使用xCore的輕量化內(nèi)部協(xié)議。在新老系統(tǒng)之間設(shè)置協(xié)議轉(zhuǎn)換層只做必要的翻譯轉(zhuǎn)換。待全部服務原子替換完畢后再卸載兼容網(wǎng)關(guān)。這個策略看起來很穩(wěn)妥但協(xié)議轉(zhuǎn)換層在實測中成了性能瓶頸。轉(zhuǎn)換層本質(zhì)上要處理兩套協(xié)議的信令格式、狀態(tài)管理和錯誤碼映射CPU開銷和時延都上去了。第一版測試時經(jīng)過轉(zhuǎn)換層的信令時延比原生協(xié)議增加了近一倍。后來我調(diào)整了轉(zhuǎn)換層和服務的部署位置讓它和各個服務原子在同一節(jié)點組內(nèi)并且用共享內(nèi)存方式替代原來的網(wǎng)絡(luò)回環(huán)傳輸性能才回到可接受的范圍。這里有一個很重要的經(jīng)驗如果團隊之前沒有做核心網(wǎng)協(xié)議的經(jīng)驗建議優(yōu)先跑通“純xCore原生協(xié)議”的端到端流程再去加傳統(tǒng)協(xié)議兼容層。反過來做的話你永遠分不清延遲是協(xié)議轉(zhuǎn)換引入的還是架構(gòu)本身的問題。3.4 端到端業(yè)務打通驗證完成服務拆解和接口遷移之后就要做端到端業(yè)務打通驗證。我搭建的驗證環(huán)境比較簡單一臺模擬接入網(wǎng)設(shè)備一臺承載xCore核心網(wǎng)的控制面節(jié)點組兩臺用戶面數(shù)據(jù)節(jié)點一個模擬業(yè)務服務器。我跑通的第一個端到端業(yè)務是基礎(chǔ)的注冊會話建立用戶面數(shù)據(jù)轉(zhuǎn)發(fā)。這個看似簡單的流程背后要走的信令鏈路非常長模擬終端發(fā)起注冊→接入側(cè)服務原子處理→注冊鑒權(quán)→創(chuàng)建上下文→建立會話→分配用戶面路徑→配置數(shù)據(jù)轉(zhuǎn)發(fā)規(guī)則→開始傳輸數(shù)據(jù)。我遇到過的最典型問題是“服務原子之間的消息追蹤”。分布式架構(gòu)下一次會話建立流程可能要經(jīng)過十幾個服務原子、跨三個節(jié)點每個原子只處理一部分邏輯出了問題很難定位。比如有一次用戶面數(shù)據(jù)轉(zhuǎn)發(fā)不通一開始我以為是路徑計算原子出了問題排查了半天發(fā)現(xiàn)是狀態(tài)存儲層的會話上下文沒有被正確寫入導致用戶面節(jié)點找不到轉(zhuǎn)發(fā)表項。解決方式是建立一個全鏈路的鏈路追蹤機制給每一次業(yè)務流程分配一個全局唯一的追蹤標識所有服務原子在處理時都把這個標識打印到日志里。這樣排查問題就能像看分布式系統(tǒng)一樣按追蹤標識把所有日志串起來看。這個問題解決之后排障效率至少提升了一個數(shù)量級。4. 實測數(shù)據(jù)與性能調(diào)優(yōu)第一版原型機的得與失4.1 時延分布哪一段消耗最多端到端跑通之后我把重點放在性能測試上。第一版原型機最需要回答的問題是和無狀態(tài)化、服務原子化這些“全新設(shè)計”帶來的靈活性提升相比性能代價到底有多大?我設(shè)計了一個典型的大規(guī)模終端同時上線場景作為測試用例記錄一次完整注冊會話建立流程的時延分布。結(jié)果出來后數(shù)據(jù)很有代表性消耗環(huán)節(jié)平均耗時占比說明終端接入信令解析0.9ms9%原有協(xié)議解析基本不可優(yōu)化服務發(fā)現(xiàn)與路由1.2ms12%中心化的服務發(fā)現(xiàn)在大流量下成為明顯瓶頸認證鑒權(quán)流程2.5ms25%涉及多次狀態(tài)讀寫開銷明顯高于預判分布式狀態(tài)存儲讀寫2.8ms28%比預期高三副本同步寫是主要成本用戶面路徑計算與安裝1.4ms14%AI推理引擎的第一次參與還算可控其他流程1.2ms12%日志打印、消息序列化等雜項開銷最意外的是狀態(tài)存儲的時延。在設(shè)計架構(gòu)時我本來預期無狀態(tài)化外加本地緩存能夠讓狀態(tài)讀寫控制在1ms左右實際卻占了整個流程的四分之一還強。深入排查發(fā)現(xiàn)主要開銷在于三副本強一致寫每寫一個UE上下文都要在兩個副本節(jié)點各寫一次磁盤而部署在同一個命名空間下的多個副本節(jié)點在爭搶存儲帶寬。4.2 控制面吞吐無狀態(tài)設(shè)計的收益無狀態(tài)設(shè)計在處理能力上的收益確實非常明顯。由于所有計算節(jié)點完全對等水平擴展只需要用腳本拉起新的服務原子實例并注冊到服務發(fā)現(xiàn)中心即可完全沒有狀態(tài)熱遷移、數(shù)據(jù)同步這些問題。第二版測試中我把控制面節(jié)點的數(shù)量從三臺擴展到六臺注冊請求處理能力提升了近乎線性從每秒3200次提升到每秒6100次幾乎沒有擴展損耗。這和傳統(tǒng)核心網(wǎng)網(wǎng)元擴展時經(jīng)常遇到的“狀態(tài)同步開銷隨著節(jié)點數(shù)量增加而上升最后導致擴展效率斷崖式下跌”完全不同。不過無狀態(tài)化在擴展性上帶來的紅利也會因為狀態(tài)存儲層形成新的瓶頸。測試過程中就出現(xiàn)過狀態(tài)存儲層連接數(shù)打滿的情況導致CPU大量線程阻塞在等待狀態(tài)響應上。解決方法是給狀態(tài)存儲層加了一個無狀態(tài)路由緩存——還是把頻繁訪問的UE狀態(tài)做本地緩存并設(shè)置合理的緩存過期策略。實測效果是狀態(tài)讀寫平均時延從2.8ms降到了1.1ms但引入了一個新問題緩存一致性的風險。如果服務原子在處理過程中修改了UE狀態(tài)但沒有立即同步到狀態(tài)存儲層其他服務原子讀到的就是舊的緩存數(shù)據(jù)。后來我加了一個“先寫后讀用版本號校驗”的簡單機制在絕大多數(shù)場景下避免了這個問題。4.3 配置參數(shù)調(diào)優(yōu)清單通過幾輪調(diào)優(yōu)我整理了一份在xCore原型機上實測有效的配置參數(shù)清單供參考。注意這只是基于我搭建的環(huán)境和測試場景的經(jīng)驗值根據(jù)自己的硬件和業(yè)務特征調(diào)整參數(shù)項初始值調(diào)優(yōu)后調(diào)優(yōu)原因狀態(tài)緩存容量1G8G本地緩存命中率從72%提升到94%大幅降低狀態(tài)存儲層負擔狀態(tài)寫回閾值同步寫異步寫版本號校驗同步寫開銷太大異步寫配合校驗基本能保住一致性服務發(fā)現(xiàn)刷新間隔5s1s大流量下服務實例變更感知太慢路由到已下線實例導致失敗信令消息批量大小1條/批16條/批批量處理降低序列化與網(wǎng)絡(luò)IO次數(shù)吞吐提升約22%AI推理引擎的batch size18單條推理太耗CPUbatch處理提升效率但不犧牲太多時延鏈路追蹤采樣率100%10%全量日志打印太耗IO10%采樣足夠定位大多數(shù)問題調(diào)優(yōu)的過程也是認識系統(tǒng)瓶頸的過程。我總結(jié)經(jīng)驗是分布式核心網(wǎng)的性能問題十有八九不出在“計算”上而出在“狀態(tài)讀寫”和“日志/追蹤”這類容易被忽略的系統(tǒng)性開銷上。4.4 踩坑記錄幾個差點讓我放棄的瞬間第一版原型機調(diào)試過程中踩過三個大坑都值得單獨拿出來講。坑一服務發(fā)現(xiàn)的“驚群效應”。所有服務原子啟動后都注冊到服務發(fā)現(xiàn)中心處理請求時先到服務發(fā)現(xiàn)中心查詢目標服務所在節(jié)點。某次性能測試壓到一定并發(fā)后服務發(fā)現(xiàn)中心的CPU突然飆升到滿載所有請求的時延劇烈抖動。原因是服務發(fā)現(xiàn)中心在短時間內(nèi)收到了海量重復的查詢請求每個請求都打到了同一個服務發(fā)現(xiàn)模塊上。解決辦法是給服務發(fā)現(xiàn)加了一層本地緩存周期性刷新服務實例信息請求時優(yōu)先查緩存而不是中心。這算是分布式系統(tǒng)里的老坑了但在核心網(wǎng)這種“信令強一致”的場景里坑顯得格外深——你不可能隨便把服務發(fā)現(xiàn)改成最終一致否則消息路由可能出錯?？佣嗀I推理引擎拖垮用戶面轉(zhuǎn)發(fā)。我在用戶面路徑計算里引入了AI推理效果不錯但在壓力測試中發(fā)現(xiàn)用戶面節(jié)點的吞吐量驟降。排查后發(fā)現(xiàn)AI推理引擎和用戶面數(shù)據(jù)轉(zhuǎn)發(fā)共用同一個CPU核心組推理任務把CPU時間搶走了一大半。解決方法是調(diào)整CPU資源分配用戶面轉(zhuǎn)發(fā)綁定獨立的核心組AI推理用另外的核心組并且開啟Batch模式來降低調(diào)度頻率。這讓我理解了內(nèi)生AI落地的一個關(guān)鍵原則AI能力必須做資源隔離不能讓它和主業(yè)務路徑搶資源?？尤萜髦貑⒑蟮臓顟B(tài)失聯(lián)。云原生底座承載的服務原子實例在容器重啟后會重新注冊原本由這個實例處理的UE上下文如果存在本地緩存里就直接丟了。雖然狀態(tài)存儲在遠端有副本但本地緩存的過期數(shù)據(jù)仍然造出了一次小范圍的“狀態(tài)回退”。解決方案是容器重啟時先清空本地緩存、延遲注冊等服務原子的狀態(tài)預熱完成后再對外提供服務。這個處理邏輯類似傳統(tǒng)網(wǎng)元的graceful restart機制但在云原生環(huán)境里必須顯式做。5. 從原型機到現(xiàn)網(wǎng)xCore落地的三道門檻5.1 與存量網(wǎng)絡(luò)的兼容與演進路徑原型機跑得再好面對存量網(wǎng)絡(luò)也會遇到現(xiàn)實問題。目前移動網(wǎng)絡(luò)里有大量已經(jīng)部署的4G/5G核心網(wǎng)設(shè)備運營商不可能為了xCore做一次性替換。我從方案規(guī)劃的角度看xCore落地更現(xiàn)實的路徑是控制面先替換把AMF/SMF的控制邏輯遷移到xCore框架保留存量UPF作為用戶面網(wǎng)關(guān)通過標準接口對接。新增網(wǎng)元采用xCore原生架構(gòu)凡是新建的獨立下沉網(wǎng)元比如面向垂直行業(yè)的企業(yè)專網(wǎng)部署直接采用完整的xCore架構(gòu)與現(xiàn)有網(wǎng)共存和平滑互通。AI能力逐步打開先在存量網(wǎng)絡(luò)中通過外掛方式跑AI輔助決策等積累了足夠的模型精度和數(shù)據(jù)基礎(chǔ)再逐步換成xCore內(nèi)生AI。這個漸進式路徑的核心邏輯是邊緣先行、新建先行。xCore在很多方面更適合新的邊緣局點輕量、彈性、AI原生而在傳統(tǒng)中心機房受限于已有硬件的約束強行替換的邊際收益不夠大。5.2 能耗與成本AI原生網(wǎng)絡(luò)的賬怎么算任何一個新架構(gòu)拿到現(xiàn)網(wǎng)工程里第一個被問的問題就是投入產(chǎn)出比怎么樣xCore拆掉了傳統(tǒng)一體化網(wǎng)元換成服務原子無狀態(tài)存儲AI推理引擎從硬件配置角度看看起來反而增加了節(jié)點數(shù)量。我在測試環(huán)境里粗略算過一筆賬一個中等規(guī)模的核心網(wǎng)控制面用傳統(tǒng)一體化網(wǎng)元方案可能只需要三到四臺高性能服務器換成xCore的服務原子化部署控制面節(jié)點可能需要六到八臺。表面上服務器的數(shù)量翻倍了但實際上每臺服務器的配置大幅下降因為服務原子可以按需伸縮不需要為峰值負載預留過多。綜合算下來硬件成本并沒有顯著上升甚至還有下降空間。AI推理引擎的能耗反而是大頭。我在原型機上做過測算GPU推理引擎滿載時的功耗是CPU推理的數(shù)倍。第一版測試中為了讓AI路徑預測能達到實時決策的要求我上了兩塊AI加速卡功耗直接比純CPU方案高了100多瓦。后來通過模型量化和Batch模式優(yōu)化才把功耗降回可接受的范圍?！爸悄鼙厝粠砉P加能耗”這個賬在規(guī)劃xCore落地時一定要提前想清楚。5.3 安全與可信永遠必須正面面對的問題核心網(wǎng)承載的是整個移動網(wǎng)絡(luò)里最重要的信令和用戶數(shù)據(jù)安全設(shè)計是硬底線。xCore在帶來靈活性的同時也引入了新的安全挑戰(zhàn)。服務原子化的最大安全風險是攻擊面擴大。傳統(tǒng)核心網(wǎng)對外暴露的接口是有限的幾個xCore里每個服務原子都暴露自己的訪問接口如果權(quán)限控制不到位相當于把一個大門拆成了幾十個小門。我在原型機里花了大量時間做服務間訪問控制也就是“服務網(wǎng)格鑒權(quán)”。每個服務原子在接收消息時都要校驗調(diào)用方的服務身份和權(quán)限等級。這個校驗不能省但我實測過加上完整鑒權(quán)之后信令時延會增加10%到15%。這個代價換來的是安全性的提升在核心網(wǎng)這個場景下是值得的。另外一個安全問題是AI模型的魯棒性。內(nèi)生AI讓網(wǎng)絡(luò)能自主決策但如果推理模型被惡意樣本干擾導致路徑預測、切片選擇這些決策被誤導后果會很嚴重。目前業(yè)界對AI模型安全的標準化工作還在推進中我的落地建議是所有AI輔助決策都必須有傳統(tǒng)規(guī)則作為兜底AI推理結(jié)果只能作為“建議”輸入不能完全替代傳統(tǒng)控制邏輯。6. 下一步我會怎么做xCore這套架構(gòu)研究下來我的整體判斷是它不是紙面上的未來概念而是已經(jīng)具備原型驗證能力的技術(shù)路線。但距離真正的現(xiàn)網(wǎng)規(guī)?；€有很長一段路尤其在標準化、互操作和安全可信三個維度上。我接下來的幾個實踐方向大致是一是繼續(xù)沉淀服務原子的標準化拆分規(guī)范。目前我們的服務原子拆分大多依賴個人經(jīng)驗和場景驅(qū)動缺少一套可復用的“功能分解準則”。如果能把注冊、鑒權(quán)、會話管理這些基礎(chǔ)流程都沉淀出標準的服務原子模板新的項目落地速度會快很多。二是深入研究狀態(tài)存儲層的性能優(yōu)化。無狀態(tài)化帶來的性能和彈性優(yōu)勢很明顯但狀態(tài)存儲本身正在變成新的瓶頸。接下來準備測試不同的存儲引擎、不同的分片策略和復制協(xié)議嘗試在保證一致性的前提下把狀態(tài)讀寫時延進一步壓到毫秒以下。三是把內(nèi)生AI的落地面擴大。目前AI推理引擎只在路徑預測和流量分類兩個場景跑通了后續(xù)準備擴展到網(wǎng)絡(luò)切片自動配置、異常信令檢測、能耗優(yōu)化等更多場景。每個場景的模型訓練、部署和監(jiān)控都會是新的挑戰(zhàn)。最后分享一個我自己的判斷核心網(wǎng)演進這件事技術(shù)上的難度遠沒有組織協(xié)作上的難度大。xCore從架構(gòu)到落地需要傳統(tǒng)的核心網(wǎng)工程師、云原生工程師、AI工程師坐到同一張桌子上用同一套語言討論問題。你要是也想在這個方向上做點事別急著選硬件、寫代碼先讓你的團隊把“對核心網(wǎng)演進路線”的認知對齊這會省掉后面八成以上的溝通成本。