王 琪，卢 军

（武汉邮电科学研究院湖北武汉430074）

随着我国经济的快速增长，各项建设都取得了巨大的成就，但与此同时，也付出了巨大的资源与环境破坏的代价，两者之间的矛盾日益尖锐，这种状况与资源的不合理利用和能源的严重浪费直接相关[1]。国家“十三五”规划强调所有的工厂与企业要绿色发展，促进人与自然的和谐共生。因此打造一个能效管理系统对工厂、企业的能源利用进行实时监控，实现最大限度的能源利用，避免资源浪费是至关重要的。同时又考虑到企业和工厂的不断发展，为了系统的持续可用性[4]，实现一个基于分布式架构的能效管理系统是非常有必要的。

系统采用Java语言，基于Dubbo框架设计了一套集权限管理、设备管理、数据采集、数据分析、设备报警、报表产出以及日志记录与一体的分布式架构能效管理系统，满足企业的需求。

1　相关技术概述

1.1　Dubbo服务框架

Dubbo是一个扩展性和灵活性都很好的服务管理框架[7]。其主要核心部件是服务运行容器、服务注册中心、服务提供者、服务消费者、服务监控中心。

1.2　ZooKeeper概述

ZooKeeper是为分布式应用程序提供高性能协调服务的工具集合，它包含一个简单的原语集，分布式应用程序可以基于它实现配置维护、命名服务、分布式同步、组服务等，在本系统中被用作Dubbo的服务注册中心，用以协调分布式应用[10]。

1.3　MySQL数据库

MySQL是一个小型关系型数据库管理系统，因为其体积小、速度快、再加上开放源码这一特点，很多网站在开发时都使用MySQL作为网站数据库。

2　系统设计

2.1　系统整体架构设计

整个系统主要分为5层，分别为Webserver入口、控制层、中间件服务层、微服务层和数据存储层。控制层在整个系统中就是最大的服务消费者，调用所有提供者的服务，返回前端Web页面，中间件服务层就是对整个能效管理系统所用到的中间件管理，微服务层主是业务逻辑和系统功能需求的实现，数据存储层用来存储、读写数据。系统整体设计架构如图1所示。

图1　能效管理系统整体设计架构图

微服务层由基础微服务、权限微服务、日志微服务、数据微服务、设备微服务、采集微服务、分析微服务、报警微服务、报表微服务组成。对于控制层Webserver来说，所有的微服务都是其服务提供者，自己是服务消费者。但在微服务层内部，我们根据系统业务的实际需求，微服务之间也有服务提供者和服务消费者之分。每一个微服务既可以作为服务提供者也可以作为服务消费者。

2.2　系统模块结构设计

根据实际的需求分析，整个系统模块设计如图2所示。

图2　能效管理系统模块结构图

2.3　系统数据库设计

设计系统采用MySQL作为数据库存储业务数据，Mongodb作为文件数据库存储文件，Redis作为辅助用来缓存数据，减少数据库的调用次数，提高数据读写速度。系统将采用分库设计，每个微服务使用自己独立的数据库，如图3所示。

图3　能效管理系统数据库设计图

每一个微服务对应一个属于自己的独立数据库，将自己的业务数据存到数据库表中。同时为了提高系统读取效率，将复杂、常用的数据存入Redis缓存中，若是需要直接从Redis中读取，不再操作数据库，提高系统读写速度。对于系统中的图片、文档等文件类型数据，用Mongodb统一存取。

3　系统实现

根据对整个系统的设计，系统主要可以从以下4个方面来实现，中间件服务的搭建，Webserver、微服务以及数据库的实现。

3.1　中间件服务搭建

系统中用到的中间件主要是ZooKeeper与Dubbo，并且所有中间件服务都在Linux服务器上部署。

3.1.1　ZooKeeper服务搭建

在系统中ZooKeeper用作Dubbo的注册中心，实现Dubbo服务提供者的注册和服务消费者的订阅，主要配置如图4所示。

图4　ZooKeeper主要配置图

配置好之后，在ZooKeeper服务bin目录下打开命令窗口输入命令“./zkServer.sh start”后，ZooKeeper即可启动。

3.1.2　Dubbo服务搭建

Dubbo是整个系统的基础，所有的微服务都是通过Dubbo来注册和运行。Dubbo配置如图5所示。

图5　Dubbo主要配置图

注册中心地址就是之前搭建的ZooKeeper服务的地址，root和guest用户是登录到Dubbo调控中心的用户名和密码。将Dubbo服务放到tomact webapp目录下，在bin目录中打开命令窗口输入命令“./startup.sh”即可启动。

3.2　Webserver服务实现

Webserver是整个系统的服务消费者，它依赖所有的微服务，以报警微服务为例，配置如图6所示。

3.3　微服务实现

图6　Webserver配置图

每个微服务只实现自己的功能，权限微服务用来控制登录权限、展示界面和用户管理；数据微服务用于管理KPI系数等系统预先导入的数据；日志微服务，详细记录系统登录用户的每一步操作；设备微服务管理系统中所有的水表、电表等仪器设备；采集微服务采集设备上报的数据给其他微服务使用并存进数据库；分析微服务可以以图标或点线图形式展示给用户设备数据对比等信息；报警微服务收到采集微服务上报的数据之后，与事先设置好的报警阈值进行对比，保障设备安全；报表微服务，以excel或word方式导出整个厂区的能耗情况报表信息。

每个微服务由Model、API、Server 3个工程组成，Model主要存放实体类，API存放该微服务所要用到的所有接口，Server存放接口实现类和各种配置文件，处理业务逻辑。这三个工程层层依赖，API需要依赖Model，Server需要依赖Model和API。每个微服务都需要通过Dubbo进行注册。下面以报警微服务配置为例进行说明，如图7所示。

图7　微服务配置图

3.4　数据库实现

系统采用分库设计，不再是一库多表，而是每个微服务对应自己的数据库，互不干扰，如图8所示。

图8　系统数据库实现图

3.5　系统功能展示

根据上述几个方面，将系统实现后，进行系统功能展示。

3.5.1　系统登录

根据设定的角色和用户名密码判断用户是否能够登录，登录界面如图9所示。

图9　系统登录界面图

3.5.2　系统能耗月度对比分析

此功能在分析微服务中实现，采集微服务采集到设备数据之后将数据推送给分析微服务。选中某一台设备之后，将根据用户选择的月份以点线图和图表的方式将该设备数据展示出来，通过数据对比可以很清楚地了解每个月每台设备的能耗情况，方便后期的能源调控，如图10所示。

图10　系统能耗月度对比图

3.5.3　系统角色权限管理

此功能在权限微服务里实现，对于不同的角色，可以任意配置菜单，在该角色的用户登录之后，可以看到不同的界面和具有不同的操作权限，如图11所示。

4　系统测试

系统测试是保证系统质量和可靠性的关键步骤，是对系统开发过程中的系统分析、系统设计和实施的最后复查。

图11　系统角色权限管理图

根据分布式系统的特点，分别在两台机器A和B上启动微服务，A启动基础、权限、分析3个微服务，Webserver和剩下的微服务都由B启动，系统启动成功。之后在B上也启动权限微服务，通过监控中心和调控中心可以看到，当系统调用到权限微服务时，会根据负载均衡策略去调用A或B，系统运行正常。Dubbo监控中心和调控中心如图12、图13所示。

图12　Dubbo监控中心

图13　Dubbo调控中心

5　结束语

文中通过对能效系统需求的分析以及对未来发展趋势的预测，设计和实现了一种基于Dubbo的分布式能效管理系统。系统采用了以Dubbo为基础框架的分布式架构，采用微服务模式，降低了系统耦合，提高了系统性能，再加上监控中心和治理中心的使用，方便了系统的后期维护或二次开发，通过具体的应用测试，展示了系统的可用性和使用价值。今后将主要关注系统性能优化方面的问题，如数据库的优化、负载均衡的使用策略等，进一步提高系统的稳定性、安全性，加深用户体验。

参考文献：