• 物联网架构成长之路(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/

  • 相关阅读:
    UVaLive 7362 Farey (数学,欧拉函数)
    UVaLive 7361 Immortal Porpoises (矩阵快速幂)
    UVaLive 7359 Sum Kind Of Problem (数学,水题)
    CodeForces 706D Vasiliy's Multiset (字典树查询+贪心)
    负载均衡服务器
    集群-如何理解集群?
    架构规划
    领域模型
    状态图
    E-R图
  • 原文地址:https://www.cnblogs.com/wunaozai/p/13860572.html
Copyright © 2020-2023  润新知