理解微前端技术原理

Posted 2021-12-03 广吾的博客

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了理解微前端技术原理相关的知识，希望对你有一定的参考价值。

我最早是在 2016 年接触到微前端的，当时社区里以介绍概念居多，在实践方案，尤其是在业务落地方面应用的比较少。后来，随着方案逐渐成熟，社区里关于微前端的讨论越来越多。

今天，我们先从概念、关键技术原理层面来对微前端进行详细说明。后续会有专门的文章来介绍微前端的实践经验。

什么是微前端

微前端的概念来源于微服务，其整体的架构思路是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，之后将这些应用组成整体，在用户看来仍然是内聚的单个产品，用户体验是一致的。

从概念上看，微前端架构由主应用和子应用两个部分组成，子应用负责具体的业务实现，主应用负责子应用的加载和卸载，即生命周期管理。

从概念延伸开来，我们不难发现，使用微前端，可以获得如下收益：

子应用独立开发、部署，技术栈无关
拆分以后，子应用拥有独立的代码仓库、独立的开发部署流程，甚至可以自由的使用任何技术栈进行开发。由此，我们可以在组织架构层面形成不同的团队来负责不同的业务模块，各个团队之间相对独立自主，互不干扰。
增量升级，多技术体系共存
对于很多大型的组织，他们的产品通常都经历了长期的迭代，功能复杂，同时技术栈通常也比较老旧。使用微前端以后，借助于独立的子应用，可以获得增量升级的能力。既可以实现新功能使用新的技术栈，同时与老技术栈共存。又可以对老功能进行逐步迭代升级，小步快跑。
产品层面的自由组合
借助于微前端，我们可以对各个子应用自由的进行上下线。换句话说，我们可以根据产品需要，自由的将不同的子应用组合成新的产品。

技术分析

在微前端架构下，有主应用和子应用两个基本角色。子应用负责具体的业务逻辑，主应用负责调度子应用。考虑到主应用的特殊性功能，为了保证整个框架的可用性，通常主应用不负责任何业务逻辑。

路由与子应用加载

由于主应用负责调度子应用，因此主应用需要具备路由管理和资源加载能力。所谓路由管理，就是主应用中需要维护一个路由表，当页面路由发生变化的时候，主应用可以知道当前需要启动哪个子应用。这个路由表可以是动态的，也可以是静态的。

知道启动哪个子应用之后，主应用就需要加载子应用的资源。通常有两种资源加载方式：

JS Entry。
通常将子应用的所有资源打包成一个入口文件，在 single-spa 的很多样例中就使用了这种方式。
HTML Entry。
子应用构建输出的是一个 HTML 文件，主应用通过加载这个 HTML 文件完成子应用的加载。

相比较而言，JS Entry 的方案限制更多一些，比如要求将图片、样式等所有资源打包成一个 JS Bundle，构建的包太大，也无法利用浏览器的并行加载能力。同时，子应用还需要与主应用约定好要挂载的节点，主应用要提前初始化好，或者子应用自行创建，避免挂载失败或者冲突。

HTML Entry 很好的避免了 JS Entry 的问题。本质上，HTML 文件充当的是应用静态资源表的角色。主应用加载了 HTML 以后，浏览器会自行下载子应用的各种资源。同时，由于构建产物是 HTML，子应用具备与独立应用开发时一致的开发体验。当然，HTML Entry 也存在缺点，比如要多一次请求，先加载了 HTML 才能知道加载哪些资源。

在加载完子应用的资源以后，主应用就可以启动子应用，完成页面渲染了。那么该如何启动子应用呢？主应用需要与子应用之前制定一个接口规范，比如在 single-spa 中就指定了 bootstrap、mount、unmount 和 unload 四个方法。子应用暴露这四个方法给主应用，主应用通过这四个方法来管理子应用的声明周期。

隔离

解决了路由和子应用加载的问题，理论上说我们已经实现了微前端的核心能力。但是，在实际的工程实践中，我们还需要解决很多的细节问题。其中最大的一部分就是如何做好子应用间的隔离。比如如何避免子应用间的样式冲突。

抛开现有的微前端方案，假如让我们从头开始实现一套微前端架构，将独立开发部署的各个子应用组合起来。相信大多数同学都会首先想到 iframe。其实我们就可以通过 iframe 来理解微前端架构中的种种技术细节。

iframe 自带的样式、环境隔离机制使得它具备天然的沙箱能力，但是 iframe 也有很多天然的缺陷，比如事件无法冒泡到顶层，路由跳转无法与主应用同步，与主应用通信复杂繁琐等。

我们可以参考 iframe 的设计思想，来设计如何对子应用进行隔离。一个传统的 iframe 具备四层能力：文档的加载能力、HTML 的渲染能力、独立执行 JavaScript 的能力、隔离样式的能力。

文档的加载能力和 HTML 的渲染能力在前面主应用加载子应用资源的时候，我们已经做了说明。

我们现在来说说如何实现独立的 JavaScript 运行环境和样式隔离。

沙箱（sandbox）

通常，子应用在运行期间会有一些污染性的副作用产生，比如全局变量、全局事件、定时器、网络请求、localStorage、全局 Style 样式、全局 DOM 元素等。为了保证应用能够稳定的运行且互不影响，需要提供安全的运行环境，能够有效地隔离、收集、清除应用在运行期间所产生的副作用，也就是沙箱的设计目标。

有两种沙箱的设计思路。一种是快照模式，另一种是虚拟机（virtual machine）模式。

快照模式

所谓快照模式，就是将启动子应用之前，对当前环境打一个快照，子应用退出之后，再重新加载这个快照来恢复环境。

在实现层面，我们可以针对每一种副作用设计一个 save 方法保存当前状态，在设计一个 load 方法来加载保存的状态。

框照模式的缺陷是对操作的顺序要求非常严格，当页面有多个子应用的时候，快照沙箱就会有多个实例存在，此时不同顺序的 save 和 load 会产生问题。

VM（虚拟机）模式

虚拟机想必大家都听说过，是一种计算机系统的仿真器，通过软件模拟具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。使用虚拟机就跟使用真实的计算机一样。

NodeJS 中也提供了 VM 模块，不过不同于传统的 VM，它并不具备虚拟机那么强的隔离性，并没有模拟完整的硬件系统，仅仅将指定代码放置了特定的上下文中编译并执行，无法用来执行不可信来源的代码。

下面的代码展示了 NodeJS 的 VM 模块的基本用法：

const vm = require(\'vm\');

const x = 1;

const context = { x: 2 };
vm.createContext(context); // 将 context 对象上下文化

const code = \'x += 40; var y = 17;\';
// `x` and `y` 在上下文中是全局变量
// 初始状态下, x 的值为 2，因为 context.x 得值是 2
vm.runInContext(code, context);

console.log(context.x); // 42
console.log(context.y); // 17

console.log(x); // 1; y 为未定义

参考 NodeJS 中 VM 模块的设计，以及 JavaScript 词法作用域的特性，可以设计出 VM 沙箱，不过与传统的 VM 差异也同样存在，它并不能执行不可信的代码，因为它的隔离能力仅限于将其运行在一个指定的上下文环境中。

let code = `(function(document, window){ /* 代码逻辑 */ })`

(new Function(\'document\', \'window\', code)(fakeDocument, fakeWindow))

针对前面提到的子应用运行产生的全局变量、全局事件等种种副作用，我们可以针对性的做处理，提供新的执行上下文。比如，用新的 window 对象用来隔离全局变量，用新的 document 来收集创建的 dom 对象，style 样式，script 标签等。全局事件、localStorage 等都可以一一进行处理。

下面借助于 Proxy，我们可以轻松的对当前的执行上下文进行劫持，创建新的执行上下文。下面的代码展示了如何劫持 window 对象。

const varBox = {};
const fakeWindow = new Proxy(window, {
  get(target, key) {
    return varBox[key] || window[key];
  },
  set(target, key, value) {
    varBox[key] = value;
    return true;
  }
});

const code = `(function(window) {
  window.a = \'111\';
  console.log(window.a);
})`;

const fn = new Function(\'window\', code);
fn(fakeWindow);

VM 模式的沙箱，可以有效的解决子应用之间、主子应用之间各种副作用的有效隔离问题。qiankun 的沙箱模式就是 VM 模式。