1. 初识微前端
“微前端”(Micro Frontend)一词最早出现在 2016 年，Thought Works 公司在他们网站的技术雷达板块发表了微前端的概念，借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，帮助大型复杂应用程序在前端开发中实现更高的灵活性和可扩展性。
2. 核心思想
微前端三大核心原则：独立开发、独立部署、独立运行。
3. 应用场景
- 项目团队成员来自多个团队：通过微前端架构，每个团队可以独立开发和维护自己的微应用，减少团队之间的依赖和沟通成本。
- 迭代挤兑导致测试、发布效率下降：每个微应用可以独立迭代，测试和发布，减少不同应用之间的冲突，提高效率。
- 跨空间、跨时间导致技术体系无法统一：每个微应用可以选择适合自己的技术栈和框架，开发者可以根据需要独立选择开发工具和技术，不受其他应用的约束。
- 多个前端应用需要达到内聚的单个产品特征：通过微前端聚合平台，将不同的微应用集成为一个统一的产品，实现整体一致性和用户体验。
4. 微前端发展
从 2016 年到现在，差不多 7、8 年的时间，其实微前端已经历了几轮变革，由最初的 iframe、single-spa 演变成如今的各大厂的微前端框架技术方案，最近一两年微前端一度成为技术热点，各大公司相继在微前端加大投入。面对微前端在落地实践中暴露的一些问题，很多公司也相继提出解决方案，比如蚂蚁集团的 qiankun，京东的 MicroApp 等等
5. MicroApp
5.1. 本质
借鉴了 WebComponent 的思想，通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 WebComponent 组件，从而实现微前端的组件化渲染。
- WebComponent：原生组件
- CustomElement：自定义元素
- ShadowDom：影子 DOM
5.2. 工作原理
整体架构思路为 CustomElement + HTMLEntry：
- micro-app 标签：上可以设置各种配置，比如开启 iframe 沙箱、开启 ssr 模式、开启 keep-alive 模式、关闭沙箱、数据通信
- HTMLEntry：就是以 html 文件作为入口地址进行渲染
5.3. 如何使用
像使用 iframe 一样简单
客户端渲染效果
5.4. 主要功能
生命周期、环境变量、虚拟路由、JS沙箱、样式隔离、元素隔离、数据通信、等等
5.4.1. 生命周期
- created： 标签初始化后，加载资源前触发。
- beforemount：加载资源完成后，开始渲染之前触发。
- mounted：子应用渲染结束后触发。
- unmount：子应用卸载时触发。
5.4.2. 环境变量
- MICRO_APP_PUBLIC_PATH ：主要在配置文件中使用，比如改造子应用静态资源前缀
- MICRO_APP_BASE_ROUTE ：主要用来设置主应用基础路由
5.4.3. 虚拟路由系统
通过虚拟路由系统，我们可以方便的进行导航守卫、跨应用的跳转，提升开发效率，并且子应用运行在这套虚拟路由系统中，和主应用的路由进行隔离，避免相互影响，如：
- 主应用控制子应用跳转
- 子应用控制主应用跳转
- 子应用控制其它子应用跳转
5.4.4. JS沙箱
确保子应用之间全局变量/事件不冲突。
5.4.5. 样式隔离
样式隔离确保子应用之间样式互相不干扰，如下图，使用 micro-app[name=xxx] 为子应用样式添加唯一前缀。
5.4.6. 元素隔离
元素隔离的概念来自 ShadowDom，即 ShadowDom 中的元素可以和外部的元素重复但不会冲突，micro-app模拟实现了类似 ShadowDom 的功能，元素不会逃离 元素边界，子应用只能对自身的元素进行增、删、改、查的操作。
5.4.7. 数据通信
- 主子应用间通信
- 子应用全局通信
5.4.8. 其他能力
- 预加载
- 缓存
- etc...
5.5. 兼容性
- 技术栈：vue、react、angular、nuxt、next
- 构建工具：webpack、vite、vue-cli
- 浏览器：PC 端，除了 IE 浏览器，其它浏览器基本兼容，移动端：ios10+ 、android5+
5.6. MicroApp接入注意
- 子应用跨域：webpack、vite
- 样式隔离：约定前缀、命名空间
- 命名空间
6. 一站式设计方案
整体架构 — 技术栈选型 — 功能模块划分
6.1. 整体架构
首先，从整个网站架构层面使用微前端架构模型，包含一个基座应用用于承载多个子应用，多个子应用之间互相隔离，如果需要通信，会基于 MicroApp 的通信机制来实现主子、子子通信，MicroApp 的各种能力同时对主应用和子应用有效。
6.2. 技术选型
微前端应用 = 微前端框架 + JS 框架 + UI 框架 + 构建工具
微前端框架：MicroApp
JS 框架：vue3、vue2、nuxt2、react18
UI 框架：element-ui、element-plus
构建工具：webpack5、vite4、vue-cli5
从主子应用的技术栈选型来分析，为了体现微前端的技术栈无关的特点，我们 4 个子应用、1 个主应用分别使用到不同的技术栈，子应用分别使用到的技术栈有 nuxt2、vue2、vue3、react18，主应用使用到技术栈 vue3。
6.3. 模块划分
从功能模块角度出发，4 个子应用，每个都承载了一个独立的业务功能模块，分别是首页、找工作、找企业、关于我们，他们之间相互独立，通过沙箱隔离方案实现 js、css、元素隔离，但是又由于一些业务耦合会产生一些交互逻辑，比如数据通信、跨应用跳转，这些 MicroApp 应用通信、虚拟路由系统能帮助我们完美解决。当然子应用的加载、卸载、渲染逻辑 MicroApp 也提供了生命周期、预加载、等一些能力。
7. 场景落地
我们最终实现的效果如下：
vue3 所实现的主应用作为整个微前端应用的基座，包含了公共头部和公共底部组件，在中间的主要内容部分，内嵌来自不同技术团队基于不同技术栈的子应用，通过切换主应用的 tabs 组件可以切换到相应的承载业务模块的子应用，整体上来看这似乎是一个普通的网站架构，但实际从底层出发，这种架构模式可以弥补巨石应用提供无限嵌套、无限拆分的能力，即使我们再去增加 N 个业务模块子应用，也不会对主应用的 size 造成过多的应用，因为最终每个应用都将是独立打包部署的，代码层面之间的部署没有任何耦合。
8. 特点
- 技术无关
- 增量升级
- 独立开发、部署、运行
- rc版本，不建议生产使用
9. 难点
- 跨域
- 资源共享
- 数据通信
- 路由跳转
10. 槽点
技术栈本身的限制：vite、react样式隔离、未知问题...
11. 总结
以上就是我们基于 MicroApp 设计的一站式微前端架构，这种架构模式很全面的体现了微前端技术栈无关的特点、增量升级的开发流程，真真正正为实战项目做出合理规划和布局，不论团队的变迁， 项目迭代的周期有多长，同时也能够经得起折腾。
试想一下，如果我们通过采用一站式的微前端架构去应用到其他的中后台场景中，这样既能够实现团队的解耦协作，也能够将中后台研发模式统一，从而解决一些共性问题，实现各业务模块的独立开发与部署，也同时具备渐进式升级，增量升级的优势，整个巨石应用都是客插拔、可拆分、可扩展。极大地提高开发效率和系统的可维护性。
