边缘计算MEC：答院士“新十问”

在今天举行的“中国移动‘5G E’网边融合技术峰会”上，邬贺铨院士再问边缘计算，让我们先睹为快！

水易，公众号：C114通信网邬贺铨院士：边缘计算“新十问”

我又皮一下~

有认识院士的帮忙给我交份答卷啊~ 

其它人要抄作业拿去，不收钱，技术扶贫~

1.边缘在哪里

最近跟很多领导都谈到这个问题，特别是国内一些知名公司的数通领导和某些云做边缘计算的同行。回答这个问题应该反过来看，应用为什么需要将业务推送到边缘。本质上MEC的存在是解决终端算力不够或者终端不可信而且数据中心延迟约束而存在的。所以基于算力/可信度/延迟 这三个维度确定边界就好，这个没有固定的答案，要从应用出发。

例如园区网其实带宽需求并不大，经常有一些零零散散的计算需求，打卡/视频监控/智能楼宇控制，这些边缘的计算其实放在网络设备的容器上就能搞定。而针对智能城市的需求，可能更多的边缘在商业区和住宅区的中间位置，白天服务商业区，晚上服务住宅区。

2.何谓多接入

多接入本质上是要解决终端漫游的问题，Wifi和5G互切换本质问题就是IP地址变了如何保障通讯不中断？Layer3的问题想继续在Layer3上修补肯定不行，只有Layer4上利用Unified ConnectionID加上源路由的方式来解决

为啥要源路由，因为有些计算业务如同院士所述，本质上是个随路计算，需要源路由的方式将数据锚定到MEC。

OTT服务商将终端/数据源到云计算中心路径之间任意节点均可定义为MEC落点，可以是纯软件形态或是集成中间件的硬件网关。

水易，公众号：C114通信网邬贺铨院士：边缘计算“新十问”

ruta的初期就考虑到了这个场景

Ruta FlowID的设计来自于做一些web应用时，用户登录地址端口也经常变化，服务器地址也因为负载均衡的需求经常在变。Json Web Token(JWT)机制便是一个很好的处理方式，另一方面基于Google Dapper论文的APM系统也需要Tracing ID做标记，而APM和NPM的结合最头疼的便是NPM可能无法解密Tracing ID,或者需要parse整个应用层协议栈找到Tracing ID。所以一直在尝试着做两者的结合，再加上以往做核心网的经历，GTP协议中也有TEID，而移动网中的大量策略也基于TEID。同时还受到QUIC Connection-ID的影响

zartbot.Net，公众号：zartbotRuta架构：5G/MEC环境下的移动性和可追踪性

3.MEC是边缘云吗？

其实院士的问题应该是MEC的运营和建设模式的问题，是DaaS/KaaS/ PaaS/SaaS，几个月前有一文就探讨过，应该从金融的角度来看，本质上还是一个收益互换和融资租赁的问题。

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

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

4.MEC与CDN和DC的异同

简单一点，CDN解决I/O密集型业务的边缘卸载，MEC解决的是计算密集型和I/O延迟的问题，当然顺便做大一点解决I/O密集型业务也可。

5.MEC计算什么？

很多时候我们在为MEC找应用的思路去建设，其实还是要从应用本身出发，基于算力/可信度/延迟 这三个维度确定MEC如何卸载计算业务。

6.MEC如何发现服务与配置？

院士有个问题提的很好：

“在车联网场景下用户和计算设备动态注册和撤销，服务通常也需要跟着进行迁移，将会导致大量突发流量，广域网的带宽不一定能动态适应，如何从设备层支持服务的快速配置？”

其实为什么不反过来想呢，基于算子的声明式计算和随路同步才是关键，网络需要提供的不是可编程能力，而是可编程计算的能力，具体见10的答案

7.MEC的业务规划从哪里来？

8.计算能力如何在云端配置？

其实这两个问题都是一个问题，如何界定什么应用或者什么算子需要卸载到MEC，有个某司内部拿奖的项目，某司大佬的评价其实说的非常中肯，Close to the source and at natural aggregation point。

9.云边端计算能力如何协同？

本质上是通信模式的变革，原来是云和端的直接通信，现在加了边，然后又要边有智能，多MEC的协同和调度又涉及了Segment Routing调度了，而这些调度资源协作更多的需要端来做，而不是中心云来处理。因为超大规模MEC部署后，再强大的中心云也无法解决极端情况下（例如极端自然灾害下的智慧城市业务）自愈能力。所以去中心化才是关键，更多的利用端的能力和边完成自组织。而通信协议上，伴随着低延迟和安全的需求，QUIC逐渐商用成为标准，QUIC SR才是未来，所以Ruta的设计思路完全符合这样的场景，同时要注意SR的控制面实现要分布式的去中心化交给边和端：

其实很多人对于为什么要利用一个去中心化的协议来重构路由器持有怀疑态度，同时对Ruta的一些底层设计还没有太多的认知。认为去中心化后不就是跟以前没有控制器的时代一样了么？传统的路由器网络通常是一些贪心算法构建的，等同于一个A~n_a_r_c~h~i_s~m状态。而基于控制器的设计方式初期由于A~u_t_o-c-r_a~c~y会带来全网自顶向下决策效率高的优势。

zartbot.Net，公众号：zartbotRuta架构：去中心化的原因

10.MEC有定式么？

没有，但是它会诞生一个很好的计算范式，通信与流计算结合的新范式，本质上是计算范式变成流计算模式后将一些算子卸载到MEC上满足算力/科新/延迟 约束。