CN108259197A - 一种基于物联网应用需求的雾计算架构模型 - Google Patents

Abstract

本发明涉及一种雾计算架构模型，其特征在于：包括物节点、雾节点和云节点，每一个雾节点部署在任何具有网络连接的地方，一个云节点服务于多个雾节点；一个雾节点服务于多个物节点。本发明针对雾计算架构的实际应用场景进行调整和改进，增强了雾计算在物联网实际应用场景中的针对性和可控性。

Description

一种基于物联网应用需求的雾计算架构模型

技术领域

本发明涉及雾计算领域，特别涉及一种基于物联网应用需求的雾计算架构模型。

背景技术

目前，物联网技术发展势头十分迅猛，每天都有数以亿计的设备，每天产生超过两个艾字节的数据。据估计，截至2020年，超过500亿的“物”将联网。如此，物联网将产生数据的数量和种类，都达到了史无前例的规模。如果，运用传统云计算的方式，将这些数据都送到云端处理，则需要耗费巨大的带宽。所以，一种新的分析和处理物联网数据的模型：“雾计算”，就应运而生了。

目前的云计算模型，对于物联网数据的容量，种类和速率，没有进行足够的分析和设计。数以亿级的新“物”也代表了各种物体类型。这些“物”，有的需要使用工业协议连接到控制器上，可能不是IP协议。但是，当需要送达云端进行分析或者存储时，必须先转化为IP协议。

为了应对技术挑战，物联网设备不断地产生数据，分析数据的过程也必须很迅速。比如化工厂的仓库中，温度数据在接近临界值时，必须立即采取行动。但是，数据必须发送到云端进行处理，这样的过程，会浪费绝佳的处理时机。以前，广泛流行的方法，将所有的数据从网络边缘，移动到数据中心来处理，增加了延时。因为设备数量的剧增，所以带宽容量很快被耗尽。工业法规和隐私问题，使得这些数据不能在设备外存储。还有，云服务器智能通过IP通信，而不是其他物联网通信协议。所以，处理大部分物联网数据的最理想地点，是靠近产生数据的设备的地方。这就带来了“雾计算”。

“雾计算”扩展了云计算的概念，离产生数据的设备更近。目前雾计算概念虽然已经提出来很长时间了但是还没真正具体的实际应用。

发明内容

鉴于上述问题，本发明在提出的雾计算概念的基础上，针对实际物联网云雾混合计算实际情况场景需求，对雾计算模型体系结构进行改进，以便提供一种克服上述问题或至少部分地解决上述问题的雾计算架构模型。

一种雾计算架构模型，其特征在于：包括物节点、雾节点和云节点，每一个雾节点部署在任何具有网络连接的地方，一个云节点服务于多个雾节点；一个雾节点服务于多个物节点。

进一步的，所述每一个雾节点还可以部署在任何具有计算，存储和网络连接性的设备上。

进一步的，在实际应用中，主要有下述4中应用情况：所述物节点与所述云节点互动；所述雾节点与所述云节点互动；所述物节点与所述雾节点互动；以及所述雾节点与所述物节点和所述云节点互动。

进一步的，所述雾节点与所述云节点互动具体包括：所述雾节点使用所述云节点补充其所需要资源，使用云存储进行备份或存储很少用到的数据；使用云中的虚拟机来处理峰值负载；使用云中的应用程序来处理所述雾节点的数据；将云数据库用作某一应用程序处理过程的一部分，与其他雾节点共享云数据库。

进一步的，所述物节点与所述雾节点互动具体是指：所述雾节点是局部范围所有物节点的处理中心、管理中心和应用中心。

进一步的，所述雾节点与所述物节点和所述云节点互动具体包括：所述物节点的编码信息被发送到所述雾节点，所述雾节点访问存储于云节点上的对象命名服务以及配套服务，找到该物品信息所存储的物理位置，然后由所述雾节点给应用系统指明存储该物品有关信息的服务器，并将文件中关于该物品的信息进行传送和应用，所述雾节点起到过滤、处理和联通所述物节点与所述云节点的互动信息。

进一步的，所述多个雾节点各自独立，每个雾节点从物理或逻辑上可包含多个计算位置，既包括应用服务的计算环境，也包括代表各种身份角色的资源中心、管理与控制中心。

进一步的，所述雾节点之间的交互协作既可以是基于Web的远程通信方式，也可以是由于位置改变而进行的局部交互；所述雾节点之间的用户可以访问本地和远程云服务中心资源，且计算环境可以改变，从而带动其位置和依赖这个位置的服务一起移动。

进一步的，所述雾节点网络的拓扑结构包括星形拓扑结构、总线形拓扑结构、环形拓扑结构、树形拓扑结构、网形拓扑结构和混合形拓扑结构。

进一步的，所述星形拓扑结构是指每个节点都由一条单独的通信线路与中心节点连结；

所述总线形拓扑结构是指将网络中的所有设备通过相应的硬件接口直接连接到公共总线上；

所述环形拓扑结构是指各结点通过通信线路组成闭合回路，环中数据只能单向传输；

所述树形拓扑结构是指结点按层次连结，信息交换主要在上下结点之间进行，相邻结点或同层结点之间一般不进行数据交换；

所述网形拓扑结构是指节点之间的联结是任意的，没有规律；

所述混合形拓扑结构是指两种或两种以上的拓扑结构同时使用。

本发明针对雾计算架构的实际应用场景进行调整和改进，增强了雾计算在物联网实际应用场景中的针对性和可控性。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一种实施例的雾计算架构模型的结构示意图。

图2为本发明另一种实施例的雾节点的拓扑结构示意图。其中，图2(a)为星形拓扑；图2(b)为总线形拓扑；图2(c)为环形拓扑；图2(d)为树形拓扑；图2(e)为网形拓扑；图2(f)和图2(g)为混合形拓扑。

具体实施方式

为便于对本发明实施例的理解，下面将结合附图以几个具体实施例为例作进一步的解释说明，且各个实施例并不构成对本发明实施例的限定。

如图1所示，一种雾计算架构模型，包括物节点、雾节点和云节点，其中，一个云节点(公共云)服务于多个雾节点；一个雾节点服务于多个物节点，每一个雾节点部署在任何具有网络连接的地方，比如，雾结点可以部署在工厂地板，电线杆，铁轨旁，汽车内，或者钻油平台上。进一步的，每一个雾节点还可以部署在任何具有计算，存储和网络连接性的设备，比如，雾结点可以部署在工业级的控制器，开关，路由器，嵌入式服务器，和视频监控摄像头上。物节点可能是一个私有云环境，也可能不是云，而是具体的物，与现有物联网环境中的物节点概念相同。

在实际应用场景中，会出现如图1所示的4中应用情况：

(1)物节点与云节点互动

描述物节点与云节点互动的情况，是在物联网早期阶段最常见的基于智能终端的物联网用例。智能终端可以轻松访问云节点，使用云端的计算、存储和数据服务。

(2)雾节点与云节点互动

描述雾节点与云节点互动的情况，雾节点使用云节点补充其所需要资源，使用云存储进行备份或存储很少用到的数据；使用云中的虚拟机来处理峰值负载；使用云中的应用程序(SaaS)来处理雾节点的数据；将云数据库用作某一应用程序处理过程的一部分，与其他雾节点共享云数据库。

(3)物节点与雾节点互动

描述物节点与雾节点互动的情况，也是在物联网早期阶段最常见的局部RFID物流信息管理的用例。雾节点是局部范围所有物节点的处理中心、管理中心和应用中心。

(4)雾节点与物节点和云节点互动

描述雾节点与物节点和云节点互动的情况，物节点的编码信息被发送到雾节点，雾节点访问存储于云节点上的对象命名服务以及配套服务，找到该物品信息所存储的物理位置，然后由雾节点给应用系统指明存储该物品有关信息的服务器，并将文件中关于该物品的信息进行传送和应用。雾节点起到过滤、处理和联通物节点与云节点的互动信息。

作为上述实施例的进一步改进，本发明的雾计算架构模型可被看作为是由多个独立的雾节点(Fog Node)组成的系统。每个节点从物理或逻辑上可包含多个计算位置，既包括应用服务的计算环境，也包括代表各种身份角色的资源中心、管理与控制中心。对于用户而言，节点之间的交互协作既可以是基于Web的远程通信方式，也可以是节点由于位置改变而进行的局部交互；节点之间的用户可以访问本地和远程云服务中心资源，且计算环境可以改变，从而带动其位置和依赖这个位置的服务一起移动。但是，用户的资源中心处于相对稳定的安全域内是不变的。

每个雾计算节点是上述服务体以及包含这些服务体的普适环境。这种环境更多地是指空间，既可以是网络中的物理位置，还可以是逻辑或概念空间。因此，该抽象模型实际上是关于服务体、位置以及它们之间的关系和关系变化的模型。位置、服务体、移动性、资源访问是雾计算系统的关键概念。其中，位置与服务体是核心概念。

雾计算节点之间的拓扑结构与网络拓扑结构一样，应该在具体实际场景应用中具有树型、环型和星型等常见结构。如图2所示，给出了多种雾结点的拓扑结构示意，其中A、B、C、D、E、1、2、3、4、5、6、7、8等均为雾节点，以方便各种实际应用，雾节点网络的最主要的拓扑结构有总线型拓扑、环形拓扑、树形拓扑、星形拓扑、混合型拓扑以及网状拓扑。其中环形拓扑、星形拓扑、总线型拓扑是三个最基本的拓扑结构。在局域网中，使用最多的是星形结构。

具体的，星形拓扑结构的每个节点都由一条单独的通信线路与中心节点连结；总线形拓扑结构是将网络中的所有设备通过相应的硬件接口直接连接到公共总线上；环形拓扑结构各结点通过通信线路组成闭合回路，环中数据只能单向传输；树形拓扑结构是一种层次结构，结点按层次连结，信息交换主要在上下结点之间进行，相邻结点或同层结点之间一般不进行数据交换；网形拓扑结构又称作无规则结构，节点之间的联结是任意的，没有规律；混合形拓扑结构就是两种或两种以上的拓扑结构同时使用，优点是可以对网络的基本拓扑取长补短，缺点是网络配置挂包那里难度大。这样每个雾计算节点既能作为独立的服务提供者，又能与其他雾计算节点一起通过MPI(Message Passing Interface)协同工作，实现分布式的云计算。

本发明在物联网实际应用场景环境中，明确了雾计算与物联网之间的关系，可对于日后雾计算的实际应用发展起到很大的促进作用，增强了物联网雾节点等方面的实际应用性。另外，本发明考虑到了各种雾节点拓扑结构，雾节点网络的拓扑结构反映出物联网中单个雾节点实体的结构关系，是建设雾节点网络的第一步，是实现各种物联网网络协议的基础，它对物联网网络的性能，系统的可靠性与通信费用都有重大影响。本发明的雾节点在实际应用中考虑增加拓扑结构，这样有助于对雾节点的控制更加简单、故障诊断和隔离容易、方便雾节点服务并易于扩展。

本领域普通技术人员可以理解：附图只是一个实施例的示意图，附图中的模块流程并不一定是实施本发明所必须的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种雾计算架构模型，其特征在于：包括物节点、雾节点和云节点，每一个雾节点部署在任何具有网络连接的地方，一个云节点服务于多个雾节点；一个雾节点服务于多个物节点。

2.根据权利要求1所述的一种雾计算架构模型，其特征在于：所述每一个雾节点还可以部署在任何具有计算，存储和网络连接性的设备上。

3.根据权利要求1所述的一种雾计算架构模型，其特征在于，在实际应用中，主要有下述4中应用情况：所述物节点与所述云节点互动；所述雾节点与所述云节点互动；所述物节点与所述雾节点互动；以及所述雾节点与所述物节点和所述云节点互动。

4.根据权利要求3所述的一种雾计算架构模型，其特征在于，所述雾节点与所述云节点互动具体包括：所述雾节点使用所述云节点补充其所需要资源，使用云存储进行备份或存储很少用到的数据；使用云中的虚拟机来处理峰值负载；使用云中的应用程序来处理所述雾节点的数据；将云数据库用作某一应用程序处理过程的一部分，与其他雾节点共享云数据库。

5.根据权利要求3所述的一种雾计算架构模型，其特征在于，所述物节点与所述雾节点互动具体是指：所述雾节点是局部范围所有物节点的处理中心、管理中心和应用中心。

6.根据权利要求3所述的一种雾计算架构模型，其特征在于，所述雾节点与所述物节点和所述云节点互动具体包括：所述物节点的编码信息被发送到所述雾节点，所述雾节点访问存储于云节点上的对象命名服务以及配套服务，找到该物品信息所存储的物理位置，然后由所述雾节点给应用系统指明存储该物品有关信息的服务器，并将文件中关于该物品的信息进行传送和应用，所述雾节点起到过滤、处理和联通所述物节点与所述云节点的互动信息。

7.根据权利要求1所述的一种雾计算架构模型，其特征在于：所述多个雾节点各自独立，每个雾节点从物理或逻辑上可包含多个计算位置，既包括应用服务的计算环境，也包括代表各种身份角色的资源中心、管理与控制中心。

8.根据权利要求1所述的一种雾计算架构模型，其特征在于：所述雾节点之间的交互协作既可以是基于W eb的远程通信方式，也可以是由于位置改变而进行的局部交互；所述雾节点之间的用户可以访问本地和远程云服务中心资源，且计算环境可以改变，从而带动其位置和依赖这个位置的服务一起移动。

9.根据权利要求1所述的一种雾计算架构模型，其特征在于：所述雾节点网络的拓扑结构包括星形拓扑结构、总线形拓扑结构、环形拓扑结构、树形拓扑结构、网形拓扑结构和混合形拓扑结构。

10.根据权利要求9所述的一种雾计算架构模型，其特征在于：

所述星形拓扑结构是指每个节点都由一条单独的通信线路与中心节点连结；

所述总线形拓扑结构是指将网络中的所有设备通过相应的硬件接口直接连接到公共总线上；

所述环形拓扑结构是指各结点通过通信线路组成闭合回路，环中数据只能单向传输；

所述树形拓扑结构是指结点按层次连结，信息交换主要在上下结点之间进行，相邻结点或同层结点之间一般不进行数据交换；

所述网形拓扑结构是指节点之间的联结是任意的，没有规律；

所述混合形拓扑结构是指两种或两种以上的拓扑结构同时使用。