腾云？驾雾？多云和算力网络

最近上下班路上读了一本书：

链接放这里只是为了让大家清楚的知道说的是什么，至于卖东西挣佣金您想多了，
相反我想谈论一下边缘计算上那些不成熟的想法。
本来这个公众号就是随手记点自己
感兴趣的东西，根本就懒得去运营

。另外这个号本来就代表自己，不代表任何公司，有做的好的我点赞分享，做的不好的我也喷：）

最早的商用边缘计算是思科在2011年提出的”Fog Computing”，一方面是提供有边缘计算能力的节点，例如
UCS-E
小型服务器插入路由器的方式提供了第一代的边缘计算能力，
另一方面是尝试在已有的网络设备控制面上提供虚拟化层来解决问题，我
们通
过在IOS-XE上启用KVM到后期启用Container支持，也就是后来的IOX项目。所以边缘计算的节点演进逐渐就变成了如下图的这种形式：

当然我们在网元中内嵌了算力，算力的呈现和调度却一直是一个难题，也不可否认思科的雾计算平台并不是很成功，Kinetic这些计算平台失败的原因我个人认为应该是编程范式的问题，简单的说前浪太早死沙滩上了，毕竟那个年代大家还是一门心思上云的，而流计算的范式也要到2017年附近flink一类的生态逐渐起来才被大家所广泛接受。

我自己关于边缘计算的实践大概是在2018年，而且直接找到了当年思科负责雾计算的杰出工程师作为Sponsor，本质上边缘计算或者算力网络的核心是通过某种便捷的方式提供算力，而算力的交付则是一个有争议的话题，是虚机、是容器、是API、是serverless，还是干脆果金属？

而这些问题的本质就是要在端到云的计算链条上插入一个节点，并构成Service-Chain，对于完成ServiceMesh改造的应用应该难度不大，因此我考虑在边缘节点上构建流计算的中间件来完成这个工作，这也就是Nimble Engine的项目。

在2018年的时候，基于Java的Flink算力其实相当有限，特别是在一些嵌入式设备上，并且当年Flink并不支持ARM，所以我被迫参考
Google Cloud Datafl
o
w，也就是下面这本书：

基本上实现了一些常见的算子和简单的通过Go channel 构成了workflow的DAG

数据处理上实现了均值/方差/偏度/峰度/分位数的统计，这样大量的值可以实时的进行基于窗口的聚合。同时针对周期性数据时间序列分析的需求，我还加了一些holt-winters的拟合算法进去，这样就可以直接inline的识别峰谷流量等季节性特征并进行控制了。最关键的一个部分是整合了Tensorflow和各种GBDT模型的算子，本来期待通过这套框架来支撑一些异构硬件的，例如在边缘设备上的NPU做上层抽象。所以这个项目最终获得了思科内部的一个大奖，

大佬的一段话非常值得回味
：“Intelligent，Distributed and Autonomous Agents proccess data close to source and at natural aggregation points”这句话才真正的道出了边缘计算的精髓。当然这个项目后期也遇到了一些问题，就是数据流如何牵引到这样的计算节点，计算资源如何自动发现和安全可信的互联互通。所以在去年六月有了一些思考，一方面是如何建立通信，另一方面是从金融的角度来看谁来建，如何建，利益如何分享的问题。

数字经济的转型本质是数据的流动，做好数据本身的加工和物流才是整个新基建链条中最为重要的一环。下一代数据中心建设的架构也将从这个角度出发，前面一二小节只是说要做什么，最重要的是第三节怎么做。

zartbot.Fin，公众号：zartbot下一代数据中心架构-2：从金融民工的视角谈新基建

后期为了算力资源的统一呈现，我开始了Ruta项目，本质上就是现有的SDWAN解决方案去做算力网络还有很多问题没考虑清楚，协议栈需要完全重新设计，很多算力赋能需要在应用的传输层处理而不是网络层去割裂。而看到前面那本书说的还要用BGP构建“Address-Family：算力”就觉得有点过于理想了，毕竟这几个作者也在某运营商去问问看你们的BGP-RR是否同意这么干，AFI、SAFI扩展的太多，而算力更新又非常频繁，BGP根本就无法收敛。所以在Ruta的设计中第一件事情就是规避复杂的BGP，采用更简单直接的分布式KV数据库的方式提供资源抽象，这一点就是参考的K8S，只是在K8S的基础上把网络的问题再处理了一次，没有像Calico那样再继续使用BGP。

另一方面对于算力网络的提法来自于运营商，运营商固有的思维模式认为从云到边的过程中网络带宽资源和延迟控制将成为他们翻盘云提供商的最好资源。但事实上这样的思维方式非常危险，一方面是电信业总是被ITU等冗长的标准牵着鼻子走，各种接口定义非常复杂。另一方面过分看重网络又丢弃了应用的本质。网络的存在应该就是用于服务算力的。
就像
前文所述那样：

MEC的建设很大程度上还是要进行收益互换和融资租赁等业务模式，本质上还是数据流如何变现的过程或者数据流如何结算的过程， 就跟电费水费一样，电站和电网如何分成的问题。实际上这里面可能会诞生一些新的企业和业务模式，例如分众传媒是跟物业合作占领了电梯的广告位， 那么接下来很有可能是云服务提供商和物业的合作，构建楼宇级的小型数据中心。

zartbot.Fin，公众号：zartbot下一代数据中心架构-2：从金融民工的视角谈新基建

算力的提供方需要更加简洁的提供算力并进行结算，整个计算运维框架就要和一个矿机那么简单，插上电和网线就能赚钱那种。另外不要高估边缘的算力需求，其实很多边缘计算模型大概率一个Rpi就能搞定，别想太复杂。关键是满足延迟需求的站点有无覆盖的问题。

其实这也给很多云提供商带来了挑战，边缘云的呈现是何种方式，当然AWS的Outpost，Azure Stack，阿里也有自己的解决方案，这些方案是否过于笨重？于我而言，自带SDWAN功能的虚拟化平台就是一个很不错的工程实践，例如下面这个uCPE的盒子：

当然这种盒子也有一些不完善的地方，例如潜在的针对大吞吐的场景需要50Gbps的SDWAN能力，现阶段行业里各个厂家都做不了，智能网卡在这里才是一个非常好的场景，可惜国内就阿里云和华为云有一些前瞻性的布局。

另一方面，
我坚信
边缘节点更多的是以果金属的形式交付，
运营商
投资算力网络时应当更加关注这一点，
因为你无法做到高效的投放计算资源和撮合交易，更多的是果金属
专卖给阿里云、腾讯
云，或者其它批发商，或者众包业务中小区物业可以自建一些算力平台，果金属外租是最容易保护他们投资的，最后让公有云他们去解决算力零售的问题，做任何生意都要想到整个链条上大家都能挣钱才是好的业务模式，有几个尝试着吃独食的云，最终总有众叛亲离的那一天