微前端是什么、价值、不足、典型模式

微前端技术调研

微前端（Micro-Frontends）是什么

为了解决庞大的后端服务带来的变更与扩展方面的限制，出现了微服务架构（Microservices），越来越重的前端工程也面临同样的问题，自然地想到了将微服务思想应用（照搬）到前端，于是有了「微前端（micro-frontends）」的概念。微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一的应用。各个前端应用还可以独立开发、独立部署。简单说就是将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

微服务与微前端概念对比。

---

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

传统前端与微前端架构对比：

传统的单体前端：

基于微前端架构的前端：

微前端的基本原理

主应用提供平台入口，包括资源模块加载器，加载公共依赖、css、js和子应用所需的依赖；各子应用需要在主应用注册，主应用初始化后，通过统一应用基座动态加载子应用，卸载上一个子应用同时加载下一个子应用；微前端需要解决子应用间路由、消息、鉴权等问题，子应用需要暴露出资源配置表（适配）

微前端（Micro-Frontends）的价值

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

微前端架构具备以下几个核心价值：

1、技术栈无关

主框架不限制接入应用的技术栈，子应用具备完全自主权。这能让系统新旧代码和谐共存，另一方面，也带来了技术选型上的灵活性，有助于新技术、新交互模式的实验性应用试错。

2、独立开发、独立测试、独立部署

子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新。任务边界划分明确, 每个子服务之间单独开发, 不同微服务可并行由不同的开发人员开发,提高开发效率；独立部署的能力在微前端体系中至关重要，能够缩小变更范围，进而降低相关风险；每个微前端都应具备有自己的持续交付流水线（包括构建、测试并部署到生产环境），并且要能独立部署，不必过多考虑其它代码库和交付流水线的当前状态。使得自动化CI(持续集成)/CD(持续交付)成为可能。

3、增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

4、独立运行时

每个微应用之间状态隔离，运行时状态不共享

5、**团队自治 **

微前端的精髓在于解藕，应用达到特定规模后，微前端开始变得有意义。其中一个好处是更多潜在的团队划分可能性，包括组建更小的全栈团队。除代码库及发布周期上的解耦之外，微前端还有助于形成完全独立的团队，由不同团队各自负责一块产品功能从构思到发布的整个过程，团队能够完全拥有为客户提供价值所需的一切，从而快速高效地运转。

微前端（Micro-Frontends）的不足

微前端的缺点

1. 应用的拆分基础依赖于基础设施的构建，一旦大量应用依赖于同一基础设施，那么维护变成了一个挑战。

2. 拆分的粒度越小，便意味着架构变得复杂、维护成本变高。

3. 技术栈一旦多样化，便意味着技术栈混乱

微前端模式与其他前端模式对比

为了说明微前端优缺点，把微前端与其他两种方案做对比结果如下。一种是规模化应用也就是巨型单体项目，另外一种是通过nginx实现根据模块区分的应用项目叫模块化项目，特点是跳转其他应用需要重新加载，并产生白屏。

从难易度上讲，微前端应用对现有项目改动和复杂度不算大，提前是你使用集成好的微前端框架。最后，模块应用和规模化应用难易度都相对较低，应该都很熟悉它们。

在性能上，规模化应用性能一定是最好的。原因很简单，用户使用期内，只加载一次框架库并执行一次框架库。微前端首先是需要加载微前端库的，指定跳转的子应用入口也必须加载，并且执行一次子应用框架库。但微前端好处是，当第二次再调用子应用，有了缓存后则不需要执行。对比规模化应用，微前端性能上略有差距，但在体验上基本可以做到一样。模块应用因为是页面跳转，所有资源都需要重新加载并执行，在性能和体验上都很差。

应用场景上，一般微前端还是应用在管理端，移动端应用比较少。主要原因是移动端应用一般不会特别复杂。例外也是有的，属于偏工具类的，比如办理贷款的客户经理端项目等。

微前端（Micro-Frontends）的模式

如何构建微前端框架？很不幸，只有一个含糊的答案：就像微服务一样，并不存在适用于所有人的单一方法，也没有业界标准。目前主流的微前端方案模式包括以下几个：

1. 前端容器化，借助Iframe

2. 基座模式，主要基于路由分发，qiankun和single-spa就是基于这种模式

3. 组合式集成，即单独构建组件，按需加载，类似npm包的形式

4. EMP模式，主要基于Webpack5 Module Federation

5. 应用组件化，Web Components模式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nJSJ8Hxl-1635295913245)(media/image5.png)]{width=“5.1875in” height=“2.8541666666666665in”}严格来讲，这些方案都不算是完整的微前端解决方案，它们只是用于解决微前端中运行时容器的相关问题。除了运行时容器，一套完整的微前端方案还需要解决版本管理、质量管控、配置下发、线上监控、灰度发布、安全监测等与工程和平台相关的问题，而这些问题中的大部分工作目前仍处于探索阶段。以下是几种方案的简要介绍：

序号 方案 说明

---

1 iframe 是传统的微前端解决方案，基于iframe标签实现，技术难度低，隔离性和兼容性很好，但是性能和使用体验比较差，多用于集成第三方系统；
2 基座模式 主要基于路由分发，即由一个基座应用来监听路由，并按照路由规则来加载不同的应用，以实现应用间解耦；
3 组合式集成 把组件单独打包和发布，然后在构建或运行时组合；
4 EMP 基于Webpack5 Module Federation，一种去中心化的微前端实现方案，它不仅能很好地隔离应用，还可以轻松实现应用间的资源共享和通信；
5 Web Components 是官方提出的组件化方案，它通过对组件进行更高程度的封装，来实现微前端，但是目前兼容性不够好，尚未普及。

总的来说，iframe主要用于简单并且性能要求不高的第三方系统；组合式集成目前主要用于前端组件化，而不是微前端；基座模式、EMP和Web Components是目前主流的微前端方案。

进一步分类：

类型 内容

---

客户端类 Piral、Open Components、qiankun、 Luigi、Frint.js
服务端类 Mosaic、PuzzleJs、Podium、Micromono
辅助库类 Module、Federation、Siteless 、Single SPA 、Postal.js 、EventBus

微前端（Micro-Frontends）拓展资料参考

序号 标题

---

1 必须知道的11个微前端框架
2 拥抱云时代的前端开发架构—微前端
3 可能是你见过最完善的微前端解决方案
4 qiankun官网
5 Micro frontends—a microservice approach to front-end web development
6 Micro Frontends
7 微前端的核心价值
8 Vue + qiankun 快速实现前端微服务
9 前端微服务化解决方案2 - Single-SPA
10 single-spa基于webpack的demo
11 single-spa结合多个框架的demo
12 single-spa-react
13 微前端如何落地
14 微前端的那些事儿
15 微前端的设计理念与实践初探

微前端（Micro-Frontends）实战（qiankun）

见qiankun与实战篇