【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 - 新旧版本协议整合

你可能感兴趣的:(物联网,iot,物联网)