随着边缘计算行业的不断发展，其业务也越来越广泛，越来越成熟。边缘计算的发展历程并不是一帆风顺，其运用起来也和传统云计算有很大不同。那么边缘计算行业所面对的挑战以及未来的发展是什么样的呢？有请网心科技的李浩为我们分享他助攻视频行业的这几年。
文 / 李浩
整理 / LiveVideoStack
大家好，很荣幸能被邀请参加此次会议。这是一次很好的交流机会，我也能和大家分享这几年走过的路径。
01
简单的产品决策
先做一个简单的自我介绍，2011年到2015年我在做通用云计算业务，与视频行业还有些距离。标准云计算最核心的是一些虚拟化，一些复杂的网络调度，更偏中心的模式，而视频是天然的分布式的架构。
2015年，整个云计算的行业趋势是大家逐渐接受云化模式，所有厂商都说计算将来是像水网，电网一样的触手可得，客户自己去建电厂是不划算的。但是我当时在想，水网、电网肯定不是几个大的机房能组成的，它一定需要一个更接近终端的网络，包括计算、存储、网络三大件。从2014年底我接触到边缘计算这个概念，就认为这个领域在未来十年是有机会补全云计算网络的。
1.1 虚拟世界的快递
计算、存储、网络三大件，最容易切入的点是网络，在2015年的时候最合适的场景是CDN。因为它已经有了规模市场，同时对比发现其中技术和模式可做的创新点非常多。类比与虚拟世界中的快递，在真实世界中运送快递，成本构成、核心竞争与虚拟世界是相同的，无非是追求多、快、好、省。真实世界的快递公司商业形态是多样的，有直营、散点加盟、直营配加盟等等，但在CDN只有一种模式，所以我们认为这里既有技术上的创新点也有模式上的创新点。很有意思的一点，物流公司目前也在学习虚拟网络的组织方法，IPIC协会在研究如何把实体的物流网络映射成虚拟的网络，把基于经验的快递变成基于算法和更加科学的数据运算。这里存在几个和现有数字网络不同的地方。一是它假设传输速度不是光速。二是它传输的物品不可复制。三是它的重传的成本非常高，丢包容忍概率非常低。IPIC基于这样的假设做了很多研究和创新。
左边是物流公司前端的实时大屏，和CDN公司的前端大屏几乎一模一样。右边是物流公司的组网模式和经营模式，它与2015年的CDN公司的相比是更丰富的。点面、块面，树状、网状映射都比当时国内CDN架构更加复杂。
1.2 不同的路径选择
回看整个CDN市场，我认为CDN分为几个路径上的选择。一种是追求平衡。通过自己的覆盖密度和节点容量来做一个测算，最终要做到节点的覆盖率和ROI的平衡。这是一个最为简化的CDN示意图，实际上的则更为复杂。这是一个类树状结构的内部组成，是一个规划好的网络。规划的依据是根据自己的经济效益和需求。密度上一般会同省同网以及各大一线城市同网。CDN不太可能在西藏、新疆等地方做城域、地级市以及更往下的小区的覆盖，因为这样在经济上是不平衡的。
第二种路径选择的核心追求是容量和质量。有一家创新型的边缘计算公司Fastly，其体量和Akamai相比小很多。但是他们特别的是在做一个类似于物流中亚洲一号仓的模式。把每个节点做的特别大，同时每个节点的配置也很高，相当于亚洲一号仓配全空运的模式。对一些高价值的流量分发，比如电商网页、Times时报等高要求流量，产生差异化的价值。他们的模式是单个节点很大，一个节点可能1到2TB，全球范围内覆盖，100个POP点；节点里自己做路由算法，通过Anycast IP做全球接入。
这种模式不仅成本非常高，而且在国内不太可行。因为那么多的POP点在国内是拿不到的，但是除去这些问题，他有一些创新是非常值得参考的。Fastly针对流量分发场景做了一些抽象，把请求分成几个处理的生命周期——接到请求、包处理、日志阶段等等。使用者可以直接在Fastly的平台上去写代码，把这些请求做一些逻辑处理，并同时配备一些很轻量化的容器方案。Shopify有一个购物车逻辑就是通过把代码运行在Fastly边缘节点上来提效，通过WASM这种轻量虚拟化的方式运行。
第三个路径的核心是强调节点数量和覆盖密度。通过在网络的各个层次部署超密集的边缘节点去覆盖。网络节点的差异性是很大的，它可能属于接入网、可能属于城域网、可能属于骨干网，单节点容量很小，但总容量很大。所以对经济效益的追求没有第一种和第二种那么严格。又因为它整体的冗余量是非常大的，所以肯以做成一个接受更多峰值同时成本更低的模型。与之相对的，它的复杂度很高。节点的波动性很大，运算能力、储存能力差距很大，所以在传输、调度、部署上要考虑很多，网心就是采用这类模式。对整个网络做估算，其中运算资源相当于过千万台在线服务器、数十万PB存储、500TB以上的带宽资源。核心任务就是如何把这些边缘网络中的资源使用起来。
有了前面模式的想法，加上我们对现实网络的一些观察，我们推出了星域云产品。想法决定很快，实现起来却非常困难。
参考业界对边缘的分层——Home edge、Network edge、Cloud edge。CDN节点就属于云边缘，可以看到资源一定是越往边缘下沉，延时就越低，资源越分散，使用难度越高但容量越大。
当时我们认为找到了一片广阔的蓝海。不仅市场好，而且我们找到了模式上的差异点，同时和我们拥有的分布式技术相匹配，又处于15年万众创新的背景下，所以就全情投入参与网心创建。
事实上是，想法虽然很容易推导出来，但实践起来非常困难。一开始的计划是2年内把网络层的边缘化做好，然后开始做存储，接着是运算。可实际上做好网络层花费了6年时间。去年才陆续将存储和计算的一些场景跑通。
02
产品实现
2.1 真实路径
2014我们年开始对迅雷进行改造，对下载流量进行边缘化的改造是最容易的。2015年切入直播行业，直播对延时对卡顿的要求很高。2016年介入长视频，之后做中短视频。挑战越来越大，外部环境也在不断变化。CDN行业价格发生了巨变，3年内价格变成了原来的1/3,从成本、效率等各方面的挑战变大。例如，ROI平衡一开始测算只要的20%利用率就可以，几年后却需要达到60%,对精细化的调度和传输要求会变得很高，对质量要求的也在不断提升。有利的点是国内带宽的持续提速，增大了整体的边缘资源池。
2.2 概要架构
这是一个概要的架构图，我们把代码嵌入到用户的APP里，所以可以做双端优化，这是边缘传输方案和传统CDN的不同点。既然可以做双端优化，那么就可以在传输协议、编码层面做更多的处理。另外一个不同点是，网心很强调部署。传统CDN模式是根据请求触发回源达到最优的部署结构。因为传统CDN的节点更大、数量更少，所以请求调度有固定的逻辑，传统CDN可以根据用户的请求，天然的将数据沉淀到网络里，形成最优的部署。可这种模式在大规模边缘节点的架构里是行不通的，首先调度路径是不可预先规划的更多变的，其次节点差异很大。可以理解为加盟快递公司的网点，有些是开在门口的10平方小网点，有些却是几千平方的大仓库。如果想要把物品调度起来，就需要前置做好部署算法，保证最优的装箱效率。反观如果都是几千平方的大仓库，请求到了直接发货就可以。
2.3 供给难题
这项工作需要解决几个核心的问题。第一个是供给。这是最难解决也是最核心的问题。这种模式本质上是自建加上一部分的加盟共享。这是一个平台经济，在其中如何保证需求端和供给端的平衡永远是一个跷跷板的游戏。可以理解成滴滴打车，是前期补贴司机，还是前期补贴乘客？尤其在B端业务上，乘客是各大公司，持续补贴乘客是很难带来粘性的。同时如果网络达不到规模、质量达不到要求，乘客是不会上车的。所以前期把网络的搭建起来，不仅要花费大量的资金，还需要网络设施升级、新业务爆发等时间窗。
对于网心核心的供给一个就是做容量的平衡，在平衡的同时在使用率上达到足够的经济效益。第二个是做激励，将所得的收入比较有效的通过结算策略分发到网络的参与者。我们有一个结算网络用于评判哪一些参与者在网络中贡献的运算能力、带宽能力、存储能力对我们的价值是最大的，以及将来的潜在价值是最大的。我们这个网络是一个开放式的网络，任何节点都是可加入的，因此反作弊也是核心的一点。
网心构建了一个资源池，包括路由器、盒子、赚钱宝、玩客云、电脑PC、服务器等等。这里面还有网心自建的节点和机房，我们自己也是平台里的参与者。通过供给的资源池，在此基础上构建分层服务。最底层是虚拟化容器平台，容器平台之上是存储、传输、网络、运算的PaaS服务。其中网络是最先行的，因为网络最容易在实际应用场景中大规模使用。同时需要一个完善的结算系统，来衡量这些服务产生的价值，再结合参与者的实际贡献以及预先的价值判断对参与者进行回馈。
2.4 传输难题
第二个需要解决的问题是一个技术性问题，我们做了一些条件分析：
一：多点传输。单点的节点容量不够大，想有效的把边缘测的资源全部利用起来，一定要使用多对一的传输模式。
二：做冗余的纠错。交互太多，传统ARQ的方式效率很低，会导致一些关键的数据阻塞。
三：可以实施复杂编码。这点很重要，相对于服务器来讲，边缘节点的运算能力更强，因为服务器吞吐的带宽量和CPU的运算能力相比，单位带宽所拥有的CPU能力较少，与边缘侧的单位带宽有几十倍的差距。所以边缘上面可以支持更复杂的信道和信源编码。
四：无速率约束。因为节点网络波动很大，信道删除概率无法推测，所以整体编码算法要追求无状态。假如我把数据切片，切片以后会有前后之分，如果前片不到，后片全到也没有用。这就是典型的简单有状态编码方式，在这种编码方式下协调沟通成本会增加很多。因此，我们需要追求无速率约束、无状态、不定长的编码方式。
五：自适应信道容量。因为本质上这是一个非均质的网络，节点有大有小，差异非常大，所以信道容量需要一定自己探测自己调整的能力。
编码算法本质上就是A ⊕X ⊕X = A，就相当于做了一个转置矩阵，核心点在于通过成功率的折损来换取计算复杂度的降低。通信里会使用一些专用硬件电路使其编解成功率提升4个9。如果使用CPU，就需要对算法进行优化，例如用3个9的成功率将算法复杂度降低一个数量级。
2.5 成本难题
需要解决的第三点是成本问题。成本问题在这几年变得越来越重要。在前些年整个行业定价高高在上的时候，成本还算不上是问题，还不需要追求利用率，不需要追求极致的装箱算法。但在现在的情况下，如果没有把资源充分的利用起来，没有把网络中的经济价值发挥到最大，就会丧失竞争优势。
网心所做的核心就是热度预估、主动部署、节点成本划分、装箱优化。节点的存储、带宽、计算、波动性是多样组合的，客户的需求场景也是不一样的，需要做当前最优匹配。网盘类的客户需要大存储小带宽，直播类的客户需要小存储大带宽，如何将他们有效的装箱，是提升经济价值的核心点。这里我们要做最小化持续的调整，这个网络绝不是调度一次就可以的，需要时刻腾挪和调整。
2.6 用户难题
还有一点是普通传输不太能碰到的，就是播放器，要和客户的播放逻辑很紧密的耦合，而这里又经常会改变。我们需要通过很碎片化的信息、日志、传输反馈来推测用户的行为。预加载逻辑是怎么做？错误处理是怎么做的？等等都需要通过综合信息来推测，当然也需要和合作伙伴、客户多做沟通。
举个简单例子，当打开一个APP，里面可能有四五个预览的小视频，我们碰到这样的场景有很多。用户是0-的请求，还是0-500KB？是全部加载，还是按顺序加载？差异是很大的，尤其要考虑升级的困难度。
业务端的指标要求也从明确的QoS指标变化为综合的QoE指标，这里给因果分析也带来了不小的挑战。
这是网心这几年在持续解决的一些问题。从目前来看，在网络层覆盖的场景已经比较全面了，但边缘计算才刚刚开始，计算、存储、以及依托于基础服务商的场景下移才刚刚开始。
03
持续升级
我们认为音视频一定是最核心的信息传输和表达的方式，内容会视频化。而且不只是人来消费视频，随着视频理解能力的提升，将来物物之间也会有音视频消费。构建物和物之间的音视频传输网络以及大型的全联通网络是我们目前已经在做的。其次运算能力的下沉，从成本层面考虑，放在一个中心机房运算，其带宽和计算成本相对是高的。例如3D设计领域，目前边缘的算力完全可以满足，如果下沉成本可以极大降低。另外，还有一些对时延比较敏感，对带宽有巨大需求的VR、AR场景，把计算放在云上一不经济二不现实，同时会带来巨大的带宽消耗。可以将运算拆解开，把背景流量通过边缘渲染。还有一些基于Device的虚拟方案，通用的容器管理方案消耗还是太大了，肯定需要类似WASM这种OnDevice的轻量方案。
04
未来展望
未来是全面数字化的社会，全真互联网或数字孪生都是讲现实和虚拟网络会越来越分不开。在这种前提下，边缘化计算只是一个概念，更核心的逻辑是未来所有的设备都是可感知、可计算的。
内容视频化，音视频将是最核心的信息传递方式，信息密度高，包括未来的物物传输，需要解决视频内容的理解。
目前边缘计算行业还处于起步阶段，需要耐心打磨，还有很长的路要走。未来中心计算和边缘计算会组成立体网络，真正形成水网、电网，计算资源无处不在触手可及。
谢谢大家！