手艺专栏 | 全篇干货！AG电投厅科技企业级微前端应用实践

数字时代，随着手艺的一直厘革，前后端疏散架构的研发模式已成为主流。但爆发式增添的营业量让前端功效需求一直增多，小而美的应用不复保存。当一个通俗应用演酿成一个巨石应用( Frontend Monolith )后，逻辑重大和臃肿的问题最先袒露，随之而来的是多人难以协作、功效耦合性高、页面加载速率变慢等一系列难题亟待解决。

当后端「微效劳」普遍普实时，「微」的看法也影响到了前端，「微前端」应运而生。

微前端（Micro-Frontends）是一种类似于微效劳的架构，它将微效劳的理念应用于浏览器端，即将 Web 应用由简单的单体应用转变为多个小型前端应用聚合为一的应用，各个前端应用可以自力运行、自力开发、自力安排。

通过跟微效劳举行比照，我们可以更清晰地明确微前端的看法：

相比于古板的前端工程，微前端架构具备以下几大优势：

大幅提升研发效能：将大工程举行拆分，显著提高打包构建速率，代码精练、解耦、更易维护；

定制化编排产品：将微应用举行个性化编排组合，快速举行产品立异；

定向增量升级：各微前端单独安排，可定向增量升级某一微应用，而不影响其他微应用，大大节约了安排本钱和降低升级危害。

基于富厚的手艺实践履历，AG电投厅科技Web前端团队在微前端领域的深入探索已有所建树。本文将重点分享在微效劳框架的配景下，AG电投厅科技自主研发和设计的微前端解决计划。

微前端手艺选型之路

微前端架构的实现方法有多种手艺蹊径，包括路由分发式、应用微效劳化、微应用、微件化、前端容器化、应用组件化等，需凭证详细场景选用合适的方法。在某些场景下，可能没有合适的计划，也可能同时使用多种计划。

因此在做手艺选型前，首先需要对公司的产品现状举行整体梳理，效果如下：

现有前端框架：公司主流使用vue,可是一些老旧系统仍使用react、jquery等；

前端工程拆分粒度：大部分产品照旧古板的大工程形态；有部分产品已举行了�？榛⒆榧鸱�，将一个大工程拆分成了多个小工程，各工程通过宣布npm插件的形式，最终被一个主工程装置聚合。

通过对公司现有产品的剖析，最终我们最终确认了手艺选型的要求：

能够做到跨手艺栈，不局限于一种前端框架；

能够将npm插件刷新成以微应用的形式举行聚合。

别的，凭证AG电投厅产品特征，微前端框架还需知足以下几点需求：

● 微应用自力开发

● 微应用自力安排

● 跨手艺栈，不局限于一种前端框架

● 能够将npm插件刷新成以微应用的形式举行聚合

● 可将微应用举行编排组合，输出差别的产品

● 加载器底座使用vue

团结公司的框架能力需求，我们最终选定三种微前端手艺蹊径团结的方法：

应用微效劳化：针关于无法拆分的系统和非vue系统，接纳微效劳化接入，举行手艺验证后选择了阿里qiankun框架；

微应用化：针对vue手艺栈已做�？榛鸱值南低彻こ�，接纳微应用化接入，使用了webpack5提供的�？榱�；

前端容器化: 针对一些老旧的非spa单页面的系统，接纳iframe接入。

微前端解决计划设计思绪

以前文所述的微前端看法可知，中心加载器是微前端的焦点所在，而加载器需具备三个基本能力：

路由分发；

加载微应用的静态资源；

可在加载器上恣意上架下架微应用。

基于上述认知，我们对微前端解决计划的各个�？樽隽巳缦律杓疲�

标识微应用

怎样包管加载器能准确的识别到对应的微应用呢？

我们决议为每一个微应用定制一个唯一id标记，即编码appCode。

中心化路由

微效劳的焦点是注册中心，微前端是否也需要一个注册中心呢？若是需要，那么微前端的注册中心又是什么呢？

通常情形下，前端页面的渲染是靠路由来控制的，那我们是否可以使用前端的路由系统来设计一套微前端的注册中心呢？

基于这个思绪，我们起源设计了一套加载器的事情流程：

1) 加载器底座拉取微应用设置信息

2) 将设置中的微应用注册到注册中心

3) 浏览器url变换驱动loader加载器加载对应微应用的资源

4) 加载微应用

微应用设置

依据上述加载器的事情流程图，我们整理出微应用的设置文件结构以及字段：

注册中心

依据上文提到的注册中心即是路由的思绪，构建出如下路由结构（以vue-router为例）：

以微应用唯一编码做为路由的name[path]。

这里需要注重的是，思量到微应用的动态加载，加载器加载的微应用个数不做限制，如一次性将所有的微应用路由所有加载，势必会造成路由数据过于重大，因此初始化时只注册中心路由，微应用对应的页面路由，则在第一次进入目今微应用的时间建设。此办法放在loader加载器中实现。

Loader加载器

加载器通过监听路由切换，自动获取路由对应的微应用的静态资源，继而举行页面渲染。

加载器主要事情流程如下：

依据此流程可以编写出加载器的流程代码(以vue为例)：

微应用设计

微应用的设计分为微效劳化接入（qiankun）和微应用化接入。

1、微效劳化-qiankun

首先在应用入口增添qiankun的生命周期

为了让微应用能被加载器顺遂加载，其构建后的文件结构以及构建路径需做适配。

为了区分请求资源的归属，在每个静态资源前都加上了appCode(微应用编码)，例如/app1/index.index,/app1/lib.js ,/app1/lib.css。因此在构建时间publicPath需设置成”./”相对路径。

构建后的文件夹一级目录下需包括微应用的设置文件和入口文件。

以下为qiankun应用打包后的文件结构：

config.json：微应用设置文件

Index.html：微应用入口文件

2、微应用化-�？榱�

�？榱钪饕鞘褂脀enpack5提供的ModuleFederationPlugin将组件�？榛涑�。

通过�？榱畹汲鲎榧�，最终天生的文件结构如下：

config.json：微应用设置文件

remoteEntry.js：微应用入口文件

AG电投厅科技微前端框架产品

综上所述计划设计整体思绪，经由产品化打磨后，AG电投厅科技Web前端团队基于公司现有前端低代码平台，自主研发和设计的微前端框架产品正式落地。

基础类库：为解决样式和编码规范统一等问题，需要一系列的基础类库，如基础组件库，样式库等；

微前端底座：提供基础的admin能力，通过门户结构组件提供扩展修改能力，底座焦点包括注册中心，资源加载器；

微应用开发脚手架：提供标准工程结构的开发脚手架，开发者可专注于营业开发，不需重复调试编译构建等重大的接入规范；

低代码平台输出标准微应用：通过低代码平台的可视化设置，快速输出标准的微应用，无缝接入微前端底座。

微前端安排场景示例

微前端的安排有两种形式，一种是将所有微应用的资源与底座加载器合并成一个文件夹，举行合并安排，只提供一个Web效劳；另一种则是将底座和微应用脱离安排，每个微应用都提供单独的Web效劳。

合并安排

自力安排

问题与反思

在微前端框架的实验历程中，遇到的主要问题有如下几点：

页面样式杂乱：由于微应用具备自力开发的特征，差别团队开发的微应用聚合到一起时，无法阻止泛起页面杂乱、不统一等问题；

团队协同性差：陪同着团队自治水平的提升，协作难题等问题随之爆发；

用户流量肩负：自力构建意味着公共资源的冗余，继而增添用户的流量肩负；

问题排查难题：当微应用与加载器底座的对接泛起问题时，除框架构建者外，开发职员往往很难定位问题所在。

目今，由于手艺生长的桎梏，有些问题确实难以短期内有用解决，但这也正是我们软件开发者们需要一直为之起劲和探索的偏向所在。未来，微前端纷歧定是未来生长趋势的收束点，可是它在未来一定会施展主要作用。

一得之见 | 企业架构下的共享能力中心建设

金融科技

2023.01.13

手艺实践| 基于Flink手艺组件，助力实时数仓建设

AG电投厅动态

2022.10.28