-
源码地址：http://github.com/micro-zoe/micro-app
-
官网地址：http://zeroing.jd.com/micro-app
微前端的概念是由ThoughtWorks在2016年提出的，它借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。
微前端主要解决了两个问题：
1、 随着迭代应用越来越庞大，难以维护。
2、 跨团队或跨部门协作开发项目导致的效率低下的问题。
这两个问题在很多公司都很常见，许多前端项目经过多年不断迭代或项目交接，技术架构早已落后，新接手的同学对于冗余的庞大项目无可奈何。微前端可以让我们跳出这个陷阱，减少新旧项目的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更简单。
如何实现微前端
实现微前端方式有很多，我们这里列出两种最常用的方式：iframe和微前端框架。
iframe是在页面中创建一个独立的window窗口，它完全和自己所在的页面隔离，具有天然的样式和JS隔离特性，这也是实现微前端最简单、最稳定的方案。但也因为iframe每次都会初始化整个window，一个iframe标签其实就是一个内嵌的浏览器窗口，所以也导致一系列的问题，比如性能不高、双滚动条、弹窗无法覆盖全局、刷新页面路由状态丢失，这些问题的根源在于iframe的渲染方式，无法很好的解决。
微前端框架也是最近几年新推出的一种微前端解决方案，它的基本原理是将子应用的JS、CSS等静态资源加载到基座应用渲染，本质上这两个应用都是在同一个页面，只是渲染的区域不同，并通过一些手段防止多个应用之间的冲突。较早推出的比较有名的微前端框架是single-spa，它主要负责渲染，即将多个独立的应用融合为一，功能相对较少，所以很多团队以它为基础进行封装，增加更多符合团队和业务的功能。比较出名且已经开源的有qiankun，qiankun在single-spa的基础上封装了很多强大的功能，比如样式隔离、JS沙箱、htmlEntry，这些功能降低了微前端的接入难度。
总结下来，iframe简单稳定，但有一些无法解决的问题，成长性不高，微前端框架接入稍难，但上限更高。当然每个项目的情况都不同，适合自己的就是最好的。
micro-app有什么优势?
single-spa是通过监听 url change 事件，在路由变化时匹配到渲染的子应用并进行渲染，这个思路也是目前实现微前端的主流方式。同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。因为qiankun 是基于single-spa进行封装，所以这些特点也被qiankun继承下来，并且需要对webpack配置进行一些修改。
micro-app并没有沿袭single-spa的思路，而是借鉴了WebComponent的思想，通过CustomElement结合自定义的ShadowDom，将微前端封装成一个类WebComponent组件，从而实现微前端的组件化渲染。并且由于自定义ShadowDom的隔离特性，micro-app不需要像single-spa和qiankun一样要求子应用修改渲染逻辑并暴露出方法，也不需要修改webpack配置，是目前市面上接入微前端成本最低的方案，并且提供了js沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。
micro-app的特点：
1、 上手简单：使用方式类似iframe
2、 侵入性低：对原代码几乎没有影响
3、 组件化：基于webComponents思想实现微前端
4、 功能丰富：JS沙箱，样式隔离，预加载等
5、 轻量的体积：≈10kb(gzip)
6、 零依赖：不依赖于任何第三方库
相关地址：
源 码 地 址：
http://github.com/micro-zoe/micro-app
官网地址：
http://zeroing.jd.com/micro-app
iPaaS地址：
http://ipaas.jd.com