算力網絡架構演進的思考

通信世界網消息（CWW）追溯算力網絡的提法，與很多新技術的歷程一樣，首先會在標準領域，比如CCSA、ITU-T看到端倪，2019年8月第一篇算力網絡相關文稿在CCSA立項。經過幾年不斷的討論，業界已經達成了一定共識，目前算力網絡已經成爲國家戰略性新興產業研究的方向之一。

從技術角度剖析算力網絡的產生必然性，必定先從雲開始談起。毋庸置疑，雲計算的確改變了企業和個人的工作方式，提供了一種彈性靈活、易維易建且性價比高的新選擇。雲計算最開始就是以一種集中的形態出現的，雲服務商把數以千萬計的服務器集中在一個地理區域內，以資源池化、可高度複用共享的方式提供各類IaaS、PaaS、SaaS服務。這的確很宏大，但在發展過程中也不斷暴露出一些問題，其中一點就是集中高掛的雲資源池並不適用於所有用戶，比如對低時延、大帶寬有訴求的用戶。雲服務商意識到了這個問題，開始向“集中-邊緣”協同的架構演進，在邊緣機房不斷增設邊緣雲，與中心雲一起對外提供雲服務。雲既然分成不同層級，提供的雲服務也相應分級，集中雲可以提供大通量的高算力服務，邊緣雲可以提供低時延、大帶寬、低算力服務。如何同時兼顧雲提供的算力能力和接入點到雲的網絡指標，給用戶選擇最合適的雲，算力網絡技術就是一種非常合適的選擇。

在算力網絡概念提出之前，已經有了雲網融合的提法，雲網融合更側重於雲，網絡在其中是提供可達性的一種手段。而算力網絡則是強調將算力和網絡並列，同時兼顧。算力網絡和雲網融合之間既有共同點，也有一定的區別。

算力網絡本質上是一個生態系統，涵蓋用戶、應用、算力、網絡等多個要素，通過算網調度平臺（或者“算網大腦”）把各要素串聯起來。作爲算力供給方和算力需求方之間的橋樑，這個平臺要真正發揮作用，必須得有豐富的應用生態、明確的算網度量、動態的調度策略，否則算力網絡就是空中樓閣，難以發揮作用。算力網絡架構（如圖1所示）可以劃分爲三層，最底層是算力網絡基礎設施層，提供算力基礎設施和網絡基礎設施。算力一般先支持自有的算力系統，後續不斷擴展，對三方算力進行納管，提供更豐富、覆蓋面更廣的算力服務。網絡則從骨幹網/城域網向下不斷滲透，將各類接入網納入管轄範疇，提供端到端的網絡服務。

圖1 算力網絡架構

中間是算力網絡控制層，起到承上啓下的作用，一方面將算力信息和網絡信息存儲起來；另一方面根據應用需求、調度策略的配置對算網進行綜合決策，選擇合適的算力資源池，並打通網絡路徑。

最上層是算力網絡服務層，提供開放能力給各類算網應用，對應用的算網需求進行語義解析，調用網絡控制層爲各類應用提供滿足要求的算網服務。

算力網絡架構

按算網調度決策的位置是集中還是分散，算力網絡可以劃分爲集中式和分佈式兩種架構。

集中式算力網絡中算網調度平臺是中樞，由它來分別獲取算力使用、網絡拓撲及質量情況，在內部通過數據庫存儲算網關鍵信息。當應用有算網請求時，由算網調度平臺進行集中決策，兼顧應用的算力請求和網絡要求，選擇合適的雲資源池，並打通網絡承載路徑，將應用流量引導過來。分佈式算力網絡中算網調度平臺（如圖2所示）功能弱化，更側重運維和分析功能。網絡邊緣節點會感知下掛的雲資源池內算力使用情況，並通過IBGP/EBGP在網絡域進行通告，這樣整網的網絡設備都有了算網關鍵信息。當應用有算網請求時，用戶側網絡設備就可以快速根據本地存儲的信息進行決策，選擇合適的雲資源池並打通網絡承載路徑。

圖2 分佈式算力網絡中算網調度平臺

一般把分佈式架構下網絡設備上新增的功能稱爲算力路由功能（如圖3所示），此時可以看到網絡設備不再是單純的網絡流量承載，在其上已經融合進了算力的因素。正如任何技術都有正反面一樣，集中式和分佈式各有優劣：集中式方案相對簡單，網絡承載設備沒有額外要求，網絡並不感知算力，但算網調度平臺作爲方案的核心，系統重載，在大規模算網部署時將成爲性能瓶頸，同時對於算網服務請求的響應相對緩慢；分佈式方案中網絡感知了算力，算力和網絡是一體內生的，對於算網請求的響應會相對快速實時，但同時也要求網絡承載設備改變轉發邏輯，能夠感知算力、同步算力並支持對算網服務請求的響應，增加了網絡承載設備的技術難度。目前集中式架構的算力網絡方案相對成熟，運營商均有類似的自研產品，一些產學研項目也在開發“算網大腦”來集中管控算力和網絡。分佈式架構的探索還在進行中，目前在標準領域、原型方面有一定成果。

圖3 分佈式架構算力路由

算力網絡關鍵技術

算力網絡依賴一些關鍵技術（如圖4所示），這些技術之間環環相扣，協同支撐算力網絡體系的實現。其中算網度量是最基礎的，相當於定義了供需雙方溝通的語言。明確好度量定義後，通過算網感知獲取系統中的算力信息和網絡信息，形成內部的決策依據。之後算網應用會發出算網請求，平臺進行算網調度提供合適的算網服務。算網度量：作爲一個拉通供需雙方的平臺，首先要有一套雙方均認可的度量標準，供給方需要遵循度量標準表述自己能提供的服務能力，請求方也需要遵循同樣的標準說明自身需要什麼樣的服務能力。網絡類的度量比較容易定義，網因子可以包括帶寬、時延、抖動、丟包率、可靠性等。算力類的算因子度量指標要按服務層次進一步劃分，IaaS類算力可以通過CPU核數、內存可用容量、存儲可用容量等指標衡量。PaaS類算力提供的服務類型有差異，需要定義不同的度量指標，比如數據庫通過QPS/TPS、消息隊列通過每秒處理的消息數來衡量等。SaaS類則提供的服務更抽象，度量也要按服務類型細分，如音頻編解碼能力、視頻編解碼能力、業務會話數、業務繁忙狀態等。算網度量是算力網絡的基石，目前在標準領域已開展若干研究，算力度量更偏重於IaaS層，PaaS和SaaS層度量需要不斷豐富。

集中式和分佈式架構均採用相同的算網度量標準，但其他關鍵技術在集中式或分佈式架構下有不同的實現方式。

算網感知：算力網絡需要對算力信息和網絡信息進行感知並記錄，作爲決策時的參考依據。

集中式架構下，算網調度平臺需要獲取雲內算力使用信息，可以採用訂閱式的被動方式獲取，也可以採用週期性主動方式獲取；同時算網調度平臺也可以從網絡域獲取到網絡拓撲信息，在平臺內部創建算網地圖，保存算力供給信息和網絡狀態信息。對於跨域場景，集中式架構支持相對簡單，調度平臺可以同時獲取多域內的算力和網絡信息，在平臺內部進行信息構建。如果算網規模較大，一方面可以通過調度平臺彈性可擴展的架構來支撐，另一方面可以按多級調度平臺方式部署，依靠軟件實現的功能相對靈活。

分佈式架構下，與雲資源池接口的網絡設備首先獲取到雲內的算力使用情況，然後通過IBGP等協議在域內進行泛洪，將算力信息同步至域內的每臺網絡設備上。此時網絡設備相互傳遞的不再僅限於網絡拓撲信息、路由可達信息、網絡鏈路信息，還額外增加了算力信息，網絡設備轉發的依據也不再僅是報文的目的地址，而是到目的地的網絡情況和目的雲資源池的算力滿足情況。對於跨域場景，需要在域間ASBR通過EBGP向對端發佈本域內的算網信息，考慮到算網信息的龐雜性，一般會在ASBR處先做域內算網信息的聚合，再對外發布，以減少信息交互量和對網絡設備的處理壓力。

算網請求：算力網絡供給側信息收集後，誰來使用？一定是對算力和網絡同時有訴求的算網應用。需要澄清的是，不是所有的應用都需要算力網絡，對時延、帶寬不敏感的應用完全可以按原有的模式構建在雲計算之上，網絡只是作爲可達性配套而已。算網應用在表述算力網絡需求時應遵循算網度量指標，與供給側相匹配。

集中式架構下，算網請求由算網應用向算網調度平臺發起，兩者之間一般通過RestAPI接口交互，接口中明確定義了應用關注的算力信息和網絡信息應如何攜帶。從根本上說，只有應用才清楚自己對算力網絡的訴求，因此算力網絡需要應用深入參與，應用是有一定改造工作量的。

分佈式架構下，算網請求直接包含在應用的流量中，攜帶算網請求可以有不同的實現方式，如果應用能加以改造，應用可以通過擴展頭的方式攜帶算力和網絡訴求，但此類改造需要操作系統的配合，有一定技術難度。另一種方式可以預先定義若干算網服務模板，以不同的服務ID對外提供，應用攜帶不同的服務ID表述自己的算網請求。

算網調度：算力網絡收到應用發起的算網請求後，結合算網感知階段收集到的算力信息和網絡信息，結合動態配置的調度策略（如雲資源負載均衡策略、就近服務策略等），選擇最匹配的雲資源池。

集中式架構下，算網調度平臺解析算網請求，進行算網決策，選擇最匹配的雲資源池，打通應用接入點到雲資源池之間的承載路徑，同時通過各種引流技術將應用流量引入承載網絡中。

分佈式架構下，應用發起算網請求後，用戶側網絡邊緣節點解析應用流量攜帶的算網請求，在內部首先做服務ID到算網請求明細需求的映射，然後進行算網決策，選擇最匹配的雲資源池，打通應用接入點到雲資源池之間的承載路徑，同時通過各種引流技術將應用流量引入承載網絡中。

算力網絡展望

算力網絡是螺旋式發展的，穩態和動態並存，當前已經有了集中式算力網絡的原型，能夠配合特定應用提供算網服務，同時算力網絡的研究還在向更深、更廣、更完善的方向延伸。

算力方面，從集中式雲計算到雲邊協同的邊緣計算，不同層級的雲資源池共同提供算網服務。未來算力可能再往下延伸到端側，各類泛在算力的存在可以作爲現有云邊資源的補充，算力網絡也可以相應向下延展，但端側算力的可信、度量、認證需要持續分析，避免引入安全風險。另外，算力度量在IaaS層比較容易達成共識，但在PaaS和SaaS層由於服務類型多樣、服務特徵不同，度量指標需要算網調度平臺和應用共同制定，還會經過較長週期。

網絡方面，目前開發重點集中在城域核心之上的網絡，未來算力網絡要繼續向下管理到接入網、城域網等，同時基於IBGP或者EBGP發佈算力信息是一個基本共識。但要想實現多廠家網絡設備之間的互通，需要運營商牽頭定義好詳細的協議報文格式，比如複用原有地址族還是新定義地址族、明確TLV字段的含義、如何避免動態與頻繁的算力變化影響相對穩定的BGP協議，都需要經過業界的充分討論。

生態方面，算力網絡是應用的支撐平臺，沒有應用，算力網絡就沒有生命。但如何讓應用願意基於算力網絡做定製開發，需要有對應用足夠的利益驅動，這不僅是一個技術問題，更是一個生態問題，如何讓各方在算力網絡的演進中持續共贏是一個需要長期推動、重點關注的方向。

IETF作爲IP網絡領域最權威的標準組織，去年成立了CATS工作組並專注於算力路由的研究，新華三也積極參與標準的寫作和推進，將在標準領域發出更多聲音。