为什么想到微前端，是巨石应用？
现代的前端应用的发展趋势正在变得越来越富功能化，富交互化，也就是传说中的SPA(单页面应用)；这样越来越复杂的单体前端应用，背后的后端应用则是数量庞大的微服务集群。被一个团队维护的前端项目，随着时间推进，会变得越来越庞大，越来越难以维护。所以我们给这种应用起名为巨石单体应用。
举例: 一个持续多年的应用，经历几年的业务的更新迭代，当项目发展到一定程度的时候就会遇到以下问题
- 业务模块之间不断的堆叠，交错引用，业务耦合如何治理？
- 老技术、老代码不敢动，新技术、新架构又想用？
- 万年技术债？既要跟随业务敏捷迭代，又要保证代码库向好发展，旧的框架类库如何平稳升级？
- 一个项目多个团队开发，你冲突我，我冲突你，如何解决并行开发的冲突？
- 代码库持续膨胀，难以维护的项目代码，是屎上雕花？还是从头再来？
什么是微前端？
现代复杂的web app或者网站，通常由很多 相对独立的功能模块组合而成，而对这些模块负责的应该是 相互独立的多个团队。这些独立的团队由于专业分工不同，会负责着 特定的业务领域，以及完成特定的开发任务。这样的团队，通常在人员组成方面囊括了从前端开发到服务端开发，从UI实现到数据库设计这样端到端的跨职能人员构成。
微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。使用两个简单的数学方程式理解
独立小应用A+独立小应用B+… +独立小应用N = 产品
品牌 + 商家 + 风控 + … + 营销 = 电商管理平台
它主要解决了两个问题：
- 随着项目迭代应用，越来越庞大，难以维护；
- 跨团队或跨部门协作开发项目导致效率低下的问题；
定义：微前端并不是指某一具体的技术，而是一种整合了技术、策略和方法的宏观架构方案，是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。
可以从理解面向垂直划分的系统 这一思想，理解微前端方案：**整个系统被垂直分割成几个松散耦合的应用程序。**每个“垂直”都负责一个单一的业务领域，如“订单”、“搜索与导航”、“产品”等。它有自己的表示层、持久层和一个单独的数据库。从开发的角度来看，每一个垂直都是由一个团队实现的，不同系统之间没有代码共享。
面向垂直划分的系统的前端架构
什么时候用
如果团队成员多、项目类型多，并且想将其打造成「内聚的单个产品」：
- 项目的团队成员来自多个团队
- 项目内多条迭代出现需求挤兑，影响测试、发布效率
- 跨空间、跨时间维度导致团队内技术体系无法统一
- 多个前端应用需要达到「内聚的单个产品」特征
- 「内聚的单个产品」中部分内容希望达到独立开发、独立发布、独立测试、独立灰度等能力
- 中后台项目，时间跨度长，演变成巨石应用，越来越难以维护。
下面图片列出的几个巨石应用中存在的问题点，自己动手打个勾，看看勾中了几个🤭
项目是否有上述这些情况呢？我们该如何解决这些问题呢？
这时候就到了这篇文章介绍的”主角”出场了，dangdangdang~~：考虑使用 “微前端”这个架构思想
现在这么多框架，该怎么选择微前端技术方案？
要知后事如何，请听下回分解🤭
