| 导语技术更新迭代下，微前端架构让你的应用可以同时兼容多个技术栈，不必为老应用的改造头疼。更重要的是，通过运用微前端架构，从代码的组织层面，到团队管理层面，都会给你的项目带来巨大的影响。但要在项目中实施微前端，有多个技术层面问题需要解决。本分享将带你走进微前端核心技术，揭秘那些“不为人知”的巧妙实现。

不写客套话了，直接进入正题吧。我自己写了一个微前端框架MFY（麦饭），你可以通过npm i mfy来使用它。这次分享主要来聊一聊实现一个微前端框架涉及的主要技术点。

概念

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用用由单一的单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。同时，它们也可以进行并行开发。——《前端架构：从入门到微前端》
微前端背后的想法是将网站或Web应用视为独立团队拥有的功能组合。每个团队都有一个独特的业务或任务领域，做他们关注和专注的事情。团队是跨职能的，从数据库到用户界面开发端到端的功能。——译，micro-frontends.org

微前端的核心价值在于 “技术栈无关”，这才是它诞生的理由，或者说这才是能说服我采用微前端方案的理由。——kuitos, qiankun作者，2020.11.20晚阿里云微前端线下沙龙
真正要解决的是，当技术更新换代时，应用可兼容不同代际的应用。

微前端是一种架构，而非一个独立的技术点。我个人从两个角度去看微前端，一个是形式上，微前端是多个小应用聚合为一的应用形式；一个是团队管理，微前端架构下，每个团队只负责独立（封闭）的功能，而且需要包含从服务端到客户端。

微前端框架对比评测

Mooa：基于Angular的微前端服务框架 https://github.com/phodal/mooa
Single-Spa：最早的微前端框架，兼容多种前端技术栈。https://single-spa.js.org/
Qiankun：基于Single-Spa，阿里系开源微前端框架。https://github.com/umijs/qiankun
Icestark：阿里飞冰微前端框架，兼容多种前端技术栈 https://github.com/ice-lab/icestark
console-os 是在阿里云控制台体系中孵化的微前端方案，定位是面向企业级的微前端体系化解决方案。https://github.com/aliyun/alibabacloud-console-os
Module Federation：webpack给出的微前端方案https://webpack.js.org/concepts/module-federation/
Luigi：一套复杂的分布式前端应用解决方案 https://github.com/SAP/luigi
FrintJS：自主解决依赖的微前端框架 https://github.com/frintjs/frint
PuzzleJS：一套复杂的前后端编译时相结合的微前端解决方案 https://github.com/puzzle-js/puzzle-js
ngx-planet：基于angular的微前端框架 https://github.com/worktile/ngx-planet
麦饭（mfy）：精巧简易的微前端框架 http://npmjs.com/package/mfy

除了webpack的联邦模块方案需要结合构建来做，比较特殊外，其他方案都是在运行时完成应用聚合。

“子应用独立运行”指子应用不需要放到基座应用这个大环境下就能自己跑，便于调试和被不同基座引入。”子应用嵌套子应用”是一个比较特殊的点，目前市面上能做到的框架不多。

微前端核心技术

这里讲的微前端技术，其实主要针对的是基座应用。它要解决的核心是资源加载和环境隔离两大问题。不同框架对子应用的要求不同，我在做麦饭的时候，希望做到子应用完全不修改就能放到父应用中跑。

环境隔离

iframe：样式和脚本运行的隔离，缺点在于无法全屏弹出层
ShadowDOM：样式隔离，缺点在于弹出层被挂在document.body下面，而样式被放在ShadowDOM内部，无法正确渲染弹出层
快照沙箱
代理沙箱

快照沙箱

多个子应用在页面上相互切换，而子应用脚本运行会给当前全局环境带来污染。快照沙箱用于解决这种污染。

这种方案只适合同一时间只运行一个子应用的场景，例如腾讯云控制台。当子应用进入界面的时候，给window上的所有属性打一个快照。子应用运行过程中window可能被修改。子应用离开界面时，把window清理干净，再把快照上的属性重新添加到window上，复原了子应用挂载前的window。

代理沙箱

代理沙箱解决一个页面内同时运行多个子应用的场景。分两个步骤实现：

创建代理对象

比如上面提到window可能被污染。那我创建一个window的代理对象，例如fakeWin，实现如下：

这样处理之后，我们在读取时可能读取到原始window上的值，但是一旦我们写入新属性之后，再读就读到刚才写入的值，但对于原始的window来说，没有被污染。

创建运行沙箱

要使代理对象作为全局对象给子应用的脚本使用，必须把子应用放在一个沙箱里面跑，这个沙箱使用我们制作的代理对象作为全局变量，这样子应用的脚本就会操作代理对象，从而与其他子应用起到代理隔离的效果。具体实现如下：

上面代码里面的window, document, location等，都是前面创建好的代理对象。

资源加载

我在写麦饭的时候，希望直接引入子应用就能跑，所以以HTML作为入口文件。开发者使用一个特殊的importSource函数来引入入口文件，这个函数可以根据入口文件，解析子应用的全部资源，并做缓存。

解析资源

解析时需要做资源树分析，也就是通过html读取所有资源文件，比如link, script[src]。在读取资源时，可能还需要读取资源本身又引入的资源。大致逻辑如下图：

在解析过程中，还需要根据registerMicroApp的配置，决定css rules怎么处理。技巧是通过 <style>.sheet 读取 CSSStyleSheet 对象，从中抽离出所有css样式规则，再按配置逻辑生成最终的样式规则。

预加载/懒加载

在设计上，一个子应用的资源有两种可选加载形式。假如你希望提前预加载子应用资源，可以在registerMicroApp时直接传入 importSource(…)，这个函数一执行，就会去请求资源回来并做缓存。但是，假如你不需要预加载，你想在子应用需要进入界面时（或打算让子应用进入界面时）才加载资源，则配置为 () => importSource(…) ，这种配置会在子应用执行 bootstrap 的时候才去请求资源。具体采用什么形式要根据你对子应用的需求来定。

路由映射

如果子应用有自己的路由系统，处理不好，子应用在切换路由时会污染父应用，导致浏览器url发生变化，结果把当前页面切到另外一个地方去了。为了解决这种问题，我做了一个路由映射功能。因为子应用是运行在沙箱中的，所以，不同层的应用得到的location是不同的，父级应用使用浏览器的location，但是它的子应用则不是，我们修改浏览器的url之后，可以通过路由映射机制，伪造子应用得到的url。具体实现是通过创建一个临时的iframe，利用代理沙箱的能力，将子应用的location代理到iframe里面的location上去。

得益于代理沙箱，子应用的url变化不会导致浏览器的url变化。

映射逻辑是，我写了一个map和reactive配置项，当浏览器的url发生变化时，通过map映射到子应用内部。子应用内部url发生变化时，通过reactive映射到浏览器，这样即使用户在某一时刻刷新浏览器，也可以通过url映射关系，准确还原子应用当前的界面。

挂载

在麦饭中，子应用需要通过一个 <mfy-app> 标签来决定子应用挂载在什么地方。和qiankun等框架不同，qiankun需要在子应用中决定挂载点，但是这可能造成冲突。我的理念是子应用开发团队不应该考虑自己应用的外部环境。所以，子应用在哪里挂载应该由父应用决定。

子应用被放在 <mfy-app> 中，给了开发者一些特殊的能力：

可以放在 v-if 内部，DOM节点被移除后挂回来，子应用还在
动画效果
keepAlive

在实现 <mfy-app> 用到了一些比较 hack 的技巧。比如需要借助 <mfy-app> 这个节点所在作用域的顶层节点，在顶层节点DOM对象上挂载一些数据，通过这个技巧，确保节点被移除后，再被挂载回来时，还能正确还原之前界面。

keepAlive则是在 <mfy-app> 节点没有被移除的情况下，子应用执行 unmount 时，并没有实际销毁子应用构建的 DOM 树，而是放在内存中，当子应用再次 mount 的时候，直接把这个内存里面的 DOM 树挂载到 <mfy-app> 内部。

通信/应用树

这部分是麦饭设计中最复杂的部分，也是最终与其他微前端框架区别的地方。

我构建了一个这样的树状数据结构，称为应用树。它表达了基于MFY开发的微前端应用中，应用于子应用的引用关系。

scope

scope概念是指一个应用起来之后，会创建一个scope（作用域），这个scope保存了该应用的一些运行时信息，同时提供了通信的接口方法。一个应用可能会有多个子应用，这些子应用都在这个scope内部，它们可以通过scope完成通信，比如 parent_app 可以给 child_app_1 和 child_app_2 下发一个指令，接到这个指令后，两个子应用执行自己的逻辑。child_app_2 可以向 parent_app 发送一个指令，而 parent_app 把这个指令转发给了 child_app_1，这样就完成了两个子应用之间的通信。这像极了 react 组件通过 props 传递数据的模式。

rootScope 是一个特殊的scope，它不是由应用创建的，而是由框架创建的。由于我把scope设计为可以广播消息的订阅/发布对象，所以，利用 rootScope 实际可以完成跨层应用间的直接通信。

connectScope

每个应用通过connectScope连接到自己所在的scope。这里需要一些技巧才能实现，在同一层，实现逻辑有点像react hooks，你不需要关心你处于应用树的哪个位置，对于子应用开发团队而言，只需要在代码中使用connectScope()函数，就可以直接连接到自己所在的作用域。如果你实现过react hooks的话，应该能理解它的一个实现原理。但是由于一些实现上的限制，你不能异步执行connectScope，必须在代码第一次执行时，同步调用connectScope获取当前子应用的scope。

状态共享

分享过程中，有同学提问“如果子应用1修改了用户的某个状态，子应用2怎么对这个修改做出响应？”

这个问题涉及到一个状态共享问题。由于我在设计时，坚持每个子应用团队应该封闭开发，开发团队不应该考虑说自己开发的应用还会和其他应用放在一起使用，或者还需要依赖其他应用的状态变化，这会让我在开发的时候一直处于对当前应用状态的未知状态，那这样就没法调试和测试了。因此，设计中我直接拒绝实现子应用间的状态共享。

但是在实际使用过程中，这种需求是存在的。因此，我建议使用通信的方式解决，子应用1发出一个消息，通过rootScope，通知网络我改变了用户状态，那么其他子应用在接受到这个消息之后，自己决定是否要重新渲染界面。

思考

跨域加载子应用问题
子应用自己还要加载资源（angularjs模板）绝对路径问题
登录态怎么传递？
多语言怎么配置？
代码共享（依赖）怎么处理？
运行时对象多个怎么办？（例如每个子应用都有自己的jQuery）
跨应用加载相同资源怎么办？（例如同时请求一个api拉取数据）

微前端不是万能的，坑也很多，所以应了那句话“没有银弹”。

小结

微前端是一种架构形式，一旦采用这种架构，就会影响到你的应用的运行方式、团队的管理方式、构建部署的方式，因此，开发团队最好经过比较长一段时间的调研之后，才决定启用这种架构
从我的分享中，你也会发现，要实现微前端框架的核心能力，需要使用一些看上去不那么优雅的hack方法，既然是hack方法，就存在一定的弊端，比较容易跳坑
这次分享只介绍了实现微前端框架的核心技术点，在实际项目中，还需要面临更多问题，但这并不是说我在劝退大家，而是希望大家在选择时，根据实际的需求决定，不要由于这个很火就上

微前端核心技术揭秘

快乐工作，快乐生活

Happy work , Happy life

Join us

本篇文章来源于微信公众号: 腾讯CDC体验设计

{{userData.name}}已认证