微前端简介

微前端的概念由微服务衍生而来：一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品

特点

类似于微服务

关键优势在于

实现上，关键问题在于（具体查看解决思路）

多个 bundle 如何集成
- 服务端集成：如 SSR 拼装模板
- 构建时集成：如 Code Splitting
- 运行时集成：如 iframe、js 前端路由、web components 等
子应用之间怎样隔离影响
- 样式隔离
- js 隔离
公共资源如何复用
- 基础资源
- UI 组件
- 业务组件
公共资源比较推荐的模式是开源软件的管理模式：所有人都能补充公共资源，但有人负责监管，以保证质量、一致性、正确性
子应用间怎样通信
- 通过自定义事件间接通信是一种避免直接耦合的常用方式
- 路由参数通信
无论采用哪种方式，都应该尽可能减少子应用间的通信，以避免大量弱依赖造成的强耦合
如何测试每个子应用都应该有自己的全套测试方案，特殊之处在于，除单元测试、功能测试外，还要有集成测试
- 集成测试：保证子应用间集成的正确性，比如跨子应用的交互操作
- 功能测试：保证页面组装的正确性
- 单元测试：保证底层业务逻辑和渲染逻辑的正确性

微前端的架构模式并非无害

导致依赖项冗余，增加用户的流量负担没有非常理想的解决办法，一种简单的方案是将公共依赖从子应用的构建产物中剔除，但又会在引入构建时耦合
团队自治程度的增加，可能会破坏写作在采用微前端之前，先要考虑几个问题
- 现有的前端开发、测试、发布流程如何扩展支持多个应用
- 分散的、控制弱化的工具体系及开发事件是否可靠
- 针对各式各样的前端代码库，如何建立质量标准

总之，微前端将产生一堆小的东西，因此需要考虑是否具备采用这种方法所需的技术和组织成熟度

类似于微服务之于后端，前端业务在发展到一定规模之后，也需要一种用来分解复杂度的架构模式，于是出现了微服务思想在前端领域的应用，即微前端。主要目的在于：