曲豫宾，李 芳

(江苏工程职业技术学院，江苏南通226001)

分布式微电网数据监控中心设计与实现*

曲豫宾，李 芳

(江苏工程职业技术学院，江苏南通226001)

微电网建设存在大量的数据采集终端，数据终端的稳定可靠数据采集.以及数据及时保存是项目要解决的问题.系统设计采用Netty框架作为底层通信框架，数据持久层采用RabbitMQ解决数据保存、业务处理中的高IO问题，引入MQTT协议解决跨平台的消息传递.实践证明，该系统能够满足微电网数据采集客户端信息及时、准确的采集与监控要求.

微电网;Netty;消息中间件;物联网协议

1 项目研究背景

全球能源短缺和环境污染问题等决定了光伏等新能源发电将成为未来国家重点发展的新兴产业.分布式微电网可以有效发挥能源采集优势，把发电网络部署到每一个分布式单元中，比如住户的屋顶等等，这样就可以更加有效地进行分布式的发电，提高发电量.美国、欧洲已经建立了分布式微电网的示范工程，中国目前也在不断加大分布式微电网的研究与应用.微电网可以将多个分布式电源、负荷、储能及控制装置结合在一起，形成一个统一自治的可控小型发配电系统，微电网“就地消费”的特点可以有效减少对集中式大电厂电力生产的依赖，以及远距离电能传输、多级变送的损耗，能有效解决大电网与分布式电源间的矛盾，充分发挥分布式发电的优势，消除分布式发电对电网的冲击，削峰填谷，提高能源综合利用效率，提高电网的安全性，对推动新能源产业的发展，建设资源节约型社会具有深远的意义.分布式微电网的研究与建设围绕着四个方面进行，分别是分布式发电技术、储能技术、能量管理系统相关技术、分布式发电站的远程监控技术等.这四个方面的技术围绕着电能的生产、储存、管理，远程监控等形成了完整的生态链，从而满足分布式微电网的运行要求.实现分布式微电网的数据采集监控要考虑的问题包括:数据采集终端的设计，网络连接协议的设计，智能终端的通信模块设计，数据采集服务器的设计，推送消息服务器的设计，业务逻辑服务器的设计等等.在本项目中，分布式微电网的数据监控与采集采用了大量的用单片机设计的智能客户终端，通过DTU与上位机相连接.上位机在进行业务处理的时候，分析并处理协议报文做好相应的业务逻辑，数据持久化在数据库中.出于项目易用性的考虑，采用较为成熟的物联网协议，比如MQTT等来设计满足各种平台的客户端，比如Ios、Android等的连接需求.

2 相关技术基础

2.1 高并发服务器框架Netty

在jdk 1.4以后的Java开发框架中引入了新的IO通信模型，在Java代码中提供了面向快的高速IO通信接口，通过定义包含数据的类，不用采用低级代码的优化就能够以块的形式来处理IO［1］.新的IO接口为原有的通信框架提供了高速处理IO通信的基础，然而由于NIO自身的复杂性及Jdk本身的Bug，处理网络闪断、客户端重复接入、客户端安全认证、消息的编解码、半包读写等问题也给自定义网络开发框架设置了极大的障碍［2］.基于这些问题，Trustin Lee开发出了工业界比较流行的 Mina与Netty框架，Netty是一个高性能的异步非阻塞通信框架，通过Future－listener机制，用户可以非常快捷的通过事件通知获取IO操作结果.

2.2 消息中间件RabbitMQ

消息中间是一类用于系统间通信，进行系统解耦的软件产品.阿里中间件团队对Kafka、Rabbit－MQ、RocketMQ消息中间件进行过性能测试对比，结果是Kafka适合产生大量数据的互联网服务的数据收集业务，而基于Erlang开发语言开发的RabbitMQ适用于对数据一致性、稳定性、可靠性要求比较高的场景，RocketMQ具有高吞吐量、高可用性、适合大规模分布式系统应用的特点［3］.在我们的系统开发中对于系统的稳定性和可靠性有着比较高的要求，因此项目采用RabbitMQ消息中间件.

2.3 物联网通信协议MQTT

在存在大量物物相连的系统中，原始的请求回答模式已经不能满足系统的要求，取而代之的是发布订阅模式，轻量级、可扩展的 MQTT(Message Queuing Telemetry Transport)协议的开发就是为了解决物物相连时存在的低功耗、网络带宽有限、网络带宽不稳定等情况.该协议由IBM公司提出.通过对比［4］，MQTT协议相对于数据分发服务(DDS)、受限应用协议(CoAP)适合于建立设备监控等设备中心化的信息系统.

3 系统设计架构

根据分布式微电网的功能需求、硬件要求，以及网络需求，设计了基于Netty的远程数据管理中心.该管理中心的设计要求是要能够稳定可靠地满足系统需求，软件模块之间应满足高内聚低耦合的设计原则，该管理中心应该具有很好的弹性，面对突发的海量数据需求，应该有灵活的扩展方案.因此，系统整体架构如图1所示.

图1 分布式微电网数据监控系统设计架构

数据管理中心底层采用Linux操作系统，在数据中心建设过程中，集成了工业界比较成熟稳定的方案.底层网络通信模块采用广泛应用的Netty框架，该框架提供非阻塞异步的网络IO管理.业务逻辑模块采用消息中间件RabbitMQ进行缓冲处理，有效地解决了系统的稳定性和健壮性的问题.业务逻辑服务器与消息中间件之间采用AMQP协议进行数据交换.数据的存储采用MySQL进行持久化.智能终端，比如Ios、Android客户端与数据中心的物联网通信模块之间采用MQTT协议进行数据的交换.同时预留了微电网数据采集终端与物联网通信模块之间的通信接口.该物联网通信模块使用RabbitMQ的插件获得对MQTT协议的支持.

分布式微电网通过智能终端采集信息，通过RS232接口将数据发送给DTU，该数据传输单元再按照指定的私有协议封装数据，通过2G/3G/4G网络将TCP报文发送给移动网络，连接到指定的服务器端套接字上进行双向的网络通信.数据终端既有对数据的采集，也存在对设备的管理控制，因此远程数据中心设计需要通过该逻辑链路发送控制指令给智能客户端.

3.1 使用Netty解决海量智能客户端的DTU长连接

微电网数据采集终端通过dtu连接到远程数据数据采集中心.物联网大致可以分为三个层次，分别是传感器层、网络层、应用层.微电网数据采集终端相对于分布式微电网的传感器，它负责采集微电网的电流、电压、功率等实时参数，同时也承担对于微电网硬件的远程控制.该数据终端通过无线网络，比如2G/3G/4G等接入到远程数据中心.由于无线网络存在网络不稳定、野外传输速度较慢等问题，而且要求能够实时传输，反向控制，因此在数据中心的设计上特别要考虑该技术要求.

微电网的支持高并发的数据中心采集模块的设计重点考虑了读心跳包的处理，基于责任链模式的特定报文的业务逻辑处理，通过对Channel的管理实现对于采集终端的管理.该模块设计结构如图2所示.

图2 基于Netty的长连接服务器设计结构

在最底层采用Linux操作系统，使用Epoll模型作为网络IO处理的底层框架，以该底层框架为基础，在第二层使用Jdk中的NIO进行非阻塞的网络IO读写，实现IO多路复用模式.在第三层的Netty框架层，使用Reactor设计模式，将服务器端发生的IO事件注册在Selector上，实现高并发的、非阻塞的、基于事件的高性能网络处理框架.通过Netty框架，实现自定义的业务逻辑处理、客户端管理，以及心跳处理.

3.2 引入消息中间件异步处理高IO服务器业务逻辑

尽管Netty已经实现了对高并发的客户端连接的处理，项目中提供一台数据存储服务器，如何保证准确、可靠、快速地进行业务逻辑处理是业务逻辑处理服务器设计中要重点解决的问题.解决问题的方案是采用生产者－消费者模式进行数据处理，待处理的消息存储在消息中间件，由消费者异步地使用AMQP协议处理消息，处理完业务逻辑结束以后，把电流、电压、功率等数据信息持久化存储在MySQL服务器.系统的整体设计结构如图3所示.大量的客户端连接在数据中心上，实时地会有大量的数据报文同时需要进行处理，报文处理时候要进行较多的业务处理，引起IO阻塞，通过消息中间的引入就可以把海量的同步信息异步进行处理;同时单台MySQL服务器要能承担大量的客户端连接;业务处理子线程能够异步、及时准确地将数据消费、解析、存储到服务器中去.

图3 基于消息中间件的业务逻辑服务器设计结构

3.3 使用MQTT协议搭建跨平台的消息服务器

图4 基于MQTT协议的跨平台消息服务器设计结构

目前工业界已经有不少可用的跨平台的消息服务器，比如Google的消息推送服务器，苹果公司的消息推送服务器，国内有极光、阿里云消息服务器等等.这些服务器目前采用的比较多的都是使用MQTT协议进行数据推送.这些服务器有些在国内不是非常畅通，有些服务器商用以后要收费，更多的是由于无法满足自定义的业务需求，同时能够连接物联网终端和手机终端，因此基于MQTT协议开发了跨平台的消息服务器.系统设计结构如图4所示.

整个系统有三种终端，通过dtu设备连接上来的智能终端，未来采用MQTT协议连接的物联网终端，智能手机终端(比如Ios、Android等客户端).针对这种低功耗不可靠网络连接的情况，MQTT协议能够提供有效的数据通信基础，基于RabbitMQ消息中间件的MQTT插件实现了物联网云服务.三种终端通过订阅发布机制实现物物相连.

4 系统具体实现

4.1 基于Netty的长连接服务器实现

Netty框架为高性能异步服务器的设计提供了良好的接口，在该框架中，需要用到两个比较重要的模型，一个是前端连接处理的多线程Reactor模型，还有一个是串行化的基于责任链模式的处理模型.多线程的Reactor模型的运行过程如图5所示［5］.

图5 多线程Reactor模型

Acceptor线程接收客户端的连接，注册到Selector选择器，有新的数据可读或者可写的时候在IO线程池中取出一个线程进行数据的读写.为了避免多线程上下文的切换，Netty框架采用了串行化的处理理念，在管道中执行Handler，完成用户自定义的业务需求.一般来讲重点处理三类业务，分别是客户端连接管理，客户端心跳包处理，自定义业务逻辑处理.

(1)客户端连接管理.借助于Netty框架提供的接口能够快速的管理客户端连接，如图6所示.支持IO端口多路复用的Selector在取得读报文事件以后，随机选择IO线程池中的一个线程，在注册的自定义报文处理中，把客户端连接的上下文发送给客户端连接管理器，由多线程共享的Map存储客户端连接的ID与上下文的键值对.这种方式的优点在于责任明确，软件模块耦合度很低，用户连接采用统一模式继续管理，便于后续的客户端管理.在代码实现过程中，DataCenterChannelManager类采用单例模式进行设计，有利于全局调用.

图6 客户端连接管理时序图

(2)客户端心跳包处理.要保持客户端的长连接，在无业务数据的时候有必要发送或者接收心跳报文.对于分布式微电网智能客户端来讲，采用DTU连接网络的客户端，心跳报文来自于智能客户端的主动上传.基于Netty框架的心跳包处理在业务链中添加对于心跳的业务逻辑处理即可，如图7所示.

图7 客户端心跳包处理流程

Dtu处于移动网络的内网，为了减少连接负载，移动网络会在没有消息发送的时候断掉客户端连接，因此为了保持长连接，DTU终端心跳时间要小于移动网络断开连接时间.每个网络断开连接时间不确定，根据生产实践，将DTU心跳时间设置为60秒，而服务器端处理心跳的时间设置为120秒，超过120秒没有收到心跳报文则断开当前连接.在事件处理链中只需要添加IdleStateHandler事件处理器即可.

(3)基于责任链模式的自定义业务逻辑处理.在报文处理过程中除了报文的分拆，心跳的处理，非常重要的就是业务逻辑的处理.在业务逻辑处理阶段，为了减少业务处理引起的性能瓶颈，通过异步的消息中间件把同步消息转换为异步的消息处理.自定义的业务逻辑处理模块继承自ChannelInbound－HandlerAdapter，将该模块注册到Pipeline中即可.

4.2 支持高IO的业务逻辑处理模块

在系统中引入消息中间件来支持对于高IO的业务逻辑处理.Netty中的worker线程在解析完成数据报文以后，将要处理的数据封装发到消息中间件的缓冲区中，由消费者线程从缓冲区中取出，处理完成，存入数据库.

(1)生产者线程向缓冲区存入消息.生产者线程就是IO处理线程池中的Worker线程，在自定义业务逻辑处理模块中，对报文做好业务封装，传入消息池.业务处理模块使用AMQP协议连接Host，经过安全验证以后将消息发到相应的队列中去，如图8所示.

图8 生产者线程存储消息时序图

(2)消费者线程处理缓冲区中的消息.消费者子线程在连接到Host的指定队列以后，进入循环轮询，查询到消息队中有消息时候，取出来进行处理，将结果持久化到服务器中去.

4.3 支持MQTT协议的跨平台消息服务器搭建

MQTT协议目前已经有较多的成熟的Server/ Broker实现［6］，比如IBM WebSphere MQ Telemetry，IBM WebSphere Message Broker，IBM Lotus Expeditor micro broker，Really Small Message Broker，开源的Mosquitto，基于云计算的 m2m.io等等.RabbitMQ 3.0以后的版本通过插件机制已经可以支持MQTT协议，因此可以在跨平台消息服务器搭建过程中，采用消息中间件RabbitMQ.目前已经有广泛的MQTT 的Client包用于支持应用程序的开发，常见的有支持C语言的Liblwmqtt，支持JAVA的Mqtt－client，支持.NET平台的MQTTDotNet，支持Python语言的MQTT－For－Twisted－Python，支持Arduino设备的Arduino client for MQTT等等.根据Android开发模型的特点，信息的订阅与发布放在Service内实现，没有放在Activity里面实现.该模块的开发充分考虑了智能终端，比如Android、Ios客户端与微电网客户端的点对点通信问题，整个结构如图9所示.

图9 支持MQTT协议的跨平台消息服务器架构

智能客户端，比如 Ios、Android客户端根据MQTT协议发布或者订阅消息，消息持久化到消息队列中去，worker线程获取到主题消息，根据消息ID的不同来发布微电网客户端的最新状态或者是更新微电网客户端的状态.

5 小结

本文基于微电网建设的实际情况，根据微电网的项目要求，重点考虑了微电网的基于DTU客户端的连接管理，跨平台多种客户端的通信，业务逻辑高效稳定的处理等多方面的实际需求，采用了开源的方案来解决实际问题，Netty框架解决客户端连接问题，消息中间件解决数据处理问题，MQTT协议的引入解决跨平台客户端连接问题，实践证明，该方案能够满足系统的功能要求，高效稳定的运行.整个系统采用单台消息中间件，单台服务器进行处理，后期对于负载不断增长要做好系统优化工作.基于MQTT协议的分布式微电网智能硬件还在开发中，后期硬件接入也要做好功能测试和性能测试工作.

［1］NIO入门.［EB/OL］.http://www.ibm.com/developerworks/ cn/education/java/j－nio/j－nio.html

［2］李林峰.Netty权威指南［M］.北京:电子工业出版社，2014.

［3］阿里中间件团队.Kafka、RabbitMQ、RocketMQ消息中间件的对比——消息发送性能［EB/OL］.http://jm.taobao.org/2016/04/ 01/kafka－vs－rabbitmq－vs－rocketmq－message－send－performance/

［4］孔祥龙，王燕.适用于低成本物联网终端的消息通讯协议比较研究［J］.无线互联科技，2015(16).

［5］李林峰.Netty系列之 Netty线程模型［EB/OL］.http:// www.infoq.com/cn/articles/netty－threading－model

［6］IBM公司.Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry［EB/OL］.ibm.com/redbooks

(责任编辑:王前)

TP39

A

1008－7974(2016)06－0016－05

10.13877/j.cnki.cn22－1284.2016.12.005

2016－09－15

南通市分布式发电与微电网技术重点实验室(CP12015007);江苏工程职业技术学院自然科学研究项目(GYKY/2016/15)

曲豫宾，男，河南南阳人，讲师.