微前端的技术拆分方式
@ 姜波 | 星期二,十月 27 日,2020 年 | 3 分钟阅读 | 更新于 星期二,十月 27 日,2020 年

路由分发式

  • 通过HTTP服务器的反向代理功能,将请求路由到对应的应用上

Image text

特点

  • 采用的最多、最容易的“微前端”方案
  • 并非一个整体,每当用户从A应用转换到B应用的时候,往往需要刷新一下页面,重新加载资源文件
  • 缺少了对应用状态的处理,需要用户重新登录,这种体验对用户来说相当不友好

前端微服务化

  • 在不同的框架之上设计通信和加载机制,以在一个页面内加载对应的应用

Image text

特点

  • 一个页面上同时存在两个及以上的前端应用在运行,而路由分发式方案则是,一个页面只有唯一一个应用
  • 在页面合适的地方引入或者创建DOM
  • 用户操作时,加载对应的应用(触发应用的启动),并能卸载应用
  • 还需要保证应用间的第三方依赖不冲突,可以通过向上游开发者提Pull Request来修复这个问题

微应用

  • 通过软件工程的方式,在部署构建环境中,把多个独立的应用组合成一个单体应用

Image text

特点

  • 大都是以软件工程的方式来完成前端应用的开发的,因此又可以称之为组合式集成
  • 通过业务作为主目录,然后在业务目录中放置相关的组件,同时拥有一些通用的共享模板
  • 拆分出每个模块之后,便只需要在构建的时候复制所有的模块到一个项目中, 再进行集成构建
  • 微应用化就是微前端的一种实践,只是使用微应用化意味着我们只能使用唯一的一种前端框架

微件化

  • 开发一个新的构建系统,将部分业务功能构建成一个独立的chunk代码,使用时只需要远程加载即可

Image text

特点

  • 每个业务团队编写自己的业务代码,并将编译好的代码部署到指定的服务器上,在运行时,我们只需要加载相应的业务模块即可(未来WebComponents)

  • 单页应用时代为了支持微件化,需要做:

    • 持有一个完整的框架运行时及编译环境。用于保证微件能正常使用,即可调用框架API等

    • 性能受影响,应用由提前编译变成运行时才编译,会造成一些性能方面的影响,具体视组件的大小而定

    • 提前规划依赖,如果一个新的微件想使用新的依赖,需要从上游编译引入

  • 此外还需要一个支持上述功能的构建系统,它用于构建一个独立的微件模块,这个微件的形式如下:

    • 分包构建出来的独立代码,如webpack构建出来的chunk文件

    • 使用DSL的方式编写出来的组件

  • 为了实现这种方式,我们需要对前端应用的构建系统进行修改,如webpack,使它可以支持构建出单个的代码段,这种方式的实施成本比微应用化成本高

前端容器化

  • 将iframe作为容器来容纳其他前端应用

特点

  • 有效地将另一个网页/单页面应用嵌入当前页面中,两个页面间的CSS和JavaScript是相互隔离的,除去iframe父子通信部分的代码,它们之间的代码完全不会相互干扰,类似于沙箱隔离
  • 采用iframe的前提是网站不需要SEO支持,设计相应的应用管理机制

应用组件化

  • 借助于Web Components技术,来构建跨框架的前端应用

Image text

特点

  • Web Components是一套不同的技术,允许开发者创建可重用的定制元素(它们的功能封装在代码之外),并且在Web应用中使用它们
  • 离现在的我们还有些距离,是一种面向未来演进的架构
  • 只需要在页面中通过Web Components引入业务模块即可,其使用方式类似于微件化的方案
  • 目前困扰Web Components技术推广的主要因素在于浏览器的支持程度

公众号

Image text

QQ

Image text

微信

Image text

微信打赏

Image text

社交链接