微前端是什么

微前端的概念是由ThoughtWorks在2016年提出的，它借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。

通俗来说，就是在一个web应用中可以独立的运行另一个web应用

微前端有什么使用场景呢？

举例

比如制作一个企业管理平台，把已有的采购系统和财务系统统一接入这个平台；
比如有一个巨大的应用，为了降低开发和维护成本，分拆成多个小应用进行开发和部署，然后用一个平台将这些小应用集成起来；
又比如一个应用使用vue框架开发，其中有一个比较独立的模块，开发者想尝试使用react框架来开发，等模块单独开发部署完，再把这个模块应用接回去

一个完善的的微前端框架应该具备哪些能力呢？

子应用的加载和卸载能力

页面需要从一个子应用切换到另一个子应用，框架必须具备加载、渲染、切换的能力
子应用独立运行的能力

子应用运行会污染全局的 window 对象，样式会污染其他应用，必须有效的隔离起来
子应用路由状态保持能力

激活子应用后，浏览器刷新、前进、后退子应用的路由都应该可以正常工作
应用间通信的能力

应用间可以方便、快捷的通信

使用微前端有什么收益呢？

技术栈无关

主框架不限制接入应用的技术栈，微应用具备完全自主权
独立开发、独立部署

微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
独立运行时

每个微应用之间状态隔离，运行时状态不共享

真的需要微前端吗?

'微前端'并不是一种技术升级,它可能是无可奈何之下的解决方案;

没有银弹，架构本身就是各种 trade–off.

满足以下几点，你可能就不需要微前端

你/你的团队具备系统内所有架构组件的话语权
简单来说就是，系统里的所有组件都是由一个小的团队开发的。
你/你的团队有足够动力去治理、改造这个系统中的所有组件
直接改造存量系统的收益大于新老系统混杂带来的问题。
系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的
系统本身就是一个最小单元的「架构量子」，拆分的成本高于治理的成本。
极高的产品体验要求，对任何产品交互上的不一致零容忍
不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略

满足以下几点，你才确实可能需要微前端

系统本身是需要集成和被集成的一般有两种情况：

旧的系统不能下，新的需求还在来。没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」
你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。

系统中的部件具备足够清晰的服务边界
通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。

为什么不用iframe?

为什么不用 iframe，这几乎是所有微前端方案第一个会被 challenge 的问题。但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 "炫技" 或者刻意追求 "特立独行"。

如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。

iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题，最终导致我们舍弃了 iframe 方案。