该系统主要是通过Spring cloud+nacos+gateway+redis+mysql+自定义消息队列+K8S+aliyun ECS进行开发，基于二期工程后为了适应大量用户的访问、更好的监控设备是否故障或网络中断及更方便的部署服务，增加监控设备服务模块，并将命令下发模块拆分重构成一个独立的工程产品（DC）来开发，向上接入业务模块下发的业务记录，向下对消息进行存储转化下发给对应设备，并在DC中自定义消息队列来按顺序存储消息；
当业务模块调用DC暴露的接口前，业务模块需自定义生成一个traceId（为了追踪整个流程）及sourceId（记录消息来源）作为header请求头传递给DC接口，DC通过检验该记录是否符合消息规范从而进一步处理；
若检验通过则进行保存并将traceId，sourceId进行保存，并调用提交接口将该记录进行转换成设备所需消息规则进行下发，（转换成的消息上带上rid随机码值保存到消息表），设备会返回传递的rid、code、timestamp属性值，若设备返回的code码200则表明下发成功，更新消息表标识为成功标识；若设备返回code码非200成功码，则下发失败并更新消息表标识为失败标识，此时的失败是设备网络中断或设备故障导致，所以进行消息下发重试：在此重试时需要防止消息重复下发，故每次重试时需要先调用设备返回rid的接口与该失败消息的rid是否相同，若不同，则将该消息进行下发，并将消息表标识更新成功；若相同则不再下发该消息。（此过程是因为下发成功，但是设备返回消息时断线或故障，导致服务未收到成功通知）
若达到重试次数后，依然没有返回rid、code，则将用户后续下发的指令进行存储，并调用当监控服务接口查看设备当前状态是否在线，若在线，则将该消息表中存储的失败标识的消息取出来按时间升序排序后放入消息队列下发给设备。
当用户在业务层面对该记录进行修改时，则调用dc后，dc通过header头传递的traceId进行查询出相关记录并对该记录进行克隆后，将副本进行更新，之后调用删除接口下发删除本体消息，在调用提交接口下发副本最新消息；在修改过程中用户可能会修改多次记录而并没有进行下发，只是调用dc的保存接口将消息进行保存，此时通过traceid可以查询到该记录所有克隆状态的消息。
通过K8S将DC服务部署到三台服务器，便于之后的灰度发布、扩容服务等操作。