微前端(Micro-Frontends)是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。微前端(micro-frontends)术语在 2016 年在 TECHNOLOGY RADAR[1] 中被提及。
微前端架构具备以下的特点:
技术栈无关。主框架不限制接入应用的技术栈,微应用具备完全自主权
独立开发、独立部署。微应用仓库独立,前后端可独立开发,部署完成后主框架自动完成同步更新
增量升级。在面对各种复杂场景时,我们通常很难对一个已经存在的系统做全量的技术栈升级或重构,而微前端是一种非常好的实施渐进式重构的手段和策略
独立运行时。每个微应用之间状态隔离,运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。比如:
通过微前端拆分成一个容器应用和多个子应用之后,各个应用能够独立部署,相互之间隔离,从而做到:
通过Nginx配置反向代理来实现不同路径映射到不同应用,例如www.abc.com/app1对应app1,www.abc.com/app2对应app2,这种方案本身并不属于前端层面的改造,更多的是运维的配置
优点:
缺点:
父应用单独是一个页面,每个子应用嵌套一个iframe,父子通信可采用postMessage或者contentWindow方式
优点:
缺点:
每个子应用需要采用纯Web Components技术编写组件,是一套全新的开发模式
优点:
缺点:
使用 Module Federation,我们可以在一个应用中动态加载并执行另一个应用的代码,且与技术栈无关,并且能够共享模块,从而减小编译时间以及降低包体积
优点:
缺点:
每个子应用独立构建和部署,运行时由父应用来进行路由管理,应用加载,启动,卸载,以及通信机制
优点:
缺点:
组合式应用路由分发是目前业内普遍使用的一种方案,并且能够满足大部分需求,接下来我们详细来看看这种实现方式
该方案使用的是基座模式,通过一个主应用(基座应用-Main APP),来管理其它应用(子应用-MicroAPP)。基座应用大多数是一个前端 SPA 项目,主要负责应用注册,路由映射,消息下发等,而微应用是独立前端项目,这些项目不限于采用 React,Vue,Angular 或者 JQuery 开发,每个微应用注册到基座应用中,由基座进行管理,但是如果脱离基座也是可以单独访问
当整个微前端框架运行之后,给用户的体验就是类似下图所示:
简单描述下就是基座应用中有一些菜单项,点击每个菜单项可以展示对应的微应用,这些应用的切换是纯前端无感知的
上面的实现过程主要如下:
注意:子应用也可以将包打成多个,然后利用 webpack 的 webpack-manifest-plugin 插件打包出 manifest.json 文件,生成一份资源清单,然后主应用的 loadApp 远程读取每个子应用的清单文件,依次加载文件里面的资源;不过该方案也没办法享受子应用的按需加载能力
当主应用和微应用同屏渲染时,就可能会有一些样式会相互污染,可以采取以下两种方案
而对于微应用与微应用之间的CSS隔离就非常简单,在每次应用加载时,将该应用所有的link和style 内容进行标记。在应用卸载后,同步卸载页面上对应的link和style即可
每当微应用的 JavaScript 被加载并运行时,它的核心实际上是对全局对象 Window 的修改以及一些全局事件的改变,例如 jQuery 这个 js 运行后,会在 Window 上挂载一个 window.$ 对象,对于其他库 React,Vue 也不例外。为此,需要在加载和卸载每个微应用的同时,尽可能消除这种冲突和影响,最普遍的做法是采用沙箱机制(SandBox)
沙箱机制的核心是让局部的 JavaScript 运行时,对外部对象的访问和修改处在可控的范围内,即无论内部怎么运行,都不会影响外部的对象。通常在 Node.js 端可以采用 vm 模块,而对于浏览器,则需要结合 with 关键字和 window.Proxy 对象来实现浏览器端的沙箱
微前端通常不会限制应用采用的框架,如何在不同的应用,框架之间进行通信是一个需要仔细考量的决定。应用间通信有很多种方式,当然,要让多个分离的微应用之间要做到通信,本质上仍离不开中间媒介或者说全局对象。
通过事件[3]进行通信应该是最简单、通用的方案了
// 监听事件
window.addEventListener('message', (event) => {
// 处理事件
});
// 触发事件
window.dispatchEvent(new CustomEvent('message', { detail: input.value }))
消息订阅(pub/sub)模式的通信机制是非常适用的,在基座应用中会定义事件中心Event,每个微应用分别来注册事件,当被触发事件时再有事件中心统一分发,这就构成了基本的通信机制
import { Observable } from 'windowed-observable';
const observable = new Observable('konoha');
observable.subscribe((ninja) => {
console.log(ninja)
})
observable.publish('Uchiha Shisui');
通过 Web Workers 进行事件通信
import Worky from 'worky'
const worker = new Worky("some-worker.js");
worker.on("eventName", function (some, data) {
// 处理
});
worker.emit("someEvent", and, some, data);
主应用创建 state store,共享给子应用使用,适用于主、子应用技术栈相同的场景。
微前端是一种将单个巨型应用转变为多个微型应用聚合为一的应用,能够解决“巨石应用”的维护性问题。实现微前端的方式有很多种,每种方案都需要考虑应用隔离和应用通信的问题,目前较为普遍使用的是组合式路由分发的方式。
TECHNOLOGY RADAR: https://www.thoughtworks.com/zh-cn/radar/techniques/micro-frontends
[2]import-html-entry: https://www.npmjs.com/package/import-html-entry
[3]事件: https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent
[4]微前端(一)- 理念篇: https://www.lumin.tech/blog/micro-frontends-1-concept/
[5]微前端-最容易看懂的微前端知识: https://juejin.cn/post/6844904162509979662
[6]微前端在解决什么问题?: https://cloud.tencent.com/developer/article/1546556
[7]微前端如何落地: https://www.infoq.cn/article/xm_aaiotxmlppgwvx9y9
[8]微前端解决方案: https://segmentfault.com/a/1190000040275586
[9]HTML Entry 源码分析: https://juejin.cn/post/6885212507837825038#heading-6