文 | 王闻宇
整理 | LiveVideoStack
大家好，我是王闻宇。非常感谢LiveVideoStack的邀请，也非常荣幸今天能和大家一起分享交流。
首先我做一个简单的自我介绍。早在2004年大学期间，我就开始从事音视频行业，和姚欣一起开发了当时很知名的P2P 网络电视软件PPLive，后来改名为PPTV。在校期间，我一直在钻研这个软件，统筹主导PPTV的流媒体、P2P、点播、直播、编解码等核心技术，并担任PPTV首席架构师。2004年的网络条件比现在要落后很多很多，当时我们仅靠10Mb的发布带宽，就稳定支持了20多万人的同时直播在线观看。当然QoS 和今天的直播比还是有所差距，17年前国内上网环境大多还是512k的ADSL，和今天的光纤完全不一样。而当时我们已经取得了在512k ADSL下能稳定支持450k视频流畅播放的骄人成绩。我深耕音视频行业近二十载，2018年，在5G时代的萌芽阶段，我看到了边缘云计算未来不可估量的发展趋势，我认为十年之后边缘云所带来的市场比当时的中心云加起来还要大，怀着激动的心情，我坚定了我的信念，汇聚全球计算资源，并为全人类服务，这也是我和姚欣一起创办PPIO边缘云的初衷。
那么如何汇聚全球计算资源呢？这就是我今天要和大家分享交流的话题：PPIO边缘云是怎么用共享经济的思路做边缘计算节点的？首先我要给大家解释为什么我们要走共享经济的路线，其次在共享经济的路线之下，我们拥有哪些核心技术，最后对PPIO边缘云的解决方案做一个详细的介绍。
1. 为什么选择共享经济？
边缘计算的使用场景更为多元化，其中包括直播流、边缘AI、云游戏、AR/VR和其他低延迟的一些服务，包括最近社交大火的Metaverse也因为超低延迟需要把算力部署在边缘节点。PPIO边缘云为什么要用共享经济的方式做边缘计算？
1.1 边缘的定义
说到边缘，到底什么是边缘？上图刚好是整个边缘的一张谱图，这个图指的是站在运营商的角度来看边缘。越往左越接近中心，越往右就越靠近用户。而除了公有云DC以外，后边的环节都可以认为它是边缘的一部分，其中主要有三类，一类是现在的大厂特别是几大云公司，比如阿里云、腾讯云以及华为云，他们的边缘节点，主要部署在了骨干网边缘，其本质是对中心云架构做了简化，成了“省级中心云”。第二类是把边缘覆在了端侧，例如盒子、路由器等。第三类是PPIO边缘云的优势所在，我们差异化地弥补了“省级中心云”与“端侧”所形成的边缘覆盖鸿沟，在城域网部署网络节点，同时在接入网汇聚网络资源，为客户提供成本更为经济、质量更加上乘的服务。
1.2 边缘节点画像
我们来看一下PPIO共享经济边缘节点画像，有三四线城市的IDC，有市县级运营商城域网机房，有小区接入机房、企业的闲置机房等，还有一些曾经是数字货币作为存储挖矿的企业最后“弃暗投明”选择为边缘计算做贡献，提供更有价值的服务。
1.3 边缘云和中心云的差异
基于这样的边缘，它和中心云之间存在多个维度的区别，既有服务器部署位置的维度，也有硬件配置、网络接入以及资源利用率的不同。如果用类似云公司的方式来做边缘，从做几万甚至十几万的节点角度去看，要重复投入大量的资本去购买宽带自建，时间周期也非常漫长。在这样的背景下，PPIO边缘云采用了新的建设方式：不再靠自己部署的方式去建设，而是借鉴共享经济的一些理念，建立一套共享经济的开拓机制，在全国范围内开发这样的边缘节点，将闲置资源利用起来。
1.4 共享经济模式的边缘云架构
PPIO共享经济模式的边缘云架构，建立了一个纵横交织的边缘云平台。纵向上，通过独有技术将异构资源进行整合，为客户提供稳定、安全、可靠的服务；横向上，通过靠近用户端的边缘节点能力，以及与云厂商的联动，打造了端到端的性能保障体系。
1.5面临的挑战
但是，基于共享经济模式建设边缘云面临诸多挑战：比如，在平台上注册上线的节点，存在作弊的现象。这与网约车刚兴起时所存在的，个别司机进行虚拟交易现象类似。再如，高度异构的问题，这里既有网络的异构、硬件的异构，也有故障的异构。另外，还有不可抗力因素，比如紧急性的停电等等，这都是要面对的挑战。因此，PPIO边缘云在基于共享经济进行边缘云建设时，借鉴了当年做P2P技术的主体思想：即，在面对局部的剧烈不稳定性的情况下，通过技术手段的整合，用整体的确定性去解决局部的不确定性，从而达到整体的稳定性。
1.6 边缘节点存储的异构性
那么如何理解异构呢？这里我重点讲述两部分。第一部分是存储的异构，另一部分是网络的异构。存储的异构是怎么回事呢？因为共享经济模式下的边缘节点相对孤立，没有形成稳定的集群。那么，我们的任务很难再像中心云那样，在每个节点上都会有一个稳定的存储池，因此我们只能让每个节点使用节点本地存储。由于节点来自于不同的供应商，存储配置参差不齐：包括磁盘的数量、类型、IOPS、容量都不相同。而任务对于存储的使用方式也是千变万化，我们需要将不同的存储抽象成统一的存储资源，提供给任务来使用。这就是我们讲的存储异构。
在这里我可以分享几个例子：如上图，第一个例子就是我们有些任务为了限制实例的日志空间，同时保护数据库空间，要求分别为日志和数据库划分独立的小分区，而剩余的存储空间则都用来做数据缓存。这样即使日志写多了，也不会影响到缓存数据和数据库，数据库也有了独立的存储空间，避免被日志和缓存数据侵占。还有的任务要求划分3个、4个甚至更多的独立的固定大小分区，同时也将剩余分区作为缓存。PPIO边缘云采用统一的模式来支持这种多变的需求，只需简单配置即可。
我们还接到一些任务，对存储的要求非常高，需要建立起一套bcache的机制，把固态硬盘作为存储的缓存机制来加速机械盘，从而把存储设备利用率用到最高，如图所示。
再举个例子，有一些任务对CPU消耗很大，而任务实例只支持使用一个存储卷。现实中，一个节点的CPU通常最多只能支持2~3个实例，节点上的盘的数量是远大于实例数的。因此，为了充分利用存储资源，我们把多个盘通过 LVM 合并成一个逻辑卷，提供给任务实例使用。这样节点的存储资源被充分利用，任务的服务能力也得到了较大提升。最有挑战的是，有时候这几个异构同时出现在一个节点上，同时随着任务的切换，节点上存储的布局也要动态地发生改变，以满足新切任务的需要。
1.7 边缘节点网络异构
那么理解了存储异构，接下来我要分享的是网络异构。网络异构在我们做共享经济模式的边缘节点的背景下，也是非常复杂的，有些资源具有公网IP地址，也有些资源在内网NAT环境中；既有大带宽的单线路的专线资源，也有一些小带宽汇聚的线路资源。 这种多线路的网络环境称为多路网络，这里面既有强服务器所带来的服务，也有强服务器通过NAT所实现的服务。在整个网络中有些服务器机器的性能也不是那么强，所以会存在计算能力相对较弱的节点的输出。也就是说我们是在一种比较复杂的网络下，要兼容各种异构的网络环境。
这里举个任务混跑的例子。常见的任务有两种：一种任务是直接能看到多路网卡并且支持多路网络，比如图示中的任务A，直接运行于多路网络然后输出；另一种任务只能支持单路网络输出，比如图示中的任务B。因此，我们要在技术上把网络环境进行打通，才能把网络资源利用的更加充分。
另外，我们也开发了一种Macvlan的方式，可以让不同的网络、任务看到的只是自己单一的网络环境，完全隔离，只能看到自己的网络而看不到别人的网络，从而形成一种干净的环境，更加安全、稳定、可靠。
2. 我们做了哪些技术？
基于刚才所分享的存储的异构、网络的异构，以及用共享经济开发建设的整个边缘网络，PPIO边缘云做了哪些核心技术呢？主要有三部分。第一部分是K8s@Edge，主要是做边缘异构资源的调度编排。第二部分是AI Ops@Edge ，基于大数据和人工智能的智能调度算法，使资源在细颗粒度下进行精确调度，提升资源的利用率。第三部分是SDN@Edge，因为我们的节点一旦下沉之后，就会出现相互之间的连接，就会出现弱网甚至准弱网的环境，所以我们是基于它来实现技术来完成。在这里我分享的三个部分都是我们使用的内部技术，而不是产品。
2.1 K8s
首先我讲一下我们的边缘编排，那么边缘编排为什么不直接使用K8s?其实最根本的原因是设计的目的不一样，K8s设计的时候是基于集群对外服务的稳定性作为第一考虑而来的，而对PPIO边缘云来说，我们设计目的是要做到资源最大化利用，这是两个完全不同的设计目的。
那么具体会存在哪些问题呢？第一个是K8s并没有很好的适应像我们这样没有集群的存储池的环境，不能很好地把状态归档在有限的存储池里；第二个是在我们节点下沉之后，它会存在一种服务，这种服务需要一些数据，不是完全无状态。而数据丢失也不会完全影响服务，就类似于CDN的缓存，这样的数据状态，我称它为一种半状态服务。但是这样的任务不能完全随意切换。第三个我们在接到任务的时候，因为任务本身存在着在很大的调配性，所以我们就需要对节点进行动态修改，也就是说在运行过程中我们要灵活地把业务进行切换，而这个切换会涉及到磁盘的划分、网络的划分，而这些是K8s没有考虑到的；最后一个是因为我们一旦下沉，面对一些比较异构的网络环境，面对弱网、内网甚至多线等环境，我们需要对他们做一种增强的支持，这也是我们为什么不直接使用K8s的原因。
不直接使用不代表我们不用K8s，因为K8s的容器编排理念已经深入人心，它的声明式API，特别是Yaml文件，很多运维人员已经非常熟悉，且非常便捷。且它的生态强大，很容易基于K8s做一些二次的开发。除此之外还可以极大地降低运维和研发的迁移以及学习的成本。
2.2 K8s@Edge
所以在研发的时候我们的思路是源于K8s，不止于K8s。上图是PPIO边缘云对于K8s@Edge边缘编排技术的架构全图，图中白色虚线框中所示为K8s的原生架构，而蓝色块部分是我们在不改动K8s的任何一行代码的条件下，基于它的接口实现的扩展。
Node这一侧，基于K8s 原生的架构，我们独创了Tasklet。图中黄色箭头线是基于整个网络定义扩展出来的一套协议，支持我们整个的整个架构。
在支持任务模型的时候，出于业务的需要，PPIO边缘云不仅支持了K8S Pod、Docker的容器，还支持原生程序和Kata容器的下发。
同时，针对环境的异构性，我们专门做了针对边缘的CPU、存储以及网络等特殊增强的隔离方案。
以上就是我们整个K8s@Edge的架构，它不但兼容了K8s命令，而且能够把任务往边缘节点进行高效编排。
2.3 AIOps@Edge
讲完了K8s@Edge，下边要讲的是PPIO边缘云另一个核心技术就是AIOps@Edge，在讲之前我们首先要理解AIOps@Edge本质解决的不是简单的计算机架构问题，而是经济学问题。这个经济学问题是什么呢？基于共享经济模式所发展的PPIO边缘云，它和传统的云会有很大的区别，它不是单边经济，而是双边经济。
在整个模型中，既包含我们的用户，也包括我们的资源供应商，这是一种循环的聚合拉动模式。而拉动的关键就是在于需要尽可能把资源复用，让不同的任务能同时使用资源，从而提高它的利用率。由于用户是按量来服务的，利用率一旦能提升，我们才能给供应商更多的收入和分成，从而能发展更多的边缘节点。
而PPIO边缘云所要做的是，既要考虑客户的需求（即QoS/QoE，覆盖的服务既要有广度和规模，部署又要有弹性，需要量的时候要给得出量来），客户面对的是异构的任务，而资源侧则需要的是透明的记账，这个账到底是多少，不能随意更改。
另外我们要有更好的利用率，要有稳定的收入。而资源本身具有异构性，而我们就是要解决在异构的业务和异构的资源环境下，同时满足双方的要求，从而完成双边经济。
那么AIOps@Edge的机制是什么？
首先，所有基础运维数据、资源状态、客户需求等数据，会被我们完善的大数据分析平台所采集。之后，大数据平台会对数据进行分析处理，并将初步结果导入AIOps@Edge市场经济撮合模型里，从而得到最终结果。最后，通过K8s@Edge边缘编排系统进行任务下发，对任务和资源进行精确匹配。
我们研发了一整套经济学的撮合机制，参考了博弈论的知识，既考虑供给节点的效益，也考虑需求业务的效益，建立了一套交易模型，最后通过算法使它达到纳什均衡，并且实现快速收敛，从而满足了供给方和需求方的要求。
经过苦心钻研，通过AIOps@Edge技术，我们的利用率整体做到了14.3%的提升，并且大大降低了错误调度、重复调度，使得整体调度效率提升了34.7%。
2.4 SDN@Edge
完成AIOps@Edge后，PPIO边缘云还面对一个问题。我们下沉的节点，相互之间的网络连接其实并没有骨干网那么强悍，甚至有些环境是准弱网的状态。什么是准弱网呢？其实它也不是完全弱网，有时候好，有时候变成弱网，基于这样的网络在做调度、分发的时候，会出现很多问题和异常，甚至想做的任务不能做到很好的调度，因此在这种环境下PPIO边缘云研发了一套SDN@Edge的技术，这个技术和之前P2P技术有很大类似的地方，相当于在服务器节点之间建立了一套高效虚拟的传输网络，从而使得我们的模型与传统云相比，不再是简单的树型结构，而是网型架构，这就是我们的SDN@Edge 。
那么既然是SDN@Edge大家肯定会问SDN@Edge和传统SDN有什么区别，上图是两者的整体区别图，后边的几张图我会用一个颜色表示一个运营商，有两个颜色的就表示要承担跨越运营商的节点。那么左边的图是传统的SDN的架构，基本上是在省级的骨干网之间通过中心的BGP节点，甚至还有DCI专线建立一套软件定义的网络。传统的SDN更多的是一种四层的软件定义网络。而PPIO边缘云做的并不仅仅只是路由的问题，而是绕开了骨干网，绕开了三线互联，基本上是在城域网和接入网两个环节打通整个网络，用了一种上层的算法协议来进行路由决策，所以SDN@Edge是七层的软件定义网络，通过它我们避免了使用昂贵的BGP带宽。
那么在这里面PPIO边缘云又做了哪些工作呢？我们实现了一套链路评估的机制，用于面对节点异构问题，节点既有多路的、单路的，也有内网的，我们运用了多种维度来进行评估。评估方式包括谷歌的BWE，TTL以及成本Cost等；因为我们节点源于共享经济模式拓展，还考虑节点的历史稳定性。根据以上维度的数据，我们给每条链路进行定期打分。
分数有什么作用呢？这就涉及到第二个环节，并行传输。简单来说，并行传输就是从A 点到H 点是跨越运营商的，中间可能存在多节点。我们根据链路进行打分，上图我用线条粗细来区分，线条越粗，表示通信性能越好，越细表示性能更差。根据上图所决定的分数，通过我们的算法，找到了多条链路，再对数据进行分片，用不同的链路传输不同的数据，多路同时传输，实现了完整的从A 点到H 点的通信。因为我们节点源于共享经济模式拓展，中间确实会存在有些节点突然离线的可能，一旦离线，我们会选择另外的路径来实行并行的传输，不会因为单路径中断而导致网络的异常。
另外对于一些延迟要求很高的场景，我们还做了数据冗余的方案，简单来说我们参考了RTC的FEC的技术，把数据切片之后，用喷泉码做了一定的扩展，用上述的多个线路同时传输编码数据。这个×表示数据的丢失，即使在传输过程中数据丢失，我们也能通过算法还原出完整的数据。因此如果有哪个链路在进行传输的时候数据发生了丢失，我们也能保证它的还原。通过数据冗余机制，我们对传输的可靠性和延迟的控制做的更好了。
以上三个技术的结合，PPIO边缘云成功构建了SDN@Edge。
接下来分享一下PPIO边缘云实现1s延迟的直播案例，简单地说，从主播到节点，我们的节点间是通过SDN@Edge来进行传输的，上图中黄色虚线就是SDN@Edge虚拟链路，实现了运营商跨越。从一个运营商，数据传输到了另外两个运营商，最终传输到了用户，这是我们案例的架构图。
3. PPIO边缘解决方案
介绍完PPIO边缘云的技术，接下来我想分享一下基于这些技术，以及我们成功解决了前面所说的挑战后，PPIO边缘云所形成的解决方案。我们的服务主要分两层，一层是IaaS，另一层是PaaS。我们的IaaS主要定位是广覆盖、海量节点、高性价比的边缘容器服务，主打的是稳定可靠的高经济性服务，既有裸金属，也有容器，而PaaS则是我们基于客户具体业务场景所提供的通用服务。
3.1 IaaS
首先讲讲IaaS，PPIO边缘云的IaaS能提供裸金属方案，也能提供重容器方案。是一个能够同时支持多链路多路网络的一套容器方案，可以更充分地利用网络、硬盘、CPU内存以及GPU来进行服务。同时也可以支持多个场景，其中比较成熟的就是图中画实线的场景，虚线场景是我们正在探索并合作中的，如果有伙伴可以一起合作虚线场景，我们非常愿意倾力支持和配合。
3.2 PaaS
上图是PPIO边缘云PaaS的解决方案。我们的PaaS主要分为CDN、直播和游戏这三类。CDN主要是点播和下载的场景，直播主要是低延时互动，云游戏主要是渲染类的场景， PaaS 更多的是提供边缘的网络能力，使得延迟达到更低。在整个方案里，PPIO边缘云有SDK的方案，也有无SDK的方案。无SDK 的方案，根据客户需求，还可以做代码的增强。由PPIO给出参考的代码，在端侧做简单的逻辑，从而使得无SDK 的时候质量大大提升。而SDK方案，可以支持各种系统和浏览器，具备极强的兼容性。
以上是我对于边缘云的一些理解和想法，同时也和大家分享了PPIO边缘云在边缘计算领域的一些构思和核心技术，希望在一个新的万亿元级的蓝海市场中，边缘计算能成为新一轮技术升级的战略要冲，爆发出更多可能性。同时，PPIO边缘云也将持续加大研发投入，不断提升技术能力，以“工匠”精神保障极致用户体验，促进跨行业应用创新，赋能千行百业。
让我们一同期待万物互联的智能时代，目睹这场边缘计算所带来的巨大变革吧！
