通訊世界網訊息（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工作組並專注於算力路由的研究，新華三也積極參與標準的寫作和推進，將在標準領域發出更多聲音。
