微服务架构在继电保护故障信息主站系统中应用研究

王志轩 王永刚 沈永良 邬军军

摘要：在大数据时代，电力系统运行方式日趋复杂，业务应用变得越来越庞大，若电力信息系统依然采用单体架构，复杂的代码以及紧密的耦合关系会导致牵一发而动全身，无法快速高效的进行项目的开发维护以及扩展。而微服务架构的出现，有助于大型项目解耦，从而实现快速开发。本文首先对不同架构在电力信息系统的应用进行了介绍，分析了不同架构的优缺点，然后针对微服务架构在电力系统中的继电保护故障信息主站系统的应用进行了可行性研究，提出了一种软件设计方案。

关键词：微服务架构;继电保护;故障信息主站

中图分类号：TM774 文献标识码：A 文章编号：1007-9416（2019）09-0095-03

0 引言

近年来，电力信息系统架构经历了从单体架构到面向服务SOA架构的发展历程。图1是一个单体架构模型，如图所示，单体架构将所有的功能模块集成在一个项目工程中，作为一个整体运行，这样的架构优点是项目架构简单，开发周期短，对于小型项目比较友好，但是全部功能集中在一起的特点，对于大型项目，由于复杂性的升高，部署频率会随之降低，给开发扩展以及后期维护带来很大麻烦。

单体架构为了实现可扩展以及可靠，增加负载均衡，就成为垂直架构。后来发展出的服务导向架构（service-oriented architecture，缩写 SOA）抽取重用的功能作为组件，通过“服务”接口的方式提供给系统其他应用，基于服务组件的SOA使得系统更易于维护，大大提高了可重用性，但是由于系统和服务之间的界限不够清晰，加上抽取的服务组件粒度较大，系统与服务耦合性高，在开发上需要更多的投入。

作为SOA的升级，微服务架构，英文全称为MICROSERVICES ARCHITECTURE，是一种较新的架构思想，微服务和SOA架构都是使用对外提供接口的方式实现系统功能，微服务架构在细粒度上更精细，接口更通用。

1 原理介绍

1.1 微服务架构

2014年，Martin Fowler在其博客文章《Micro Services》首次提出微服务概念，微服务围绕业务领域，通过分解功能的方式，将一个系统分解成一个或多个组件，从而实现独立开发管理，每个组件被称为微服务。每个微服务代表一个小的业务能力，微服务之间松耦合，可被独立部署。谷歌、推特等很多互联网公司开始使用微服务架构来实现其业务逻辑。

微服务架构模型如图2所示。

微服务架构下的系统具备如下特点：

更灵活：不同微服务之间的松耦合关系使得系统的更改对微服务影响更小，微服务可以按需更改;

易开发：不同微服务可由不同团队甚至不同编程语言、不同数据库进行并行开发，只需对外提供API服务，提高开发效率;

易测试：每个微服务可独立进行部署测试，降低了部署测试的难度;

微服务的缺陷在于业务逻辑复杂的情况下微服务数量可能过多，导致服务治理成本的升高。

1.2 微服务框架Dubbo

Dubbo作为一个阿里巴巴自主研发的一个分布式服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及提供SOA服务治理解决方案，自2012年开源以来，深受开发人员欢迎。

如图3所示，Provider作为服务提供者，通过向注册中心注册的方式暴露服务，并向监控中心汇报调用时间，Consumer是调用远程服务的服务消费者，向注册中心订阅所需服务。各个组件名称及功能如表1所示。

1.3 Kafka消息总线

消息总线关乎系统内实时数据的转发性能，对模块间交互设计具有较为关键的影响。

Kafka由LinkedIn开发，作为一个高时效、分布式、支持分区的和多副本的基于发布/订阅的消息系统，Kafka具有高吞吐率、可扩展、低延迟、容错性等特点，可实时处理保信主站业务中大量的数据。其使用场景包括消息系统、日志收集、流式处理。

此外，Kafka消息总线还可以搭配Redis实时内存数据库，打造出超高性能数据处理基础架构。

如图4所示，Producer是消息的发送者，Consumer作为消息的消费者对消息进行消费，消息通过Topic进行分类保存。

2 基于微服务架构的系统模型

如图5所示，架构采用前后端分离的方式，客户端命令通过调用业务层微服务接口进行用户操作以及界面展示。微服务模块包含： Kafka消息总线微服务、模型初始化微服务、数据召唤微服务、WEB發布微服务，主动上送微服务、故障归档微服务以及其它各个业务微服务模块，此外还有数据库访问微服务模块。不同微服务之间通过Dubbo框架实现接口之间的调用。

考虑到数据库使用场景较多，不同业务下均有涉及，而且数据之间存在关联，本系统选用数据共享模式，微服务之间的数据共享在一个数据库模块中，供所有微服务模块使用。

数据库使用历史数据库MongoDB+实时数据库Redis+模型数据库打造出高性能的数据存储模式，每个数据库提供相应的访问接口：MongoDB历史库访问微服务，Redis实时库访问微服务、关系型数据库访问微服务。历史库和实时库之间通过数据同步微服务实现数据的更新同步。

数据从子站通过103或者61850通讯协议发送到通讯前置，通讯前置将消息发送Kafka消息总线，由Kafka消息系统进行统一发布、供消息消费者订阅。业务处理微服务进行消费并通过数据库访问微服务接口进行数据库操作。

3 结语

本文对电力信息系统几种软件架构方式进行了介绍，着重对微服务这一架构思想进行了利弊分析，提出了一种基于微服务架构的继电保护故障信息主站系统软件设计方法，系统主要优势在于易维护、可扩展、高性能，解决了传统单体架构的一些弊端，为微服务架构在电力信息系统中应用提供了一些参考。