微前端在平台级管理系统中的最佳实践

1、什么是微前端？

近十年来，前端技术有了长足发展，各种概念与框架层出不穷。从架构的角度来看技术的演进，前后端分离是其中最重要的分水岭。正是由于前后端分离，才衍生出了 Angular、React、Vue 三大框架，配合 webpack、babel 等社区开发工具，形成了以框架为中心的 SPA（Single Page Application） 应用开发技术体系。SPA 基本上成了中后台前端应用开发的事实标准。

随着技术演进和需求变化，大型 SPA 项目逐渐变成了巨石应用。打包时间变长、跨团队沟通成本变高、问题越来越多，SPA 在巨石应用中成了甜蜜的负担。

为了解决前端开发过程中巨石应用带来的问题，借鉴后端微服务的思想，把前端巨石应用拆分为多个子应用，让前端子应用具备独立开发、独立流水线、独立部署的能力，并且能够在运行时组合起来。我们将这套策略称之为微前端方案（微前端方案并不是一个具体的技术，而是一系列方案的组合）。

2、什么是通用管理端工程？

中原银行通用管理端工程，承担着我行平台级管理系统的角色，为行内各项目提供了一套具有统一的设计规范、前端框架、开发模式和技术栈的模板工程。目前已支持我行几十套内部系统的开发。

开发人员在管理端项目开发中经常会遇到以下两个痛点：

实现一套功能完备的用户、角色、权限等管理端的功能，繁琐且复杂。

与行内系统、平台、规范、架构等进行对接，需要分别学习了解，费工费时。

中原银行通用管理端工程解决了这两个痛点，让业务方可以只关注于业务开发，为业务赋能提效。

3、当管理端工程遇上微前端

银行系统通常生命周期长、业务复杂。生命周期长使得对历史遗留项目升级困难，业务复杂带来了项目和团队的管理开发过程中的各种问题。

为了解决这些痛点，统一开发平台团队基于现有技术栈，结合微前端的理念，在管理端工程中集成了微前端开发能力。制定如下微前端策略：

微前端应包含构建工具、主应用、子应用、应用加载器、应用管理中心等模块，并具有相应的设计体系保证子应用之间交互一致性。其中，构建工具基于 webpack 实现，应用加载器使用 qiankun 实现。

理想情况下，使用管理端工程的各个系统子应用之间可以任意迁移。非管理端工程项目可以参考此方案实现类似策略。

下面介绍下我们在集成微前端过程中的最佳实践：

3.1、应用拆分

微前端第一步，确定主、子应用范围。基于现有管理端工程模板，我们制定了逐步拆分子应用的策略。我们把通用管理端工程按业务聚合度拆分为一个基座主应用和多个子应用。

如何让子应用及其功能与主应用的菜单结合，如何管理子应用及其功能菜单的权限，是影响工程整体统一的关键因素。

基于此诉求，我们的方案是：把子应用及其功能，抽象为主应用的多级菜单，结合菜单权限管理的能力，实现对子应用的路由控制。

3.2、应用管理中心

有了主应用和多个子应用的存在，就需要对子应用进行管理。在主应用中，我们新增了应用管理中心功能，提供了子应用统一看板。开发者可以在应用管理中心内快速创建子应用、控制子应用上下线、配置子应用参数等。

3.3、子应用动态批量注册

基于应用管理中心功能，我们可以拿到线上维护的子应用数据信息。在运行时，批量动态注册子应用到应用加载器 qiankun 中，让多个子应用可以按需加载和展示。

子应用权限通过线上配置实现，并且在开发流程中也无需手动写代码注册，降低了使用复杂度，提高了开发效率。

3.4、三种开发模式

针对不同的开发场景，我们提供了三种开发模式，每个模式各有优缺点，项目组可按需进行选择：

线上主应用，本地子应用：本地只需启动子应用，节省本地资源消耗，线上主应用通过配置加载运行本地子应用。缺点是需要一台测试机器部署主应用。

本地主应用，本地子应用：本地启动一个主应用，通过配置加载运行本地的子应用。缺点是相对消耗本地资源。

主子融合：本地只启动一个融入主应用部分功能的子应用，模拟主应用环境，优点是独立部署更加便利。缺点是不利于主应用更新，并且增加了子应用的体积。

其中 1、2 是我们的优先推荐方案。

3.5、内部构建工具定制脚手架

在前端开发过程中，开发人员需要面临各种工程化方面的问题。需要了解 webpack 、babel 、postcss 等整个前端工具链，才能打造出一个开发时效率高，运行时性能好的前端构建体系。

为了降低开发者使用难度，我们创建了内部构建工具 walle，将构建流程与项目剥离。这样带来两个好处：

用户无需关注构建打包的复杂配置，工具链集成，只需要关注与 walle 的命令与配置。

walle 可以单独升级，其依赖的 webpack、babel 等会跟随升级，解决了构建流程升级不及时问题。

针对微前端我们默认解决了 webpackJsonpFunction 以及 name 冲突问题，同时还提供了脚手架定制能力，可以直接创建微前端模板。

3.6、增强 mock 能力

主应用加载子应用时，子应用内个别接口可能会有特殊需求，例如需要走 mock 或者代理到与主应用不同的服务器。这种场景下，如果统一使用主应用的服务配置，每次都需要修改主应用，极大地降低了灵活性。因此，我们支持了各个子应用使用独立 mock 服务和代理服务功能，这样就可以灵活选择方案，满足各种接口类型的需求。

3.7、设计体系

无规矩不成方圆，没有设计体系形成的微前端应用，其体验会产生割裂感。开发平台联合管信设计团队制定了一套开发设计规范。规范包含基本要素、界面设计、组件设计等。按规范开发，可以有效避免主子应用间的样式冲突，也可确保各个子应用间的风格主题统一。

3.8、统一的体验

管理端工程中主子应用具有统一整体布局，统一的导航（菜单与面包屑），以及统一的日志记录能力。

另外，结合构建工具和设计体系，把开发部署产生的交互差异在运行时消除，主子应用共享登录信息，简化了子应用开发过程。

3.9、IE 10/11 兼容能力

行内有部分系统需要支持 IE 10/11 浏览器，我们针对 IE 兼容做了多种测试，进行问题修复和调优处理，主要解决了 IE 10/11 下 qiankun 的 ShadowDOM 降级失败及 snapshotSandbox 缺陷问题。目前该解决方案已在行内落地并稳定运行。

为回馈开源社区，我们在 qiankun 源码提交了 PR，该解决方案已经合并到 qiankun 的 master，并发布到了最新版本 npm 包。

同时，我们通过分析和优化 single-spa 源码，基于扩展接口，重写匹配函数，IE 10/11 下使用 location.href 替换 location.origin，还解决了 IE 10/11 下 single-spa 激活路径失效问题。

4、未来展望

目前通用管理端工程中已集成了微前端的开发能力，并且已经发布了正式版本。

但微前端就是银弹吗？当然不是。一些小型项目 SPA 已经足够了，使用微前端反而会带来更多负担。另外，技术永远在发展，总会有新技术打破旧技术的枷锁，作为开发者，我们需要顺势而为，拥抱变化。

qiankun、single-spa 是应用加载的终极解决方案吗？当然也不是。如社区里新提出的 webpack 的 module federation， 基于 web 标准的 web component 方案等。微前端作为一种拆分应用的思想比具体的类库要更长久。

微前端和敏捷开发、DDD 有结合之处吗，微前端和低代码又能碰撞出什么火花，你的答案是什么？

本文转载自原银科技

原文链接：微前端在平台级管理系统中的最佳实践

5、参考资料

1.    https://martinfowler.com/articles/micro-frontends.html

2.     https://single-spa.js.org/

3.    《Micro Frontends In Action》Michael Geers

4.    《微前端的核心价值》Kuitos