微前端的原理及实现

1、简介

只听过“微服务”,“微前端”又是什么硬核技术?html

它正是借鉴微服务的概念来应用在前端上,将一个巨大的前端工程拆分红一个的小工程,这些小工程具有独立的开发和运行能力,而整个系统就由这些小工程协同合做。前端

微前端是一种相似于微服务的架构,它将微服务的理念应用于浏览器端,即将单页面前端应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还能够独立开发、独立部署。同时,它们也能够在共享组件的同时进行并行开发——这些组件能够经过 NPM 或者 Git来管理。

能够跟微服务这么对比着去理解:bootstrap

微服务 微前端
一个微服务就是由一组接口构成,接口地址通常是 URL。当微服务收到一个接口的请求时,会进行路由找到相应的逻辑,输出响应内容。 一个微前端则是由一组页面构成,页面地址也是 URL。当微前端收到一个页面 URL 的请求时,会进行路由找到相应的组件,渲染页面内容。
后端微服务会有一个网关,做为单一入口接收全部的客户端接口请求,根据接口 URL 与服务的匹配关系,路由到对应的服务。 微前端则会有一个加载器,做为单一入口接收全部页面 URL 的访问,根据页面 URL 与微前端的匹配关系,选择加载对应的微前端,由该微前端进行进行路由响应 URL。

2、 为何须要微前端

在 toB 的前端开发工做中,咱们每每就会遇到以下困境:后端

  1. 工程愈来愈大,打包愈来愈慢
  2. 团队人员多,产品功能复杂,代码冲突频繁、影响面大
  3. 心里想作 SaaS 产品,但客户老是要作定制化

微前端的实现,意味着对前端应用的拆分。拆分应用的目的,并不仅是为了架构上好看,还为了提高开发效率。浏览器

微前端带来这么一系列的好处:前端框架

  1. 应用自治。只须要遵循统一的接口规范或者框架,以便于系统集成到一块儿,相互之间是不存在依赖关系的。
  2. 单一职责。每一个前端应用能够只关注于本身所须要完成的功能。
  3. 技术栈无关。你可使用 Angular 的同时,又可使用 React 和 Vue。

除此,它也有一系列的缺点:服务器

  1. 应用的拆分基础依赖于基础设施的构建,一旦大量应用依赖于同一基础设施,那么维护变成了一个挑战。
  2. 拆分的粒度越小,便意味着架构变得复杂、维护成本变高。
  3. 技术栈一旦多样化,便意味着技术栈混乱。

3、如何设计微前端架构

就当前而言,要设计出一个微前端应用不是一件容易的事——尚未最佳实践。在不一样的落地案例里,使用的都是不一样的方案。出现这种状况的主要缘由是,每一个项目所面临的状况、所使用的技术都不尽相同。为此,咱们须要了解一些基础的微前端模式。架构

1. 架构模式

微前端应用间的关系来看,分为两种:基座模式(管理式)、自组织式。分别也对应了二者不一样的架构模式:框架

基座模式。经过一个主应用,来管理其它应用。设计难度小,方便实践,可是通用度低。
自组织模式。应用之间是平等的,不存在相互管理的模式。设计难度大,不方便实施,可是通用度高。ide

就当前而言,基座模式实施起来比较方便,方案上便也是蛮多的。

而不论种方式,都须要提供一个查找应用的机制,在微前端中称为服务的注册表模式。和微服务架构类似,不管是哪一种微前端方式,也都须要有一个应用注册表的服务,它能够是一个固定值的配置文件,如 JSON 文件,又或者是一个可动态更新的配置,又或者是一种动态的服务。它主要作这么一些内容:

应用发现。让主应用能够寻找到其它应用。应用注册。即提供新的微前端应用,向应用注册表注册的功能。第三方应用注册。即让第三方应用,能够接入到系统中。访问权限等相关配置。

应用在部署的时候,即可以在注册表服务中注册。若是是基于注册表来管理应用,那么使用基座模式来开发比较方便。

2. 设计理念

在笔者实践微前端的过程当中,发现了如下几点是咱们在设计的过程当中,须要关注的内容:

中心化:应用注册表。这个应用注册表拥有每一个应用及对应的入口。在前端领域里,入口的直接表现形式能够是路由,又或者对应的应用映射。
标识化应用: 咱们须要一个标识符来标识不一样的应用,以便于在安装、卸载的时候,能寻找到指定的应用。一个简单的模式,就是经过康威定律来命名应用。应用生命周期管理。高内聚,低耦合。

3. 生命周期

前端微架构与后端微架构的最大不一样之处,也在于此——生命周期。微前端应用做为一个客户端应用,每一个应用都拥有本身的生命周期:

Load,决定加载哪一个应用,并绑定生命周期
bootstrap,获取静态资源
Mount,安装应用,如建立 DOM 节点
Unload,删除应用的生命周期
Unmount,卸载应用,如删除 DOM 节点、取消事件绑定.

这部分的内容事实上,也就是微前端的一个难点所在,如何以合适的方式来加载应用——毕竟每一个前端框架都各自不一样,其所须要的加载方式也是不一样的。当咱们决定支持多个框架的时候,便须要在这一部分进入更细致的研究。
随后,咱们要面临的一个挑战是:如何去拆分应用。

4. 技术方式

从技术实践上,微前端架构能够采用如下的几种方式进行:

  1. 路由分发式。经过 HTTP 服务器的反向代理功能,来将请求路由到对应的应用上。
  2. 前端微服务化。在不一样的框架之上设计通信、加载机制,以在一个页面内加载对应的应用。
  3. 微应用。经过软件工程的方式,在部署构建环境中,组合多个独立应用成一个单体应用。
  4. 微件化。开发一个新的构建系统,将部分业务功能构建成一个独立的 chunk 代码,使用时只须要远程加载便可。
  5. 前端容器化。经过将 iFrame 做为容器,来容纳其它前端应用。
  6. 应用组件化。借助于 Web Components 技术,来构建跨框架的前端应用。

实施的方式虽然多,可是都是依据场景而采用的。有些场景下,可能没有合适的方式;有些场景下,则能够同时使用多种方案。

https://alili.tech/archive/11...

https://qiankun.umijs.org/zh/...

https://baijiahao.baidu.com/s...

https://www.cnblogs.com/scdis...

相关文章
相关标签/搜索