物联网架构

物联网是互联网的外延。将用户端延伸和扩展到物与人的连接。物联网模式中，所有物品与网络连接，并进行通信和场景联动。互联网通过电脑、移动终端等设备将参与者联系起来，形成的一种全新的信息互换方式

DCM系统架构

  • 设备感知层（Device）：利用射频识别、二维码、传感器等技术进行数据采集
  • 网络传输层（Connect）：依托通信网络和协议，实现可信的信息交互和共享
  • 应用控制层（Manage）：分析和处理海量数据和信息，实现智能化的决策和控制

image.png

三要素

  • 设备联网：通过不同的网络协议和通信标准，实现设备与控制端的连接
  • 云端分析：提供监控、存储、分析等数据服务，以及保障客户的业务数据安全

  • 云边协同：云端接受设备上报数据，下发设备管控指令

    云 / 边 / 端协同

    云端计算、终端计算和边缘计算是一个协同的系统，根据用户场景、资源约束程度、业务实时性等进行动态调 配，形成可靠、低成本的应用方案。从过去几年的发展积累来看，AI 已在物联网多个层面进行融合，比我们合作的海康威视、旷视宇视、商汤科技等纷纷发布了物联网AI相关平台和产品，和移动和小区进行了紧密的融合。
    image.png

    物联网平台接入

    image.png
    向下连接海量设备，支撑设备数据采集上云；
    向上通过调用云端API将指令下发至设备端，实现远程控制。
    上行数据链路

  • 设备建立MQTT长连接，上报数据（发布Topic和Payload）到物联网平台

  • 物联网平台通过配置规则，通过RocketMQ、AMQP等队列转发到业务平台

下行指令链路

  • 业务服务器基于HTTPS协议调用的API接口，发布Topic指令到物联网平台。
  • 物联网平台通过MQTT协议，使用发布（指定Topic和Payload）到设备端。

    门锁接入

    WIFI门锁：非保活 平常处于断电休眠状态，需要MCU 唤醒才能传输和发送数据
    蓝牙门锁：MCU串口对接和SDK对接，近距离单点登录和远距离网关登录
    Zigbee门锁：非保活 但是保持心跳，MCU对接，Zigbee协议控制。
    NB-Iot门锁：可以通过公网连接，把门禁变成SAAS服务，MCU
名词 解释
SaaS Software-as-a-Service ，提供给客户的服务是运营商运行在云计算基础设施上的应用程序。用户可以在各种设备上通过客户端界面访问应用，例如计算机浏览器。用户不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等资源，一切由 SaaS 提供商管理和运维。
PaaS Platform-as-a-Service，表示平台即服务理念，客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但客户能控制部署的应用程序，也可能控制运行应用程序的托管环境配置。
IaaS Infrastructure-as-a-Service ，表示基础设施即服务理念，提供的服务是对所有计算基础设施的利用，包括 CPU、内存、存储、网络等其它计算资源。用户能够部署和运行任意软件，包括操作系统和应用程序。

各种协议

HTTP协议（CS用户上网）
HTTP协议是典型的CS通讯模式，由客户端主动发起连接，向服务器请求XML或JSON数据。该协议最早是为了适用web浏览器的上网浏览场景和设计的，目前在PC、手机、pad等终端上都应用广泛，但并不适用于物联网场景

  • 由于必须由设备主动向服务器发送数据，难以主动向设备推送数据。
  • 物联网场景中的设备多样，运算受限的设备，难以实现JSON数据格式的解析

RESTAPI（松耦合调用）
REST/HTTP主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。因此适合在物联网的应用层面，通过REST开放物联网中资源，实现服务被其他应用所调用。
CoAP协议（无线传感）
简化了HTTP协议的RESTful API，它适用于在资源受限的通信的IP网络。
MQTT协议（低带宽）
MQTT协议采用发布/订阅模式，物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发
适用范围：在低带宽、不可靠的集中星型网络架构（hub-and-spoke），不适用设备与设备之间通信，设备控制能力弱，另外实时性较差，一般都在秒级。协议要足够轻量，方便嵌入式设备去快速地解析和响应。具备足够的灵活性，使其足以为 IoT 设备和服务的多样化提供支持。应该设计为异步消息协议，这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定，若使用同步消息协议，IoT 设备需要等待服务器的响应，必须是双向通信，服务器和客户端应该可以互相发送消息。
AMQP协议（互操作性）
用于业务系统例如PLM，ERP，MES等进行数据交换。
适用范围：最早应用于金融系统之间的交易消息传递，在物联网应用中，主要适用于移动手持设备与后台数据中心的通信和分析。
XMPP协议（即时通信）
开源形式组织产生的网络即时通信协议。被IETF国际标准组织完成了标准化工作
适用范围：即时通信的应用程序，还能用在协同工具、游戏等。
XMPP在通讯的业务流程上是更适合物联网系统的，开发者不用花太多心思去解决设备通讯时的业务通讯流程，相对开发成本会更低。但是HTTP协议中的安全性以及计算资源消耗的硬伤并没有得到本质的解决。
JMS （Java消息服务）
Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。
Zigbee协议
低功耗，它保持IEEE 802.15.4（2003）标准

IOT流量洪峰

智慧社区IOT领域，不管是嵌入式芯片还是应用服务器都需要传递消息，常见上行的消息有：人脸识别开门、烟感雾感告警、共享充电桩充电，下行的广告下发、NB门禁开门指令、超级门板显示等，由于物联网设备时不时会故障和断网导致大量的流量洪峰，传统消息队列需要针对性优化。

  • 上下行拆分上行消息特征：并发量高、可靠性和时延性要求低下行消息特征：并发量低、控制指令的成功率要求高
  • 海量Topic下性能Kafka海量Topic性能会急剧下降，Zookeeper协调也有瓶颈多泳道消息队列可以实现IoT消息队列的故障隔离
  • 实时消息优先处理NB门禁实时产生的开门指令必须第一优先级处理，堆积的消息降级设计成无序、不持久化的，并与传统的FIFO队列隔离
  • 连接、计算、存储分离Broker只做流转分发，实现无状态和水平扩展计算交给Flink，存储交给nosqlDB，实现高吞吐写
  • 消息策略-推拉结合MQTT针对电池类物联网设备，AMQP针对安全性较高的门禁设备消费端离线时存到queue，在线时将实时消息和从queue中拉取的消息一起推送

image.png
如果解决海量Topic
首先要做的就是分区、分组等水平拆分的方式，接下来考虑单实例如何处理更多Topic，传统消息队列在海量Topic下顺序写会退化成随机写，性能大幅下降

  • 人工Sharding：部署多个Kafka集群，通过不同mq连接来隔离
  • 合并Topic，客户端封装subTopic。比如一个服务的N个统计项，会消费到无关消息基于这个思路，使用Kafka Streams或者Hbase列存储来聚合

针对单个Topic海量订阅的问题，可以在上层封装广播组件来协调批量发送
image.png