做物联网平台相关的工作已经快两年了，对这其中技术平台搭建仍旧有一些“不清不楚”、或者“一知半解”，写这个文章以此来梳理一些思考并做一些总结；
这里先不谈物联网边缘侧的异样性，比如不一样的场景、不一样的协议、不一样的终端形态等带来的物联网化方案实现的差异性；仅谈物联网平台侧，通常这样一些工作要做：
- 第一步就是设备接入，即平台侧允许设备接入到平台里来，即设备认证的问题；
- 第二步是物模型的实现：数据采集能力、设备控制能力；
- 第三步是设备数据的持久化：即数据统一的持久化策略，不受采集数据的形态制约；
- 第四步是数据的分析能力：流式计算、规则引擎；
- 第五步是其他平台对接能力：给其他系统提供信息输入输出、抽象的设备反控能力 API；上游可能是数据统计展示层、工单业务层、设备能力对接等；
一些大厂对于物联网平台例如：阿里IoT 平台、百度天工物联网平台、亚马逊云物联网平台、微软Azure IoT均有自己的在某一层上的然独特的一些概念，但大致均不偏离上述工作；
当前实现方案、问题及解决办法
当前实现了一版物模型方案，即『就事论事』的原则下设计通讯协议、模型元信息；即设备发生啥事就上报『事件』，不关注历史则上报『属性』，设备控制即为『服务』；这样有一个好处就是轻量级，但带来的一个弊端就是站在服务器端角度没法看到设备『全貌』，物模型设计不好的话可能需要回溯『事件』历史；
这里面少了一层『影子』的设计，加入了『影子』即将数据采集、和设备控制与设备底层能力的对接逻辑就完全解耦了，平台侧甚至设备端均可容易的获取到设备全貌。后端所有的控制只需要操作『影子』数据，或者在『影子』数据变化时产生『属性』或『事件』的数据；这样又引出三个新的问题：
- 实现物模型数据采集：模式的观察『影子』变化，即需要预先设定变化监控逻辑，抽象的『影子』的『观察者』；
- 基于『影子』通讯协议：无论是设备端还是平台侧，观察到『影子』变化需要同步数据；
- 数据的『时效性』和『时序性』问题：这个可能得依赖时间戳和数据版本号来实现；另外『时效性』往往包含业务层含义，比如『将灯的颜色设置为「红色」』，业务上层不需要在一定时间内知道设置结果；但『晚上七点准时打开灯』，业务上层可能需要关注设备在线状态、某一定时间内是否打开成功等；
这里参考两张阿里-设备影子的图
另外有一个考虑，是否可以考虑：『影子』的『观察者』使用 ES5 的 Object.defineProperty 来实现『变化劫持』之后再实现协议层面的数据同步等工作，例如：
leg light = {};
Object.defineProperty(light, 'color', {
set: function (val) {
console.log('劫持数据变化 ---> 执行数据同步。');
}
});
顺便提一句，这也是 VUE 实现双向绑定的基础；
甚至设备端也可以使用同样的『影子』的『观察者』实现方式，『劫持』之后执行的就是设备命令；
『影子』带来的不仅是天生的设备全貌，还让平台侧和设备侧只依赖『影子』数据：即双方只需操作或监视『影子』数据即可实现物模型，让双侧的工作变得更加轻量化；数据变化、数据同步、物模型均可交给架构来统一考虑；实现起来较为复杂，需要考虑的东西还有很多。
上层应用对接的思考
上层应用对应有两处值得抽象思考的，设备控制 API和业务工单。
设备控制 API
这一层需要考虑设备控制能力的接口抽象，可能有如下：
- 通用性入参、出参；
- 是否需要设备在线；
- 是否立即执行并返回结果；
业务工单
业务工单即是上层业务系统收到 IoT 的信息后系统做出的反应，比如业务系统根据告警可能要生成维修工单，业务系统根据对应的故障进行派单、准备维修配件等；
这里需要思考的是告警的状态问题，即产生告警之后是否可以再次产生，有些告警可以自发产生，也可能自发接触；如果产生了之后又自发接触了，那和业务系统如果已经生成了工单了该做何处理呢？
这里需要对告警概念做一些精准定义：可以自发产生又可自发接触的，我们称之类『异常』，『异常』在某种情况下比如持续时间长、超过阈值过大进而升级为『告警』。生成告警继而生成了工单后，即说明发生了某种严重的异常状况，必须需要人为干预（异常未必需要人为干预），工单也得人为干预进而结束；这也就是说明 IoT 的告警的输出一定是
到足够『严重』，不能进行自发解除；人为干预再解除，而后可再次触发；也就是说 IoT 的告警必须带有状态，与工单的人为干预动作相关联；
要不然：告警和工单一起『触发-生成』、『接触-结束』，工单就没有意义了；
一些参考 ：