序
要回答这个问题，我们首先要解决的是：什么是“微”。大家可能已经听说过微服务的概念， 微服务是后端服务的一种架构模式，它想解决的问题是可用性问题、扩展性问题、耦合度问题，进而演变出“服务治理”，"服务发现"等等技术。例如：
通过熔断、限流等机制保证高可用；
微服务之间调用的负载均衡；
分布式事务（2PC、3PC、TCC、LCN等）；
服务调用链跟踪
配置中心
服务自动发现等等。
1、微服务的“微”字在于 单一职责
一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
2、还有一个面向服务
将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力
这两个基础的能力构成了微服务整个的架构体系，是围绕服务、围绕一个个单一的职责体系的，它将一个、多个不同业务体系内的服务连接起来合并成一个大的业务模块，再分而治之，对每个服务做相应的技术、业务处理，合并成了一整个面向服务的业务。当服务发生故障，熔断机制产生作用，兜底服务马上启用，然后调用告警服务，将信息通知给通知服务，接着通知服务负责提醒对应的人员查看并解决问题。
这一系列的操作就是微服务的“微”字所要解决的问题，它把传统的大型项目拆分成各个不同的业务模块，再由各种一致性组件、可用性组件把它们组合起来使用。
“微”是分治的意思，那微前端是什么呢？
历史 后端jsp时代JSP时代没有太多的悬念，我依稀还记得那个年代，当我clone下后端爸爸的代码，笨拙的在windows电脑上按照csdn的步骤安装java的jdk，打开百度搜索“JRE和JDK的区别是什么，我有没有装错”...一言难尽。总之那个年代，我们前端的代码大多数必须经过后端同学在jsp里面的标签处理才可以在线上使用这个时候拆分、分治的工作都集中在js，会分为很多套不同的js代码，在script中依次引入操作的。
这个阶段前端其实并不“微”，只是作为一个界面脚本标记存在的而已。
渐渐的ajax、jquery、require.js的出现打破了前端生态的模式，ajax使前后端分离，jquery使前端变得更加容易编写，而AMD的模块规范以及require.js的出现让前端从此变得不一样了，前端进入了模块化的时代。
require.js是遵循AMD协议的一个前端模块化库
最早的时候，所有Javascript代码都写在一个文件里面，只要加载这一个文件就够了。后来，代码越来越多，一个文件不够了，必须分成多个文件，依次加载。下面的网页代码，相信很多人都见过。
<script src="http://www.likecs.com/1.js"></script> <script src="http://www.likecs.com/2.js"></script> <script src="http://www.likecs.com/3.js"></script>requireJS的写法：
模块代码：
// main.js require(['moduleA', 'moduleB', 'moduleC',function (moduleA, moduleB, moduleC){ // some code here });requireJS可以通过我们现在熟悉的request()，类似的写法去引入一个模块，在这个时候，它的理念跟iframe相结合，就有了第一个“微前端”的架构模式，当然这个时候的微前端并不很“微”。
通过一张阿里云的控制台的图来解释这套架构的模式：
主应用负责框架、通信、路由、资源分配。
子应用负责实现业务。
两者之间通过一套特定的sdk进行交互。
已经非常接近微服务的整体概念了。 通过主框架解决共性问题，拆分各个不同的微模块、微应用解决各个单一职责的问题，这个时候每个应用是面向应用的,即应用本身只对应用本身负责，它有很多特性：
1、技术栈无关，遵循同一套通信机制即可
2、应用解偶，团队之间通过主框架基座进行交互
3、热更新插拔，不需要全部更新主框架，只需要更新对应的应用即可
4、可动态降级熔断
等等特性，可以说这一时期的前端已经进入了微前端时代。当然不是所有的应用都适用于这一个庞大的开发模式，毕竟阿里云几十上百个不同的应用模块是需要庞大的业务支撑的。
打包技术与SSR(服务端渲染)然后gulp出现了，webpack出现了，angular、vue、react单页应用都出现了。
但问题来了，我们知道我们一个单页应用里资源是很重的。首页的加载速度需要很大的代价去优化它。这个时候iframe会带来比较严重的体验问题。
Single-spa出现了。
一个用于前端微服务化的JavaScript前端解决方案