大家好，我是 易师傅，上篇文章给大家主要讲解到了 《微前端的入门》，这篇文章给大家收集归纳了微前端常用的框架，以及他们优缺点；
如果你正在做微前端，但是苦于不知使用哪一个微前端框架而苦恼时，我相信这篇文章能够给到你答案。
如果您对微前端感兴趣可以关注我的专栏 《微前端从入门到进阶》；
细想一下：通过微前端常见的解决方案，其实我们是可以归纳一些微前端存在的问题，比如 样式冲突、消息通信、脚本互斥、公共依赖加载等问题；所以 微前端框架 就因为这些问题应运而生了。
应用隔离主要分两种情况：
主应用与微应用之间的隔离；微应用与微应用之间的隔离；应用间所隔离的主要是 Javascript 的沙箱隔离和 CSS 的样式隔离；
由于在微前端场景下，不同技术栈的子应用会被集成到同一个运行时中，所以我们必须在框架层确保各个子主应用之间不会出现样式互相干扰的问题；
例如：一个团队的微应用的样式表为 h2 { color: black; }，而另一个团队的微应用则为 h2 { color: blue; }，而这两个选择器都附加在同一页面上，就会冲突；
为了避免这个问题，常见的解决方案有：
每当微应用的 JavaScript 被加载并运行时，它的核心实际上是对全局对象 Window 的修改以及一些全局事件的改变，例如 jQuery 这个 js 运行后，会在 Window 上挂载一个 window.$ 对象，对于其他库 React，Vue 也不例外。
为此，需要在加载和卸载每个微应用的同时，尽可能消除这种冲突和影响，最普遍的做法是采用沙箱机制（SandBox）；
沙箱机制的主要特性如下图：
常见实现沙箱的方法：
微前端最常见的问题之一是如何让微应用之间能够 相互通信。
一般而言，我们建议让微应用之间尽可能少地交流，因为这通常会重新引入我们最初试图避免的那种不适当的耦合代码。也就是说，通常我们只需要 某种程度的跨应用通信即可。
常见的通信方式：
自定义事件通信，是降低耦合的一种好方法；全局 state store 机制；发布-订阅（pub/sub）模式的通信机制；地址栏作为通信机制；正式因为这些问题的存在，所以就导致了一系列的微前端框架出现，下面主要给大家介绍下全世界范围内比较有名气的一些框架。
Single-spa 是最早的微前端框架，兼容多种前端技术栈；
概念：Single-spa 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架；
我们都知道 spa 应用 的理念是让独立的应用程序组成一个完整的页面， Single-spa 并不用依赖于单个框架和每个特性，而是你可以在不同的新框架随意使用；
简单来说就是一个聚合，使用这个库可以让你的应用可以 使用多个不同的技术栈（vue、react、angular等等)进行同步开发，最后使用一个公用的路由去实现完美的切换；
优点：
缺点：
正是因为有了
Single-spa，才让大部分微前端框架得以出现，所以以下所讲的微前端框架几乎都拥有Single-spa的优点。
Qiankun 是一个基于 single-spa ，阿里系开源的微前端框架，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。
设计理念：
由于主应用微应用都能做到技术栈无关，qiankun 对于用户而言只是一个类似 jQuery 的库，你需要调用几个 qiankun 的 API 即可完成应用的微前端改造。像使用 iframe 一样简单。将巨石应用 拆解成若干可以 自治的松耦合微应用，而 qiankun 的诸多设计均是秉持这一原则，如 HTML entry、沙箱、应用间通信等。这样才能确保微应用真正具备 独立开发、独立运行 的能力。qiankun 的在线案例：
优点：
缺点：
eval函数的安全和性能是有一些争议的： MDN的eval介绍；另外阿里系还有另外两款微前端框架：
- Icestark，是一个面向大型系统的微前端解决方案；
- Alibaba Cloud Alfa，是在阿里云控制台体系中孵化的微前端方案，定位是面向企业级的微前端体系化解决方案；
这两款框架相较于
Qiankun来讲社区活跃度以及 demo 较少，所以不太推荐使用该框架，大家了解即可。
Micro App 是京东出的一款基于 Web Component 原生组件进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。
它是目前市面上接入微前端成本最低的框架，并且提供了 JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信 等一系列完善的功能。
优点：
EMP 是欢聚时代基于 Webpack5 Module Federation 搭建的微前端方案；
由于是基于 Webpack5 Module Federation 来搭建的，所以相对与微前端跨框架、状态解决方案混淆比较严重，且 EMP 解决的是项目解耦而不是多系统聚合，与 bit（下面讲的） 这种跨项目组件复用平台较为类似；
优点：
缺点：
Garfish 是由字节跳动开源的一套微前端解决方案，主要用于解决现代 web 应用在前端生态繁荣和 web 应用日益复杂化两大背景下带来的 跨团队协作、技术体系多样化、应用日益复杂化等问题，Garfish 已经经过大量的线上应用的打磨和测试，功能稳定可靠。
框架特性：
丰富高效的产品特征
高扩展性的核心模块
高度可扩展的插件机制
设计理念：
另外字节跳动开源的号称
「现代 Web 工程体系」的 modern.js 也是解决微前端的一个框架，大家感兴趣的可以去 官网查看，因为该框架是一整套工程体系解决方案，所以可酌情选择；
由国外 bit 开发团队开源的一款跨项目的组件复用平台框架；将独立的组件构建、集成组合到一起去管理；
优点：
严格意义上来讲 Bit 与微前端有较大的的出入，所以 Bit 较为适合那种使用组件来开发项目，且技术栈较为统一的项目；
Liugi 是国外 SAP 团队开源的一个用于微前端 JavaScript 框架；
Luigi 框架提供了配置选项、API 函数和开箱即用的功能，使迁移到微前端架构更容易。Luigi 为您的所有微前端提供一致的用户导航，确保更好的用户体验。
优点：
Open Component（简称 OC）项目宣布其目标是 前端世界中的无服务器。
更具体地说，OC 旨在成为一个 一站式微前端框架，从而使其成为一个丰富而复杂的系统，其中包括从组件处理到注册表、再到模板、甚至包括 CLI 工具。
OpenComponents 有两个部分：
Piral 是国外 smapiot 团队研发的一款基于 React 的微前端解决方案，其可以无限制地扩展开发工作、渐进部署并基于无服务器基础架构。
其定义了两个概念：
优点：
相较于国外其它微前端框架，Piral 有更好的社区，文档，团队，如果你还在思考使用哪种微前端框架，Piral 不失为一个不错的选择；
当然以上只是概述了一些比较常见的微前端框架，还有一些较为优秀且开源的，欢迎大家补充；
Qiankun、Micro App、Garfish、Liugi、Piral 你都可以选择；Qiankun、MicroApp 都可选择，可优先考虑 Micro App；Piral、PuzzleJs 较为适合；当然，其实无论哪种方案都可选择其中的较为符合的框架，但是为了满足自己项目与业务场景，可能需要自己一个一个去踩坑才能实现了。
最后说一句： 用新技术，更多的不是因为先进，而是适合。
该系列是一个由浅入深让你从微前端的 选型、定型、造型 三个方面出发，全面深入了解微前端的 原理及理念，如何搞定一个企业级微前端服务从提出到落地的专栏；
感兴趣的朋友可以关注我的专栏 《微前端从入门到进阶》，想与更多前端大佬交流，可以进入 我的掘金主页加 vx 吹水；
我正在参与掘金技术社区创作者签约计划招募活动， 点击链接报名投稿。