实现微前端的几种方案优劣对比
什么是「微前端」？
微前端官网 给予的解释是：用于构建具有多个可以独立发布功能的团队的现代 Web 应用程序的技术、策略和秘诀（Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently）。 该词于 2016 年底首次出现在 Technology Radar 中，它将微服务的概念扩展到前端世界。当前的趋势是：构建一个功能丰富且功能强大的浏览器应用程序，也就是单页应用程序，它位于微服务架构之上。随着时间的推移，通常由单独的团队开发的前端层会增长，并且变得更加难以维护。
Micro Frontends（微前端）背后的想法是：将一个网站或 Web 应用视为由独立团队拥有的功能组成。每个团队都有其关心和擅长的独特业务领域或任务。一个团队是跨功能的，从数据库到用户界面，端到端的开发其功能。
为什么要采用微前端？
随着 Web 应用的日渐强大，随之而来的是前端项目不断膨胀。业务需求不断叠加的情况下，巨石项目越来越难维护，编译时间越来越难等。微前端的出现，就是为了解决这种大型单页面应用程序后期无法维护的问题，它可以将前端整体分解为小而简单的块，摒弃大型单体应用方式，每个模块可以独立开发、测试、部署，可以单独访问，最后将不同子系统(模块)聚合成一个完整的应用出现在客户面前。
微前端背后的核心思想
- 与技术无关
每个团队都应该能够选择和升级他们的堆栈，而无需与其他团队协调。 自定义元素 是隐藏实现细节同时为其他人提供中性界面的好方法。 - 隔离团队代码
不要共享运行时，即使所有团队都使用相同的框架。构建自包含的独立应用程序。不要依赖共享状态或全局变量。 - 建立团队前缀
就尚无法隔离的命名约定达成一致。命名空间 CSS、事件、本地存储和 Cookie，以避免冲突并明确所有权。 - 优先使用本机浏览器功能而不是自定义 API
使用 浏览器事件进行通信 ，而不是构建全局 PubSub 系统。如果你真的需要构建一个跨团队的 API，尽量让它尽可能简单。 - 构建弹性站点
即使 JavaScript 失败或尚未执行，您的功能也应该很有用。使用 通用渲染 和渐进增强来提高感知性能。
实现微前端的几种方案
| 方案 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| iframe 嵌套 | 子应用通过 iframe 嵌套的方式来引入 | 实现简单、独立部署访问、天然隔离，子应用之间自带沙箱，互不影响 | 应用之间通信不便、浏览器前进/后退会重置 iframe 页面、样式和兼容性具有局限性 |
| Nginx 转发 | 通过 Nginx 配置的反向代理来实现不同路径映射到不同应用 | 改造简单、成本低、快捷 | 切换应用的时候、会刷新页面 |
| npm 包引入 | 子应用通过 npm 构建发布的方式来部署，由主应用来引入打包集成 | 方案成熟、较简单 | 打包部署慢，不能单独部署、技术栈需统一 |
| 通用中心路由基座式 | 子应用可以使用不同的技术栈，并且之间相互独立，无依赖，统一由主应用进行管理，注册，节点挂载，卸载等（主要有 single-spa 、 qiankun 等框架） | 不限定技术栈、单独部署 | 通信方式不够灵活 |
| 封装 WebComponents | Web Components 是浏览器原生组件，它有能力以组件加载的方式将微应用整合在一起作为微前端 | 不限定技术栈、独立开发、应用间隔离 | 浏览器兼容问题、微前端方面探索不成熟 |
| 去中心模式 | 脱离基座模式，每个应用之间都可以彼此分享资源。如基于 Webpack 5 Module Federation 实现的 EMP 微前端方案，可以实现多个应用彼此共享资源分享 | 通信方式多、单独部署，子应用更新同步成本低，构建速度快 |
关乎 qiankun 框架的简单说明
乾坤（阿里系开源微前端框架），使您和您的团队能够利用 微前端 构建下一代和企业级的 Web 应用程序。它的灵感来自并基于 single-spa 。它具备以下好处：
- 不限定技术栈：可以接入不同技术栈开发的第三方平台、也可以使用不同技术栈的最优的开源解决方案；
- 改造成本低：不需要对已有的巨型应用进行架构升级、代码重构，只需要对新的模块使用 qiankun 微前端的模式进行开发部署即可，主应用直接引入使用；
- 性能优化：模块独立开发部署加载，可以做到按需加载，不浪费额外的资源；
- qiankun 是基于 single-spa 的优化版，解决了 single-spa 遗留的样式污染、内存泄漏、没有父子应用数据通信方式等痛点。
