基于Kafka的分布式能效管理平台的设计与实现*

朱幼普 卢 军

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

1 引言

随着互联网技术的发展越来越迅速，通过信息化管理平台对能源进行分配和管理，实现能源的信息化监管和控制，从而达到节约能源和保护环境的目的也越来越明确。如何将各种计量设备（水表，电表，传感器等）采集的数据进行实时可靠的传输，如何应对计量设备数据准实时访问的业务应用需求、提高计量设备采集数据的准实时应用能力，以及对计量设备状态的准实时监控，成为搭建能效信息化管理平台需要考虑的关键问题。Apache Kafka，作为一种分布式的消息系统，由于具有可水平扩展、高吞吐率和实时性等优点而被广泛的使用。本文重点研究数据的传输过程，并搭建了一个基于Kafka分布式消息队列的能效数据管理平台，为机关或小区的分项用能数据的智能采集，状态监控、统计分析和能耗管理等提供了良好的支持。

2 相关技术介绍

2.1 Kafka分布式消息系统

Kafka是由Linked In研发的一个分布式消息系统，它以具有水平扩展和高吞吐量率的特性而被广泛使用。目前越来越多的开源分布式处理系统，例如Storm、Spark都支持与Kafka集成［1］。

近年来，对流数据和运营数据的分析处理已经成为在线分析、实时监控等应用的重要组成部分［2］。Kafka正是针对这样的需求，将海量且复杂的数据进行分布式缓存的消息系统［3］。其主要设计目标如下：

1）高效的数据持久化能力。能够在常数时间复杂度实现TB级以上的数据读∕写入硬盘。

2）高吞吐率。在廉价的商用机器上单机可支持每秒100万条消息的读写。

3）支持在Broker中进行消息的分区存储，并且对分区中消息的读取是有序的。

4）在线也能实现水平扩展。

Kafka分布式消息系统在收集和分发海量的日志数据文件时具有较低的延时性［4］。它可同时支持数据的在线处理和离线处理。Kafka的系统设计（例如，分布式架构，分区存储，顺序硬盘读写等）使其在吞吐量和可伸缩性方面具有很好的表现。Linked In公司在使用Kafka一段时间后，每天的数据处理量可以达到百G级别。

Kafka的架构如图1所示。

图1 Kafka架构图

本文的能效管理系统之所以选用Kafka作为实现各个微服务之间数据缓存与订阅模块主要由于其具有以下优势：

解耦合：各个微服务通过实现Kafka这个统一的接口进行数据交换，降低了系统模块之间的耦合。

可扩展性：若采集微服务向Kafka推送的消息量剧增，可通过水平扩展Kafka的broker节点实现消息量的负载均衡。

强大的缓冲能力：面对微服务之间访问数据量的剧增，Kafka消息队列可以有效地缓冲系统的流量压力，避免系统在大数据的压力下崩溃，保证了系统的稳定性［5］。

健壮性好：作为分布式消息系统，Kafka在部分功能失效的情况下，不会影响整个系统的正常运行。

2.2 Zookeeper［6］

Zookeeper是一个高性能，开源分布式应用协调服务。分布式应用可以基于它实现更高级的服务，比如同步，配置管理，集群管理，名空间。Zookeeper使用文件目录树作为数据模型。

针对学生整体英语基础差、听力能力普遍较低、听力训练投入时间不足和大学英语听力教学课时锐减、大学英语四、六级考试听力分值比例增加的严峻现实，独立学院的大学英语教师应积极按照《大学英语教学指南》的要求，充分利用现代信息技术，为营造多渠道、多方面的教学环境和学习环境；独立学院非英语专业学生更应积极配合老师，在信息技术环境下，积极进行听力练习，来提高自身的英语听力能力。

由于Zookeeper可配置管理分布式系统，因此Kafka集群通常使用Zookeeper进行协调管理。Kafka代理的增加和减少都将触发Zookeeper服务通知生产者和消费者，生产者和消费者就会与Kafka集群中的其它代理协调工作。

3 基于Kafka分布式能效管理平台的设计

3.1 系统的整体架构设计

系统整体划分为五个层次，从上到下依次为接入层、控制层、中间件服务层、微服务业务支撑层和数据存储层。如图2所示：

接入层：接入层由Nginx服务器集群组成，用户请求首先发送到接入层，Nginx服务器接收到用户请求后，通过负载均衡将请求反向代理到控制层［7］。

图2 系统整体架构设计图

控制层：控制层使用Spring Boot作为开发平台。Spring Boot提供了开箱即用的SpringMVC框架，使用SpringMVC处理接入层转发过来的请求大致可分为三种情况：1）从Redis缓存中读取数据；2）从MongoDB中获取上传的文件或图片［8］；3）调用微服务接口执行业务。另外，需要配合Redis缓存服务器实现session共享。

中间件服务器层：使用Zookeeper作为服务注册配置中心，所有向外提供接口的微服务都需要在Zookeeper上进行注册后方可被其他消费者调用。控制层在处理用户请求时，将作为服务接口的消费者，在Zookeeper上查询和执行相应的微服务。在Zookeeper之上配合Dubbox对微服务进行管理和监控。将Redis作为缓存服务器，一方面为控制层提供session共享支持，另一方面为分布式系统提供缓存服务，加快数据查询响应速度和效率［9］。将Kafka作为消息通信服务器，支撑各个微服务之间的通信，实现消息收集和传播的功能。

微服务业务支持层［10～12］：

2）日志微服务：记录用户操作日志和系统日志，提供日志录入和查询的接口；

3）权限微服务：维护用户、用户组、角色、菜单、按钮数据，提供鉴权的接口；

4）设备微服务：维护计量设备、电网环境、能耗设备、节点信息；

5）采集微服务：采集计量设备上报的实时数据，并将数据记录到日示数表，配合Redis缓存支撑报表查询业务；

6）报警微服务：维护报警等级、报警级别、报警类型和实时报警数据，配合Redis缓存支撑报警报表业务；

7）外部数据微服务：提供第三方数据的导入、存储和查询的接口，为报表提供数据支持；

8）报表微服务：提供报表数据获取，分析和查询；

9）分析微服务：对采集微服务采集的数据进行处理，并将处理结果存入数据库中。

3.2 基于Kafka的数据传输流程实现

本系统中，Kafka是微服务之间通信的媒介［13～14］，至关重要。计量设备采集的数据是我们需要分析利用的数据，这些数据存储在专门的数据库文件中，当其他微服务（例如分析微服务或报警微服务）需要对这些数据进行分析处理时，采集微服务作为消息的推送者（producer），会先将数据推送到Kafka集群中，Kafka集群则将这些数据以日志文件的形式持久化到硬盘中，分析微服务和报警微服务作为消费者（consumer），会从Kafka消息队列中拉取数据进行消费，消费者对每一条消息的消费情况会同步到Zookeeper服务器集群中，若某个微服务出现异常停止消费，Zookeeper会将此消费者最后消费消息的偏移量offset记录下来，等到微服务恢复正常后从此偏移量继续消费消息，从而确保每条消息被成功消费。因此，本系统在数据传输方面的设计具有较高的可靠性。此外，本系统采用Kafka提供的数据批处理的接口，计量设备采集的数据批量传输到Kafka集群中，其他微服务从Kafka集群里批量拉取数据进行分析处理，减少了网络传输的开销，使整个系统的性能更高。

4 实验验证与结果

4.1 实验环境

实验环境所用服务器为高性能服务器，机器配置如表1所示。

测试主机有3台，用于搭建Kafka和Zookeeper的集群，3台主机网络配置信息如表2所示。

表2 Kafka测试集群信息

4.2 实验过程及结果

启动Kafka集群和Zookeeper集群，准备一定规模的源数据进行采集，设定采集微服务向Kafka集群中推送消息的时间为每5分钟一次，然后依次启动分析微服务，报警微服务等来消费这些数据，通过Kafka自带的监控工具来查看数据消费的情况。

实验结果如图3所示，图中描绘了对于不同数量的平行消费者，消息的吞吐量变化的趋势。图中的虚线代表消费者每秒钟消费的消息条数，实线代表消费者每秒钟消费的消息数据量的大小，从图中可以清晰地看出，随着平行消费者数量的增加，数据的吞吐量基本呈线性增加。

图3 消息吞吐量

5 结语

作为新一代分布式消息系统，在大数据背景下的今天，Kafka为我们处理海量数据提供了研究方向。本文利用Kafka在数据传输方面的优势，设计了一个实时可靠的能效信息管理平台，确保了设备采集数据传输的实时性和可靠性，而且采用Kafka分布式部署的方式，提高了平台的可扩展性。然而，在某些极端情况下，本系统也存在缺陷，当采集微服务持续不断地向Kafka集群中推送消息时，会导致Kafka需要保存的数据量非常大，整个系统的性能会受到影响［15］。针对此问题，在下一步研究中，我们还需要对系统进行更深入的优化，使系统具有更好的性能。