前言
本文由昨日的面试有感而发，因为工作久了接触的项目会多，复杂场景也会多起来，尤其是当公司有一些老旧的项目需要新项目融合到一起去维护，这时关于微前端这个概念是不可能不去了解的，那么什么是微前端，如何通俗的理解呢？下面就是我对它的理解，希望能给看文章的你一个思路吧！
微前端是什么？
微前端的概念来源于微服务，摒弃了大型单体应用的方式，将前端整体分解为小而简单的块儿，这些块儿可以独立的开发、独立测试、独立部署、同时仍然可以聚合为一个产品来使用。
特点：
1. 与技术栈无关
2. 独立开发部署
3. 渐进式增量升级
本质上是一种理念
微前端不是一门具体的技术，而是整合了技术策略和方法的架构理念，技术上实现上你可以使用脚手架、辅助插件或者规范约束等等以生态圈的形式展现出来，是一种宏观上的架构，这种架构目前有多种方案，也没有技术栈的约束，每一套微前端架构下的具体应用都可能使用了不同的技术栈。
可以使用同一种技术栈开发所有微前端架构下的应用；也可以将不同技术栈的项目整合成一个项目去运行。
它解决了什么问题？
它帮助我们拆分巨型的应用，降低耦合度，使应用变得更加可维护，同时兼容历史应用，轻松实现增量开发。或者将多个可独立交付的小型前端应用聚合为一个整体的架构设计。
拆分和细化
当下前端领域，单页面应用（SPA）是非常流行的项目形态之一，而随着时间的推移以及应用功能的丰富，单页应用变得不再单一而是越来越庞大也越来越难以维护，往往是改一处而动全身，由此带来的发版成本也越来越高。微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。
整合历史系统：
在不少的业务中，或多或少会存在一些历史项目，这些项目大多以采用老框架类似（Angular.js 1）的B端管理系统为主，介于日常运营，这些系统需要结合到新框架中来使用还不能抛弃，对此我们也没有理由浪费时间和精力重写旧的逻辑。而微前端可以将这些系统进行整合，在基本不修改来逻辑的同时来同时兼容新老两套系统并行运行。
它的具体适用场景
下面来分享两个场景。
项目场景1：
有一个老的项目是用vue 写的，另一个老的项目是用angular完成的，而新的项目是用的react技术栈，现在要实现将这三个项目合并，使用同一份菜单，顶部和底部的样式，且点击不同菜单展示不同项目的不同路由。
项目场景2：
有多个子项目用的是相同的技术栈react，现在要进行合并，使用同一份菜单，点击跳转到不同项目，左侧菜单和顶部的样式共用。
应对方案：
对于两种场景，都可以使用社区的一些框架来实现。
我们公司项目遇到的是从一种场景发展到第二种场景，所以我们初期用
iframe跳转来过渡，然后在这个期间进行组件重构，对于第二种场景使用的是基于阿里的icestark的微服务架构：icestark
首先我们将项目整合的前提新创建了一个主项目，它包含有顶部和底部样式，以及左侧的通用菜单。然后建立一个本地数据库，数据库存储了所有子项目的路由配置，不同的子项目分配不同的子域名，且要求各个子页面路由定义结构一致，修改
umirc.js配置实现路由分发。实现所有子项目共用同一个登录，主项目调用接口去获取用户菜单，一次登录即可获取整个项目菜单，展示在左侧，获取的子项目展示在右侧指定区域。
社区还有哪些微前端的解决方案？
下面是两个框架在官网的一句话介绍。两个框架各有优点，对于这两个方案你有什么看法，欢迎评论区讨论呀。
qiankun: 可能是你见过最完善的微前端解决方案
MicroApp: 一款轻量、高效、功能强大的微前端框架
文档：
配置对比：
下面就对比一下这两个主流的框架的一些配置，仅供参考。
| 功能配置 | qiankun | micro App |
|---|---|---|
| 框架体积 | 94kb | 30kb |
| 渲染原理 | 路由监听 | CustomElement |
| 数据通信机制 | 基于props属性传递 | 基于发布订阅+CustomElement |
| 接入成本 | 中 | 低 |
| 多框架兼容 | ✅ | ✅ |
| JS沙箱 | ✅ | ✅ |
| 样式隔离 | ✅ | ✅ |
| shadowDom | ✅ | ✅ |
| 预加载 | ✅ | ✅ |
| 静态资源地址补全 | ❌ | ✅ |
| 元素隔离 | ❌ | ✅ |
| 插件系统 | ❌ | ✅ |
结语
在现在这个开源大环境下，使用哪个框架，或者自己实现微前端都可以，哪种方式使用的更舒服就用哪种。但是如果你当前的项目使用微服务之后，变的维护成本急剧增加，那就要考虑是否适合微前端，不是一种架构适合所有场景的，尝试去考虑其他方案。
一句话总结：微前端架构是可以与多个可以独立发布功能的团队一起构建现代化Web 应用程序的技术、策略和方法。
参考文献：
