You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

146 lines
14 KiB
Markdown

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 09 | 边缘中心:物联网网关有多重要?
你好,我是郭朝斌。
在进阶篇的前几讲我剖析了物联网中跟设备有关的几个技术点包括物模型、设备的零配置组网、设备进行网络通信要用到的MQTT协议等。
但是,并不是所有的设备都能**直接**接入互联网,直接跟云平台通信。比如智能家居中的一些传感器,它们使用的通信技术是 BLE 或者 ZigBee本身连 IP 地址都没有。那么,这样的设备要怎么联网呢?
## 物联网网关:设备和云平台之间的桥梁
这个时候,我们就需要借助**物联网网关**的能力了。举个例子,我主持设计过一个冷库温湿度监测系统,它是基于 LoRa 通信技术的。
我们知道,冷库的环境是非常复杂的。首先,库房内部的**蜂窝网络信号一般都很差**,一方面是因为要增强保温性能,所以墙壁做得比普通的墙体要厚;另一方面是因为库房位置通常位于城市的郊区,比较偏远,所以经常是完全没有网络信号。其次,库房的**信号环境是千变万化的**,因为会出现满仓、空仓等多种情况。
所以,在冷库内部部署的监测设备,如果直接连接蜂窝网络的话,完全不能实现可靠和稳定的通信。
这种情况下,我选择的解决方案就是,在有稳定网络信号的地方部署物联网网关,让冷库里面的监测设备,通过 LoRa 这种穿透能力强、空旷环境通信范围可以达到几公里的技术跟网关通信,从而**间接**地实现设备的联网。
![](https://static001.geekbang.org/resource/image/d6/2b/d6c122e2b43b2c8c9ee860a2945d222b.jpg)
我们可以看到,物联网网关正在成为整个物联网体系中不可或缺的角色。它作为物联网设备与云平台之间的桥梁,变得越来越重要。
## 协议转换:搭建桥梁的关键
那么,物联网网关凭什么能搭建这座桥梁呢?奥秘就在于**协议转换**。其实,刚才智能家居和冷库的例子,就已经体现了这个功能。
BLE 、ZigBee 和 LoRa 设备在跟网关通信的时候,需要网关基于开放的或者内部私有的协议,解析出数据;然后网关再使用跟云平台的连接协议来组织数据,完成数据传输。
这个过程自然就要求网关设备能够支持不同的通信技术。我在下面给出了一张网关通信接口的结构示意图。
![](https://static001.geekbang.org/resource/image/46/1c/46ec62221a9667baab1bb03e42ed691c.jpg)
看这张图跟看地图一样,上北下南,上半部分叫“北向接口”,下半部分叫“南向接口”。这可不是我在生造概念,而是行业内约定俗成的说法。
**北向接口**需要接入互联网,所以通常的选择有 RJ45 以太网口、光纤接口、Wi-Fi 和 4G、NB-IoT等蜂窝网络模组等。
**南向接口**用来连接物联网设备,除了刚说的 BLE、ZigBee、LoRa、Wi-Fi这些无线技术的接口常见的还有用在**工控机**Industrial Personal Computer工业控制计算机上的 RJ45以太网口、RS232、RS485等有线接口。
这里需要注意的是,每个网关设备的接口类型和个数不是固定的,因为网关产品一般会根据应用场景确定几个不同的规格型号。不同型号的网关需要支持不同类型的协议,以及不同个数协议的转换,所以网关的协议转换功能一般采用插件的软件架构方式。
**插件机制**这种二次开发能力非常重要。一方面,它让我们可以根据接口的情况,动态、灵活地配置协议转换功能;另一方面,它也可以方便我们开发私有协议的解析功能。
比如通过 BLE、ZigBee 或 LoRa 技术跟网关通信的设备,它们通常采用的是私有的应用层协议,这就需要我们基于设备架构设计时定义的私有协议,专门编写解析代码。
至于使用 RJ45网口或 Wi-Fi 跟网关连接的物联网设备,除了采用基于 TCP或者UDP的私有协议之外也可能采用我们之前讲过的 MQTT 或者 CoAP这样标准的协议。这时我们就需要按照这些协议的格式来处理。
另外,工控机 和 **PLC** Programmable Logic Controller可编程逻辑控制器中经常使用的标准协议有 Modbus、ProfiBus、OPC UA 和 BACnet 等。如果你在相关行业,可能对它们有一定了解。这些协议也是需要进行转换的,因为它们一般只应用于工业领域。这里我就不展开介绍了,如果感兴趣的话,你可以在 Wikipedia 上查询到详细的资料。
## 网关的其他功能
经过协议转换,网关就得到了通用格式的数据。对于这些数据,网关还需要进行持久化,把数据临时存储起来。
网关的**存储功能**可以防止因网络临时故障等原因,导致设备数据的丢失。另外,网关和设备的配置信息也需要存储在网关中,以便设备运行过程中快速读取。
同时,数据的**安全性**也非常重要,物联网网关需要做好这几个方面的事情:
1. 完善的**本地身份认证**。这样可以防止网关设备被随意修改软件或者数据。
2. 网关保证**数据的加密传输**。因为很多物联网设备的计算能力非常弱,不具备进行数据加密的能力,这时就需要借助网关来保证数据或者控制命令的加密和解密。
3. 网关能够支持**运营商专网接入**,或者支持**VPN**Virtual Private Network虚拟专用网络技术。这里我补充说明一下VPN技术的好处是基于互联网网络建立加密通道。这样既保证了数据传输的安全可靠又比建立专线成本要低。常用的VPN协议有 IPsec、OpenVPN等。
除了我刚才讲到的协议转换、存储功能和安全管理,物联网网关一般还有**设备管理**、**网关配置**、**空中升级**这些功能模块。它们比较容易理解,我就不在这一讲展开介绍了。
到这里呢,我就把**传统**物联网网关的功能都讲解了。看到“传统”两个字,你可能疑惑了:还有现代网关吗?是的,现在有一个趋势就是越来越强调物联网网关的**数据分析处理**能力。
我在第4讲介绍过数据的分析处理。我们知道云计算平台凭借着强大的处理能力、存储能力和极高的性价比已经成为物联网系统的有力支撑。现在的物联网应用系统主要就是基于云平台实现数据分析处理任务的。
## 在网关上做数据分析
既然如此,那为什么我们还要在网关上运行这些计算的任务呢?这是因为随着物联网的发展,海量的设备接入网络,随之而来的,是更加海量的数据源源不断的产生,并上传到云平台。
这就给云平台提出了很大的挑战。一方面是极大地消耗有限的网络带宽资源;另一方面,网络的不确定因素很多,有可能导致不可控的延时,从而对业务应用造成不可接受的影响。
而且物联网数据通常**与物理实体关系密切**。比如家庭监控摄像头中,家庭成员的肖像等视频信息是非常敏感的;而在工业场景中,很多数据是机密的。如果这些信息全部上传到云平台,会给用户带来很大的安全风险。
所以,现在行业内已经开始尝试将云平台上的部分计算服务,下沉到靠近数据发生地的“边缘设备”上进行,这就是**边缘计算**的由来,而物联网网关是边缘计算中**最轻量级**的解决方案的关键。
## 边缘计算的好处
怎么理解这种技术架构上的进化呢?你可以想一想,人体是如何处理各种感知信息的,是不是所有的信息都需要大脑来处理呢?
其实人体神经系统的信号是**分层级**传递和处理的。我们中学上生物课时都做过类似的试验,如果手指放到蜡烛上,手是下意识地快速移开,然后大脑才意识到发生了什么。这是四肢的一种非条件反射,它是由大脑皮层之下的低级别神经系统,如脑干、脊髓,直接控制完成的。它们距离四肢更近,可以保证在危险的情况下,更加快速地做出反应。
![](https://static001.geekbang.org/resource/image/40/45/4051144174eb30fa69a92f3b205f3f45.jpg)
边缘计算的设计,与人体的这个构造类似。边缘设备,比如物联网网关,完成**初步**的数据处理,和**需要及时响应**的计算任务;而云平台负责需要**大规模数据**和**复杂计算**的数据分析工作,以及完成**整体的协调和控制**。
具体来说,云平台将原有的云计算模型的部分计算任务迁移到网络边缘设备上来;网络边缘设备(比如路由器、移动网络基站等),在数据源附近执行数据处理和数据分析任务。这样一来,就降低了云计算中心的计算负载,减轻了物联网对于网络带宽的压力,提高了数据处理的效率。
我将边缘计算模型的好处,总结为四个方面:
1. **延迟低。**数据只需要从产生设备传输到边缘设备,传输距离短,数据不需要通过其他网络,网络延迟低。
2. **节约了主干网带宽。**缓解大量数据传输所造成的网络拥堵想象。尤其像一些银行的专有网络,本身带宽非常有限,只能用于传输关键性的数据。
3. **计算可用性好。**数据在网络中的路径长度显著变短,因网络波动引起的计算服务不可用情况将有所减少。
4. **隐私性更好。**由于边缘设备距离用户近,用户的隐私数据不再需要上传到云平台,因此,在边缘计算场景下,用户的隐私也可以得到更好的保护。
## 边缘计算对网关的影响
技术架构的变化,一般也会对系统提出新的需求。边缘计算对网关的影响,主要体现在三个方面。
首先,为了更好地在网关中运行边缘计算任务,网关需要支持**虚拟化技术**,这在目前的实践中通常是采用**容器技术**实现。容器天然具有轻量和可移植的优点,非常适合开发人员快速测试应用程序,也方便维护人员在网关上大规模部署和更新应用程序。另外,容器技术也更利于网关使用容器自动运维平台技术,比如 Kubernetes来实现应用程序的编排等功能。
其次,因为网络环境的不确定性,网关需要具备一定的**自治能力**。当网关与云平台的通信中断时,这种情况不应该影响网关处理数据的计算任务,和对物联网设备的管理。
最后,因为边缘计算的引入,我们需要在网关侧实现数据分析处理的任务。而网关的硬件资源非常多样,业务需求也千差万别,所以网关上提供统一的**开发框架**变得更加重要。开发框架可以为开发人员提供一致的API 和组件的互操作能力。这样开发人员可以更加高效地实现业务功能,也更容易和其他厂商协作。
这里我把加入边缘计算能力后的网关架构图放在下面,供你参考。
![](https://static001.geekbang.org/resource/image/df/08/dfff704f684838dc0d5d35732d156208.jpg)
## 怎样实现边缘计算?
我知道,你现在最可能提出的问题就是:有什么开源软件可以助力网关实现边缘计算呢?
我简单介绍一下开源的生态,也方便你更好地理解网关的相关技术。
首先说一下**标准化组织**。目前,在推进边缘计算的标准组织主要有三个,分别是:
1. Linux 基金会下的 [LF Edge](https://www.lfedge.org/about/mission/) Linux Foundation Edge和致力于推进Cloud Native的 [CNCF](https://www.cncf.io/)Cloud Native Computing Foundation
2. Eclipse 基金会下面的 [Eclipse IoT](https://iot.eclipse.org/) 项目
3. OpenStack基金会
至于**容器技术**方面的开源项目,主要有 [KubeEdge](https://kubeedge.io/en/) 项目它的主要思路是将Kubernetes从云端扩展到边缘设备方便应用程序在边缘网关上的编排和调度同时实现云端和边缘设备的协同数据处理。
关于**开发框架**,比较知名的是 [EdgeX Foundry](https://www.edgexfoundry.org/) 项目定位是为工业物联网提供通用的边缘计算框架。为此它适配了很多协议提供出标准的API接口。
专门针对**智能家居领域**的项目有 [Home Edge](https://www.lfedge.org/projects/homeedge/) ,它是三星贡献的一个开源项目,用于加速智能家居设备的边缘部署。
## 小结
总结一下,随着物联网应用场景越来越多,物联网网关正在成为“边缘中心”。它成为物联网的**“云、边、端”架构**(即云平台、边缘、终端三部分)中非常重要的组成部分。你在做物联网网关的架构设计和功能开发中,需要重点关注的内容有:
1. 物联网网关是设备与云平台之间的桥梁,网关的南向接口和北向接口都非常多样。因此协议转换功能是必须包含的功能。它保证了物联网设备数据的可靠上传,和云平台控制命令的有效执行。
2. 关注网关基础功能的实现。这些功能包括存储功能、安全管理、设备管理、网关配置和空中升级这些功能模块。它们既保证了数据的安全和可靠传输,也为远程维护提供了支持。
3. 你需要根据业务场景决定网关对于边缘计算的支持能力。边缘计算对于物联网网关的架构有3个方面的影响
1 容器技术。容器技术的应用利于开发人员快速开发、测试应用程序,也方便维护人员在网关上大规模部署、更新应用程序。同时,基于容器自动运维平台技术可以实现应用程序的编排等功能。
2自治能力。它可以保证网络环境不稳定时网关的数据分析处理任务的正常执行。
3开发框架。开发框架利于开发人员的开发工作也有益于各部分组件的协同互操作。
## 思考题
最后,我还是给你留一个思考题。
边缘计算已经成为物联网的必要组成部分,行业内云计算企业、网关设备商、运营商都积极参与推进技术体系的发展。那你有使用这些边缘计算产品吗?应用在什么业务场景呢?
欢迎你在留言区和我交流,也欢迎你将这一讲分享给你的朋友一起讨论学习。