微前端是借鉴后端微服务的概念而来。如果你对微服务的概念比较熟悉,那么微前端也差不多。

在以前,我们把所有前端的功能都在一个前端工程里实现,可以称之为——单体前端。那微前端,就是把这么一个单体前端拆分为多个前端工程,这一套机制与方法就叫微前端。

那我们来看一看单体前端和微前端在架构上的区别:

从上图可以看出,微前端相比单体前端工程来说,多了一个微前端运行时。这个运行时在用户访问的 URL 与页面映射之间,切分出了新的一层。当用户访问一个 URL 时,会首先由微前端运行时拦截,然后其判断该 URL 属于哪一个微前端工程,于是加载该微前端工程。后续行为就跟单体前端一样了,该微前端接管路由匹配,找到组件并渲染页面。

那么,这里有几个问题要在微前端架构里实现:

  1. 如何判断该 URL 属于哪一个微前端工程
  2. 如何加载(或卸载)微前端工程

问题一属于注册信息的问题,每一个微前端工程都应该进行注册,声明其匹配的 URL。比如 /a 匹配微前端 A,/b 匹配微前端 B。这样当用户访问 http://domain.com/a 时,就匹配上微前端 A。所以,我们需要一个注册中心,专门收集各个微前端的注册信息。微前端运行时会拉取该信息,确定匹配规则。

那确定了微前端,我们就需要把该微前端下载下来并运行起来。我们知道前端工程通过打包后,基本可以分为 js、css 这类资源文件。那么加载一个微前端,就相当于要下载这些 js、css 文件,并运行它们。这个也可以通过注册信息来实现。但要注意的一个问题是,这些资源文件,是有版本号的,比如 app.28sn913f048d3.js。如果每次发布微前端后,都手动去注册,势必比较麻烦。在 Engage 里,我们通过微前端工程的 index.html 来获取这些资源的版本及其完整地址。

如有其他疑问,可以联系 Engage 平台团队了解更多。