微前端在银行系统中的实践

作者：陈凯

在银行金融领域，上线较早的业务系统由于历史原因和人员变动，遗留下诸如前端架构未能统一，老crm还是传统erp风格，jsp页面上使用jQuery + YUI等问题。vue框架下的项目因为历史问题也存在不少技术包袱，如：core版本众多，业务逻辑混乱，组件上下文耦合严重，甚至有的项目架构用异步+storage实现browser router这类“灾难性”架构问题。

1.需求分析

目前我所在的团队主要负责行内对公业务的系统与产品的应用开发维护，公司驿站作为服务对公条线作业的产品，其前端结果是顶通+内容区+底部说明，顶部和底部组件高度固定，主内容区自适应屏幕。顶部组件展示导航信息，底部组件展示版权和跳转链接，应用内容全部填充到主内容区域。

在对公条线数字化转型的大背景下，对公司驿站优化改造的需求如下：

• 明确驿站作为对公业务门户入口，前台业务系统属于子系统，为了客户经理使用体验不割裂，站内跳转是最佳跳转方案
• 系统A与B需要开发一套相同的客户经理管理模块

对公前台业务体系下的系统，后期这类重复建设需求会很多，考虑到组件复用，降低开发成本，需要在技术和架构层面，考虑如何把公司应用的某些页面、组件塞到主应用中呈现。

2.技术选型

iframe

这可能是最容易想到的解决方案，这种方案优势比较明显：

• 老旧项目技术栈落后，重构成本高，后期也无大版本变动或者已封板但需稳定运行，我们称这类应用叫做巨石应用。
• 嵌入内容总是完整的页面
• 对嵌入页面加载渲染等性能无要求

当然使用过iframe的同学，都应该知道有多“坑”。

• URL不同步：浏览器刷新，iframe的URL丢失，前进后退按钮无法使用。
• UI不同步：DOM结构不共享
• 全局上下文完全隔离，内存变量无法共享：Iframe内外的通信、数据同步的需求，主应用通过postMessage，子应用接受并同步；身份认证实现也较为麻烦，主应用的cookie透传到根域名都不同的子应用下实现免登陆。
• iframe应用渲染慢：每次子应用进入都需要浏览器重新构建上下文，资源重新加载，页面重新渲染

MPA + 路由分发

通过nginx根据访问路径分发到不同的业务系统，再由各个业务系统根据pathname完成组件装载返回到浏览器。

优势：

• 不限制技术框架
• 独立部署和运行
• 应用之间相互隔离

劣势：

• 用户体验分裂，不考虑网络的前提下，子应用加载时间根据自身架构决定，不可控。
• 由于应用之间相互独立，导航栏、顶部和底部这类公共组件复用性较差。
• 非同域下的应用之间信息通讯通过URL传参安全性较差。

npm包分发

npm私包也是经常使用的方案，从业务系统抽取组件，发布npm包，引用包。对开发人员能力要求较高，需要考虑将这个部分代码抽取若干个文件，同时要考虑跟现有系统做上下文解耦。但是，npm包分发隐藏在业务背后的问题也不容小觑。

• npm包的更新需要下游依赖项目重新编译部署才能生效。