美文网首页
微前端的技术拆分方式

微前端的技术拆分方式

作者: 大吕泽 | 来源:发表于2019-12-28 15:37 被阅读0次

    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

    相关文章

      网友评论

          本文标题:微前端的技术拆分方式

          本文链接:https://www.haomeiwen.com/subject/ugysoctx.html