微前端架构解析
作者:Atom
字数统计:1.3k 字
阅读时长:4 分钟
实际项目中为了降低大型复杂应用的开发、升级、维护以及团队协作的成本。因此而诞生了微前端这种前端架构, 类似于后端微服务 (Microservices) 的概念。
微前端架构是一种将前端应用拆分成多个更小、更简单的应用，每个应用都是独立的，可以独立开发、独立部署、独立运行。这样可以让团队更好的协作，提高开发效率，降低维护成本。
特性
- 微应用可以采用不同的技术栈，支持独立开发
- 微应用可以单独部署到不同的服务器上，支持独立部署
- 微应用的运行可以不依赖其他微应用，支持独立运行
为了使整个单体应用可以根据不同的业务进行解耦，微前端会将单个应用拆分成多个聚合在一起的小型应用。在聚合的过程中需要一个容器应用（在微前端里称作主应用），主应用通过设计导航将各个拆分的小型应用（在微前端里称作微应用）聚合在一起，可以根据导航进行微应用的切换
路由切换方案
- 如果主应用是 SPA 应用，此时导航是路由跳转，根据前端路由进行微应用切换；
- 如果主应用是 MPA 应用，此时导航是链接跳转，根据后端路由进行微应用切换；
- SPA 和 MPA 应用都可以通过其他方式来切换微应用，例如动态切换微应用的 Script
- 除此之外，复杂的业务场景还可以是上述几种方案的结合体
微前端方案
如果项目本身采用 SPA 模式进行开发，则可以通过以下方案进行微前端改造：
- 基于 NPM 包的微前端：将微应用打包成独立的 NPM 包，然后在主应用中安装和使用；
- 基于代码分割的微前端：在主应用中使用懒加载技术，在运行时动态加载不同的微应用；
- 基于
Web Components的微前端：将微应用封装成自定义组件，在主应用中注册使用； - 基于
Module Federation的微前端：借助Webpack 5的Module Federation实现微前端； - 基于动态
Script的微前端：在主应用中动态切换微应用的Script脚本来实现微前端； - 基于 iframe 的微前端：在主应用中使用 iframe 标签来加载不同的微应用；
- 基于框架（JavaScript SDK）的微前端：使用
single-spa、qiankun、wujie等通用框架。
方案一、 IFrame
在微前端中 iframe 方案需要一个主应用，包含导航和内容区的设计，通过切换导航来控制内容
在 iframe 的方案中，导航设计可以是前端框架路由来控制不同微应用所在 iframe 的显示和隐藏，也可以通过自己设计切换逻辑来动态加载 iframe
在首次加载 iframe 应用时，都会因为服务端请求而导致内容区带来短暂的白屏效果
优缺点
优点
- 站点隔离和浏览上下文隔离，可以使微应用在运行时天然隔离，适合集成三方应用；
- 移植性和复用性好，可以便捷地嵌在不同的主应用中。
缺点
- 主应用刷新时， iframe 无法保持 URL 状态（会重新加载 src 对应的初始 URL）；
- 主应用和 iframe 处于不同的浏览上下文，无法使 iframe 中的模态框相对于主应用居中；
- 主应用和 iframe 微应用的数据状态同步问题：持久化数据和通信。
方案二、 Npm
NPM方案仅仅适合集成一些小型微应用，如果微应用的资源过大，势必要对微应用的构建进行资源优化处理，例如多入口应用的三方库去重、弱网环境下 chunk 大小分离控制、懒加载、预加载等。
除此之外，主应用集成的微应用过多，也会导致构建多份重复的框架带来构建体积过大的问题，还需要考虑主子应用的共用框架抽离问题。
优缺点
优点
- 微应用可以使用不同的技术栈进行开发；
- 微应用不需要进行静态资源托管，只需要发布到 NPM 仓库即可；
- 移植性和复用性好，可以便捷地嵌在不同的主应用中；
- 微应用和主应用共享浏览器的 Renderer 进程、浏览上下文和内存数据。
缺点
- 如何处理主应用和各个微应用的全局变量、CSS 样式和存储数据的冲突问题；
- 微应用的构建需要做额外的配置，构建的不是应用程序而是 JavaScript 库；
- 由于微应用构建的是库包，因此不需要代码分割和静态资源分离（例如图片资源、CSS需内联在JS内）
- 微应用发布后，主应用需要重新安装依赖并重新构建部署。