物联网的应用模式

最新推荐文章于 2023-09-26 07:13:09 发布

血夜之末

最新推荐文章于 2023-09-26 07:13:09 发布

阅读量1.8k

点赞数

分类专栏：架构文章标签：物联网架构

本文链接：https://blog.csdn.net/cureking/article/details/120028001

版权

架构专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、前言

什么是模式？简单说就是一种总结，一种模版，一种标准流程。惯用法-设计模式-架构风格，就是IT这边常见的三层模式。至于应用模式，我的理解是特定应用领域下的模式。

由于物联网的特性，其有很多应用模式。这些应用模式并不是专属于物联网应用领域，而是在物联网应用领域，放大了这些应用模式的效果与价值。

简单说一下，文章中提及的工业物联网项目下的风机监测。
工业物联网项目下的风机监测系统，是通过一系列传感器检测风场诸多风机的状态，比如是否存在倾斜倒塌风险。

二、应用模式

1.Interpolation（插入）

a.定义

通过某网络的周边节点数据，确定中间节点数据

b.问题

一个在时空上连续分布的数据，由于网络波动等原因，缺少部分分布点的数据。

c.解决

由于时空分布的连续性，某个点的数据不可能出现突然猛然增降（如果真的有，大概率也被视为异常数据，进而被清洗了），所以可以通过该点周边的数据平滑地推断出该点的数据。

d.缺点

缺点无非两点：数据可信性、方案落地的要求
前者，由于有部分数据并不直接来自于实际采集，必然导致最终结果的一定程度失真。
后者，这个方案的落地，必须确保这些时空分布点的关联性足够强，尤其是时空点的分布并不是足够密集时。

e.示例

以工业物联网项目下的风机监测系统为例。
时间：就单个风机，如果倾斜传感器采集频率为10/s，那么连续1分钟内的数据只有590，那么也是可以接受的。甚至这些数据只有300个，只要数据丢失呈现均匀分布，而不是断崖式的，那么也是可以接受的。只是后续，需要让技术确定为什么采集数据少了这么多。囧
空间：同样就单个风机而言，即使在一个小时内某个倾斜传感器没有采集数据，但其他部位的倾斜传感器工作正常，那么可以通过其他传感器，推断出这个故障传感器的数据。进而保证上层程序正常运转。

2.Sensor Facade（传感器装饰）

a.定义

通过中间服务，将传感器原始数据，转换为可读性更高的数据。接耦，带来硬件升级的成本降低

b.问题

传感器型号众多，从通行协议，到交互方式，差异性较大。尤其一些型号的传感器，可能突然就不生产了。

c.解决

类似于设计模式的Facade模式，通过一个Facade层，屏蔽具体硬件型号带来的差别，为上层提供统一的数据模型。

d.缺点

每种传感器都需要建立对应的facade，并且统一的数据模型的抽象决定了这层Facade的上限。
至于每层facade的新增开发量，就取决于facade的抽象设计水平了。

e.示例

以工业物联网项目下的风机监测系统为例。
该系统的倾斜传感器有五种，后续还要支持更多传感器类型。这些传感器来自不同的厂家，有的使用mqtt协议，有的使用自定义二进制协议，采集的数据也存在差异（是否有温度采集）。
为了避免影响到上层应用，所以在终端服务器（网关层）进行了Facade处理。通过抽象的二进制协议解析&交互模块和Mqtt交互模块，将不同传感器的数据进行处理，最终获得一个统一的倾斜数据模型，供上层应用使用。

3.Cache（缓存）

a.定义

当传感器数据被异步获取/发送时，可以将缓存的数据返回，进而提高性能，避免重新采集/生产数据。

b.问题

传感器数据的被访问频率，与传感器采集频率不同步，或者传感器数据被多个消费者异步消费。

c.解决

传感器数据采集/处理完毕后，将结果数据置入一块缓存。在数据尚未缓存失效期间，外部（其他传感器/服务节点）请求数据时，直接返回缓存中的数据。

d.缺点

仅适用于异步数据交互，异步处理复杂度相对高一些。

e.示例

以工业物联网项目下的风机监测系统为例。
该检测系统有一个震动传感器的数据采集，由于震动数据的特殊性，所以必须是连续的高频采集。比如一天采集十分钟长度，频率为1000HZ的数据。这份数据采集后，会有三个数据流出向：

交由算法程序处理，计算结果储存到数据库中
将转化后的数据进行存储，便于后续算法优化
上层应用可能会扫描到该数据，用于上层使用（如展示等）
当时的解决方案，就是本地通过文件系统缓存原始数据，消费者（算法、转换程序、上层应用）通过异步扫描的方式获取该数据。每天创建对应缓存文件后，会清理一天前的缓存文件。

4.Gateway（网关）

a.定义

整个系统出入流量的“总闸”。实现安全传输，以及相关协议转换（利用Interpolation、Sensor Facade等）

b.问题

用户请求格式、协议存在很大差异。每个微服务都需要进行请求格式转换、协议转换，并对返回进行处理。
与此同时，每个微服务都需要实现完整鉴权，确认请求权限。并且由于每个微服务都暴露在外网，系统安全性大大降低。
而这一切，带来了性能降低、成本提高、安全性降低等一系列问题。

c.解决

系统进出流量，统一经过网关，由网关作为edge service，进行系统内外的交互。
一方面由于网关隔绝了系统内外，大大提高系统内其他服务的安全性。
另一方面由于所有流量都经过网关，所以请求&响应的统一处理可以交由网关处理，如协议转换，格式转换、安全传输等。

d.缺点

系统增加了一个可能的新性能瓶颈-网关。这包含了网关所带来的性能瓶颈，以及网关的单点故障考量等。
作为系统的基础组成，网关的设计影响了系统的安全，性能等。不合理的网关设计，反而会带来耦合，进而提高系统的复杂性。

e.示例

以工业物联网项目下的云平台为例。
云平台，采用了网关，进行协议转换，以及鉴权等。
协议转换：由于存在传感器将原始数据直接上传云平台，所以云平台需要协议转换模块，进行内容的转化。
鉴权：通过网关统一对传感器、用户的权限校验，内部服务进行“裸奔”。而部分敏感操作，有对应服务进行二次权限校验。

f.扩展

网关是一个逻辑概念，并不是类似路由器这样的物理存在。而在应用中，可能被拆分为多个组件。
这里要说一下，之前小伙伴问我XXX集团的网关是什么组件，是不是Spring的gateway。说实话，就是没有理清这里的概念。网关虽然是功能上一个整体概念，但落在应用中，可能是由多个组件组成。而SpringCloud的gateway等，只是一个较为成熟的落地方案，可以理解为一个用于快速应用的脚手架。比如在XXX集团里的统一接入层，包含了网关的功能，包含CDN、LVS、XXX（类似Nginx）、鉴权平台、无线接入平台等等。

5.Sensor Aggregator（传感器聚合器）

a.定义

往往上层服务所需信息，不只是在一个传感器中体现，而是在多个传感器的聚合信息中。

b.问题

物联网某个“物对象“的状态/某个指标，是由多个传感器数据聚合而来。如果平台接受所有传感器数据，这个数据量就超出了当前系统的承受量。

c.解决

物联网某个“物对象“的状态/某个指标，可通过对相关的多个传感器采集数据聚合而来，再将聚合后的结果，上传至平台。

d.缺点

需要对多个传感器数据进行聚合，可能需要对应聚合算法
末端的单个传感器，往往缺乏多个传感器的数据聚合能力，所以可能需要额外的硬件，进行数据聚合。
由于聚合方式&算法的缘故，可能聚合结果存在一定程度的失真。

e.示例

以工业物联网项目下的风机监测系统为例。
风机的倾斜指标，是由塔顶倾斜与塔底倾斜组成。不同部位的倾斜是由三个倾斜传感器的数据，通过算法聚合而来

空间三个维度分别对应一个传感器，进而获得较为精确的结果。感兴趣的小伙伴，可以自己计算哈。

f.扩展

数据聚合并不仅仅针对于“物对象”的单个指标，也可以直接针对“物对象”。具体粒度取决于业务需求，以及技术限制等。

6.Control Aggregator（控制聚合器）

a.定义

通过对传感器&传感器集合数据分析，进行决策，进而对控制集进行操作

b.问题

一方面一个事件的处理，往往会涉及多个控制传感器的处理（亮灯、起落架抬起等）。另一方面，每次相关事件处理，都需要调用多个控制传感器。

c.解决

通过定义控制聚合器，由控制聚合器，调用对应的多个控制传感器。

d.缺点

控制聚合器往往是单独的硬件（部分情况下为逻辑模块），需要额外处理。另一方面控制聚合器不太容易进行变更，如变更所属控制行为。

e.示例

以工业物联网项目下的中控系统为例。
工业物联网的中控系统，存在报警控制聚合器逻辑模块。一旦系统触发对应报警，则由报警控制聚合器触发对应的蜂鸣器、红灯等。

f.扩展

多个控制行为的聚合，如触发报警，会涉及红灯、蜂鸣、弹窗等
我认为原文档这部分描述不够好。原文是：

The Control Aggregator pattern uses analysis performed on the collected information of multiple sensors to create actions that may occur on multiple control points to achieve a desired outcome.