微前端实现原理、框架选型之类的文章比较泛滥，我不打算讲这些玩意，本文主要来源于笔者过去一年落地微前端的一手经验，尽量不讲技术细节，而是讲一个体系化的方案是怎么搭建起来。
文章较长，耐心看完保证会有收获。
背景与痛点
首先来看下业务背景，方便读者了解我们为什么选择微前端，以及其他相关技术选型的原因。
前端在架构上面的变化远落后于后端，后端的架构已经经历了微服务、中台化、DDD 改造的腥风血雨…
在改造成微前端之前, 我们也是一个巨型的单体应用，后面随着业务的复杂化，业务和团队进一步进行拆分， 我们的前端项目也根据康威定律，进化成为了‘多页应用’， 如下图所示：
我们主要做的是 2B 业务，做 POC(概念验证) 和私有化部署是家常便饭，在已有的架构下，我们需要应用某些配置可能会牵扯多个项目，比如主题、文案、接口配置等信息的修改，需要针对多个项目进行创建分支、修改代码、构建、发布、部署… 一系列繁琐的流程
主要原因是我们的业务系统经过长期、多团队、多业态的迭代，积累了大量的技术债。
- 技术栈老旧，开发效率低，我们想要应用新的技术和规范，但碍于项目体量大、质量差，重构举步维艰。
- 子应用的拆分没有固定的范式。有些模块按照团队拆分出独立的仓库，有些仓库则采用 MonoRepo。前者仓库之间存在大量重复代码、缺乏管理；而后者 MonoRepo 则越来越臃肿, 职责不清晰，编译缓慢, 逐渐也演变成了
巨石应用。 - 基于多页的子应用缺乏管理，规范/标准不统一。无法统一控制视觉呈现、共享的功能和依赖。造成重复工作
- 新旧项目、第三方应用集成都很复杂。
- 多行业、多团队的项目特性，导致工程管理复杂，扩展性差。
- 部署方式原始。
- 应用按照菜单聚合，而不是按照业务聚合
- …
