算力网络国家枢纽节点「算力网络架构演进的思考」

通信世界网消息（CWW）追溯算力网络的提法，与很多新技术的历程一样，首先会在标准领域，比如CCSA、ITU-T看到端倪，2019年8月第一篇算力网络相关文稿在CCSA立项。经过几年不断的讨论，业界已经达成了一定共识，目前算力网络已经成为国家战略性新兴产业研究的方向之一。

从技术角度剖析算力网络的产生必然性，必定先从云开始谈起。毋庸置疑，云计算的确改变了企业和个人的工作方式，提供了一种弹性灵活、易维易建且性价比高的新选择。云计算最开始就是以一种集中的形态出现的，云服务商把数以千万计的服务器集中在一个地理区域内，以资源池化、可高度复用共享的方式提供各类IaaS、PaaS、SaaS服务。这的确很宏大，但在发展过程中也不断暴露出一些问题，其中一点就是集中高挂的云资源池并不适用于所有用户，比如对低时延、大带宽有诉求的用户。云服务商意识到了这个问题，开始向“集中-边缘”协同的架构演进，在边缘机房不断增设边缘云，与中心云一起对外提供云服务。云既然分成不同层级，提供的云服务也相应分级，集中云可以提供大通量的高算力服务，边缘云可以提供低时延、大带宽、低算力服务。如何同时兼顾云提供的算力能力和接入点到云的网络指标，给用户选择最合适的云，算力网络技术就是一种非常合适的选择。

在算力网络概念提出之前，已经有了云网融合的提法，云网融合更侧重于云，网络在其中是提供可达性的一种手段。而算力网络则是强调将算力和网络并列，同时兼顾。算力网络和云网融合之间既有共同点，也有一定的区别。

算力网络本质上是一个生态系统，涵盖用户、应用、算力、网络等多个要素，通过算网调度平台（或者“算网大脑”）把各要素串联起来。作为算力供给方和算力需求方之间的桥梁，这个平台要真正发挥作用，必须得有丰富的应用生态、明确的算网度量、动态的调度策略，否则算力网络就是空中楼阁，难以发挥作用。算力网络架构（如图1所示）可以划分为三层，最底层是算力网络基础设施层，提供算力基础设施和网络基础设施。算力一般先支持自有的算力系统，后续不断扩展，对三方算力进行纳管，提供更丰富、覆盖面更广的算力服务。网络则从骨干网/城域网向下不断渗透，将各类接入网纳入管辖范畴，提供端到端的网络服务。

图1 算力网络架构

中间是算力网络控制层，起到承上启下的作用，一方面将算力信息和网络信息存储起来；另一方面根据应用需求、调度策略的配置对算网进行综合决策，选择合适的算力资源池，并打通网络路径。

最上层是算力网络服务层，提供开放能力给各类算网应用，对应用的算网需求进行语义解析，调用网络控制层为各类应用提供满足要求的算网服务。

支付宝领icloud空间

算力网络架构

按算网调度决策的位置是集中还是分散，算力网络可以划分为集中式和分布式两种架构。

集中式算力网络中算网调度平台是中枢，由它来分别获取算力使用、网络拓扑及质量情况，在内部通过数据库存储算网关键信息。当应用有算网请求时，由算网调度平台进行集中决策，兼顾应用的算力请求和网络要求，选择合适的云资源池，并打通网络承载路径，将应用流量引导过来。分布式算力网络中算网调度平台（如图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协议，都需要经过业界的充分讨论。