基于abp的小小设备控制系统设计

客户有一堆小设备，需要通过小程序来控制它们，主要是设备门的开关、电源开关、状态查询、压力控制等。下面主要纪录下设计思路。

源码地址：https://gitee.com/bxjg1987_admin/abp

视频讲解地址：https://www.bilibili.com/video/BV1M5411j7Lo?from=search&seid=14452337061864244964

最初的设计是这样的

 

 

核心流程有3个，分别用绿、蓝、黑这3种颜色来标识。

流程1：小程序端发送指令控制设备(开关、舱压调整等)

以开关电源控制为例

1. 小程序向wei服务端发起请求，说我想关闭设备id为1的那个设备
2. wei服务端准备一条消息（说我要关闭id为1的那个设备），发送给RabbitMQ消息队列
3. RabbitMQ消息队列将消息推送给硬件服务器
4. 硬件服务器解析消息，根据设备id和按协议约定准备byte[]指令下发给具体设备
5. 设备回复消息给硬件服务器
6. 硬件服务器组织一条回复消息（所id为1的设备已经关闭成功）发送给RabbitMQ消息队列
7. 消息队列将回复消息推送给web服务端
8. web服务端通过abp提供的通知功能（默认基于a's'p.net core signalr）通知小程序端，

此时小程序端开源认为操作成功，但是不是太准确，另一种办法是小程序再查一次设备状态确认下。所以上面的步骤5可以向设备触发一个请求，让设备立即上报一次数据。默认情况下设备是轮询的比如30秒上报一次数据。

流程2：设备轮询30秒上报一次数据

1. 设备上报状态数据
2. 硬件服务器将设备状态数据存储到数据库
3. 硬件服务器向RabbitMQ消息队列发送一条消息，说设备id为x的设备上报了状态数据
4. RabbitMQ消息队列将消息推送给web服务端
5. web服务端通过abp提供的通知机制通知小程序端

步骤3没必要直接将状态数据推送给消息队列，因为此消息的接收方未必关系具体的数据，目前设计只是说有设备状态上报了，这个消息通知到接收方，由接收方决定是否主动来查设备状态

流程3：小程序主动查询设备状态

这个就比较简单了

1. 小程序端向web服务端发起查询请求
2. web服务器直接从数据库查询设备状态返回就可以了

有点问题，这样查询不是设备的当前状态，我们可以再定义接口直接去查一次当前设备的状态，但是这样编码比较大，也不利于我们复用现有流程。最简单的办法是定义一个接口，向设备发送一条指令说请你立即上报一次数据，小程序原有的查询设备状态查到就是最新的了。

设备服务端SuperSocket

开源地址：https://github.com/kerryjiang/SuperSocket，这是个设计得比较好的，基于.net core的socket的通信框架。官方有文档学起来比较简单。

它负责与设备通信，可以单独部署在一台服务器上。

基于Abp的Web服务端

这就不多说了，因为它已经为我们提供了很好的web服务端基础设施，免得从头做起。此服务端也可以单独部署一台服务器

消息队列RabbitMQ

其它mq没用过，就用它咯。它主要是解耦设备服务端和web服务端的，主要是它可以主动推送消息给接收方，也可以考虑使用redis的推送来实现。消息队列也可以单独部署一台服务器

简化后的设计

如果设备比较少，请求量不大可以用下面这种简化的设计

 

既然是简化，流程就不说了。主要是省略了消息队列，并且省略了指令回复的处理，而是使用轮询的方式，比如每过10秒查一次当前设备状态，控制设备时，只是下发指令，而不等结果，因为我们的轮询会查到下一次的设备状态。

这里有些注意：

• 设备上报状态存入数据库时可以使用一个全局的数据库连接
• web服务器向设备服务器发送指令时也可以考虑使用全局的tcp连接
• web服务器向设备服务器发送指令时可以使用supersocket提供的客户端库

结束

简化后的方案最low，但是也最容易实现，目前源码中就是采用的这种方式。前一种方式稍微好点，3台服务器可以分开部署，如果并发再大点可以考虑下分布式了，再不行就放弃这个上思路，直接上个阿里云IOT啥的。