模拟面试、简历指导可私信找我，最低的价格收获最高的指导~已帮助50+名同学完成改造！

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心。

前言

本文由昨日的面试有感而发，因为工作久了接触的项目会多，复杂场景也会多起来，尤其是当公司有一些老旧的项目需要新项目融合到一起去维护，这时关于微前端这个概念是不可能不去了解的，那么什么是微前端，如何通俗的理解呢？下面就是我对它的理解，希望能给看文章的你一个思路吧！

微前端是什么？

微前端的概念来源于微服务，摒弃了大型单体应用的方式，将前端整体分解为小而简单的块儿，这些块儿可以独立的开发、独立测试、独立部署、同时仍然可以聚合为一个产品来使用。

特点：

  1. 与技术栈无关  2. 独立开发部署  3. 渐进式增量升级复制代码

本质上是一种理念

微前端不是一门具体的技术，而是整合了技术策略和方法的架构理念，技术上实现上你可以使用脚手架、辅助插件或者规范约束等等以生态圈的形式展现出来，是一种宏观上的架构，这种架构目前有多种方案，也没有技术栈的约束，每一套微前端架构下的具体应用都可能使用了不同的技术栈。

可以使用同一种技术栈开发所有微前端架构下的应用；也可以将不同技术栈的项目整合成一个项目去运行。

它解决了什么问题？

它帮助我们拆分巨型的应用，降低耦合度，使应用变得更加可维护，同时兼容历史应用，轻松实现增量开发。或者将多个可独立交付的小型前端应用聚合为一个整体的架构设计。

拆分和细化

当下前端领域，单页面应用（SPA）是非常流行的项目形态之一，而随着时间的推移以及应用功能的丰富，单页应用变得不再单一而是越来越庞大也越来越难以维护，往往是改一处而动全身，由此带来的发版成本也越来越高。微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。

整合历史系统：

在不少的业务中，或多或少会存在一些历史项目，这些项目大多以采用老框架类似（Angular.js 1）的B端管理系统为主，介于日常运营，这些系统需要结合到新框架中来使用还不能抛弃，对此我们也没有理由浪费时间和精力重写旧的逻辑。而微前端可以将这些系统进行整合，在基本不修改来逻辑的同时来同时兼容新老两套系统并行运行。

它的具体适用场景

下面来分享两个场景，可以使用不同的微前端解决方案。

项目背景1：

我们有一个老的项目是用vue 写的，而新的项目是用的react技术栈，现在要实现将两个项目合并，使用同一份菜单，点击不同菜单展示不同项目的不同路由。

项目背景2：

现在有多个子项目用的是相同的技术栈，现在要进行合并，使用同一份菜单，点击跳转到不同项目，左侧菜单和顶部的样式不变。

应对方案：

对于两种场景，都可以使用社区的一些框架来实现。

我们公司项目遇到的是从一种场景发展到第二种场景，所以我们初期用到跳转来过渡，对于第二种场景使用的是基于阿里的icestark的微服务架构：首先建立一个本地数据库，数据库存储了所有子项目的路由配置，不同的子项目分配不同的子域名，且要求各个子页面路由定义结构一致，修改umirc.js配置实现路由分发。实现所有子项目共用同一个登录，主项目调用接口去获取用户菜单，一次登录即可获取整个项目菜单，展示在左侧，获取的子项目展示在右侧指定区域。

阿里开源微前端架构：icestark[1]

社区还有哪些微前端的解决方案？

下面是两个框架在官网的一句话介绍。两个框架各有优点，对于这两个方案你有什么看法，欢迎评论区讨论呀。

qiankun: 可能是你见过最完善的微前端解决方案

MicroApp: 一款轻量、高效、功能强大的微前端框架

文档：

MicroApp文档地址[2]

qiankun文档地址[3]

配置对比：

下面就对比一下这两个主流的框架的一些配置，仅供参考。

总结

在现在这个开源大环境下，使用哪个框架，或者自己实现微前端都可以，哪种方式使用的更舒服就用哪种。但是如果你当前的项目使用微服务之后，变的维护成本急剧增加，那就要考虑是否适合微前端，不是一种架构适合所有场景的，尝试去考虑其他方案。

一句话总结：微前端架构是可以与多个可以独立发布功能的团队一起构建现代化Web 应用程序的技术、策略和方法。

结语

我是林三心，一个热心的前端菜鸟程序员。如果你上进，喜欢前端，想学习前端，那咱们可以交朋友，一起摸鱼哈哈，摸鱼群，关注我，拉你进群，有5000多名前端小伙伴在等着一起学习哦 -->

模拟面试、简历指导可私信找我，价格超级实惠~已帮助50名同学完成改造！

作者：玖月晴空
链接：https://juejin.cn/post/7203266679601791034
来源：稀土掘金