微前端在得物客服域的实践/那么多微前端框架，为啥我们选Qiankun + MF

一、业务背景

当前客服一站式工作台包含在线服务、电话、工单和工具类四大功能，页面的基本结构如下：

每个业务模块相对独立，各有独立的业务体系，单个模块体积较大，项目整体采用SPA + iframe的架构模式，其中的工单系统就是通过iframe嵌套的。在客服业务不断迭代的过程中，SPA + iframe的架构模式暴露出了很多问题，主要问题如下：

• 问题一：SPA架构模式下，由于各个模块集中于一个架构下，导致首屏加载资源过多，首屏加载速度较慢；SPA只有入口文件，所以需要对各个模块做业务模式兼容，导致入口文件代码条件语句较多，代码紊乱，出现线上问题的时候，排查较为困难，如果有新的同学参与开发，梳理业务也较为困难，甚至有的时候难以理解。
• 问题二：项目中嵌套大量的iframe，iframe也会拖累页面的加载速度，iframe使用postMessage通讯时也会带来数据延迟，数据丢失等各种问题，客服使用时间较长的时候，当切换iframe中的页面时，前一个页面中的无法被完全释放，导致浏览器所占的内存不停的飙升，最终导致浏览器崩溃。

基于上面两个问题，我们用微前端技术对一站式工作台做了业务上的拆分，本文主要阐述在拆分过程中遇到的问题和挑战。

二、技术方案调研

通过对微前端技术方案的调研，可以知道：微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用，具备以下几个核心价值：

• 技术栈无关：主框架不限制接入应用的技术栈，微应用具备完全自主权
• 独立开发、独立部署：微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
• 增量升级：在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
• 独立运行时：每个微应用之间状态隔离，运行时状态不共享

通过对开源社区相关微前端技术的调研，现今主流的微前端解决方案主要包括以下这些：

• 技术框架：iframe、single-spa、qiankun、icestark、Garfish、microApp、ESM、EMP
• 技术亮点：js Entry、html Entry、沙箱隔离、样式隔离、web Component、ESM、ModuleFederation

解决方案	来源	特点	缺点
iframe	-	天生隔离样式与脚本、多页	窗口大小不好控制，隔离性无法被突破，导致应用间上下文无法被共享，随之带来开发体验、产品体验等问题无法做到单页导致许多功能无法正常在主应用中展示
single-spa	国外	Js Entry, 主应用重写 window.addEventListener拦截监听路由的时间，执行内部的reroute逻辑，加载子应用	基于reroute，对于需要缓存，加载多应用的场景不适合
qiankun	蚂蚁金服	基于 single-spa，增加了 html-entry,sandbox, globalSate, 资源预加载等核心功能	需要编译为umd方式，对于AMD，systemJs支持不友好，且官方没有公开支持vite构建
icestark	阿里	把大部分配置通过 cache 写进window['icestark'] 全局变量	只对React支持，跨框架支持不友好
Garfish	字节	对现有 MFE 框架的增强版，VM 沙箱	-
microApp	京东	基于web Component的实现	存在兼容性问题，微前端方面的探索不够成熟
ESM	-	微模块，通过构建工具编译为js，远程加载模块，无技术栈限制，跟页面路由无关，可以随处挂载	无法兼容所有浏览器(但可以通过编译工具解决)，需手动隔离样式（可通过css module解决），应用通讯不友好
EMP	欢聚时代	基于Module Federation、去中心化、跨应用状态共享、跨框架组件调用、远程拉取ts声明文件、动态更新微应用、第三方依赖的共享等能力	目前无法涵盖所有框架

经过调研以及结合我们的业务现状，采用了 qiankun + Module Federation 作为我们微前端的技术框架，按照功能拆分，将应用拆分为4个独立的系统，可以独立开发