微前端基本概念

一、微前端概念

微前端的概念是由Thought Works 在2016年提出来。微前端借鉴了后端微服务的架构概念，将后端微服务的理念应用在浏览器，核心在于将一个庞大复杂前端项目拆分成多个独立灵活的小型应用，每个应用都可以进行独立开发，独立运行和独立部署。最后通过微前端的技术将这些小型应用融合为一个完整的应用，或者将原来运行已久、没有关联的几个独立应用融合为一个应用。微前端既可以将几个项目融合成一个项目，又可以减少项目之间的耦合，提升项目的可扩展性，相较于一整块的前端仓库微前端架构下的前端仓库更加的小巧灵活。

1.1 什么是微服务架构？

微服务架构是将大型复杂系统按照功能或者业务需求垂直切分成更小的子系统，这些子系统以独立部署的子进程存在，他们之间通过轻量级的，跨语言的同步（REST、grpc）或者异步消息网络调用进行通信

1.1.1 微服务架构的重要特征：

• 整个应用程序被拆分成相互独立但包含多个内部模块的子进程。
• 与模块化的单体应用或SOA相反，微服务应用程序根据业务范围或领域垂直拆分
• 微服务边界事外部的，微服务之间通过网络调用（rpc或消息）相互通信
• 微服务是独立的进程，它们可以独立部署
• 它们以轻量级的方式进行通信，不需要任何智能通信通道

1.1.2 微服务架构的有点：

• 更好的开发规模
• 更快的开发速度
• 支持迭代开发或现代化增量开发
• 充分利用现代软件开发生态系统的优势（云、容器、Devops、Serverless）
• 支持水平缩放和细粒度缩放
• 小体量，降低了开发人员认知复杂度

1.1.3 微服务架构的缺点：

• 更高数量级的活动组件
• 复杂性从代码转移到基础设施
• RPC调用和网络通信的大量增加
• 整个系统的安全性管理更具挑战
• 整个系统的设计变得更加困难
• 引入了分布式系统的复杂性

1.1.4 微服务架构使用场景

• 大规模Web应用开发
• 跨团队企业级应用协作开发
• 长期收益优于短期收益
• 团队拥有能够设计微服务架构的工程师

1.2 微前端的核心价值

1. 技术栈无关： 主框架不限制接入应用的技术栈，微应用具备完全自主权。
2. 独立开发、独立部署： 微应用的仓库应该是独立的，前后端都能进行独立的开发，部署完成之后，主框架自动完成同步更新
3. 增量升级： 在面对各种复杂的场景，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好实施渐进式重构的手段和策略
4. 独立运行： 每个微应用之间状态隔离，运行时的状态隔离

1.3 一个完善的微前端应该具备哪些能力？

1. 子应用的加载和卸载能力: 页面需要从一个子应用切换到另一个子应用，框架必须具备加载、渲染、切换的能力
2. 子应用独立运行能力： 子应用运行会污染全局的window对象，样式会污染其他应用，必须要有效的隔离起来
3. 子应用路由跳转状态保持能力： 激活子应用后，浏览器刷新、前进、后退子应用的路由都应该可以进行正常的工作
4. 应用间通信的能力：应用建通信的能力

二、 微前端的技术拆分方式

从技术实践上，微前端架构以以下几种方式进行：

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

实践1、 路由分发式

通过路由将不同的业务分发到不同的对前端应用中(通过http反向代理来实现)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7FA4tO1r-1675931051327)(/download/attachments/2350379521/%25E6%2588%25AA%25E5%25B1%258F2022-12-06%252015.59.37.png?version=1&modificationDate=1671434600435&api=v2)]

使用路由分发方式时最简单的“微前端”方案，通过这种方式，我们只是将这些不同的前端应用拼凑在一起，使他们看起来更像一个完整的整体。但是这个应用并不是一个完整的整体。当用户从A应用传递到B应用时，需要刷新下页面，重载页面资源，我们只需要将用户状态从A应用传递到B应用

实践2、 前端微服务化

每个前端应用都是完全独立(技术栈、开发、部署、构建)的，最后通过模块化的方式组合出完整的前端应用，采用这种方式时意味着一个页面上同时存在两个及两个以上的前端应用在运行，而路由分发式的方案是，一个页面只有唯一一个应用
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4ZPenyJs-1675931051328)(/download/attachments/2350379521/%25E6%2588%25AA%25E5%25B1%258F2022-12-06%252016.11.58.png?version=1&modificationDate=1671434600987&api=v2)]

我们需要做到：

1. 在页面合适的地方引入或者创建DOM（现有前端框架离不开基本的HTML元素DOM）；
2. 用户操作时，加载对应的应用，并且能卸载应用
3. 保证应用间的第三方依赖不冲突，当我们需要处理不同的技术栈时，我们需要针对性的出一套移除DOM和相应应用监听的方案，并且需要保证应用间的第三方依赖不冲突

实践3、微应用化

微应用化是指，在开发时应用都以单一、微小应用的形式存在，运行时通过构建工具合并这些应用，组合成一个新的应用，微应用化意味着我们只能使用唯一的一种前端框架

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-juqo13Ys-1675931051328)(/download/attachments/2350379521/%25E6%2588%25AA%25E5%25B1%258F2022-12-06%252016.17.22.png?version=1&modificationDate=1671434602705&api=v2)]

实践4、 微件化

微件（Widget）是一段可以直接嵌入应用上用运行的代码，它由开发人员预先编译好，在加载时不需要做任何的修改或编译
微件化是指每个业务团队编写自己的业务代码，并将编译好的代码部署到指定服务器，运行时，只需要加载相应的业务模块，更新时只需要更新对应的模块即可
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vVMElZB6-1675931051329)(/download/attachments/2350379521/%25E6%2588%25AA%25E5%25B1%258F2022-12-06%252016.21.24.png?version=1&modificationDate=1671434601632&api=v2)]

为了支持微件化，需要保证：

1. 持有一个完整的框架运行时及编译环境，用于保证微件能正常使用，即可调用框架api等
2. 性能受影响，应用由提前编译变成了运行时编译，会造成一些性能方面的影响 - 具体视组件大小而定
3. 提前规划依赖，如果一个新的微件想使用新的依赖，需要从上游编译引入

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

1. 分包构建出来的独立代码, 如webpack构建的chunk产物
2. 使用DSL的方式编写出来的组件

实践5、前端容器化 - iframe

实践6、 应用组件化 - Web Components

三、 微前端的业务划分方式

1. 按照业务拆分
2. 按照权限拆分
3. 按照变更频率拆分
4. 按照组织结构拆分
5. 跟随后端业务拆分

四、微前端的架构模式

从微前端应用见的关系来看分为两种： 基座模式(管理式)、自由组织模式
不论哪种方式，都需要提供一种查找应用的机制，在微前端中成为服务的注册表模式。和微服务架构相似，不论哪种微前端方式，都需要有一个应用注册表的服务，它可以使一个固定值的配置文件，如JSON文件，或者是一个可动态更新的配置，又或者是一种动态服务，主要做以下的事：
* 应用发现， 让主应用可以寻找到其他应用
* 应用注册，提供新的微前端应用，向应用注册表注册的功能
* 第三方应用注册，即让第三方应用接入系统中
* 访问权限等相关配置

基座模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZJiPQiSC-1675931051329)(/download/attachments/2350379521/%25E6%2588%25AA%25E5%25B1%258F2022-12-07%252017.41.20.png?version=1&modificationDate=1671434602197&api=v2)]

1. 在这种模式的微前端架构中，基座应用承担了微前端应用的基础与技术核心。
2. 基座模式，是由一个主应用和一系列业务子应用构成的系统，并由这个主应用来管理其他子应用，包括从子应用的生命周期管理到应用间的通信机制。
3. 基座模式中的主应用，类似于API Gateway 的概念，它作为系统的统一入口，负责将对应的请求指向对应的子服务。作为应用的基础核心，还需要:
   • 维护应用注册表。在应用注册表上表明系统有多少个服务，能否找到对应的应用等
   • 管理其他子应用。如在何时加载应用，何时卸载应用等
4. 子应用，则是负责各个子模块的业务实现

自由组合模式

1. 系统内部的各个子系统能根据不同的规则形成一定的结构或者功能
2. 采用这种模式可以使系统内的各种前端应用，都各自拥有一个小型的基座管理功能，也相当于么每个应用都有基座
3. 采用基座模式时，用户要访问A应用要先加载主应用才能访问；采用自由组合模式则只加载A应用，不加载主应用，这也使这种模式拥有更高的自主性

五、微前端的设计理念

1. 去中心化： 应用注册表
2. 标识化应用
3. 应用生命周期管理
   • 这是前端微架构和后端微服务之间最大的不同之处
   • 生命周期包括三个部分： 加载应用、运行应用、卸载应用
4. 高内聚，低耦合