物联网架构成长之路(57)-物联网阶段性小结3

1.前言

　　距离上一次写物联网系列已经半年多过去了。一直没有更新该系列。主要是平台完成的七七八八了。但是由于我远离硬件需求端，对于一些特定的需求，不理解，避免闭门造车。加上之前断断续续跟一个公司合作开发。最近半年安装他们公司进行深入定制化，现在样品也陆续开始发出去了。预计进入商用阶段，同时平台完善后，基于平台还将陆续有一些应用被开发。

　　还有他们公司也找了个前端，对我那个基于layui的框架界面进行优化，采用vue-element进行重构开发。基于此，还将有配套硬件开发包出售。两年了。一切都朝着越来越好的方向发展。

　　最近在公司也开始带新人了。物联网平台的事情，公司继续没有让我做和得到重视。正职，我还是继续我的企业信息化，争取明年底把运营分析系统搭建起来。平时周末就继续搞自己的物联网平台。加油哟~~~

 

2. 物联网新架构图

　　这个是年初二月份画的。最近半年是主要是写一些API和日志分析，还有应用。这部分还没有形成完整的文档和流程，所以还不发出来。

 

如上图所示，各个功能点详述

　　A: 作为物联网设备端的一环，我们的手机也可以理解为一个功能较多的智能设备，跟那种资源受限，功能单一的普通设备是一样的。只是一般的手机性能较为强大，推荐使用MQTT+JSON的通信方式及协议
　　B: 普通的智能设备一般也分为高性能硬件和低性能硬件，一般是推荐能使用MQTTs+JSON通信方式的设备尽量使用MQTT+JSON。一些类似NB模块的也可以使用CoAP+JSON通信方式
　　C: 对于低功耗需求或者低性能设备，又或者是以前旧的设备，而无法使用的。可以使用TCP自定义协议。但是此时需要一个网关服务器。用来实现协议转换。这个协议转换，如果放到偏服务器测，那么称之为协议网关。如果放到偏设备测，那么称之为边缘节点。如果还带有管理界面或者编程实现逻辑的，也称之为边缘计算。最后转换成平台规定的协议格式进行通信。
　　D: 以上A、B、C三类设备，最后都是作为数据生产者，把采集到的数据发送到平台。设备通信需要设备认证，我们平台采用“一机一密”，“一型一密”两种方式进行设备认证。然后设备携带设备的DeviceSN、DeviceKey、DeviceUUID等信息登录到EMQ服务器。按照协议进行通信。
　　E: 这部分作为设备接入，采用EMQX这个中间件。是MQTT的Broker。开源，免费。开源版本也有自带集群功能。该中间件只是作为数据传输，转发的功能，不进行过多的逻辑操作与运输。设备认证是，EMQ通过WebHook方式，HTTP API读取P功能，进行判断是否合法设备已经通信是否符合平台规定Topic权限策略。D方向是数据的生产者，平台采用编写一个转发程序，一般采用订阅根节点。然后根据不同的Topic构造不同的Topic，这个Topic与MQTT的Topic不一样，是属于Kafka的Topic。由于MQTT与Kafka两者都是消息队列，但是底层数据结构不一样。Kafka的Topic不能太多。因此要进行归类。
　　F: 从EMQ经过F到I，可以直接在EMQX里面写插件，简单的进行转发，这个插件也不是很难，我自己也写过。网上实现的也有，这种方式实现性能会比较好。但是由于还要重新学习Erlang，要实现过多的业务逻辑会有点麻烦。
　　G: 通过插件方式实现是一种方式，也可以通过定义MQTT的根Topic，按照Topic进行不同类别的转发。前期优先使用这种方式。比如根据MQTT的Topic的后缀是event、alarm、property等功能进行转发到Kafka。因为payload里面已经有客户ID，产品ID、设备ID
　　H: 作为Kafka的生产者，因为可能会出现数据高峰，已经消费者的处理时间问题。引入Kafka消息队列，解决生产者与消费者问题。H这里会做出动态化，插件化。比如要增加一个支付服务，那么H部分就是对Kafka的pay这个Topic写数据。然后J消费者如果刚好有个支付服务，刚好订阅pay这个Topic，就可以消费这些数据。
　　I: Kafka是第二版引入的一个中间件。也是一个开源、免费的中间件。主要实现架构层级分离。生产者与消费者的分离。配置规则与策略还要详细了解。
　　J: 消费者，这里就是插件化。比如有个客户有特殊需求，那么通过一个customer的Topic，经过H。那么这里只需要编写一个订阅I的customer的Topic。就可以实现自定义逻辑。标准平台会实现一些标准的插件。比如K的持久化插件，比如L的报警服务。以后这里会做成一个生态。一个插件市场。让平台生态化。
　　K: 持久化服务，作为一个标准插件。如果设备生产者遵循标准化通信方式，那么可以直接使用这个插件，插件会收集所有的数据，并通过简单的逻辑处理，将数据持久化到时序数据库，如InfluxDB。然后使用开源的Grafana图表进行展示。有特殊需求的，还可以获取Grafana或者自己封装成HTTP API给第三方调用，使用这些数据。做数据分析与利用。
　　L: 报警服务，这个也是物联网比较常见的一个服务。比如设备消费端通过event这个Topic发到J，这个L就刚好是订阅这个event的Topic的。就分析传输过来的数据。逻辑判断是否需要报警。需要告警的，会通过钉钉的开发API，通知到钉钉群。有能的，可以实现到短信、微信公众号等方式。都是可以插件化实现。
　　M: 这里的M已经是客户人员。就是所谓平台的租户了。平台会提供一个Web界面或者OAuth开放文档，让客户自定义皮肤。平台遵循前后端分离的微服务架构。
　　N: 平台需要交互，同时也需要与第三方公司的客户系统进行对接。这里有两种方式，一种是客户直接利用平台的OAuth或者HTTP APIKey进行远程调用。还有一种是通过CallBack，让平台调用第三方系统。
　　O: 标准平台会提供给M客户一个账号密码，功能客户登录到设备管理Web后台。登陆后可以查看产品、设备配置一些基础信息。
　　P: E是标准化产品的中间件。EMQX，一般不需要进行二次开发。EMQ提供了丰富的API和配置项。平台适用里面的auth_http方式，通过HTTP调用来实现设备的“Topic权限策略”，“设备帐号密码认证”，“设备状态获取”等功能。
　　Q: 这里有三个基础功能“Topic权限策略”，“设备帐号密码认证”，“设备状态获取”。采用微服务，每个服务都对应一个功能。
　　R: 这里是一些基础微服务，包含后台管理界面、设备管理界面增删改查登录功能。还有OTA固件升级管理。设备物理模型管理。
　　S: 一些基础存储服务，包含关系型数据库Postgres，非关系型数据库Redis，还有对象存储的MinIO等。
　　T: 这里也是一些微服务基础组件，包含配置中心，日志中心，运维中心等。
　　U: 后台运维Web管理界面，超级管理员登录界面。负责平台的日常管理、监控、运维等工作。

 

 

本文地址：https://www.cnblogs.com/wunaozai/p/13860572.html
本系列目录： https://www.cnblogs.com/wunaozai/p/8067577.html
个人主页：https://www.wunaozai.com/