客户有一堆小设备，需要通过小程序来控制它们，主要是设备门的开关、电源开关、状态查询、压力控制等。下面主要纪录下设计思路。源码地址：https://gitee.com/bxjg1987/abp
最初的设计是这样的
核心流程有3个，分别用绿、蓝、黑这3种颜色来标识。
流程1：小程序端发送指令控制设备(开关、舱压调整等)
以开关电源控制为例
- 小程序向wei服务端发起请求，说我想关闭设备id为1的那个设备
- wei服务端准备一条消息（说我要关闭id为1的那个设备），发送给RabbitMQ消息队列
- RabbitMQ消息队列将消息推送给硬件服务器
- 硬件服务器解析消息，根据设备id和按协议约定准备byte[]指令下发给具体设备
- 设备回复消息给硬件服务器
- 硬件服务器组织一条回复消息（所id为1的设备已经关闭成功）发送给RabbitMQ消息队列
- 消息队列将回复消息推送给web服务端
- web服务端通过abp提供的通知功能（默认基于a's'p.net core signalr）通知小程序端，
此时小程序端开源认为操作成功，但是不是太准确，另一种办法是小程序再查一次设备状态确认下。所以上面的步骤5可以向设备触发一个请求，让设备立即上报一次数据。默认情况下设备是轮询的比如30秒上报一次数据。
流程2：设备轮询30秒上报一次数据
- 设备上报状态数据
- 硬件服务器将设备状态数据存储到数据库
- 硬件服务器向RabbitMQ消息队列发送一条消息，说设备id为x的设备上报了状态数据
- RabbitMQ消息队列将消息推送给web服务端
- web服务端通过abp提供的通知机制通知小程序端
步骤3没必要直接将状态数据推送给消息队列，因为此消息的接收方未必关系具体的数据，目前设计只是说有设备状态上报了，这个消息通知到接收方，由接收方决定是否主动来查设备状态
流程3：小程序主动查询设备状态
这个就比较简单了
- 小程序端向web服务端发起查询请求
- 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啥的。