“空间分离带来的协作问题”&“时间延续带来的升级维护负担”,是在一个规模可观的或年龄超过 3 年的B端系统都会存在的问题。
1、你新入职一家公司,老板扔给你一个 5 年陈的系统,需要你在这个项目上持续迭代加功能。
2、你们起了一个新系统,只给了一个要求:"如何确保这套系统在 3~5 年内还葆有生命力,不会在 3、5 年后变成又一个遗产项目?"
在产品圈混过的都知道,别说 3、5年了,有几个人敢保证自己的系统在一年后把所有依赖包升级到最新,还能跑起来?
传统的云控制台应用,几乎都会面临业务快速发展之后,单体应用进化成巨石应用的问题。
为了解决产品研发之间各种耦合的问题,大部分企业也都会有自己的解决方案。国内外几个著名的云产品控制台,是这样解决的:
-
MPA 方案的优点在于部署简单、各应用之间硬隔离,天生具备技术栈无关、独立开发、独立部署的特性。
缺点则也很明显,应用之间切换会造成浏览器重刷,由于产品域名之间相互跳转,流程体验上会存在断点。
-
SPA 则天生具备体验上的优势,应用直接无刷新切换,能极大的保证多产品之间流程操作串联时的流程性。
缺点则在于各应用技术栈之间是强耦合的。
那我们有没有可能将 MPA 和 SPA 两者的优势结合起来,构建出一个相对完善的微前端架构方案呢?
SPA是前单页Web应用的意思,(single page web application,SPA),就是只有一张Web页面的应用,是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
SPA做为各种解决方案的基础,天生具备体验上的优势,应用直接无刷新切换,能极大的保证多产品之间流程操作串联时的流程性。
随着一个项目需求变得越来越多,项目体积变得越来越大得时候,单页面应用得弊端也渐渐得暴漏出来,最大直观问题就是文件加载过大导致页面性能下降。
关于网页加载速度,可以阅读文章App和Web分别的加载原理&加载方案设计(4千字)
或参考书籍《后端产品经理宝典》第二章内容:
那么如何可以更好得解决这个问题,是不是可以从业务上进行拆分呢,各个模块单独使用各自得html呢,于是有了MPA(多页面应用)。
多页面应用(MPA,MultiPage Application),即每一次页面跳转的时候,后台的服务器都会给我们返回一个新的HTML文档,这种类型的网站就是多页面网站,或者称之为多页面应用。
通过webpack控制入口文件,打包出来多个最终文件同时提供多个html,可以实现模块之间项目独立从而达到解耦得目的,达到了我们得目的。
但是也随之带来了一些弊端,MPA路由基于文档跳转,每一次跳转带来得负担就是需要重新加载。
公共资源文件,性能上对比SPA大大降低,切合到实际开发中当项目太大多个部门共同开发时,所有人共同开发一个独立工程,一旦一个模块代码出现问题会影响到整个前端工程,线上发布同样会遇到同样得问题,一个模块会影响整个工程。
先来看看微服务。微服务将单体服务拆分成多个服务如图:
多个服务相互独立,通过聚合层对外暴露公共端口,每个服务实现独立部署,那么前端是不是也可以这么做呢,于是微前端就诞生了。
微前端(Micro-Frontends)是一种类似于微服务的架构,它将微服务的理念应用于浏览器端,即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。
微前端不是单纯的前端框架或者工具,而是一套架构体系,这个概念最早在2016年底被提出。
微前端架构解决了哪些SPA与MPA解决不了的问题呢?
3)解决开发过程中各个模块相互影响的问题,达到了模块独立开发。
IT的很多解决思路是:Give back to Ceasar what is Ceasar's and to God what is God's(——《圣经·新约》)
我们只需要在主系统构造一个足够轻量的基座,然后让各子应用按照共同的协议去实现即可。
这个协议可以包括,主应用应该如何加载子应用,以及子应用如何被主应用感知、调度,应用之间如何通信等。
这个协议不应该包括,子应用要如何确保隔离性、安全性,也就是子应用除了实现一些较为简单的协议之外,跟开发一个正常的 spa 应用应该没有任何差别,包括不应该有 开发、构建、发布 等流程上的侵入。
只要子应用实现了这几个协议,其他的东西怎么玩,我们都不需要关心或干预。
这样的话,其实整个系统就变成了一个真正的、基于运行时的插件平台了。
微前端架构旨在解决单体应用在一个相对长的时间跨度下,由于参与的人员、团队的增多、变迁,从一个普通应用演变成一个巨石应用(Frontend Monolith)后,随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
统计一下业界关于”微前端“发过声的公司,会发现使用微前端的公司,基本上都是做 ToB 软件服务的,没有哪家 ToC 公司会有微前端的诉求(有也是内部的中后台系统),为什么会这样?
很简单,因为很少有 ToC 软件活得过 3 年以上的。
对很多做 ToB 领域的中小企业而言,这样的系统可能是他们安身立命之本,不是能说扔就扔的,他们承担不了那么高的试错成本。
阿里云最早的那些产品的控制台,去看看那些电信软件、银行软件,哪个不是 10 年+ 的寿命?
大部分企业应用都会有一个核心的诉求,就是如何确保我的遗产代码能平滑的迁移,以及如何确保我在若干年后还能用上时下热门的技术栈?
衡量权重占比:从解决问题看,1)和2)最高。从长期看,3)很重要。
云产品对于微前端的诉求是基本相同的,包括背后的 管控、编码 能力等。
我们需要清楚一件事,并不是只有云产品才需要微前端,也并不是所有采用微前端方案的公司都是做云产品的。
微前端的初衷应该还是来解决工程问题的,带来的产品价值在不同的领域可大可小。
比如在阿里云这种典型的云产品控制台的场景下,它带来的产品价值就会很可观。
因为阿里云作为提供 IAAS 服务的云平台,它需要的就是平台、产品的被集成能力,在这种场景下,微前端能力能非常好的契合这个诉求。
但需要强调的是,并不是所有采用微前端的客户,都是阿里云这种 IAAS 平台产品。
很多中小型控制台大多没有产品自由组合能力的诉求。产品能力只能算是微前端的能力的一种延伸。
当我们的系统中有多个不同的子模块,并且子模块之间有相对独立且完整的功能体系时, 一旦子模块变得越来越多, 那么整个应用将变得非常庞大且臃肿,开发和维护成本大大提高。
如果在这种场景下我们采用SPA模式开发,那么项目后期将变得不可想象,页面首次加载将变得非常慢(可能会遇到这种情况,开发一个复杂系统,页面首次加载花了20多秒,所以不得不采用MPA来处理)。
我们采用MPA(多页应用)模式,虽然解决了应用臃肿的问题, 但仍然存在很多有待处理问题,比如模块切换需要重新刷新页面, 公共组件无法共享,子模块直接,父子模块之间的通信问题,开发部署繁琐等.这写都是传统开发模式会遇到的问题.
这时候可以考虑使用微前端架构:可以让我们在主应用中共享公共组件和状态(但是要保证子应用运行时内部的状态隔离), 并且不同子模块之间可以单独开发部署, 模块间切换不刷新页面, 并且模块之间,父子应用之间可以通过某种简单的方式实现通信。
对于用户来讲,和之前访问网站时的体验一致,没有响应速度(资源加载、应用响应等)上面的区别。
各应用之间的通信方便,可互相调用各应用所提供的数据接口以及组件接口等。但同时也不会带来项目之间的相互影响。
如下图,统一入口和鉴权,统一基座。用户各自登录自己权限下的子系统。
比如产品的自由组合能力,比如以 widget 这种可视化方式直接输出产品的能力等等。
效率问题。微前端首先解决的,是如何解构巨石应用,从而解决巨石应用随着技术更迭、产品升级、人员流动带来的工程上的问题。
解构之后还需要再重组,重组的过程中我们就会碰到各种隔离性、依赖去重、通信、应用编排 等问题。在解决了这些问题之后,才是产品的自由组合、输出等能力。
同时由于有了前者能力的铺垫和加持,这些产品上的价值提升也就变得很自然和容易。
做到代码的时代和次元隔离并且拥有良好的用户体验,是微前端的核心:随着时间的推移,团队人员的流动,会慢慢发现一些事情:比如原维护团队看旧系统代码,就像在看原始人用原始的姿势拉着原始的屎。微前端的理想状态也许就是用最爽的姿势写最新的业务模块。
微前端的意义就是将这些庞大应用进行拆分,并随之解耦,每个部分可以单独进行维护和部署,提升效率。
https://martinfowler.com/articles/micro-frontends.html
https://micro-frontends.org/
本篇文章来源于微信公众号: 唧唧歪歪PM