从今天开始笔者跟大家探讨一个万物互联领域最近几年比较火的概念-边缘计算，乍一看这个名字会让人感觉跟当年的刚出现云计算一样，老瓶新装的东西。那是不是这样的呢？在正式引入边缘计算这个概念之前，我们先暂且不去在意这个名字。先从现实的场景入手，分析一下现在依然红的发紫的云计算是否可以解决时下的万物互联的问题，有哪些问题是无法解决的，而这些无法解决的问题是否有解决的方案。
1、万物互联时代新挑战
不是有句名言“只要站在风口猪也能飞起来”，每一项新技术的革命和兴衰都是跟时代紧密相连的，所以照例，我们先看看时下我们所处的时代特征。当前我们正处在移动互联网的鼎盛时代，如果说在这个时代关键的技术和产品，那就是云计算、4G通信和手机，云计算带来了集中的计算力，大数据分析能力；4G通信则带来了超大的带宽，随时随地的上网连接；手机则已经变成我们日常生活必不可少的一部分。借助于这些技术和产品，我们可以随时随地的解决衣食住行的各种问题，但实际上它们人为中心，围绕人的需求，解决人的衣食住行等各类消费诉求，比如说支付宝、美团、滴滴、抖音等。这些技术不过将原来的PC扩展为手机、平板、手表等各类智能设备，本质上并没有发生太大的改变，主要带来消费类产业的升级。
万物互联时代，这一切将变得完全不一样，将会带来垂直产业的深刻变革。传统行业已经无法适应当前的时代趋势，无法创造更大的社会价值，在生态，能源等各个方面已经无法适应时代要求，所以需要谋求新的产业升级和数字化转型，会有海量的设备入网。如上图所示，是两个时代不同的对比图。在万物互联时代，不再仅仅局限于消费类产业升级，会涉及到千行百业，比如智能交通、智慧城市、自动驾驶、智能机器人、智能监控等等。首先从连接的视角看，手机已不再是主要的连接对象，我们日常生活中的路灯、智能电表、水表摄像头、汽车、路面等等都会连接上网，图中列举出的只是很少的一部分，按照万物互联的愿景将会有万亿级的设备接入，这样的接入量是不可想象的。
海量的接入设备势必会诞生海量的数据，如上图所示，有相关的统计，在移动互联网数据数据量在PB级别，而到了万物互联时代，随着入网的设备呈指数型增长，这个数据量变为ZB级别，这些数据需要进行传输、存储和计算，现在的移动互联网的云计算架构能否承受是值得商榷的。在时延方面，移动互联网时代的云计算，在处理的时延上并没有特别严格的要求，20~30ms的时延需求也是可以的，但是在万物互联场景下，连接的设备如自动驾驶、AR、还有时下炒的火热的元宇宙，要想能实现完全的自动驾驶、不需要人接入、还有完全的浸入式体验，这些都需要有超快的响应速度，当前估算的起码要到1ms的级别。除了时延的要求，上面的设备特别是元宇宙还会产生大量的数据，这些数据需要上网入云，在移动互联网时代只能提供GB或者10GB的带宽，但是这种场景下就需要TB的数据传输量了。最后就是数据的安全和隐私，在移动互联网时代，所有的核心设备都集中在云侧，上传的数据也是用户可控的，但是万物互联时代，设备很有可能在用户不可知的情况下就把数据自动送到云端了，因此对于这样的风险，对于万物互联，需要更高的数据安全和隐私保护的策略。
2、云计算架构的局限性
面对海量的连接，当前的网络的表现如何呢，我们知道当前的网络是基于移动互联网的应用场景搭建的，连接的主要设备是手机、电视、PC等设备，因此其扩容的速度也是根据这些设备的数量有序增长的。来到万物互联场景，连接的设备势必会远远超过当前的网络承载能力，特别是核心网，扩容的速度很难赶上指数级的数据增长规模。 面对海量的数据，万物互联的场景，会有更多样的接入协议，更多的接入设备，如果所有的设备的数据都送到一片云上，数据量就会撑爆那片云，云端的服务器需要指数级的扩展，很明显这样的扩展规模对任何一家云提供商来说都是无法承受的，此时就需要一种新的计算模型或者架构去分担这些数据的处理。
当前的云计算架构能否满足时延要求呢。因为在数据上送时需要经过一段很长的传输路径，才能送到数据处理中心，当前的基础网络架构就是这样的一种拓扑结构，需要逐跳寻址，数据的产生的终端距离云可能有很长的距离，几公里甚至是几千公里，网络也会时常出现拥塞，网络时延是不可控的，所以会有超长的时延。超长的时延，在自动驾驶场景，危险发生时还没有反应过来，在佩戴AR头盔或者眼镜时会出现眩晕。再来看看数据隐私和安全，因为万物互联的设备通常是不受控的场景下上传数据，所以很容易将个人敏感数据送到云端，虽然云端有很强的安全设备和团队去保障安全，但是也非常容易吸引黑客去窃取大量的数据，百密总有一疏，万一黑客攻破了云设备的安全防护网，其造成的损失非现在可比拟的。因此需要一条新的思路，不要所有的鸡蛋放到一个篮子里，这样诱惑也大，风险也高。
当前很多的基础网络设备和云计算设备，为移动互联网时代搭建的，不可能推倒重来，那成本是无法预估的，也不现实，肯定要按照事物的演变规律去扩展，因此我们可以顺着这个思路往前前进一小步。
3、朴素解决方案
面对海量的数据暴增，不要将所有的计算压力都让云去承担，学会去分担压力，既然集中的方式压力太大，那就用分散的方法，将大量数据就地处理解决，需要上报的数据再上送到云端。这样当需要大数据分析的时候，云端也能提供，当需要做小数据分析的时候，就由本地自己解决，云的担子一下子就轻了很多。面对时延的问题，是因为要传很长的距离才能送到云上，那我们是否可以不把数据都上传到云端，是否可以在本地或者局域网范围内就把时延敏感数据处理了，只让少量的对时延不敏感的数据上送到云端，这样不就可以把网络上传的那部分时延问题解决了。
面对海量的连接问题，同样的现行的网络无法承载这种指数型增长的连接需求，那是否可以不要将所有的连接都指向云计算中心，让这些接入的设备分散连接，分散地处理数据，这样对于现行核心网络的冲击是最小的，也能很方便地将对设备的接入进行扩展。面对数据的隐私和安全问题，万物互联的很多连接和上传处理的数据是不受个人的控制的，很有可能会把敏感数据送到了不知道哪片云上，然后不知道哪天就在那片云上原地爆炸。因此我们不希望将个人敏感的数据上送到云，就可以就地存储，这样起码可以知道数据在哪里，隐私被暴露的风险也会降低许多。
好了，这就是针对前面提到的4个核心问题，我们想到的朴素的解决方法，如果我们将这些解决问题的方法稍微进行技术化的改造，不就可以有了一个好的解决方案。笔者顺着这个逻辑总结的图示如下。
既然云是集中式的，那我们是否可以将这种架构改成分布式的，不要将所有的计算压力都放到云端，应该分散到各个小的计算中心，再将小的计算中心合成大的计算中心，这样一级一级的做汇聚，就可以在很大程度上降低对云的依赖，海量的数据处理问题在在架构层面上也就得到了解决，我们称之为架构下沉，云计算也从遥远的地方来到了靠近设备的边缘，我们称之为云边缘吧，读者不必纠结这个概念，就只要知道这个云计算来到了网络边缘设备上。
上面是将整片云下沉到了边缘设备上，但是有些场景下，我们并不需要将整片云沉下来，而只需要将部分资源沉下来，就可以解决问题。就拿前面提到的时延问题来说，就可以在本地将时延敏感数据处理了，而这就只需要将云上的计算资源下沉下来即可。AI/应用相关的计算资源可以根据自己的场景需求，来到对应的边缘设备上，在本地上报数据后立刻计算处理，给出响应结果。简单举个自动驾驶多辆车相互感知的例子，如果将每辆车的数据送到云端再去处理，则时延上肯定满足不了要求，但是如果我们将数据就在路边设备或者5G基站上就处理了，那问题也就迎刃而解。
继续看另外一个高带宽的问题，因为有大量的设备接入，上行的带宽就会撑爆核心网资源，前面我们将云下沉到边缘设备上了，那核心网如果也跟着下沉，对之前已经存在的核心网的冲击是不是就会降低。实现上只需要将边缘设备组成一片小的云，然后在这片小的边缘云上加入新的接入设备，并通过将核心网下沉下来，就可以在这片小的边缘云上实现需求，多片这样的小边缘云就可以将核心网的压力分解下来。还是举个例子，为了实现自动驾驶感知周围环境，会在路边放置很多传感器（路面情况、路边距、路面承载能力、路面湿滑程度），还会有现有的路灯、交通灯、摄像头、基站等非常多的设备，这些传感器会实时产生大量数据，跟车辆通信，此时可以将一个基站作为边缘设备，将数据放到基站处理，各个基站之间构成一朵边缘云，保证在不同路段的车和路的通信，数据就近处理，因为是时效性的数据，处理完就没有用了，完全没必要送到云端去占用网络资源。
最后就是数据隐私的问题，既然将数据送到云端被暴露的风险更高，那我们的隐私数据就可以不放到云端，在本地进行存储。因此我们可以把存储资源下沉下来，将设备的敏感数据就近存储。并不是说数据被存到了本地就一定是安全的，相反因为本地的存储、安全等各种资源的受限，跟云端有专业的设备和团队去维护和保障，可能被攻击的风险更大。但是攻击的价值可能就降低了，因为分散的存储隐私数据，对于黑客来说要逐个攻破，每次获得的隐私数据也是很少的，价值不会很大，不像云端动则几千万上亿的隐私数据，有巨大的价值驱动力。还是举个存储资源下沉保障隐私的例子，我们的智能家居的入口现在很多都在布局智能音箱，摄像头等，这些数据其实只要离开家庭，被送上云，对我们来说就是很恐怖的事情，说不定哪天自己的隐私就被“送上头条”，如果我们将这些数据就在本地存储，心理上比较容易接受，起码没有被送到不知道哪片云上。
上面的4个解决方案，总结起来就会发现几个关键词：分布、就近、边缘侧、资源下沉（架构、计算、存储、网络），没错这也是边缘计算定义中最为核心的几个关键字，下一篇我们会看到边缘计算在学术界和工业界的定义，就会发现边缘计算不过如此。
未完待续...
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）