运维开发网

微前端在解决什么问题?

运维开发网 https://www.qedev.com 2021-01-16 12:01 出处:51CTO 作者:mb5ff9827b65e5b
写在前面上一篇微前端到底是什么已经从概念定义及实现思路上探究了微前端是什么的问题,而要彻底理解微前端的话,还需要想清楚这些问题:为什么需要微前端?微前端能解决什么问题?组件化解决不了吗?微前端究竟带来了什么?多技术栈并存?统一的技术栈不好吗?一.背景:为什么需要微前端?从最初的HTML内联脚本,到9102年的几十万行JavaScript代码,前端已经变得越来越重:几个G的前端代码库数百号前端开发人

写在前面

上一篇微前端到底是什么已经从概念定义及实现思路上探究了微前端是什么的问题,而要彻底理解微前端的话,还需要想清楚这些问题:

为什么需要微前端?

微前端能解决什么问题?组件化解决不了吗?

微前端究竟带来了什么?多技术栈并存?统一的技术栈不好吗?

一.背景:为什么需要微前端?

从最初的 HTML 内联脚本,到 9102 年的几十万行 JavaScript 代码,前端已经变得越来越重:

几个 G 的前端代码库

数百号前端开发人员

几 MB 的 Bundle Size

也越来越复杂:

层出不穷的框架、类库

各式各样的工程化体系

别具特色的跨端实践

因而需要一种分解复杂度、提升协作效率、支持灵活扩展的架构模式,于是,微前端登上了舞台

二.应用场景:微前端能解决什么问题?

微前端的理念类似于微服务,将庞大的整体拆成可控的小块,并明确它们之间的依赖关系。

通过拆分自治、支持多技术栈并存的方式,解决前端应用所面临的种种问题:

业务模块间日益加剧的耦合如何治理?

开发团队如何拆分、解耦,才能达到并行开发的目的?

新框架、新方案如何适应现有的工程环境(构建工具等)?

旧的框架类库如何平稳升级?

按业务功能将一整块前端应用分解成一系列更小、更内聚的微前端应用,同时通过明确的交互协议来管理这些应用间的依赖关系,实现不同业务模块的解耦。并将每个微前端应用交由独立团队负责,各自独立开发独立部署,充分利用并行性

另一方面,在多技术栈并存能力的加持下,不仅能够低成本引入新的技术实践,还允许低风险地替换产品局部功能,意味着依赖项升级、架构更替、UI 改版等重大决策都能以循序渐进的方式平稳落地:

分解:将应用拆分成由一系列小型应用(子应用)组成的应用

替换:替换子应用

组合:确保替换过的能够和谐工作

通过微前端框架建立应用间的主从关系(1 个容器应用 + n 个子应用),接着进行局部替换,直至全部完成。然而,实践中通常需要在重构的同时保证新特性的持续迭代,所以实际流程可能是:

抽象:增加一层主从关系,比如通过前端路由来控制

扩展:新增子应用

组合:原应用直接作为一整个子应用,带着新特性(新增的子应用)上线

重构:(时间上能与扩展并进)分解、替换原应用

让重构等工作能够在相对较长的时间跨度下可控地渐进完成,而无需承担一刀切的资源需求与变更风险

组件化解决不了吗?


The problems they’re supposed to solve sound to me like they’re already solved by a good component model. So is this solving an organizational issue rather than technical one? Such as if two teams can’t agree on anything, even shared infra.

(摘自I don’t understand micro-frontends.)

诚然,组件化也能实现拆分自治,比如在 React 中可以通过React.lazy + Suspense的方式优雅地完成代码拆分

但这建立在组件模型统一(或者说技术栈一致)的前提下,而微前端的另一半优势在于能够打破单一技术栈的限制:


They are microservices in the browser. Meaning separately built and deployed frontend apps that can choose their own framework and libs. The purpose is organizational scaling and avoiding framework lock-in.

这是组件化、模块化等方案所无法满足的。同样的,git submodule、npm module 等拆分方案也都无法直接提供多技术栈并存的能力

三.意义:微前端究竟带来了什么?

工程价值

一半来自模块化带来的好处,诸如:

研发效率提升:多业务线并行开发,团队自治,独立迭代

交付成本降低:应用级功能复用

运维风险降低:变更范围缩小

另一半来自多技术栈并存能力的好处:

技术选择增多:不再与单一技术栈捆绑在一起,有助于新技术、新交互模式的实验性试错

可复用性增强:技术栈差异不再是功能复用的障碍,对于第三方模块尤为重要

重构风险降低:低风险局部替换,渐进地完成大规模重构

当然,允许多技术栈并存,并不意味着鼓励引入尽可能多的技术栈,因为更少的技术栈通常更有利于基础设施建设、资源复用与经验共享

商业价值

微前端视角下的 Web 应用是一系列独立功能的组合:


The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams.

(摘自What are Micro Frontends?)

因此,微前端应用能够像云计算背景下的云服务一样能够即取即用,实现应用模块级(第三方)功能的接入/融合,其商业价值在于:

细粒度、可组合的前端产品形态:前端产品/能力能够以更细粒度,更灵活的形态输出(像云服务一样按需自由组合)

微前端应用生态:规范化的微前端应用能够形成生态,进而产生类似于小程序的平台体系

参考资料

Micro Frontends

I don’t understand micro-frontends.

扫码领视频副本.gif

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号