于是就有人想出了“雾计算”的概念。雾计算简单来说就是在终端和数据中心之间新增一个“网络边缘层”，把一些并不需要或者不马上需要放到“云”的数据在这一层直接处理和存储，这样就可大大减少“云”的压力，同时也提升了传输速率，降低延迟性。由于计算能力较弱，雾计算更多的是提升网络传输的速度。

 

　　不仅如此，雾计算还有高可靠性的优点。为了服务不同区域的用户，相同的服务会被部署在各个区域的雾节点上，比如说智能设备终端本身；这样的话，一旦某一区域的服务异常，用户请求可以快速转向其他临近区域，而云计算一旦遇到网络或者服务器崩溃造成的危害则将要大得多。

 

　　最后就是对于资源消耗的降低。云计算的耗电问题已经被提及了无数次，《纽约时报》几年前曾作出过数据统计，谷歌位于全球的数据中心每年要消耗掉约3亿度的电量，这一数字超过了三万户美国家庭的全年用电量。数据中心的电力消耗已经成为重要成本，其中冷却系统占有不可忽视的比重。雾计算节点因为地理位置分散，不会集中产生大量热量，并不需要额外的冷却系统，从而减少耗电。

 

　　对雾计算的炒作质疑

 

　　从上文中可以看到，雾计算的提出确实从一定程度上解决了云计算的一些顽疾。但是对于“雾计算”仅仅只是一个炒作概念的质疑却甚嚣尘上。这些质疑主要集中在以下几个问题，我们一一来进行讨论：

 

　　（1）增加边缘网络层会增加拥堵

 

　　有人说雾计算的亮点就只是与物联网的结合，而且这个结合的基础，不是计算能力的提高，也不是业务模式的创新，而仅仅是由于传感器的数量增加。并用了一个例子进行说明：原本地铁到机场之间需要公交成来接驳，但随着人员的增多或者有些人赶时间，于是就改用出租车来进行接驳，但出租车数量的增加并不会提升整体的运力，如果数量过于冗余，反而会适得其反。

 

　　这个问题事实上是由于提出的人对雾计算的本质理解不够深刻而导致的。事实上用机场来进行类比，就说明了提出这个问题的人不专业。事实上云计算是一个中心集散地似的存在，而雾计算做的就是一定程度的去中心化，给集散中心减轻负担。用一个企业的决策可以进行类比：云计算相当于是一个企业所有的决策都由总经理来做，这在企业较小的时候是可行的，但是当企业逐渐发展壮大，每天所需要做的决策越来越多，由总经理一个人做决策就有点力不从心，这就需要增加管理层来承担一部分的决策工作，管理层接到员工的需求之后进行判断，如果非常重要的内容就继续上传给总经理进行决策，如果不是很重要的内容就自行决定，不占用总经理的时间。这才是雾计算的本质，并不是增加去机场的出租车，而是阻止一部分人并不需要去机场的人去机场。

 

　　（2）雾计算只是进行了分段传输，并没有解决延时问题

 

　　还有人质疑说“雾计算的本质是在云与本地之间搭建一个中转站，但这一中转中心并没有解决网络带宽的问题，而只是原本的一个一公里变为两个0．5公里，这个中转中心同样会面临因并发的数据传输量的激增导致的网络拥堵。云端的传输速度的问题主要不在于传输的距离、传输的设备，而是主要取决于传输的数据量的大小，传输的数据量越小，传输的速度也就更快。”

 

　　这个问题其实本质上跟一个问题是相似的，雾计算并不是来解决带宽问题的，也并不只是进行了分段传输，虽然表面上是将距离进行了分段，但是其本质在于通过网络边缘层的计算，减少进入后0．5公里的传输压力；同时通过增加和分散传感器减轻前0．5公里的传输压力。雾计算所做的就是减少数据量的传输，从而提高传输的速度。当然“这个中转中心同样会面临因并发的数据传输量的激增导致的网络拥堵。”这句话却没有涉及本质上的问题，因为虽然雾计算能在一定程度上减轻传输的压力，但是它究竟能承受住多大的数据量激增也并不一定，毕竟万物互联的时代，数据量的增长完全超乎我们的想象。

 

　　雾计算在视频技术领域的应用前景

 

　　由于视频监控系统网络化、高清化、智能化的进步，是一个需要传输、处理海量数据的系统，因此雾计算在这个领域也有很好的应用前景。2016年9月，任正非签署了华为与徕卡共同设立麦克斯？别雷克创新实验室的协议。他预计，未来的信息社会将有90％以上的流量来自图像和视频。

 

　　总结

 

　　事实上，对于雾计算抱有“炒作”质疑的人，大多是因为对雾计算不甚了解。这些人更多的或许是一种对新事物的习惯性排斥，当然也不乏一些一边说着“云计算、雾计算、霾计算”，一边不愿意对雾计算做更多了解的调侃。还是那句话，我们要给新生事物更多的包容和耐心，日新月异的世界，我们依据过往知识和经验做出的判断不一定准确。再不济，我们也至少要做到因为了解而发言，对一件事物进行抨击是很容易的，但我们在进行抨击的时候至少要心怀敬畏，不能信口开河。