一、前言
什么是模式？简单说就是一种总结，一种模版，一种标准流程。惯用法-设计模式-架构风格，就是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.
Data from a large number of sensors needs to be collected and analyzed, possibly leading to control actions taken across multiple devices.
但控制聚合，其实与是否多个传感器数据没关系。
可以理解，传感器聚合器和控制聚合器都是个“头”，系统通过“头”，进而把握”头“下面的存在。
简单来说，系统是个Boss，xx聚合器就是TL，xx就是对应TL下的员工。Boss直接从传感器聚合器获取信息，直接将命令下发给控制聚合器。至于这两个聚合器怎么获取数据，怎么进行控制，Boss不管。
7.Multicast（多播）
a.定义
单个事件，发送给多个消费者进行消费（可以是实例内（唤醒判断、数据ETL），也可是实例间（中控、平台））
b.问题
一个事件的发生，往往会处罚多个action。
并且这些action时常变化，如果编码到事件源，则会导致系统耦合度过高。
c.解决
其实就类似架构设计中的事件驱动架构，设计模式中的观察者模式等。
由事件源发出一个消息，感兴趣的消费者可以进行订阅，并执行对应的action。
d.缺点
事件源，到消费并不是可靠的，可能存在丢失。可能需要建立可靠性消费，但这样系统的复杂度和成本就会大幅提升。
另一方面，由于是异步（不考虑同步）消费，消费结果是无法直接反馈给事件源。但可以通过中间状态&事件源采用事件驱动处理进行改善。
e.示例
以工业物联网项目下的中控系统为例。
当报警触发，会发送出对应的报警消息。系统内部会有多处消费，如：
- 通信服务，消费报警信息，进而对目标群体，进行短信推送等。
- 指标展示服务，通过websocket向用户大屏，推送对应的报警消息。
- 控制聚合模块，消费报警消息，触发对应的报警控制传感器，如红灯、蜂鸣等
- 。。。
三、总结
其实看完之后，会发现每个模式都似曾相识，都与以前接触的架构、模式、方法论千丝万缕。就像多播应用模式，设计模式中的观察者模式、架构风格中的事件驱动架构，其实都是一样的。
所以，希望大家在看了这些应用模式后，将它内化为自己的东西，最好能看到各个应用模式背后的架构思想。