适用于智能配电网前端微服务的跨系统集成平台优化

方燕琼，唐升卫，顾博川，代仕勇

（1.广东电科院能源技术有限责任公司，广州 510080； 2.广东电网有限责任公司电力科学研究院，广州 510080）

引言

作为智能电网的关键环节，智能配电网的建设愈发得到了重视。但配电网具有地域分布广、电气设备种类多和数量多、状况复杂等特点[1-3]，导致配电网的信息更加多样化。尤其随着更多智能电气设备接入配电网，配电网信息具有数据源复杂[4]、数据结构多样、数据量大等明显的大数据特征[5,6]。

不仅配网设备在地域上分散分布，而且受技术所限，许多分包的配网业务在系统中也是割裂的。因此在当前智能配电网建设过程中，多以单一功能模块形成孤立的垂直系统为主，容易形成信息孤岛，而构建高性能的跨系统集成平台，将有助于配电网信息的充分利用和共享。

1 配电网跨系统业务

随着智能配电网信息系统的业务也在不断地发展，业务功能逐渐的增多，信息系统的组织结构、软件架构不断地升级和变化[7,8]。智能配电网业务结构如图1所示。

图1 智能配电网业务结构

导致大型的单体项目面临一些问题，一方面，单一的系统已经过于的庞大甚至臃肿，需要进一步的根据不同的业务进行细化；另一方面，市场上许多大型系统根据业务领域被拆分成许多子系统分包给不同的企业开发。随着不同的业务系统的拆分，技术栈也因而变得越来越难以统一，出现了多元化的情景。在走向多元化后，用户需要切换不同的系统和账号查看想要的结果，无疑就增加了用户的操作。因此，为了将已经拆分的业务整合成一个整体便于用户获取业务信息，现急需一个能够接入各企业分包业务并聚合数据的系统平台。

传统前端代码通常会根据单个系统划分为一个项目，而项目的体积是与业务的复杂度是成正相关的，业务增多会逐渐导致项目的体积臃肿。为了适应这个变化往往需要更多的开发者、更细粒度的团队组织。在开发过程中，各模块解耦到各自完成，上线时糅合在一起运行，其中产生出层出不穷的分支合并、代码回滚，都会造成合作效率的骤降。从根源上看造成这种局面的是框架设计的问题，因此需要对整个项目进行解耦，使原本复杂的单体应用拆分为多个相对独立的应用，使每个模块都可以单独部署上线，同时通过微服务的方式，动态组合各个独立的应用。

为了克服现有技术之间的互通性和业务的拆分，形成科学有效的一体化技术架构与应用顶层设计[9],前端开发出现了一种类似于微服务架构的微前端的概念。即将单页面前端应用由单一的单体应用转变为多个小型前端应用集成一个系统，并且各个前端应用都支持独立开发部署。

针对微前端架构的解决方案，目前出现的架构分为以下几种方式：路由分发式、前端微服务化、微应用[10,11]、微件化、前端容器化、应用Web Components化。前端微服务化现有的实现方案还缺乏独立部署的标准，无论是开发还是打包部署，都需要对相关子应用和基座重新修改和打包。

2 现有的前端微服务的实现方式及缺点

在当前微服务中存在多种实现方式，其中主要是以下几种方式：

1）使用 HTTP 服务器的路由来重定向多个应用。通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即该方式只是将这些不同的前端应用拼凑到一起，使其从表面上体现出来的是一个完整的整体。与其他的微服务相比，此技术在子应用的切换会导致页面刷新，非常影响用户体验。

2）在不同的框架之上设计通讯、加载机制，诸如 Mooa 和 Single-Spa：本技术是基于Single-Spa上改进的一种方式。比原生的更加方便灵活，以及新增了基于iFrame的方式来解决第三方框架冲突的问题。在后端服务的通信中，通过rest接口等方式实现的方式不能移植到前端中，通过设计一种单独的应用间的通信方式，增加了数据交互性。

3）通过组合多个独立应用、组件来构建一个单体应用：组合式集成，即通过软件工程的方式在构建前、构建时、构建后等步骤中，对应用进行一步的拆分，并重新组合。这种方式似乎很理想，即在满足多个团队并行开发的同时，又能构建出适合的交付物。然而它有一个严重的限制即必须使用同一个框架。鉴于业务是拆分后再重新组合的，这与单独的微前端相比，部署更加繁琐，因此重新组合时容易出错等问题和限制性比较大。

4）iFrame技术。使用 iFrame 及自定义消息传递机制：iFrame可以创建一个全新的独立的宿主环境，这表示前端应用之间可以相互独立运行。然而，现最需要获取的是用户加载或卸载应用的时机和环境；该过程所出现的难题是采取怎样的动画过渡能够让用户使用时更加自然，单纯的iFrame恐难以做到。

从上述分析可知，当前的微服务技术只侧重于单个内容，缺少综合使用，导致微服务效果还没充分发挥。

针对智能配电网日趋复杂的信息系统，亟需一种高效的处理方法，本论文将综合使用上述的前端服务技术，优化Single-Spa并且集成iFrame的技术，通过优化wepack的打包方式分包加载资源。通过配置文件的方式简化了Single-Spa的初始化。通过新增iFrame的嵌入方式，创建全新隔离的宿主环境。通过自定义的应用间的通信方式，加强与简化应用间的通信。

3 新型的前端微服务

本文提供了一种基于前端微服务化的跨技术栈开发系统的优化，该前端微服务的内容包括：对子项目应用资源的打包配置优化、设计路由的相应机制，以及应用间的通信方式。此技术可以整合不同的技术栈的应用，减少应用的资源大小以及控制应用权限等功能。

3.1 整体思路

本文以一个实际的智能配电网应用场景，研究了一个父项目为主框架，配以表示不同业务模块的多个子应用构建的前端微服务解决方案。图2描述了前端微服务的整体结构，父项目在用户登录后通过获取的用户权限，将请求回来的菜单储存在状态管理器中，当访问某一子应用的路由时，首次会在子应用中与路由表作比较，将路由信息动态添加到该子应用的路由表中，借此控制整个项目的路由，分发到各个子项目中，进而对子应用的权限进行控制。

图2 前端微服务整体结构

业务的拆分可以解耦单一项目，但未经优化的项目打包方式还是会使项目加载变慢，优化前端打包的方式是必不可少的方式；服务通过配置文件的方式实现，有利于子应用动态增删改查，更深层次的话可以根据用户的身份权限来注册不同的应用；解决应用间的数据共享问题一方面打通了应用之间的关联性，另一方面也减少了接口的请求，减少公共数据需要从后端获取；整合iFrame方式的前端微服务的优点在于可以创建独立的宿主环境，防止代码的污染。

3.2 具体实现

本新型前端微服务的具体实现方法如图3所示， 该实现方法主要由子项目应用资源的打包配置优化、设计路由的相应机制，以及应用间的通信方式三个部分组成。

图3 前端微服务实现方式

1）打包配置优化

微前端原则上各个子应用可兼容不同的前端框架，对于不同的前端框架的部署方式不一，本文采用基于vue开发的子应用打包优化方案。首先修改项目的打包文件，分包加载模块文件，接着将不同的插件包分包打包在不同的文件中，达到减少打包后的文件大小，据测试对比，打包后的文件大小可减小50 %。

将子应用的配置单独成文件，并且子应用使用manifest自动加载经过hash值的文件，具体方法：让子应用使用 stats-webpack-plugin 插件，每次打包后都输出一个只包含重要信息的manifest.json文件。父项目先ajax请求这个json文件，从中读取出需要加载的js目录，然后同步加载。

2）设计路由的相应机制

微前端主架构使用vue扩展Single-Spa，并增加路由管理，增加支持iFrame模式的加载，使用router.addRoutes动态添加相应iFrame路由。主框架基于vue-cli的脚手架进行集成，并使用element-ui作为前端库，并引入路由router，Single-Spa，axios等相关插件。

当开发一个新的应用时，需要在主应用配置并更新相应的子应用。通过增加应用配置文件，在文件中声明相关应用的名称及对应的地址和端口，可用于初始化Single-Spa的时候将其注册到主框架中；具体实现是通过遍历调用微服务框架的注册函数registerApplication为项目注册子应用，并且自定义远程加载mainfest.json文件，解析需要加载的js文件，简化了注册的过程。

3）应用间的通信方式

为了解决应用间的数据共享问题，本文设计了一套应用通信的机制。由于主框架中使用vue作为开发环境，所以使用vuex作为统一的状态管理器，并且使用事件收发器在主框架中定义全局函数，提供主框架与子应用之间的数据通信，并修改状态值。具体实现为APP1在调用事件收发器后修改主框架的状态管理器的状态值后，APP2亦可通过事件收发器获取主框架内的状态值，实现多个子应用间的数据通信与同步。

3.3 现场应用

本文提出的前端微服务已经应用于翁源地区电网的配电网自动化系统，通过供电可靠性分析、负荷预测、电压质量监测、用户重复停电统计、台区重过载统计、配变档位调节排行，可以对智慧台区、光储微网配网线路进行全方位的监测[12-15]，当监测到异常情况时，智能台区可以自动发出重过载预警和配变调节预警。前端微服务应用如图4所示。本前端微服务的应用将极大提升智能台区的运行效果，为智能电网的信息化、数字化、智能化发展打下坚实一步。

图4 前端微服务应用

4 结论

本文提出的适用于智能配电网前端微服务的跨系统集成平台优化方案，通过对整个项目进行解耦，使原本复杂的单体应用拆分为多个相对独立的应用，使得每个模块都可以单独部署上线；通过设计应用间的通信方式，解决了应用间的数据共享问题，打通了应用之间的关联性。前端微服务应用于大型项目，对现阶段臃肿的系统进行拆分有着极大的帮助，一方面可以解耦单体应用，使业务分离；另一方面，对项目部署上线及版本迭代也有着更快捷的提高。