1.路由分发式。通过HTTP服务器的反向代理功能,将请求路由到对应的应用上
路由分发式微前端,即通过路由将不同的业务分发到不同的独立前端应用上,每当用户从A应用转换到B应用的时候,往往需要刷新一下页面、重新加载资源文件
2.前端容器化。将iframe作为容器来容纳其他前端应用
3.微应用。通过软件工程的方式,在部署构建环境中,把多个独立的应用组合成一个单体应用
微应用化是指,在开发时应用都是以单一、微小应用的形式存在的,而在运行时则通过构建系统合并这些应用,组合成一个新的应用
微应用化与前端微服务化架构类似,他们在开发时都是独立应用,在构建时又可以按照需求单独加载
如果以微前端的单独开发、单独部署、运行时聚合的基本思想来看,微应用化就是微前端的一种实践。只是使用微应用化意味着我们只能使用唯一的一种前端框架
除了限制开发人员使用同一个框架,它还有一些缺点:
所有应用的依赖需要统一,一旦依赖版本不一致,可能会带来其他问题
高度依赖于持续集成,每个子应用在提交的时候,都会重新构建出整个应用,一旦一个子应用出错,系统就会出错
微应用化的形式是,在构建时以单体应用的形式构建;在运行时,以应用模块的形式存在。从原理上说,我们做的只是从多个项目中复制出代码,然后合并到一个项目中
microapps
app-routing.module.ts
reports.module.ts
...
dashboard
dashboard.module.ts
...
reports
reports.module.ts
...
settings
settings.module.ts
...
除了主的app模块,还包含了dashboard、settings、reports三个模块。在微应用化里,上述应用便是最后构建过程中的应用。在构建之前这些模块是以独立App的形式存在的,可以独立的开发运行。而主的App模块下的功能,则可以变成主工程。这时,一共会有四个代码仓库
主代码库,只包含一个空白的框架式代码,它是一个单独的应用,可以独立构建,构建完成则成为包含另外三个应用的完整工程
dashboard应用,在构建时复制对应模块、目录的代码到主工程
4.前端微服务化。在不同的框架之上设计通信和加载机制,以在一个页面内加载对应的应用
每个前端应用都是完全独立(技术栈、开发、部署、构建独立)
采用这种方式意味着,一个页面上同时存在两个及以上的前端应用在运行
在加载应用时的事件绑定及应用入口
在卸载应用时的事件解绑
目前都采用基座化的方式来加载其他应用,基座化方式可以支持加载不同的前端框架,以及在基座工程上绑定业务逻辑
整体的工作流程:
主工程在运行的时候,会去服务器获取最新的应用配置
主工程在获取配置后,将逐一创建应用,并为应用绑定生命周期
当主工程监测到路由变化的时候,将寻找是否有对应的路由匹配到应用
当匹配到对应的应用时,则加载相应的应用
基座包含以下功能:
管理其他子应用
负责应用间的通信
设计路由的响应机制
支持嵌入常规及iframe模式
Single-SPA自称是一个JavaScript的原框架,他可以用于构建可共存的微前端应用,每个前端应用都可以用自己的框架编写。它能实现如下内容:
在同一页面上使用多个框架而不用刷新页面
使用新的框架编写前端代码,而无需重写现有的应用程序
延时加载前端应用和代码,用于改善初始加载时间
缺点:
系统构建复杂,应用需要集成在一起进行构建
不支持不同应用的部署分离
代码结构复杂
有额外的大量学习成本
5.微件化。开发一个新的构建系统,将部分业务功能构建成一个独立的chunk代码,使用时只需要远程加载即可
每个业务团队编写自己的业务代码,并将编译好的代码部署(上传或者放置)到指定的服务器。在运行时,我们只需要加载相应的业务模块即可
如果存在第三方开发组件,就不得不考虑寻找如iframe这样的隔离方案。微件化并不适合复杂的前端应用。
对于传统的多页面应用来说,微件化是相当容易实施的方案。在传统的多页面应用结构中,只需要编写相应的HTML、CSS、JavaScript,就可以在加载微件时创建相应的组建和元素,再替换到相应的DOM结点上,这种方式类似于WebComponents
6.应用组件化。借助于Web Components技术,来构建框架的前端应用
对于不能从头使用Web Components,有两种方式可以结合Web Components来构建微前端应用
使用Web Components构建独立于框架的组件,并在对应的框架中引入这些组件
在Web Components中引入现有的框架,类似于iframe的形式
方式 开发成本 维护成本 可行性 同一框架要求 实现难度 潜在风险
路由分发 低 低 高 否 *
iframe 低 低 高 否 *
微服务化 高 低 中 否 **** 针对每个框架做定制及Hook
微件化 高 中 低 是 **** 正对构建系统,如webpack进行hack
微应用化 中 中 高 是 *** 统一不同应用的构建规范
WebComponents 高 低 高 否 ** 新技术,浏览器的兼容问题
js 隔离
一个子应用从加载到运行,再到卸载,有可能会对全局产生一些污染。这些污染包括但不限于:添加、删除、修改全局变量(比如:window.$ = jQuery)、绑定全局事件(比如:window.addEventListener、修改原生方法或对象(比如:Promise)、修改原生方法或对象的原型链(比如:XMLHttpRequest.prototype.open)。而所有这些子应用造成的影响都可能引起潜在的全局冲突。为此,我们需要在加载和卸载一个应用的同时,尽可能消除这种影响
硬隔离
简单来说,就是在每个子应用加载之前,都进行一次 reload,这样可以保证每个子应用在渲染时都是一个全新的环境,哪怕是上一个子应用把 window 上的属性改了个遍,也丝毫没有影响
css 隔离
子应用与子应用之间的 css 隔离非常简单,我们只需要在子应用加载时,标记该子应用所有的 link 和 style 文件。在子应用卸载后,同步卸载所有的 link 和 style 即可
子项目原本需要加载的公共部分(如vue、vuex、vue-router、ivew/element、私有npm包等),全部由主项目调度,配合webpack的externals功能通过外链的方式按需加载,一旦有一个子项目加载过,下一个子项目就不需要再加载,这样一来每个子项目的dist文件里就只有子项目自己的业务代码(最终子项目包的体积缩小了80%,只有几十k),项目实际加载速度快了很多
umijs/qiankun
网友评论