微前端哪些事？

微前端解决方案有哪些？

qiankun(乾坤)、飞冰（ iceworks ）、OnePiece、Magix、icestack、legaoLoader、umijs 根据乾坤整合了 @umijs/plugin-qiankun

微前端解决了什么？

解决历史遗留单页巨石应用(Frontend Monolith)的维护问题，分解应用的复杂度，降低项目的迁移维护风险；这才是人们采用微前端方案最重要的原因；

微前端的核心价值：

• 技术栈无关（提高扩展灵活性，不限于单一技术（组件不可替代））：
  • 主框架不限制接入应用的技术栈，子应用可自由组合
• 独立开发、独立部署：
  • 子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
• 独立运行时：
  • 每个微应用之间状态隔离，运行时状态不共享
• 增量升级（分解应用复杂度，解耦各个子应用，降低开发风险）：
  • 在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略，可以减少或不重写原有代码，直接开发新的模块；
• 体系化方案解决（复用性强，降低开发维护成本）：
  • 微前端并非只是加载一个异步模块，改造应发的一系列问题通过体系化的方案解决；

微前端是什么？

微前端不是框架、不是工具/库，而是一套架构体系，它包括若干库、工具、中心化治理平台以及相关配套设施。

微前端包括 3 部分：

1. 微前端的基础设施。这是目前讨论得最多的，一个微应用如何通过一个组件基座加载进来、脚手架工具、怎么单独构建和部署、怎么联调。
2. 微前端配置中心：标准化的配置文件格式，支持灰度、回滚、红蓝、A/B 等发布策略。

3. 微前端的可观察性工具：对于任何分布式特点的架构，线上/线下治理都很重要。

   微前端具体要解决好的 11 个问题：

4. 微应用的注册、异步加载和生命周期管理；

5. 微应用之间、主从之间的消息机制，如何通讯；
6. 微应用之间的安全隔离措施；
7. 微应用的框架无关（同页面多个技术栈）、版本无关；
8. 微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；
9. 微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；
10. 微应用的发布流程；
11. 微应用打包优化问题；
12. 微应用专有云场景的出包方案；
13. 渐进式升级：用微应用方案平滑重构老项目；
14. 独立团队之间如何协作。

你可能会问直接用iframe？主要几个局限问题

iframe 的原生硬隔离方案无法突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

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

iframe 隔离 vs 沙盒隔离

• iframe 是全独立模式，互补干扰；
• 沙盒是以隔离模式独立，而是有分享和协同的可靠环境；

JS Entry vs HTML Entry

样式隔离和 js 隔离请参考：https://segmentfault.com/a/1190000020122048

参考文档：

• 微前端方案
• 微前端架构实践
• 能是你见过最完善的微前端解决方案