基于vue框架下的银行业务整和
在银行金融领域，上线较早的业务系统由于历史原因和人员变动，遗留下诸如前端架构未能统一，老crm还是传统erp风格，jsp页面上使用jQuery+YUI等问题。vue框架下的项目因为历史问题也存在不少技术包袱，如：core版本众多，业务逻辑混乱，组件上下文耦合严重，甚至有的项目架构用异步+storage实现browserrouter这类“灾难性”架构问题。
1.需求分析
目前我所在的团队主要负责行内对公业务的系统与产品的应用开发维护，公司驿站作为服务对公条线作业的产品，其前端结果是顶通+内容区+底部说明，顶部和底部组件高度固定，主内容区自适应屏幕。顶部组件展示导航信息，底部组件展示版权和跳转链接，应用内容全部填充到主内容区域。
在对公条线数字化转型的大背景下，对公司驿站优化改造的需求如下：
明确驿站作为对公业务门户入口，前台业务系统属于子系统，为了客户经理使用体验不割裂，站内跳转是最佳跳转方案
系统A与B需要开发一套相同的客户经理管理模块
对公前台业务体系下的系统，后期这类重复建设需求会很多，考虑到组件复用，降低开发成本，需要在技术和架构层面，考虑如何把公司应用的某些页面、组件塞到主应用中呈现。
2.技术选型
iframe
这可能是最容易想到的解决方案，这种方案优势比较明显：
老旧项目技术栈落后，重构成本高，后期也无大版本变动或者已封板但需稳定运行，我们称这类应用叫做巨石应用。
嵌入内容总是完整的页面
对嵌入页面加载渲染等性能无要求
当然使用过iframe的同学，都应该知道有多“坑”。
URL不同步：浏览器刷新，iframe的URL丢失，前进后退按钮无法使用。
UI不同步：DOM结构不共享
全局上下文完全隔离，内存变量无法共享：Iframe内外的通信、数据同步的需求，主应用通过postMessage，子应用接受并同步；身份认证实现也较为麻烦，主应用的cookie透传到根域名都不同的子应用下实现免登陆。
iframe应用渲染慢：每次子应用进入都需要浏览器重新构建上下文，资源重新加载，页面重新渲染
MPA+路由分发
通过nginx根据访问路径分发到不同的业务系统，再由各个业务系统根据pathname完成组件装载返回到浏览器。
优势：
jquery框架定义
不限制技术框架
独立部署和运行
应用之间相互隔离
劣势：
用户体验分裂，不考虑网络的前提下，子应用加载时间根据自身架构决定，不可控。
由于应用之间相互独立，导航栏、顶部和底部这类公共组件复用性较差。
非同域下的应用之间信息通讯通过URL传参安全性较差。
npm包分发
npm私包也是经常使用的方案，从业务系统抽取组件，发布npm包，引用包。对开发人员能力要求较高，需要考虑将这个部分代码抽取若干个文件，同时要考虑跟现有系统做上下文解耦。但是，npm包分发隐藏在业务背后的问题也不容小觑。
npm包的更新需要下游依赖项目重新编译部署才能生效。
包发布时间长了，容易出现产品依赖版本不一致导致的体验割裂。
无法进行灰度发布
技术栈耦合，peerDependence一定程度可以解决基础依赖重复应用的问题。
一定程度丧失了动态下发代码能力，导致了过慢的工程相应速度，跟现在云服务时代格格不入。
3.微前端方案
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化web应用的技术手段及方法策略----MicroFrontends
基座模式
通俗地讲，通过搭建一个地基，配合我们的配置中心来管理微应用，基座模式会有一个大的容器来包含所有的微应用。国内微前端应用最多的就是这个模式。常见的架构有single-spa、qiankun、ice-stark。
EMP
去中心模式，技术核心是webpack5ModuleFederation，可以在实现应用隔离的基础上，实现应用间的资源共享和通讯。面向未来，EMP可能是最接近后端领域的微服务。
4.微前端实践
qiankun是由蚂蚁金服推出的比较成熟的微前端框架，基于single-spa进行二次开发，用于将web应用由单一的超大型应用拆解成多个小型前端应用聚合为一的应用。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。