【IOT】物联网架构实践(持续更新)

本文纯粹是个人在公司中经历的物联网架构演变过程
单纯的作为技术交流

物联网版本 V0.1 - 简介

早期公司开始搭建并接触物联网的时候，只知道使用MQTT协议进行通讯，通过主题作为桥梁，也没有深刻了解MQTT的协议内容，在网络上大概调研了几种MQTT-Broker，例如EMQX，fhmq，还有Java写的(Netty+MQTT)等等一众，最后选择了GO语言开发的fhmq ，不仅支持集群(经过测试，集群没什么用)，还支持kafka的桥接插件与Http权限认证等相对比较齐全的功能。
数据从设备端采集到MQTT后，需要被微服务端消费，在经过调研fhmq的kafka插件不满足业务需求后，我用SpringBoot研发了一套桥接程序，作为MQTT与Kafka数据双向流通的桥梁。
早期的流计算选型没有纠结太久，在Flink与Spark中较为果断的选择了Flink
早期时候所有的服务部署在Docker上(使用docker-compose)
架构

部署环境	部署方式	MQTT broker	mqtt<=>Kafka桥接程序	流计算	微服务
docker	docker-compose	fhmq	springboot	flink	springcloud

物联网版本 V0.2 - 流计算业务

在整体架构稳定的情况下，接下来我们对Flink花费较多的时间进行研究，我们的流计算处理3个模块的内容

1. 物联数据（属性，事件）
2. 充电计费逻辑（业务处理）
3. 监控告警

所得出的成就如下：

• 从Flink的1.12版本研究到了最新的Flink1.14版本
• 从FlinkSQL与FlinkStreaming都进行的较为深入的使用
• 部署模式（初期是基于session[docker]与flink on yarn[Ambari平台]）
• 基于Streaming的valueState对Flink的保存点检查点进行了丰富的测试
• 开放Flink的普罗米修斯metrics端口进行指标的监控(多用于任务状态)
• 对Flink的外部维表的几种join方式都进行了调研
• 当时保障了线上生产环境超过半年的流计算的稳定性

物联网版本 V0.3 - 流计算部署

由于平台大力推崇云原生，所以首先将原先通过docker(docker-compose)进行部署的环境统一通过kubernetes进行部署(前期的时候部署方式比较随意，有通过heml，有通过直接create yaml，也有通过operator)
在物联网比较核心的流计算部分，我们的演变是：

1. flink on yarn
2. flink-session (docker)
3. flink-session + HA (k8s)
4. flink application (k8s)

可以看出我们最后选择的部署方式是Application 模式,我们有100个左右的job在这种模式下部署(分配的机器只有3台)，我们目前进行的优化有：

• 最早使用git上开源版的operator进行部署
• 改造源码定时生成保存点并且再重新部署的时候自动识别读取保存
• 基于gitlab的cicd对k8s部署进行协调
• 通过集成nacos将任务配置统一管理
• 对部分flink内存模型进行优化
• 最后在22年4月我们将原先的operator改成flink官方的apache-flink-k8s-operator(实话实说有不少bug…也等待其慢慢完善)
• 开发插件式开放k8s容器的ingress与service的工程进行辅助
• 我们还会持续借鉴业界优秀大厂的经验，对我们的架构持续迭代

物联网版本 V0.4 - 物模型

会在这里讲一下我们对于物联网协议的物模型的理解，我们参照了

• 国家电网
• 阿里云Alink
• 华为云
• 小米
  最后实现了我们自己的一套物模型方案，再次较为简要的描述下：
  同样的，我们也分为事件、属性、服务。只不过再这之上，我们添加了模块，OTA升级，上下线等单独的模块，例如：
  突然有事，下次再写

物联网版本 V0.5 - 数据仓库（实时数仓）- ODS

物联网版本 V0.6 - 数据仓库（实时数仓）- DWD

物联网版本 V0.7 - 数据仓库（实时数仓）- DWS

物联网版本 V0.8 - 数据仓库（实时数仓）- ADS

物联网版本 V0.x - 数据仓库（离线数仓）

物联网版本 V0.x - 新旧版本协议整合