什么是微前端

将web应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用可以独立运行、独立开发、独立部署。

微前端的优势

• 复杂度可控： 每一个UI业务模块由独立的前端团队开发，避免代码巨无霸，保持开发时的高速编译，保持较低的复杂度，便于维护。
• 独立部署：每一个模块可以单独部署，不对其它模块有任何影响。
• 技术栈无关：在同一个项目下可以使用不同的前端技术栈。
• 容错：单个模块发生错误，不影响全局。
• 扩展：每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗。

微前端的劣势

• 复杂的集成：需要考虑JS隔离、避免CSS冲突，并考虑按需加载资源
• 第三方模块重叠：需要考虑第三方库依赖冗余额问题

微前端架构模式

• 基座模式：通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
• 自组织模式：应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。

微前端设计理念

• 中心化。应用注册表。这个应用注册表拥有每个应用及对应的入口。在前端领域里，入口的直接表现形式可以是路由，也可以是对应的应用映射。
• 标识化。我们需要一个标识符来标识不同额应用，以便于在安装、卸载的时候，能寻找到指定的应用。
• 生命周期管理。
  • load, 决定加载哪个应用，并绑定生命周期
  • bootstrap, 获取静态资源
  • mount, 安装应用，如创建dom节点
  • unload, 删除应用的生命周期
  • unmount, 卸载应用，如删除dom节点，取消事件绑定
• 高内聚，低耦合。

微前端技术方式

路由分发式

通过路由将不同业务分发到不同的、独立的前端应用上。通常使用服务器的反向代理来实现,又或者是应用框架自带的路由来解决。如下图所示

应用微服务化

每个前端应用都是完全独立（技术栈、开发、部署、构建）、自主运行的，最后通过模块化的方式组合出完整的前端应用。诸如微前端框架Single-SPA或者mooa。如下图所示

微应用化

在开发时，应用都是以单一、微小应用的形式存在，而在运行时，则通过构建系统合并这些应用，组合成一个新的应用。如下图所示

微件化

微件，指的是一段可以直接嵌入在应用上运行的代码，它由开发人员预先编译好，在加载是不需要再做任何修改或者编译。而微前端下的微件化则指的是，每个业务团队编写自己的业务代码，并将编译好的代码部署到指定的服务器上，在运行时，我们只需要加载相应的业务模块即可。对应的，在更新代码的时候，我们只需要更新对应的模块即可。如下图所示：

从远程加载来对应的javascript代码，在浏览器上执行，生成对应的组件嵌入到页面的相应部分。

IFrame前端容器化

iframe作为一个比较老的技术，一直很管用。它能有效的将另一个网页嵌入到当前页面中，两个页面间的css和javascript是互相隔离的（除去父子通讯部分的代码）。iframe便相当于是创建了一个全新的独立的宿主环境，类似于沙箱隔离。但是用iframe也有一些缺陷，会导致资源的重复加载，会让路由、历史记录和深层链接变得更加复杂，还会影响页面的响应速度。

WC应用组件化

web components是一套比较新的技术，允许开发者创建可重用的定制元素，并且在web应用中使用它们。

微前端方案对比

对比标准

目标 | 描述 -|-|- a. 独立开发 | 独立开发，而不受影响 b. 独立部署 | 能作为一个服务来单独部署 c. 支持不同框架 | 可以同时使用不同的框架，如Angular、Vue、React d. 摇树优化 | 能消除未使用的代码 e. 环境隔离 | 应用间的上下文不受干扰 f. 多个应用同时运行 | 不同应用可以同时运行 g. 共用依赖 | 不同应用是否共用底层依赖库 h. 依赖冲突 | 依赖的不同版本是否导致冲突 i. 集成编译 | 应用最后被编译成一个整体，而不是分开构建

对比结果

O 表示支持， 空白表示不支持， -表示不受影响