导读如果你正在推进多个老后台系统的统一入口建设但又不希望大规模重构现有项目这篇文章更适合作为一份偏落地、偏接入层面的参考。1. 背景和需求分析公司产品升级后需要将目前 10 独立运行的后台系统整合为统一后台管理平台整体模式为“主应用 子应用”。之所以没有继续采用纯前端路由跳转或 Nginx 路由分发核心原因在于这两类方式很难同时满足下面几类诉求统一入口与统一体验。跨系统切换时具备基础通信能力。尽可能少改存量系统代码。保留各系统独立开发、独立部署能力。因此最终将方案方向收敛到了微前端。1.1 现状描述维度现状系统现状10 独立运行的后台系统技术栈仍以 Vue2 Vue CLI Element UI 为主构建工具Vue CLI部署模式各系统独立域名、独立部署业务关联系统间存在业务关联需要跨系统切换操作1.2 需求分析当前需求并不是“重构所有系统”而是在尽量不动原有技术栈的前提下完成统一接入。因此核心诉求可以归纳为下面四点不做技术栈变更系统代码尽量少改动以最低成本接入统一平台。完成系统集成与统一体验通过统一菜单控制各系统切换。保持独立开发、独立部署能力不打乱现有研发与发布节奏。方案需要支持后续渐进升级例如从 Vue2 平滑过渡到 Vue3。2. 方案对比为了让结论更清晰先给出一张总览表。方案适配度一句话结论qiankun中高能力完整但对存量系统接入改造相对更重micro-app高与当前场景最匹配综合实施成本最低Wujie中高需求匹配度较好但运行机制和维护复杂度略高Module Federation低更偏模块共享不适合 10 独立后台整站接入iframe中低适合作为临时兜底不适合作为长期方案下面展开说明每种方案的优缺点。2.1 qiankun优点方案成熟、社区案例多能力完整具备 JS/CSS 沙箱、较强隔离和预加载等能力技术栈兼容度高适合多种前端框架接入。不足对存量系统通常需要做生命周期、路由、入口等适配在老项目统一接入时配置和改造复杂度偏高对于多应用同时在线、应用级保活这类场景虽然能做但并不是当前项目里性价比最高的选择。2.2 micro-app优点接入轻量主应用可以直接通过标签方式接入子应用入侵低支持 JS/CSS 沙箱、虚拟路由、数据通信和预加载兼容多框架并提供 Vite、Vue、React 等接入方式支持 keep-alive适合后台系统频繁切换。不足生态广度和案例可复用性不如 qiankun需要理解其虚拟路由与组件化接入方式keep-alive 偏应用级保活页面级或组件级细粒度缓存仍然需要子应用自行处理部分老旧全局脚本和历史插件仍需做兼容性验证。2.3 Wujie优点组件式接入基于 iframe webcomponent天然具备较强隔离能力支持多应用同时激活在线支持 keep-alive切换体验较好路由同步、弹窗处理和通信能力相对完整。不足现成案例相对较少运行机制理解成本更高多应用常驻会带来更高内存占用如果项目对“多应用强保活”要求不高部分能力会出现冗余对历史代码、特殊浏览器行为和第三方库仍需专项验证。2.4 Module Federation优点非常适合“多个独立构建共同组成一个应用”的场景支持远程模块动态加载支持共享依赖能够减少重复打包适合组件库、页面模块、业务模块的独立发布。不足更偏“模块共享 / 工程拆分”而不是“多套独立后台整站接入”没有内建的整站级沙箱、路由治理与应用通信体系对于 10 已存在的独立后台系统改造量通常较大。2.5 iframe优点基于浏览器原生能力接入最直接隔离最彻底JS/CSS/DOM 基本天然隔离对独立域名、独立部署的旧系统友好作为临时兜底方案成本最低。不足路由割裂、通信能力弱、用户体验弱每个 iframe 都是完整文档环境内存占用更高更适合过渡期方案不适合作为长期架构。3. 选型结论本次选型最终采用micro-app。原因并不是它“能力最强”而是它在当前 10 后台系统整合场景下能够以更低的改造成本实现统一接入。独立部署。渐进升级。更高的落地效率。换句话说这次选型更看重的是“综合落地性”而不是“单点能力上限”。4. 主应用和子应用的基础接入这部分不展开具体架构设计只聚焦最基础、最常见的接入动作主应用怎么挂载子应用子应用怎么适配微前端环境以及主子应用之间怎样做最小数据透传。4.1 主应用初始化安装依赖npm i micro-zoe/micro-app --save启动micro-app// main-app/src/main.js import microApp from micro-zoe/micro-app microApp.start()如果项目里会统一放置子应用入口配置也可以抽成简单的注册信息// main-app/src/utils/microApps.js export default [ { name: micro-my-App, url: process.env.VUE_MYAPP_URL, baseRoute: /myApp, }, ]4.2 主应用挂载子应用在主应用页面中可以直接通过micro-app标签挂载子应用。对于后台类系统这种接入方式通常足够直接也更容易落地。!-- MicroAppContainer.vue -- template micro-app namemicro-my-app :urlmyAppUrl baseroute/myApp :datamicroData keep-alive / /template script export default { name: MicroAppContainer, data() { return { myAppUrl: process.env.VUE_MYAPP_URL, microData: { token: localStorage.getItem(token), userInfo: JSON.parse(localStorage.getItem(userInfo) || {}), }, } }, } /script这一步的重点只有两个主应用负责把子应用入口地址传进来。主应用只透传最基础的数据例如token、userInfo。4.3 主应用向子应用透传数据如果需要在运行时继续同步登录态或发送退出通知可以直接使用setData。// main-app/src/utils/actions.js import microApp from micro-zoe/micro-app export function syncAuthToSubApp() { microApp.setData(micro-my-app, { type: init, token: localStorage.getItem(token), userInfo: JSON.parse(localStorage.getItem(userInfo) || {}), }) } export function broadcastLogout() { microApp.setData(micro-my-app, { type: logout, }) }对大多数后台系统来说这样的“最小透传”已经能解决大部分统一登录和切换问题没有必要一开始就把主子应用耦合得太深。4.4 子应用适配微前端环境子应用侧最常见的改造点有两个一个是静态资源路径适配一个是接收主应用透传的数据。先处理publicPath// micro-my-app/src/public-path.js if (window.__MICRO_APP_ENVIRONMENT__) { __webpack_public_path__ window.__MICRO_APP_PUBLIC_PATH__ }然后在子应用入口中引入// micro-my-app/src/main.js import ./public-path import Vue from vue import App from ./App.vue new Vue({ render: (h) h(App), }).$mount(#app)4.5 子应用接收主应用数据子应用可以通过addDataListener接收主应用传递的数据。这里建议只处理与接入直接相关的内容比如登录态同步、退出通知等。// micro-my-app/src/utils/microAppAuth.js if (window.__MICRO_APP_ENVIRONMENT__) { window.microApp?.addDataListener((data) { if (data?.token) { localStorage.setItem(token, data.token) } if (data?.userInfo) { localStorage.setItem(userInfo, JSON.stringify(data.userInfo)) } if (data?.type logout) { localStorage.removeItem(token) localStorage.removeItem(userInfo) location.hash #/login } }, true) }如果子应用后续还需要向主应用上报事件也可以再扩展通信能力但在第一阶段先把“能接入、能运行、能同步基础登录态”做好通常更重要。5. 小结对于多套独立后台系统整合这类场景微前端选型最重要的不是参数堆得有多满而是是否适合当前项目的真实约束。从这个角度看micro-app 的优势并不在于它是“最强方案”而在于它足够轻、足够稳、足够适合存量系统接入。如果当前目标是统一入口、减少跳转割裂、尽量少改老系统那么它确实是一个很务实的选择。
