微前端框架设计

导读

无论你们有意或者无心间，或多或少都已经接触到了微前端这个新的概念，这种新的前端架构真的有存在的必要吗？毕竟没有银弹，在新的架构体系下，它除了带了好处之外，同时也带来了风险和技术挑战。本文将带你揭秘微前端给现有的工程化体系带来了的意义，和它的架构设计，以及简单讲解一下微前端的核心模块loader、sandbox。

微前端是一种相似于微服务的架构，它经过将一个单体的web应用拆分红多个子应用，在运行时经过主应用来加载对应子应用来达到解耦子应用单独运行、开发、部署的目的。

为何须要微前端

咱们先来了解一下微前端出现的缘由，因为大部分开发同窗开发的都是单体应用。先举几个实际工做中开发单体应用常见的问题吧：

• 同窗A跟我吐槽：
  • 场景：
    • 最近要接受一个遗留后台系统，里面的技术老旧不说，连框架都是本身造的轮子，文档也没有
  • 问题：
    • 近期可能有一些新功能要增长到旧系统内，可是在原有系统上改造难度高
    • 后续可能会对旧系统内的现有功能作一些改造，可是原有的一套技术体系老旧，想要重构到ts+react+webpack，可是里面有些祖传页面大几率不会迭代，又必须保持线上
• 同窗B团队近期也遇到了问题：
  • 场景：
    • 他们所在的团队要负责一个运营后台系统，目前系统内的功能已经很是庞大，涉及的成员也很是多，里面每个子菜单的功能都很是庞大，每一个子菜单可能都是因为不一样的团队在负责。而且目前全部功能所有聚合在一个项目内
  • 问题：
    • 项目内的代码规范和技术体系选择，都会形成不一样团队的争议
    • 某个子菜单内的功能进行了变动整个项目都须要从新打包部署，增长了不稳定性和分支混乱，部署时间长
    • 不一样子菜单内同时有需求迭代，二者的功能须要进行合并才能部署到预发、线下，这就形成了不一样需求之间的互相挤兑，影响测试发布效率，并且还须要保证相互之间没有影响

在前端应用日益复杂化，框架技术更新迭代快的场景下，现有的单体工程化方案在多团队协做、解决历史遗留代码力不从心，微前端工程化方案很好的解决了上述问题：技术栈无关、拆解巨石应用。

微前端的核心价值

• 拆解巨石应用为多个子应用
  • 子应用独立运行和发布
  • 增量升级
• 技术栈无关
• 沙盒隔离子应用

经过微前端的核心价值咱们能够很好的解决上述问题：历史遗留代码、跨多个团队协做、发布效率问题。跨空间和时间的产品极可能会致使应用变成一个巨石应用、技术栈老旧，致使项目的维护成本变高，微前端就是为了解决这些问题。

在简单了解了现有工程体系的问题，还有微前端能解决的问题以后，咱们来简单了解一下微前端的技术架构。

微前端的技术架构

why not iframe

其实从浏览器原生的方案来讲，iframe不从体验角度上来看几乎是最可靠的微前端方案了，主应用经过iframe来加载子应用，iframe自带的样式、环境隔离机制使得它具有自然的沙盒机制，但也是因为它的隔离性对用于体验带来了一些反作用：

• 视窗大小不一样步（例如咱们在iframe内的弹窗想要居中展现）
• 登陆态cookie同步问题
• 子应用间通讯问题
• 大量组件重复

SPA微前端架构

从iframe的用户体验咱们很难将其做为微前端的标准方案，那咱们本身要作一套微前端框架具体要作哪些事情呢，从iframe功能咱们大体可以了解到，微服务框架须要具有如下几个功能：

• 子应用加载器（Loader）
• 路由控制（Router）
• 沙盒隔离（Sandbox）
• 子应用通讯（Store）

主工程基座

微前端架构必须有一个主工程基座，基座主要是作为承载子应用的容器，子应用经过导出对应的格式，主应用在进入到对应路由时加载对应的子应用。

微前端核心功能

Loader

loader是微前端核心模块的加载器，能够经过loader来进行子应用的加载，目前的微前端方案设计里面通常有两种模式。

第一种是非侵入式，经过加载对应子应用的 index.html 文件，再经过对首页html文件进行解析，获取到子应用的js文件和css文件，进行加载。

另外一种是子应用打包成一个js文件，按照规范的导出格式,主应用只加载 index.js 文件。获取到对应的render和destroy方法。

let vm;
module.exports = {  render () {  vm = new Vue({  render: (h) => h(Home),  }).$mount(dom);  },  destroy() {  vm.$destroy();  } } 复制代码

做为模块加载器它一般须要提供如下几种能力：

• 下载子应用源码
• 编译解析子应用导出内容
• 将公共依赖注入到子应用中

External

在微前端中有一个须要解决的问题就是，子应用间的公共依赖，咱们如何抽离项目间的公共依赖呢，因为咱们将一个应用拆分红了多个子应用，那子应用之间的依赖如何复用。若是了解commonJS的同窗应该知道，commonJS具有加载模块缓存能力，加载过的模块会将其缓存起来，那么是否是咱们能够将子模块以commonJS的规范进行打包。在加载子模块时，提供全局的exports和require方法，将子应用导出的exports进行收集,在require时加载咱们配置的external资源。

commonJS加载实现

Module._catcheModule = {}
function req(moduleId){  if(Module._catcheModule[p]){  //模块已存在  return Module._catcheModule[p].exports  }  //没有缓存就生成一个  let module = new Module(p);  Module._catcheModule[p] = module;  //加载模块  module.exports = module.load(p);  return module.exports; } function Module(p){  this.id = p  this.exports = {}  this.load = function(filepath){  return Module._extensions(this)  } } Module._wrapper = ['(function(exports,require,module,__dirname,__filename){','\n})'] Module._extensions = function(module){  let fn = Module._wrapper[0] + fs.readFileSync(module.id,'utf8') + Module._wrapper[1]  vm.runInThisContext(fn).call(module.exports,module.exports,req,module)  return module.exports } 复制代码

经过上面commonJS的源码模式实现，咱们只须要将exports中增长公共依赖，而且子应用经过webpack构建工具，提供external配置一样的公共依赖便可。

Sandbox

在微前端框架中另外一个核心的模块就是沙盒，因为多个子应用会反复的展现在同一个容器内，子应用中不免会形成对当前环境的反作用，例如：全局样式、全局变量、监听事件、定时器等。沙盒在这里主要是为运行中的程序提供隔离环境，避免应用之间相互影响。

在web端设计沙盒咱们须要考虑哪些因素

• 全局环境污染
• 事件污染
• style污染
• 定时器污染
• localstorage污染

为解决全局环境污染和style污染，一般采用，快照模式和代理劫持模式。

快照模式

• 沙盒启动时
  • 遍历存储当前全局环境变量，将其缓存
  • 遍历head全部标签，将其缓存
• 沙盒运行时
  • 执行反作用程序
• 沙盒关闭
  • 遍历缓存遍历将其与全局环境对比，发现差别进行还原
  • 将当前head标签与缓存标签进行对比，发现差别进行还原

代理模式

• 沙盒启动时
  • 缓存原始节点添加、删除、在节点前插入等原始方法
  • 缓存添加监听事件、移除监听事件方法
  • 缓存添加定时器事件、移除定时器事件
  • 将缓存的事件更改成代理事件，在代理事件内部执行真实事件前，收集变动
• 沙盒运行时
  • 执行反作用程序
• 沙盒关闭
  • 恢复沙盒运行期间产生的变动
  • 移除代理事件

最后

招聘

另外也但愿可以吸引更多优秀的同窗加入咱们，加入字节跳动。

团队相关介绍：ByteDance Web Infra Team is hiring

可经过：zhouxiao.shaw@bytedance.com 进行投递