困局
在开始前，我们先来看看传统架构方式的一个发展历程：
可以归纳为三个阶段：
- 前后端一体
- 前后端分离，单体应用
- 前后端分离，后端微服务化
在前后端进行分离后，后端仅负责数据处理工作，前端的职责开始扩张。同时前端技术的发展也促使前端应用的复杂度不断提升。这时，传统的单体架构在大型应用中就稍显乏力了，尤其是中后台项目，时间跨度长，很容易就演变成巨石应用，越来越难以维护。
举例: 一个持续多年的应用，经历几年的业务的更新迭代，当项目发展到一定程度的时候就会遇到以下问题
- 业务模块之间不断的堆叠，交错引用，业务耦合如何治理？
- 老技术、老代码不敢动，新技术、新架构又想用？
- 万年技术债？既要跟随业务敏捷迭代，又要保证代码库向好发展，旧的框架类库如何平稳升级？
- 一个项目多个团队开发，你冲突我，我冲突你，如何解决并行开发的冲突？
- 代码库持续膨胀，难以维护的项目代码，是屎上雕花？还是从头再来？
你们的项目是否有上述这些情况呢？我们该如何解决这些问题呢？
破局
“微前端”这个词首次出现是在2016年 ThoughtWorks Technology Radar 中，但是直到最近几年才被频频提及，那么它是破局之法吗？
微前端源自微服务这种服务端的技术范式，微服务的核心关键在于服务的抽象，用于解决服务端高并发、高可用等问题。而微前端和微服务不尽相同，微前端是一种多个团队通过独立发布的方式来共同构建现代化 web 应用的技术手段及方法。微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的工程膨胀、开发维护困难等问题。
微前端背后的思想是认为：现代复杂的web应用，通常由很多 相对独立的功能模块组合而成，而对这些模块负责的可能是 相互独立的多个团队。这些独立的团队由于专业分工不同，会负责着 特定的业务领域，以及完成 特定的开发任务。这样的团队，通常在人员组成方面囊括了从前端开发到服务端开发，从UI实现到数据库设计这样 端到端 的 跨职能人员 构成。
然而微前端这个概念并不新鲜。它实际上与 自包含系统 概念一脉相承。在过去，微前端之类的思路，会被称为 面向垂直划分系统的前端集成。称之为微前端，是因为这个词，对于前端开发人员来说更加易于理解。
定义：微前端并不是指某一具体的技术，而是一种整合了技术、策略和方法的宏观架构方案，是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。
使用场景
目前来说，微前端并不是一个无脑使用的架构方案，相比现行的架构方案，还是会带来一些工程复杂度的提升。那么什么场景下可以考虑使用微前端呢？
1. 复用别的的项目页面
在新项目中需要集成一些其他已开发好的项目时，或者直接复用已有的一些功能模块时，常规的方案就是把代码直接拷贝过来，但是会有一些问题：
- 技术栈不一致，依赖版本不一致，等等问题需要做处理。
- 更新比较麻烦，别人代码更新，我们需要去做同步。
2. 巨无霸项目的自由拆分组合
一个功能齐全的大型项目，在开发维护时面临到如下问题：
- 代码越来越多，打包越来越慢，部署升级麻烦，一些插件的升级和公共组件的修改需要考虑的更多，很容易牵一发而动全身
- 项目太大，参与人员越多，代码规范比较难管理，代码冲突也频繁。
- 产品功能齐全，但是客户往往只需要其中的部分功能。剥离不需要的代码后，需要独立制定版本，独立维护，增加人力成本。
当你遇到如上两种情况，那么你可以考虑接入微前端。
想了解微前端更多的信息请查阅micro-frontends。