Udesk微前端之路
Udesk为什么要做微前端?
微前端是最近这两年比较热的一个概念,随着前端框架的流行以及前端工程化的程度越来越高,多数公司都会采取前后端分离的方式,来构建自己的单页面应用系统。Udesk在2017年初便开始实践微前端了,只不过当时微前端这个概念还没有被广泛提起。虽然现在微前端已经深入人心,也有一些大公司把微前端做的比较工程化了,比如蚂蚁金服的 qiankun ,美团也有微前端的内部实践,不过在那个时候还没有这些工具。
我们当时正处在前端技术栈迁移的阶段,希望把主要开发框架从Ember逐步迁移到React,但又不希望把现有系统彻底重写,所以需要一种方式能够逐步增量更换技术栈。由于Udesk业务和客户量都发展很快,把整个产品线都停下来完全做系统重写是不可能的,所以我们希望这个过程能够是渐进、增量式的,新功能要与 Ember主系统无缝集成,而且要保持SPA的使用体验,不能做页面刷新。
除了技术方面的需求,在业务也有很迫切的需求。从2016年开始,Udesk拉起了多条新业务线,前端团队也很快扩大到了近40人的大团队,每一个业务线都是独立的SaaS产品。新业务产品需要与核心客服系统有机集成起来,甚至新产品之间也要相互融合。另外,客服系统已经比较庞大,需要对系统能够按业务模块进行拆分解耦,子应用要能独立开发、部署、运维,提高系统的灵活性和弹性。
前端项目有哪些痛点?
随着前端系统规模的变大,在系统打包尺寸、构建效率和业务分离等方面都给我们提出了新的挑战。虽然Webpack提供了很多机制来尽量减少包的尺寸,比如 minify 、 tree-shaking 、 dll 、 split chunks 、 HappyPack 、 dynamic import 等。其中最接近系统分治理念的就是 dynamic import 做代码分割,一般的做法都是根据路由把系统分成多个子包,主包只包含首页面渲染需要用到的代码,这样主包的尺寸就会大幅减少,从而提高了首屏加载的速度。
但这些还是解决仅仅 单一系统 的问题,对于一些 ToB 的大型系统或者跨地域的团队来说,这些是还是不够的。他们需要解决下面这些痛点:
业务分离,系统分治解耦;
团队技术栈不同,异构系统集成;
按业务进一步拆分bundle;
单个大型系统构建时间长;
业务子系统独立开发、部署、限制错误边界;
低代码场景,需要嵌入用户侧自定义代码;
上面这些从根本上来说还是一个系统分治的架构思想,无论我们怎么优化webpack,当一个系统业务模块很多的时候,我们优化带来的尺寸下降,还是很快会被大量的业务代码所淹没,主系统仍然是一个庞大的 Frontend Monolith (前端单体)。当然除了代码尺寸问题,更重要的是所有业务线耦合在一起,一块编译、一块部署,一旦发现一个问题,整个系统需要做回滚,那些没有问题的业务模块也会受到影响,如果有的团队是在异地,甚至跨时区的话,协同部署更是很难的事情。
如果系统能被分割为N个子应用的话,不但可以按需嵌入到主系统,我们还可以把多个子应用按业务相关性进行自由组合,就可以形成满足不同客户场景的多种 解决方案 ,这对于 ToB 业务来说还是有很大优势的。
微前端还能提供解决历史技术栈的一剂良方,对于一个大型系统来说,变更技术栈是一个很难的事情,意味着使用新的语言或框架把所有历史代码重写。一方面开发工作量十分巨大,但这还不是最重要的,时间成本才是最难承受的。假如老系统重写需要两年时间,那我们是停下主业务两年,等待新版本完成再上线吗?这恐怕是任何一个公司都无法承受的。如果采用微前端,我们可以把系统拆分为多个子业务模块,完成一个模块就上线一个模块,系统迭代速度大大加快,而且同时也有时间响应老系统的开发需求。还有一个优势就是,新模块可以使用最新的技术栈。由于现代框架都很轻,而且模块化和隔离性都做的很好,完全可以在一个页面中运行多个框架实例,甚至两个不同版本的框架。所以在新模块中可以使用各种新框架,方便团队的技术升级,和新技术探索。
图片
架构图
技术选型
图片
由于保持单页面的使用体验是我们的核心诉求之一,所以前面两个方案很快就被淘汰了,接下来我们就主攻 jsSDK 这个方向。最后在填了很多的坑之后,最终子系统被成功嵌入到了主系统中,而且效果也是非常不错的。每个子系统独立开发、部署、运维,发版节奏完全自己控制。主系统按需动态加载子系统,动态渲染并挂载,与主系统虽然跨了技术框架,但仍可以完美融合,并且浏览器前进、后退、甚至刷新页面后都可以正常还原子页面,与一个系统的单页面使用体验无异。
实现方案
下面说一下微前端子应用sdk的具体实现过程,为了缩短篇幅,仅用代码展示了一些最小化的demo,但足以说明整个的工作原理。
先给大家展示一张流程图,展示了子应用sdk动态加载以及与主系统进行交互的过程。主、子系统的动态加载和交互的过程是通过主系统的sdk-loader
组件来完成的,可以动态加载sdk文件以及做sdk的缓存,在下面还有详细介绍。
图片
SDK工作流程图
主入口文件,SDKClass
class SDKClass {undefined
constructor(options) {undefined
// 可以让主系统传递各种sdk需要的options,例如多语言、鉴权信息、以及事件回调等
this.options = options || {};
this.isDestroyed = false;
}
// 主渲染方法,把sdk内容渲染到指定的父系统容器中
renderTo(container) {
if (container == null) {
container = document.body;
}
this._sdkContainer = document.createElement("div");
container.appendChild(this._sdkContainer);
// SDK的内容定义在RootApp中
render(<RootApp />, this._sdkContainer);
}
// 销毁sdk实例,以及渲染的所有dom元素
destroy() {
if (this.isDestroyed) {
return;
}
this.isDestroyed = true;
unmountComponentAtNode(this._sdkContainer);
this._sdkContainer.parentNode.removeChild(this._sdkContainer);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
}
export default SDKClass;
从代码中可以看出来,一个sdk的核心就是一个 SDKClass ,通过webpack打包成 UMD 规范的包,这样既可以被主系统已 amd 或 cmd 模块系统导入,也可以直接在页面中引入,通过 window 全局变量来访问。主系统拿到SDKClass 后,需要进行实例化,然后调用sdk实例的 renderTo 方法把内容渲染到指定容器中。由于没有导出 SDKClass 外的任何信息,所以一个SDK是一种很 “干净” 的引入,不会污染主系统或与主系统的代码产生冲突,也就是代码隔离性比较好。
renderTo
这是sdk的主入口,我们可以把sdk的内容定义在 RootApp 中,渲染到主系统的容器中。在 RootApp 中,我们一般会按照路由来划分sdk子系统的多个模块,同时把根路由设置为主系统对应模块的页面路由的地址。这样当主系统加载完sdk的js并且实例化调用 renderTo 方法时,sdk内部的路由系统会自动从根路由下渲染子页面。如果主系统有多个父页面需要嵌入同一个sdk的话,则可以通过sdk的构造函数在 options 中把 根路由 动态传递进来。
class RootApp extends React.Component {undefined
constructor(props) {undefined
this.state.context = {};
}
render() {undefined
return (
<React.StrictMode>
</React.StrictMode>
);
}
}
destroy
在单页面应用系统中,我们需要特别注意内存管理,防止内存泄露。在主系统中每次进入动态模块,都会实例化一个sdk的示例,而sdk实例就是一个完整的web应用,里面包含了dom元素以及很重的组件状态信息,所以当模块切走时,需要把当前的sdk实例销毁掉,释放相应内存。同时,在sdk内部,也要利用 destroy 的时机,把所使用的外部数据也要相应销毁。
双向交互
有时候父子系统之间有比较强的互操作,主系统要响应子系统中的某些事件,做出相应处理,或者在主系统的某个事件中,触发子系统的一些动作。这些其实也比较容易实现,由于sdk是在主系统中实例化的,主系统可以持有对sdk实例的引用,然后调用其公开方法,来实现 父调子 的动作。至于 子调父 的动作,可以在实例化sdk时,通过 options 传递一些事件回调过去,在sdk中合适的时机进行触发,或者 SDKClass 实现观察者模式,可以让主系统注册相应的事件,这样事件管理更规范一些。
class SDKClass {undefined
on(eventName, handler) { }
off(eventName) { }
}
那如果一个宿主页面中,引用两种SDK,而两个SDK要进行相互通信的话,那该怎么办呢?其实也没有什么特别的,宿主页面应该承担两个 内聚 的sdk实例之间通信的责任。由于A、B两个SDK都是宿主页面实例化出来的,所以宿主页面也就保持着 a 、 b 两个实例的引用,我们可以让宿主页面监听 a 的事件,然后在 event handler 中调用 b 实例的方法,可以实现 a 、 b 之间的互操作。
sdk-loader组件
我们在流程图环节提到了 sdk-loader 组件,这其实是在主系统中封装一个组件,把 sdk 的动态加载、缓存、自动销毁、无污染传递 SDKClass 等特性都封装了一下,可以在主系统中方便使用。但这是一个可选项,如果我们不实现 sdk-loader 的话,也可以把sdk的 js 和 css 事先引入主页面中,可以直接获取sdk通过 UMD 规范导出的 SDKClass 的全局变量,实例化并调用 renderTo 渲染。请注意,关于 revisionUrl 的解释,在下一节中有详细的描述。
class SdkLoader extends React.Component {undefined
static defaultProps = {undefined
jsUrl: “”,
cssUrl: “”,
revisionUrl: “”,
onLoaded: null, // function(SDKClass) { }
onDestroying: null,
}
componentDidMount() {undefined
fetch(${revisionUrl}?v=${Date.now()}
).then((resp) => {undefined
return resp.text();
}).then((version) => {undefined
let scriptDom = document.createElement(‘script’);
Object.assign(scriptDom, {undefined
type: “text/javascript”,
async: true,
src: ${jsUrl}?v=${version || Date.now()}
});
document.getElementsByTagName(‘head’)[0].appendChild(scriptDom);
let styleDom = document.createElement("link");
Object.assign(styleDom, {
rel: "stylesheet",
type: "text/css",
href: `${cssUrl}?v=${version || Date.now()}`
});
document.getElementsByTagName('head')[0].appendChild(styleDom);
});
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
}
revisionUrl有什么用?
主系统是通过 jsUrl 来加载sdk的,但如果sdk修改内容重新编译的话,有可能存在浏览器缓存问题。为了避免浏览器使用旧缓存,我们通常会在加载js时后面增加上一个动态参数,比如script.src = this.props.jsUrl+"?v="+Date.now() 。但如果使用时间戳作为参数的话,也有一个副作用,就是每次加载都会使用一个新的 url 进行加载,这样每次都会重新下载js文件,即便是内容完全一致。当文件没有变化的时候,我们希望能利用浏览器缓存,避免重复加载。所以比较理想的情况是,如果sdk没有改动,我们希望浏览器尽量使用缓存,如果sdk改动了内容,我们希望浏览器能自动缓存失效,加载新版本。
为了实现这样的效果,我们可以在构建sdk时,引入一个“版本”文件,也就是 revisionUrl ,里面存放的是sdk的编译版本号。至于版本号的生成策略,可以根据自己的实际情况来设定。这样的话,如果sdk发版,则编译版本文件必然发生变化,否则编译版本内容始终保持不变。然后我们优化一下 sdk.js 的加载策略,先加载 revisionUrl 文件,获取编译版本号,然后再以编译版本号为动态参数加载 sdk.js ,这样基本上就实现了我们想要的效果。当然加载版本文件时,我们最好以时间戳
为动态参数,以确保每次获取编译版本时都不存在缓存问题,同时由于版本号文件的尺寸非常小,相对于加载 sdk.js 文件来说代价基本就可以忽略不计了。
当然,有人可能会说,webpack打包出来的文件都会加上文件 hash ,这样不就很容易避免js缓存问题了?在开发一个web应用的时候,这确实是一个普遍遵循的最佳实践。但如果是对外界提供的sdk的话,如果 jsUrl 文件名带 hash 的话,每次改动都会改变文件名,而 jsUrl 又是配置在主系统中的,就会导致父系统频繁跟着改 jsUrl 、发版,两个系统又都耦合在一起了。
那有没有一个办法,既能最大程度复用浏览器缓存,而又不必每次都多发一个 version 串行化请求呢?其实是可以做到的,但有一个前提,就是父子系统团队比较紧密,捆绑在一个 CI & CD 管道中。子系统先构建,然后获取子系统的主入口的 jsUrl ,然后自动写入到主系统的配置文件中,再启动主系统的构建过程。这样两个系统就可以联动编译了,由于 jsUrl 里面包含了 hash ,我们在 sdk-loader 中直接使用 jsUrl 加载就可以了。如果你的团队不是紧密关联,而是松散关联的话,就无法进行自动化联合构建了。
所以没有一个绝对完美的解决方案,要根据自己的实际情况进行权衡,选择一个相对最合适的方案。
如何传递SDKClass
在前面提到了 无污染传递SDKClass ,具体是什么意思呢?由于子系统sdk是在主系统的 sdk-loader 中动态创建 script 标签来加载的,要与主系统传递数据只能通过 window 全局变量来实现,这样是会存在全局变量污染的。当然,现代浏览器在逐渐支持 [JavaScript modules] 特性,允许我们加载一个Javascript模块,但毕竟是新特性,浏览器兼容性不是太好,暂时还不能使用。其实我们可以借助另外一个很少使用的 api document.currentScript ,可以在sdk文件内部获取加载的 script 标签对象,然后通过这个 dom 对象来做一些数据传递。
sdk.js
class SDKClass { }
// 1. 向主系统传递SDKClass
if (document.currentScript) {undefined
document.currentScript._sdkClass = SDKClass;
}
sdk-loader
let script = document.createElement(‘script’);
script.type = ‘text/javascript’;
script.async = true;
script.src = this.props.jsUrl;
script.onload = function () {undefined
// 2. 接收sdk实例,而不污染全局变量
let sdkClass = this._sdkClass;
}
CSS隔离性
在SDK中渲染出来的内容也是带样式的,那如何做到sdk释放的样式与主系统不冲突呢?也就是如何保证CSS隔离性呢?
首先在SDK中不限制 css 预处理器的使用,无论是 less 还是 Sass 都是在编译阶段起作用的,所以不影响最终输出css的内容。当然css文件还是样式的主要载体,我们在写css样式时要注意,不要写全局样式,或者引入 normalize.css 这种全局样式重置库,否则势必会与主系统的样式体系产生冲突。如果一定要写一些全局性的 class ,或者全局设置一些 dom 的样式,建议在所有样式的最外层再包装一层作用域,比如:
.sample-sdk {undefined
div {undefined
line-height: 1.5;
}
.bold {undefined
font-weight: bold;
}
.center {undefined
text-align: center;
}
}
把所有的样式都封装在 .sample-sdk 内部的话,所有全局样式也就变成了“局部样式”。然后我们在SDK的 renderTo 方法中,在整个内容最外层渲染一个父容器,把 class 设置为 sample-sdk ,这样里面的样式就都会起作用了。而父系统中,没有任何父系统的元素包含在 sample-sdk 中,所以不会干扰父系统的样式。
当然,我们更推荐大家在SDK中使用 CSS Module ,在webpack中引入自己框架相相应的插件就可以了。由于 CSS Module 的 class 是被 hash化 的,名字随机性很好,与主系统样式隔离的效果非常好。
异常上报
一般前端系统中会引入异常上报机制,例如sentry等,确保前端发生脚本异常时,能上报到监控系统中。当引入sdk时,脚本错误会跨越系统边界,能够同时被主系统和sdk子系统捕获。为了区分两个系统中发生的脚本异常,我们可以通过 error.stack 中获取错误初次发生的文件,如果是sdk的 jsUrl 则是sdk的错误边界,否则则是主系统的。
新版本通知
由于主系统和sdk子系统的开发周期都是隔离的,所以有可能发生用户在主系统渲染了sdk时,而sdk更新了新编译版本,我们最好能显示一个新版本提醒,这样用户可以知道更新了新版本,然后刷新页面以加载新版本sdk。
这个功能也不难实现,我们可以在sdk中定期轮询自己的 revisionUrl ,当发现编译版本内容变更时,便可以在sdk顶部或其它合适的地方显示一个新版本提示,提醒用户刷新页面加载新版本。当然,用户也不是一定要刷新页面来加载新版本sdk的。我们可以先卸载掉当前sdk实例,然后再重新加载新版本sdk重新渲染,并自动导航到用户最后停留的界面。甚至,我们基于sdk服务端配置的一些策略,实现倒计时 强制 自动更新也是可能的,在这里就不赘述了。
多版本管理
当第一个版本的sdk开发完成后,如果我们需要继续添加新特性该怎么办?是直接修改,然后再重新打包发布吗?这个时候需要分两种情况来看,第一种,如果父子系统是一一对应的关系,且都同属于一个大系统,或者说子系统就是父系统的一个模块,那这么做问题不大。第二种情况是,sdk是一个公开的系统,会被多个外部系统嵌入,甚至作为一个开源项目,那就不能随便修改了。这个时候我们需要跟 npm 的管理方法类似,需要维护多个版本,也就是说,最好每次新增特性,甚至修复bug都生成一个新的版本。这样发布新版本就不会影响到正在使用老版本的外部系统了。那些引用了某个版本的外部系统,也不会因为某个新版本的改动而受到影响,是否升级新版本完全由自己来决定。
我们需要在自己的构建系统中,引入一个真正的 version 文件,每次 publish 一个新版本,需要升级一下版本号,然后把打包的所有内容防止在该版本对应的目录下,也就是说,我们最终的输出目录,第一层目录应该是 版本 文件夹,每个版本的所有文件都应放置在相应版本目录下。而我们发布给外界的 jsUrl 以及cssUrl 应该是包含了版本的,比如:http://www.sample-code.com/sdk/v1.0/static/js/main.js
总结
以上便是Udesk在微前端方面摸索和实践的过程,借助于微前端的思想,我们可以把多个子应用拆分为独立的sdk项目,甚至可以实现前端框架的渐进式替换,即把某一个小模块或者某个页面使用新框架实现,再动态替换掉主系统的某个模块,而不用等待系统都替换完以后再上线,几乎不影响正常的迭代速度。大家可以参考这里提供的思路,实现自己的微前端解决方案,可以进一步根据自己系统的需求,再完善一些细节,以更贴近自己的业务。
引用文献
https://micro-frontends.org/
https://medium.com/@somnath.mondol/adopting-micro-frontends-architecture-12005d8c9e65