【微前端】架构_产业新知_资讯_猿巴巴

引言

“空间分离带来的协作问题”＆“时间延续带来的升级维护负担”，是在一个规模可观的或年龄超过 3 年的B端系统都会存在的问题。

01 场景思考和大厂方案
02 SPA、MPA、MicroFrontend
03 微前端架构解决了什么？
04 微前端的应用主战场
05 产品视角

场景思考和大厂方案

1、场景思考

思考两个场景：

1、你新入职一家公司，老板扔给你一个 5 年陈的系统，需要你在这个项目上持续迭代加功能。

2、你们起了一个新系统，只给了一个要求："如何确保这套系统在 3~5 年内还葆有生命力，不会在 3、5 年后变成又一个遗产项目？"

在产品圈混过的都知道，别说 3、5年了，有几个人敢保证自己的系统在一年后把所有依赖包升级到最新，还能跑起来？

2、大厂方案

传统的云控制台应用，几乎都会面临业务快速发展之后，单体应用进化成巨石应用的问题。

为了解决产品研发之间各种耦合的问题，大部分企业也都会有自己的解决方案。国内外几个著名的云产品控制台，是这样解决的：

关于MPA、SAP等可见下文介绍

MPA 方案的优点在于部署简单、各应用之间硬隔离，天生具备技术栈无关、独立开发、独立部署的特性。

缺点则也很明显，应用之间切换会造成浏览器重刷，由于产品域名之间相互跳转，流程体验上会存在断点。

SPA 则天生具备体验上的优势，应用直接无刷新切换，能极大的保证多产品之间流程操作串联时的流程性。

缺点则在于各应用技术栈之间是强耦合的。

那我们有没有可能将 MPA 和 SPA 两者的优势结合起来，构建出一个相对完善的微前端架构方案呢？

SPA、MPA、MicroFrontend

1、SPA，单页面应用

SPA是前单页Web应用的意思，（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。

SPA做为各种解决方案的基础，天生具备体验上的优势，应用直接无刷新切换，能极大的保证多产品之间流程操作串联时的流程性。

缺点则在于各应用技术栈之间是强耦合的。

随着一个项目需求变得越来越多，项目体积变得越来越大得时候，单页面应用得弊端也渐渐得暴漏出来，最大直观问题就是文件加载过大导致页面性能下降。

关于网页加载速度，可以阅读文章 App和Web分别的加载原理＆加载方案设计（4千字）

或参考书籍《后端产品经理宝典》第二章内容：

那么如何可以更好得解决这个问题，是不是可以从业务上进行拆分呢，各个模块单独使用各自得html呢，于是有了MPA（多页面应用）。

2、MPA，多页面应用

多页面应用（MPA，MultiPage Application），即每一次页面跳转的时候,后台的服务器都会给我们返回一个新的HTML文档,这种类型的网站就是多页面网站,或者称之为多页面应用。

通过webpack控制入口文件，打包出来多个最终文件同时提供多个html，可以实现模块之间项目独立从而达到解耦得目的，达到了我们得目的。

但是也随之带来了一些弊端，MPA路由基于文档跳转，每一次跳转带来得负担就是需要重新加载。

公共资源文件，性能上对比SPA大大降低，切合到实际开发中当项目太大多个部门共同开发时，所有人共同开发一个独立工程，一旦一个模块代码出现问题会影响到整个前端工程，线上发布同样会遇到同样得问题，一个模块会影响整个工程。

如何避免呢，答案就是微前端解决方案。

3、MicroFrontend，微前端

先来看看微服务。微服务将单体服务拆分成多个服务如图：

多个服务相互独立，通过聚合层对外暴露公共端口，每个服务实现独立部署，那么前端是不是也可以这么做呢，于是微前端就诞生了。

微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

各个前端应用还可以独立运行、独立开发、独立部署。

微前端不是单纯的前端框架或者工具，而是一套架构体系，这个概念最早在2016年底被提出。

微前端架构解决了什么？

1、SPA与MPA解决不了的问题

微前端架构解决了哪些SPA与MPA解决不了的问题呢？

1）对前端拆分解决了MPA的资源重新加载的问题；

2）解决了SPA体积过大的问题；

3）解决开发过程中各个模块相互影响的问题，达到了模块独立开发。

整体结构如图：

2、上帝的归上帝：轻量的基座

IT的很多解决思路是： Give back to Ceasar what is Ceasar's and to God what is God's （——《圣经·新约》）

我们只需要在主系统构造一个足够轻量的基座，然后让各子应用按照共同的协议去实现即可。

这个协议可以包括，主应用应该如何加载子应用，以及子应用如何被主应用感知、调度，应用之间如何通信等。

这个协议不应该包括，子应用要如何确保隔离性、安全性，也就是子应用除了实现一些较为简单的协议之外，跟开发一个正常的 spa 应用应该没有任何差别，包括不应该有开发、构建、发布等流程上的侵入。

只要子应用实现了这几个协议，其他的东西怎么玩，我们都不需要关心或干预。

这样的话，其实整个系统就变成了一个真正的、基于运行时的插件平台了。

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

微前端的应用主战场

1、ToB 软件服务

统计一下业界关于”微前端“发过声的公司，会发现使用微前端的公司，基本上都是做 ToB 软件服务的，没有哪家 ToC 公司会有微前端的诉求（有也是内部的中后台系统），为什么会这样？

很简单，因为很少有 ToC 软件活得过 3 年以上的。

而对于 ToB 应用而言，3~5 年太常见了！

对很多做 ToB 领域的中小企业而言，这样的系统可能是他们安身立命之本，不是能说扔就扔的，他们承担不了那么高的试错成本。

阿里云最早的那些产品的控制台，去看看那些电信软件、银行软件，哪个不是 10 年+ 的寿命？

大部分企业应用都会有一个核心的诉求，就是如何确保我的遗产代码能平滑的迁移，以及如何确保我在若干年后还能用上时下热门的技术栈？

1）沟通效率衡量；

2）原型改动范围衡量；

3）部门工作流程衡量。

衡量权重占比：从解决问题看，1）和2）最高。从长期看，3）很重要。

2、云产品

云产品对于微前端的诉求是基本相同的，包括背后的管控、编码能力等。

我们需要清楚一件事，并不是只有云产品才需要微前端，也并不是所有采用微前端方案的公司都是做云产品的。

微前端的初衷应该还是来解决工程问题的，带来的产品价值在不同的领域可大可小。

比如在阿里云这种典型的云产品控制台的场景下，它带来的产品价值就会很可观。

因为阿里云作为提供 IAAS 服务的云平台，它需要的就是平台、产品的被集成能力，在这种场景下，微前端能力能非常好的契合这个诉求。

但需要强调的是，并不是所有采用微前端的客户，都是阿里云这种 IAAS 平台产品。

很多中小型控制台大多没有产品自由组合能力的诉求。产品能力只能算是微前端的能力的一种延伸。

产品视角

1、什么情况下使用微前端

当我们的系统中有多个不同的子模块,并且子模块之间有相对独立且完整的功能体系时, 一旦子模块变得越来越多, 那么整个应用将变得非常庞大且臃肿,开发和维护成本大大提高。

如果在这种场景下我们采用SPA模式开发,那么项目后期将变得不可想象,页面首次加载将变得非常慢（可能会遇到这种情况，开发一个复杂系统，页面首次加载花了20多秒,所以不得不采用MPA来处理）。

我们采用MPA(多页应用)模式,虽然解决了应用臃肿的问题, 但仍然存在很多有待处理问题,比如模块切换需要重新刷新页面, 公共组件无法共享,子模块直接,父子模块之间的通信问题,开发部署繁琐等.这写都是传统开发模式会遇到的问题.

这时候可以考虑使用微前端架构：可以让我们在主应用中共享公共组件和状态(但是要保证子应用运行时内部的状态隔离), 并且不同子模块之间可以单独开发部署, 模块间切换不刷新页面, 并且模块之间,父子应用之间可以通过某种简单的方式实现通信。

2、微前端架构下的用户体验

对于用户来讲，和之前访问网站时的体验一致，没有响应速度（资源加载、应用响应等）上面的区别。

各应用之间的通信方便，可互相调用各应用所提供的数据接口以及组件接口等。但同时也不会带来项目之间的相互影响。

如下图，统一入口和鉴权，统一基座。用户各自登录自己权限下的子系统。

3、系统本身

微前端带来各种业务提升、产品提升的价值。

比如产品的自由组合能力，比如以 widget 这种可视化方式直接输出产品的能力等等。

效率问题。微前端首先解决的，是如何解构巨石应用，从而解决巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题。

解构之后还需要再重组，重组的过程中我们就会碰到各种隔离性、依赖去重、通信、应用编排等问题。在解决了这些问题之后，才是产品的自由组合、输出等能力。

同时由于有了前者能力的铺垫和加持，这些产品上的价值提升也就变得很自然和容易。

4、团队和技术栈

做到代码的时代和次元隔离并且拥有良好的用户体验，是微前端的核心：随着时间的推移，团队人员的流动，会慢慢发现一些事情：比如原维护团队看旧系统代码，就像在看原始人用原始的姿势拉着原始的屎。微前端的理想状态也许就是用最爽的姿势写最新的业务模块。

微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。

（完）

【微前端】架构

更多相关内容

核酸检测企业们的南柯一梦：在常态化取消和重启之间

“蔚小理”，请全面开战！

【ICML2022】深度学习中的协同和对称：数据、模型和推理算法之间的交互

机泵振动故障怎么办

重新理解「沟通」：好好说话的自救指南

估值600亿元，湖南人做的辣条上市了

付费惹众怒，“屡败屡战”的视频平台变现有多急

史上最全资产划转处理全攻略！

王缉思：有人总想把中美拉入战火，“中美发生战争”言论不能再扩大了

企业之间的订单、要货单需要交印花税吗

猿巴巴_商业服务平台精选

【微前端】 架构