物联网架构方案思考

方向H

已于 2022-09-23 16:09:52 修改

阅读量963

点赞数 2

分类专栏：物联网文章标签：物联网项目架构 iot

于 2020-03-16 16:02:58 首次发布

本文链接：https://blog.csdn.net/dream_meng/article/details/104900746

版权

物联网专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1.前言

1.1.系统设计有无通用方案？

一般的IT系统，稍微复杂一些，都会存在一个架构。架构在初期可能不觉得有多么重要，但随着业务发展，架构可能成为系统开发的瓶颈，导致无法再迭代下去。
不同的系统，会有不同的架构，即使同一个系统，由不同的架构师设计也会有不同的架构。架构不存在正确与否的，只能说在不同的场景，存在优劣之分。
如何设计一个系统，此问题过于庞大不在本文讨论范围。那么如果细化一个问题：架构设计能否有通用方案？
上述问题，如果限制了系统范围，同时只要求解决该范围80%的问题，那么确实是可以设计出通用方案的。

本文根据笔者的经验，探讨物联网一般的设计方案，如有错误，请轻拍砖。

2.物联网系统设计目标

2.1.物联网系统要解决的问题

2.1.1.“连”是核心需求

物联网首先要解决的问题，是让大量的设备接入系统。一般的物联网系统要求和设备实现双向通信，故要求的连接一般是长连接（TCP连接），并且需要连接稳定，为保证连接稳定，一般都会加入心跳机制。由于长连接是耗资源的，单台服务器能承受的连接有限，故设计的系统必须是可以扩展的，即可以通过堆机器增加连接能力。

2.1.2.数据处理是主要任务

物联网产生的数据大部分为时序数据，由设备按周期产生。由于考虑到设备众多，每台服务器处理能力有限，同样需要设计的系统必须是可以扩展的。同时一般要求设备连接服务器和数据处理服务器要解耦，因为不同的设备数据，一般处理过程也不一样。

2.1.3.指令和控制是基本需求

一般物联网还需要由上向下发送指令，如快递柜打开，门锁打开等。故系统需要设计一个指令通道。指令通道如果需要相当的可靠性，还需要一个独立的指令通道，和数据通道分开传输予保证可靠性。

3.系统总体设计

3.1.总体架构框图

3.2.设备登录过程

设备登录可以采用登录网关http方式登录。http为大多数开发者熟悉，开发简单。设备通过http报文（一般为json）把设备号，设备类型，位置等信息传递到服务端，服务端验证真伪后通过算法返回一个登录令牌和一个负载较低的连接服务器地址，设备通过这两个信息，使用TCP接入连接服务器，完成登录。

3.3.设备在线状态维护

已经登录的设备，通过TCP心跳包，定时向连接服务器上报心跳信息。连接服务器把当前活动的设备登记到缓存数据库（redis），并设置过期时间，如果连接服务器一定时间未收到心跳，则关闭连接同时redis的活动信息亦会自动删除。
其中redis中的活动设备信息，是为了管理后台和业务服务器查看当前活动设备使用，作为一个信息交换媒介。

3.4.消息和数据处理

连接服务器收到的设备信息，通过消息队列（kafka）转发到业务处理服务器。这里通过消息队列的方式，实现了连接服务器和业务处理服务器之间的解耦。因为解耦，连接服务和业务处理可以完成独立开发而不相互影响。比如连接服务因为性能可以使用Java或者C++开发，业务处理因为灵活性的要求可以使用python开发。

3.5.指令处理

上述的消息和数据出来，通过kafka消息队列转发，是考虑到kafka的高性能，kafka的多主架构，可以抗住更大量的流量转发。
但在指令转发场景，更重要的是可靠性，并且通常指令流量不会很大。rabbitmq具有较高的严谨性，数据丢失的可能性更小，故指令通道采用rabbitmq实现转发。
同时消息和指令通过不同通道转发，可以故障隔离，不会因为消息数据太大，影响了指令的传输。