1. 微前端的背景

1.1 微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API进行通信的 小型独立服务 组成。 微服务的主要思路：

• 将大应用分解生 相互连接的小的服务（微服务），一个微服务完成某一特定功能
• 每一个微服务都有自己的独立的业务逻辑和适配器，并且可以使用不同的技术栈
• 微服务使用统一的网关进行调用

思路总结：大应用细致化分，使得服务内部更加内聚，服务之间耦合性降低，利于团队开发和后期维护

1.2 微前端

微前端的概念借鉴于后端微服务，将微服务这种架构和组织方法应用于前端，这就是微前端。

2. 微前端是什么

发展历程：巨石应用--->前后端分离的应用--->微服务--->微前端

同1.2，微前端是一种架构代码的风格，就是可以独立交付的前端应用被组合成一个大的整体应用；

3. 现在Web应用面临的问题

DX(developer experience)

• 业务领域的代码库不够独立和高度可重用
• 相同的产品功能由多个团队开发 / 产品功能难以保持统一
• 新的产品理念无法在不同的应用中快速复用 / 实现
• 快速迭代新子业务 / 干净移除将被淘汰的子业务

UX(user experience)

• 性能体验
• 页面跳转和用户体验问题

总结：

1. Spa单页应用应用随时间越来越大，维护往往牵一发动全身，开发和维护成本越来越高--->微前端可以将庞大的应用解耦，每个部分独立开发和部署，提升开发和维护效率（独立开发和部署）；
2. 老旧项目，技术栈过时，但是业务要求并不需要重新迭代该项目--->微前端可以将这些系统整合，在保证原项目基本逻辑的同时，兼容新老两套系统（技术栈无关）。

4. 微前端的特点

说人话：

1. 独立开发/部署---各个团队之间仓库独立，单独部署，互不依赖
2. 技术栈无关------主框架不限制接入应用的技术栈，子应用可自主选择技术栈
3. 独立运行时------微应用之间运行时互不依赖，有独立的状态管理
4. 增量升级-------当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性；- 提升效率 应用越庞大，越难以维护，协作效率越低下。微应用可以很好拆分，提升效率

5. 微前端的价值

与第四点特点并没有严格区分，只是不同角度的描述

6. 微前端应用应该具备哪些能力

说人话

• 子应用并行-----类似组件并行
• 子应用嵌套-----类似于组件嵌套
• 父子应用通讯---类似于父子组件通信。主应用下发状态，子应用调用主应用的方法。。。
• 预加载---------空闲时间加载子应用，提升页面的加载速度
• 公共以来加载---大部分子应用都会用到的资源或者子应用
• 按需加载-------
• Config Entry和HTNL Entry----核心功能
• JS沙箱和Css隔离----js和Css互不影响

7. 微前端解决方案有哪些

1. 使用HTTP服务器的路由来重定向多个应用
2. 基于 iframe 完全隔离的方案

iframe 就相当于页面里再开个窗口加载别的页面

优点：

• 非常简单，无需任何改造
• 完美隔离，JS、CSS 都是独立的运行环境
• 不限制使用，页面上可以放多个 iframe 来组合业务

缺点：

• 每次进来都要加载，状态不能保留
• 完全的隔离导致与子应用的交互变得极其困难，无法与主应用进行资源共享
• iframe 中的弹窗无法突破其本身，比如子应用里有一个 Modal，显示的时候只能在那一小块地方展示，不能全屏展示
• 整个应用全量资源加载，加载太慢

4. EMP基于webpack module federation
5. 使用纯的Web Components构建应用
6. 业界主流微前端框架

• 基于 single-spa 路由劫持方案
• qiankun

8. 使用乾坤搭建微应用项目