最近开始在公司项目使用微前端，从零开始接触了微前端。

微前端定义

微前端是一种类似微服务的架构，他将微服务的理念应用到浏览器端。 简单来说，将一个庞大的前端服务拆分为 n 个小服务，在运行时聚合。 每个小服务可以独立开发，独立运行，独立部署。

微前端的价值

其核心价值如下：

  • 技术无关
  • 独立开发，独立部署
  • 增量升级
  • 独立运行，多应用之间互不影响

什么时候该使用微前端

  1. 维护一个庞大的前端项目，其构建，打包，发布，部署效率低下

  2. 多团队维护一个庞大的项目，代码版本控制和合并变得困难

  3. 历史项目中使用旧时代的技术栈，老系统不能抛弃，新技术得不到使用，没精力去重构整个应用

  4. 多团队，多项目开发，基础库如：react, react-router, antd, 自定义组件库如何更友好的控制统一版本？

  5. 大型项目中（比如：前端有 20 个服务），公共资源需要更新，如何做到只更新一处，不需要每个服务都更新，打包，上线

  6. 浏览器端，多前端服务，如何更好的做到通信？

  7. 跨公司，跨团队 协作一个项目时，如何优雅高效的落地？

  8. A 应用需要 引用 B 应用的 几个页面 或 整个服务。如何 0 成本引用，并且 B 服务新版发布，A 服务需要自动更新？ …

微前端的实现方式

iframe

优点

  1. 完美支持 js 隔离，样式隔离 缺点
  2. url 不同步， 浏览器刷新时，iframe 中的 url 状态会丢失
  3. iframe 局部弹框
  4. 内外通信效率低下，变量不能共享
  5. 每次进入，资源都会被重新加载，速度较慢

服务端路由

使用 nginx / k8s ingress 反向代理到不同的前端服务。 优点

  1. 开发成本低
  2. 配置简单 缺点
  3. 多应用之间切换时，每个应用都会重新加载，影响体验（可以思考 传统页面 和 SPA 区别）
  4. 多应用间不能共享数据
  5. 多应用间通信困难
  6. 多应用公共依赖重复加载

web components

优点

  1. 每个服务拥有独立的脚本和样式 缺点
  2. 改造成本大
  3. 各个浏览器兼容不友好
  4. 多应用公共依赖重复加载

single-SPA

优点

  1. 良好的体验，多服务切换如同单体 SPA
  2. 具备服务的生命周期
  3. 共享数据
  4. 兼容不同技术栈运行 缺点
  5. 多应用间，无多应用沙箱机制
  6. 多应用间，样式命名不慎会导致冲突
  7. js entry 导致子服务和基座强耦合

qiankun

优点

  1. 基于 single-SPA 封装，开箱即用
  2. 技术无关，多技术栈可以共存
  3. html entry 接入，解耦基座和子服务
  4. 样式隔离
  5. js 沙箱机制
  6. 资源预加载
  7. 提供全局错误机制
  8. 提供跨服务通信机制
  9. 提供服务的生命周期
  10. 脱离基座，单个服务降级运行策略处理 缺点

缺点

  1. 不兼容 ie 系列