基于微服务架构的电力基建全过程管理平台

郝鹏海，密兴峰，朱 军，时 旭

（南京南瑞信息通信科技有限公司，南京 210003）

0 引言

随着电网建设业务的不断发展，用户数据量越来越大，业务需求日益多样化和复杂化。传统的基于单体架构设计的电网基建信息化管理平台已不能有效支撑电网基建业务的发展，很多局限性已经开始体现。其中包括：

（1）代码业务耦合严重、可靠性差。随着基建平台业务的扩展，单体架构下的业务耦合严重，一旦一个模块出现问题，将会影响整个平台的运行，同时开发过程中要花费时间理解业务，开发效率大大降低。

（2）增加技术债、部署困难。代码、组件之间的依赖过多，导致一些技术债难以被修复，并且随着代码量的增大，系统的全量部署费时费力。

（3）扩展性差，在贯彻落实公司建设三型两网现代化一流能源互联网企业战略目标，实现电力系统各个环节万物互联、人机交互，打造状态全面感知、信息高效处理、应用便捷灵活的泛在电力物联网的背景下，平台对计算机资源的要求越来越高，传统的单体架构各个组件对计算机资源的要求不同，很难有效地扩展和分配资源。

基于当前电力基建工程项目管理过程中出现的问题，本文设计了一种基于微服务架构的电力基建全过程数字化管理平台。将基建平台根据业务场景拆分成了多个微服务，从而达到系统的解耦。同时基于Spring Cloud 中间件，采用去中心化、服务化、异步化、高可用设计思路，提高了系统的可靠性和稳定性。

1 系统架构技术

1.1 微服务架构技术

微服务架构是近几年来软件架构领域出现的高频词汇，是基于传统的SOA 架构演进而来的一种架构模式，微服务架构将应用程序构建为以业务领域为模型的小型自治服务集合，其提倡将传统的单体架构或分布式架构中的单体应用程序和服务划分成更小粒度的服务，这种服务称之为微服务。微服务独立开发部署，并与其他的微服务互相隔离。微服务之间提供restful 风格的服务，通信协议采用http 协议，每个微服务都围绕着具体的业务而构建。这些服务共用一个最小型的集中式管理，服务可用不同的语言开发，并使用不同的存储技术。相比于传统的单体架构，微服务架构的优点主要有以下几个方面：微服务将一个大型的系统按照功能拆分成了一系列独立的解耦的微服务，其能独立地开发、构建、发布和部署，而不影响其它的依赖业务，极大地简化了单体架构的复杂性，系统的开发、扩展和维护的成本都大大降低。并且微服务架构（见图1）的技术选择不受约束，同一个系统内的每个微服务都可以采用不同的适合自身业务需求的技术和存储方式，因此系统的性能也显著提高。

图1 微服务架构图

1.2 基建全过程系统微服务技术选型

目前主流的微服务框架有Dubbo 和Spring Cloud。由表1 可知，Spring Cloud 拥有更多的项目模块，例如网关、链路追踪等。相比于RPC调用，基于http 协议调用的rest 方式通过牺牲少量的服务调用性能，消除了服务提供方和调用方代码级别的强依赖。并且Spring Cloud 作为Spring 的旗舰项目，它能够与Spring Framework、Spring Boot 等Spring 项目完美融合。基建管理平台整合多种业务，需要支持多语言，同时为了实现项目的持续集成、快速交付，服务内部使用统一的技术框架更有效率，因此选用Spring Cloud作为系统的设计架构。

表1 Spring Cloud和Dubbo功能对照表

2 基建全过程综合管理系统架构设计

基建平台采用微服务微应用技术路线，微服务基于Spring Cloud 分布式框架开发，微服务之间在注册中心Nacos通过Feign 组件相互调用，并引入Spring Zuul 和Nginx 组件做负载均衡处理，Hystrix 处理微服务调用降级及熔断问题，应用Redis 做分布式缓存，Kafka 消息队列做微服务异步解耦以及消息的订阅与消费，采用Zookeeper 提升Kafka 的高可用性能，引进ElasticSearch 提升平台的数据搜索速度。平台技术架构采用分层设计，自下向上分为基础设施层、平台层和应用层共三层，系统架构图如图2所示。

图2 微服务架构电力基建全过程管理平台架构图

2.1 应用层

PC 应用前端开发采用渐进式框架Vue2.x，移动应用采用i 国网作为基础开发框架。采用HTML5 前端开发技术，提供平台统一工作入口和工作台，移动应用工作台等，实现直接面向终端用户的交互界面。

2.2 平台层

平台层自上而下分为网关服务层、业务服务支撑层和平台服务支撑层。网关服务层采用Spring Zuul 和Nginx 实现负载均衡。基建全过程管理平台后端服务部署在多台云服务器上，使用Nginx 做反向代理，把前端的请求进行分发，多台服务器平均分担负载，实现负载均衡，减轻单台服务器的压力。如图3所示，Zuul通过一系列的Filter 将整个HTTP 请求过程连成一系列操作来实现对HTTP请求的控制。

图3 Spring Zuul的处理流程图

用户使用浏览器打开基建全过程管理平台，向Spring Zuul 发出请求，请求被路由之前首先调用前置过滤器PRE Filter，进行身份验证、资源审查、记录调试等操作。然后通过路由后过滤器ROUTER Filter 将请求路由到微服务实例，紧接着响应发送到后置过滤器POST Filter，为响应添加标准的HTTP HEADER、收集统计信息和指标，并且把响应从微服务发送到客户端。在请求发送过程中如果发生错误，将会执行异常过滤器ERROR Filter。

业务服务支撑层分为职能管理和项目管理。职能管理包含计划管理服务、技术管理服务、技经管理服务、安全管理服务、质量管理服务、队伍管理服务六大专业。计划管理服务提供项目年度计划编制、季度预测、计划开工在建投产统计等功能，支撑项目整体进度情况把控的相关内容。技术管理服务提供新技术新材料成果管理、施工装备管理、施工图设计管理等设备成果管理服务，为技术成果、设计图纸、施工装备信息的录入、申报、下达、编制等工作提供支撑。技经管理服务提供项目可研估算管理、施工图预算管理、工程结算管理、农民工工资支付等服务，支持报表的上传、解析功能。安全管理服务提供安全检查管理、作业票统计、风险预警发布等功能。质量管理服务提供质量检查分析、标准工艺管理、质量验收分析等功能。队伍管理服务提供职能管理队伍、项目管理队伍、技术支撑队伍、施工骨干队伍四支队伍的信息注册、录入、审核、查询功能，同时为基建队伍专业能力评价录入、结果管理等工作提供支撑。项目管理提供基建项目建设中的项目前期、工程前期、工程建设和总结评价四个阶段的信息管理以及流程审批功能。

业务服务层用微服务微应用思想，设计实现业务服务中心，将基础全过程管理平台各项基础功能拆分为对应的微服务、微应用，通过基础功能微服务API 互调用，支撑完整的基建全过程管控需求。按职能管理、项目管理两条主线，将服务中心的基础能力进行组合，形成可支撑实际业务流程、业务功能的各项业务服务，保障业务变更的灵活性，支撑上层业务需求。

平台服务支撑层包括流程服务、权限服务、审计服务等基础服务，保证业务流程的正常流转。

2.3 基础设施层

结构化数据存储采用MySQL一主多从配置，每个微服务一个数据库Schema 模式，冷备采用每日全量备份模式，非结构化存储采用UDS 文件平台，实现内外网文件同步，缓存采用Redis存储会话、菜单权限、高频业务操作数据等；通过UEP 消息中间件ActiveMQ 和UDS 文件平台实现数据的纵向贯通。

3 基建全过程综合管理系统实现

3.1 服务注册与发现

微服务架构将复杂的大型应用拆分成了多个高内聚、低耦合的小型微服务，从而实现快速的迭代更新。但是随着业务的扩充，微服务数量的增多，服务之间的调用关系也越来越复杂，服务的维护成本大大增高。因此引入了服务注册中心。服务注册和发现指每个微服务向注册中心汇报自己的服务地址、服务内容、端口和服务状态等信息，当有服务依赖此服务时，从注册中心获取可用的服务列表并发起请求，服务消费者不用关心服务所处的位置和状态，具体用哪个实例对外提供服务则由注册中心决定。目前主流的服务注册与发现产品有Spring Cloud中提供的Eureka和阿里开发定制的Nacos。

相比于Eureka，Nacos 服务实例的修改响应更快，同时Nacos 集注册中心与配置中心于一身，方便服务与配置的统一管理。因此选用Nacos 作为基建管理平台的注册中心，注册原理如图4所示。

图4 Nacos注册原理图

3.2 微服务子系统的构建

微服务的开发基于Spring 全家桶，服务开发框架SpringBoot，服务治理框架Spring Cloud以及持久化框架Mybatis。以计划管理服务progress-service 为例说明微服务子系统的构建流程。

（1）使用maven 构建项目，在依赖文件pom.xml中添加相关的依赖，如服务注册中心、服务配置中心nacos-discovery 依赖以及各种服务模块。在bootstrap.yml配置文件中配置微服务的启动端口server.port，nacos注册中心的地址，数据源配置和mybatis配置等相关服务配置。

（2）生成服务启动类，用于启动微服务。在服务启动类上添加@EnableDiscoveryClient 注解，开启服务发现注册功能，添加@MapperScan 注解，用于扫描DAO 层的接口到容器中。添加@EnableFeignClients 注解，用于启动feign 客户端。部分代码如下：

@SpringBootApplication （scanBasePackages= "com.nariit.emp"）

@MapperScan（"com.nariit.emp.progress.core.mapper"）

@EnableDiscoveryClient

@EnableFeignClients（basePackages="com.nariit.

emp"）

@RefreshScope

@EnableScheduling

public class ProgressApplication ｛

public static void main（String［］args）｛

SpringApplication.run（ProgressApplication.class.args）；

｝

@Bean

public RestTemplate restTemplate（）｛

return new RestTemplate（）；

｝

｝

（3）微服务相关接口的开发，包括DAO 层、service 层、controller 层的开发。对于远程调用的接口，创建接口时使用@FeignClient 注解，name 中的参数为注册在nacos 中的微服务名称，接口上的value 为接口的调用url，别的微服务调用计划管理服务progress-service，只需要在接口服务层注入ProgressClient 实例，直接通过方法名即可通过Feign 完成计划管理服务的远程接口调用。部分代码如下：

@FeignClient（name=${progress-service},fallbackFactory=ProgressClientFactory.class）

Public interfaces ProgressClient｛

@PostMapping（value="/progress/demo/getPrjInfoByPrj-Code"）

R＜List＜ProjectInfo＞＞getPrjInfoByPrjCode（String projectId）;

｝

（4）启动计划管理微服务，通过swagger 验证服务的可用性。图5为接口调用界面。图6 为progress-service服务Nacos注册图。

图5 swagger接口验证界面

图6 progress-service服务Nacos注册图

3.3 基于微服务架构的基建全过程管理平台的部署

基建全过程管理平台部署在自建云环境。互联网边界部署了边界防火墙、Web 防火墙、IPS 进行安全防护。自建云内外网环境中包括4个微应用、71 个微服务、22 台虚拟机、MySQL主从提供应用服务、接口服务。系统采用F5 负载均衡减轻服务器压力。MySQL、Redis 和Elasticsearch等数据存储服务部署在自建云上。

基建全过程管理平台部署在自建云环境。互联网边界部署了边界防火墙、WEB 防火墙、IPS 进行安全防护。自建云内外网环境中包括4个微应用、71 个微服务、22 台虚拟机、MySQL主从提供应用服务、接口服务。系统采用F5 负载均衡减轻服务器压力。MySQL、Redis 和Elasticsearch等数据存储服务部署在自建云上。

采用Apache Jmeter 对基建全过程管理平台中的计划管理微服务进行高并发性能压力测试。为了测试的准确性，选取了计划管理微服务中的项目核准看板接口进行压测，该接口需要远程调用项目管理微服务提供的项目单项信息查询接口。测试数据如图7所示。

图7 Jmeter测试参数

其中线程数设置为2000，Ramp-Up 时间设置为10s，循环次数设置为20，即模拟在10s 时间内，2000 个用户上线，每个用户发送20 个请求，共计40000次请求。高并发性能压力测试结果如图8所示。详细数据见表2。

表2 压测结果

图8 Jmeter测试结果

由结果可见，基于微服务架构的基建全过程管理平台在高并发的情况下，系统的平均响应时常大大降低，同时系统的最大响应时常相比单体架构也有显著的提升，减少了接口异常的概率。

3.4 基建全过程管理平台应用效果

基建全过程管理平台微服务微应用技术体系实现了基建平台的全过程数字化管理。图9为基建管理平台控制台首页，提供平台功能的总览以及跳转功能。图9横向菜单中的每一个菜单项代表一个单独的微服务模块。以计划管理微服务为例，图10 展示了计划管理微服务在职能管理上提供的相关功能菜单中的季度预测模块，展示了2022 年变电、线路季度预测，开工预测与投产预测。图11 展示了项目管理中的四个阶段。由六大业务微服务支撑实现相关功能。

图9 基建全过程管理平台首页展示

图10 计划管理服务相关功能

图11 项目管理相关功能

4 结语

本文研究并实现了一套基于微服务架构的基建全过程管理平台，基于电网基建项目建设过程管理的实际业务需要，把复杂的业务系统拆分成多个微服务，以微服务的形式实现了基建平台内各功能模块之间的高内聚、低耦合。计划管理、技术管理等专业功能可独立地开发、部署，大大降低了应用开发的门槛和部署的时间，同时保障了业务变更的灵活性。为了基建业务的安全平稳运行，在今后的平台优化工作中，会融合人工智能算法做风险预警和安全施工隐患分析，有效规避施工建设中可能出现的安全隐患事故和进度滞后风险。