物联网架构方案思考「建议收藏」

2022-10-02 11:58:20 浏览数 (1)

大家好,又见面了,我是你们的朋友全栈君。

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实现转发。 同时消息和指令通过不同通道转发,可以故障隔离,不会因为消息数据太大,影响了指令的传输。

3.6.存储设计

采用不同的数据库,存放不同的数据库方式。业务数据一般要求严谨性,采用关系型数据库mysql,时序数据因为性能的需要,采用时序数据库cratedb。

3.7.管理后台

管理后台可以使用典型的B/S系统。管理后台的主要职责是管理当前系统的设备,查看当前接入设备的状态,给设备发送指令等。管理系统可以同时在缓存数据库redis,业务数据库mysql,时序数据库cratedb获取信息进行展示和管理。

4.其他

本文所描述的物联网架构,作为开源项目在github开发并持续更新,欢迎大家关注。 github地址:https://github.com/Darren1414/IoTPlatform

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/192140.html原文链接:https://javaforall.cn

0 人点赞