什么是微前端
官网上是这么描述的
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
- 背景
从官网我们可以了解到：微前端最早是出现在2016年的ThoughtWorks Technology Radar。它将微服务的概念推广到了前端。当前的趋势是构建一个功能丰富且强大的单页面应用程序，它位于微服务架构之上。但是随着我们不断的迭代产品，前端层的业务变得繁重复杂且越来越难维护。这就是我们说的前端单体( Frontend Monolith)
- 什么是微前端
微前端背后的想法是将整个的网站或者Web应用程序看作是独立团队所拥有的功能组合，每个团队负责各自的功能模块，每个团队是跨职能的，从数据库到用户界面，端到端的开发其功能。
通过下面这个图，我们可以更好的了解到：底部垂直排列的团队是这个架构的核心。
它们各自以页面或片段的形式产生特征。您可以使用 SSI 或 Web Components 之类的技术将它们集成到到达客户的组合页面中。
前端集成描述了一组用于将团队的用户界面（页面和片段）组装到集成应用程序中的技术。您可以将这些技术分为三类：路由、组合和通信。根据您的架构选择，您有不同的选择来解决这些类别。
从上述的介绍我们可以了解到微前端更像是一种概念而不是具体的技术。它是一种组织和架构的方法。
微前端解决什么问题
- 公司选择使用微前端的第一个路线是提高开发效率。在分层架构中，多个团队参与构建新的功能。减少团队之间的等待时间是微前端的主要目标
现在的架构都没有扩展到前端开发的概念，依然是单体、前端/后端拆分和微服务。他们都带有一个整体式的前端。
从这里我们可以理解微前端的优点：
- 可独立部署
- 将故障风险隔离到更小的区域
- 范围更窄，因此更容易理解
- 具有较小的代码库，可以在您想要重构或替换它时提供帮助；并且可以减少意外耦合的情况出现
- 更可预测，因为它不与其他系统共享状态
解决的问题：
拆分和细化
当下前端领域中，单页面应用（SPA）是非常流行的前端趋势。但是随着项目的迭代，功能和代码会越来越繁杂。耦合度也会越来也高。微前端的意义之一就在于将这些繁杂的代码和功能模块进行拆分和细化整合历史系统
在不少的业务中，老系统和新系统是共存的，作为开发人员没办法浪费时间和经历将老系统进行改写。微前端可以将新旧系统进行整合。在一套系统中同时兼顾两个子系统
微前端的好处
我们不是根据特定的技术方法或实现细节来定义微前端，而是强调其出现的属性及其带来的好处
- 增量升级
- 简单、解耦的代码库
- 独立部署
- 自治团队
目前国内的微前端的种类
- 基座模式
通过搭建基座、配置中心来管理子应用。如目前大部分的单页面应用基本都会选择qiankun框架，也存在基于业务的自制方案 - 自组织模式
通过约定进行互相调用 - 去中心模式
脱离基座模式，，每个应用之间可以彼此分享资源。如基于webpack 5 moudle Federation实现的 EMP微前端方案,可以实现多个应用彼此共享资源的分享
