微前端.md

微前端

• 微前端不一定是一种新技术，也不必太复杂。只要我们保证代码隔离和团队自治，无论我们采用何种技术栈，我们都可以达到相同的效果

由来

• 工程越来越大，打包越来越慢
• 团队人员多，产品功能复杂，代码冲突频繁、影响面大
• 在后端服务开发中，为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现了微服务架构
• 把应用程序设计成一系列松耦合的细粒度服务
• 允许使用不同的编程语言来编写不同服务
• 前端也出现这样的问题，即，一种由独立交付的多个应用组成整体的架构风格。将前端应用分解成一些更小更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品
• 比起一整块的前端代码库，微前端架构下的代码库倾向于更小/简单、更容易开发
• 传统开发的缺点
  • 历史项目，祖传代码
  • 交付压力，当时求快
  • 就近就熟，当时求稳
  • 导致技术栈落后，甚至强行混用多种技术栈，耦合混乱，不敢动，牵一发动全身

每个微前端都应具备有自己的持续交付流水线（包括构建、测试并部署到生产环境），且要能独立部署，不必过多考虑其它代码库的状态

意义

• 技术栈无关，主框架不限制接入应用的技术栈，微应用具备完全自主权
• 独立开发、独立部署，微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
• 增量升级，在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
• 独立运行时，每个微应用之间状态隔离，运行时状态不共享
• 微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

技术方案

package 集成

• 将每个微前端发布为一个 npm 包，并让容器应用程序将所有微前端应用作为依赖项
• 这意味着只要有一个包更新，即使是小版本，宿主也要重新构建一次。不建议使用这种方案

iframe

• 优点：隔离得很彻底
• 缺点：速度慢，浏览器处理 iframe 要启动更多的进程；页面刷新难以保存状态，路由、历史记录等等

使用 umd 包

• 通过 script 标签引入放在 cdn 上的资源，可以始终保持最新，子应用更新不需要通知宿主
• 具有完全的灵活性，宿主可以控制什么时候载入每个应用，以及渲染应用时额外传参数
• vite 库模式：https://cn.vitejs.dev/guide/build.html#library-mode

微前端架构存在的一些普遍问题

下载量

• 独立构建的 JavaScript 文件可能导致重复的公共依赖，从而增加用户的下载量
• 例如，如果每个微应用都包括自己的 React 副本，那么用户就得多次下载 React

环境差异

• 在本地开发时无法把所有微应用和对应的后端都启动起来，不得不在本地进行环境的简化。
• 如果开发环境和生产环境不严谨一致，容易造成问题。如果开发者想要完全模拟生产环境，会比较耗时

治理复杂性

• 要管理更多的东西：更多的代码库、更多的工具、更多的构建管道、更多的服务器、更多的域名等