浅谈边缘计算在物联网(IoT)当中的运用-电子发烧友网

边缘计算是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。其应用程序在边缘侧发起，产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。目前，许多科技企业已经在边缘计算上开始自己的布局。

未来，我们会看到越来越多的像智慧城市、智能工厂、智能制造、智能零售等一系列创新商业模式，它们在运用物联网技术的过程中，需要用到数据采集、处理、上传数据的边缘端计算设备和网关设备。这些设备或者是相应的解决方案，配合分布式数据库和分布式的数据处理，就构成一个完整的边缘计算体系。但这个体系不是独立存在的，它会跟云计算产生非常多的数据和应用互动。

边缘计算简单架构图

提到边缘计算，我们会联想到秒杀时候，使用CDN进行负载分流；可能也会联想到数据中心和分布式服务器；或者想到数据中心和设备采集网关；或者想到华为AI 神经网络芯片、离线地图，离线语音识别；或者自动驾驶，电动汽车等等……

这边不深入考究边缘计算的概念，具体可以查看维基百科或百度百科

边缘计算的架构图很简单，如下图所示

(图片来源：https://www.zhihu.com/question/35792003?sort=created)

为什么需要边缘计算？

也许你会第一反应是中心计算力不足，网络延迟，数据量庞大，这些都是常见的因素……

数据上涨

随着芯片计算力的发展、硬件成本的降低，加上网路提速，大概每十年一次变革，数据呈现指数级的增长。也许在2020-2030年，通过5G和AI的变革，计算机正在吞噬一切可以数字化的东西，那时候数据的增长不知道会是什么恐怖级别？

显然，这个时候的数据中心，已然无法承担集中式带来的各自延迟，缓慢，痛苦……

成本上涨

为什么边缘计算还能节省成本？

几十万用户的公司，只需要处理百级 QPS 的量，只需要 10 台左右的服务器；

上百万用户的公司，只需要处理千级 QPS 的量，需要有 50 台左右的服务器；

上千万用户的公司，需要处理万级到十万级 QPS 的量，需要 700 台左右的服务器；

上亿用户的公司，其需要处理百万级 QPS 的量，需要上万台的服务器。

以上数据不是完全标准的，但是可以确定的是像BAT，TMD这些大厂的服务器都是以万计算的。

如上图所示，十万用户到上亿用户，用户量也就多 100 倍，为什么服务器需要1000倍？因为，当架构变复杂了后，你就要做很多非功能的东西了，比如，缓存、队列、服务发现、网关、自动化运维、监控等……

如果我们能够把那上亿的用户拆成 100 个百万级的用户，那么只需要 5000 多台机器。

分担计算

海量数据则能够就近处理，大量的设备也能实现高效协同的工作，诸多问题迎刃而解。因此，边缘计算理论上可满足许多行业在敏捷性、实时性、数据优化、应用智能、以及安全与隐私保护等方面的关键需求。

这里举个简单的应用，假如一个项目有5万个设备点，每隔5分钟一次采集，那么一年后的测点数据可能就是100G量级。对这些数据的统计就会是一个耗时耗力的事情。

边缘计算应用场景

既然边缘计算是一种必然，那么边缘计算会应用在哪些场景呢？我觉得至少以下这些场景会用到：

处理一些实时响应的业务。它和用户靠得很近，所以其可以实时响应用户的一些本地请求，比如，某公司的人脸门禁系统、共享单车的开锁。

收集并结构化数据。比如，把视频中的车牌信息抠出来，转成文字，传回数据中心。我们知道大华，海康等主流摄像头设备本身自带车牌识别等功能就是一个典型的应用

实时设备监控。主要是线下设备的数据采集和监控。比如，设备告警、设备联动、设备管理、设备统计等

P2P 的一些去中心化的应用。比如：边缘结点作为一个服务发现的服务器，可以让本地设备之间进行 P2P 通讯。

边缘计算的运用场景还是十分丰富的，还有很多是我们所想象不到的，我们正在期待神经网络芯片助力AI智能，未来的设备必然会更加强大，更加边缘化。

边缘计算的技术？

边缘计算涉及到的技术包括方方面面，这里截取要点分析。

API Gateway相当于一个门卫的角色，和设计模式的Facade（门面模式）很像，是系统的唯一入口。网关可以是一台服务器，也可以是一个比较强大的设备。

网关还可以进行往下分层级，像众星拱月一样，最后通过一个大的门卫作为唯一的入口。这种星型的网关架构可以控制每个子网关或者叫子边缘计算的粒度。当然这种架构也带来更大的复杂度。

一个网关一般包含以下这些组件：服务注册，请求路由，负载均衡，弹力设计，安全管控。此外网关对性能、集群和高可用也是需要考虑的一个要点，对于初创中的团队，这些其实可以放在最后去考虑，后续业务起来后依然是一个必须考虑的重点，比如单点故障导致的所有访问瘫痪，性能低下导致的请求延迟，或者没有使用异步机制导致的吞吐量低下等等……

服务函数化(Serverless)

传统的做法，我们都需要在服务器上持续运行进程以等待 HTTP 请求或 API 调用，而Serverless可以通过某种事件机制触发代码的执行。

"如果说微服务是以专注于单一责任与功能的小型功能块为基础，利用模块化的方式组合出复杂的大型应用程序，那么我们还可以进一步认为 Serverless 架构可以提供一种更加 " 代码碎片化 " 的软件架构范式，我们称之为 Function as a Services（FaaS）。所谓的 " 函数 "（Function）提供的是相比微服务更加细小的程序单元。"——左耳朵耗子

不同于微服务的是函数化更加碎片，而且无需进程等待，这是他的杀手锏。最后推荐两个GO语言的开源框架

openfaas

fission

数据同步

边缘和中心的关系千丝万缕，就物联网来说，中心需要的数据是什么呢？大部分是决策数据，也就是那些官老爷要看的数据，至于设备什么时候告警，什么时候出故障等等数据不一定要实时或者全部同步到中心，也就是说你的数据延迟一段时间并不妨碍，甚至隔天都问题不大。

如果要同步，一般如何做？

通过消息队列写时复制(Wirte And Copy)，这种方式实时性高，有很好的削峰填谷。

通过DB层面发布订阅进行数据同步，这种同步是日志级别的，性能有保障，但是调式有坑，不建议使用。

我所了解的建筑智能化设备设施这个行业，边缘设备只要不是闹人命的故障，比如电梯故障，火灾报警什么的，大部分的业务其实都和钱和安全没有多大关系，也就是对高可靠的依赖是非常弱的。当然不排除医院或者机场等特殊情况。

总结

本文主要探讨了物联网领域的边缘计算这个概念和简单架构图，接着简单介绍为什么需要边缘计算以及边缘计算的使用场景和关键技术。边缘计算和物联网一起兴起，还有很多未知等待探索，一起行动吧……

引用链接：