一文让你了解微前端的现状 _微前端

在前端 Web 开发中，微前端（microfrontends）是一个备受争议的话题。它是否值得开发者采用？面对如此之多的神奇案例，人们无法否认微前端正日益流行这个事实。本文将探究微前端的具体使用场景和使用群体，并给出能快速轻松上手的现有解决方案。
什么是微前端？微前端将大规模的后端系统切分为很多面向前端的微服务，力图实现一定程度的改进。

这里的主要问题是，各个部分总是作为一个整体被使用和体验的。

用户体验（UX）是由前端直接负责的，因为后端系统从来不会被直接整体访问。
该问题存在多种解决方案。最简单的做法是将现有 API 的数据交换模型替换为 html 输出。只需一个超链接即可实现服务（视图）间的跳转。尽管这种解决方案是有效的，但缺点是在很多情况下并不能提供用户所需的 UX 。

文章插图

分布式 Web 应用的演进
显然，要将那些各自独立的较小 UI 部分聚合为一个整体的前端，需要的是一些更为复杂的解决方案。这应视为分布式 Web 应用演进的下一步。
一个重要的问题是，如何理解微前端与组件和模块的关系。事实上，组件、模块、微前端等概念，都是以构建单元的形式实现可重用性和所承担的功能。它们之间的唯一差别是所处的层级不同，具体而言：

组件是底层 UI 库的构建单元；
模块是相应运行时的构建单元；
软件包是依赖解析器的构建单元；
微前端是当前应用的构建单元。

如上，微前端可视为组成人体的各个器官，软件包则对应于组成各器官的细胞，而模块就是分子，组件对应于原子。
为什么要使用微前端？使用微前端的原因多种多样，常见的原因多是技术性的，但往往有现实的商业用例（或者提升 UX 的用例）在背后提供支持。
究其根本，微前端解决方案可提供如下特性：

单个前端部分可独立开发、测试和部署；
无需重新构建即可添加、移除或替换单个前端部分；
不同的前端部分可使用不同的技术构建。

由此可见，微前端主要实现了解耦。在应用到达一定规模后，微前端就有了用武之地。其中一个潜在优点是，它支持组织分割为更多团队，乃至创建更小的全栈团队。

文章插图

微前端对全栈团队的支持
微前端在如下场景中将更发挥更大作用：

多个团队贡献同一个前端
一些独立的部分需由特定的用户或团队激活、终止激活或 roll out
需支持外部开发人员对 UI 进行扩展
UI 的特性集每日 / 每周都在增长，并不会影响系统其它部分
不论应用如何增长，都需要维持恒定的开发速度
支持不同团队使用不同的开发工具

微前端的使用者目前，微前端得到越来越多企业的积极采纳，下面给出部分最新列表：

DAZN
Elsevier
entando
Fiverr
Hello Fresh
IKEA
Bit.dev
Microsoft
Open Table
OpenMRS
Otto
SAP
Sixt
Skyscanner
smapiot
Spotify
Starbucks
Thalia
Zalando
ZEISS

…… 不胜枚举！
各个企业所采用的方法当然各有千秋，但是大家的目标是一致的。

文章插图

使用微前端技术的企业（由 Luca Mezzalira 提供）
企业列表正不断增长，从 ThoughtWorks、HLC 等咨询公司，到 SalesPad、Apptio 等 SaaS 服务提供商。还有更多传统企业已经押注微前端，典型实例就是德国的隐形巨头 Hoffmann 集团。
Hoffmann 集团很好地展示了微前端并不需要多么大型的团队，也不需要占用多少内部资源。该集团与多家服务提供商有业务往来，这是其选择微前端的一个重要因素。
实例：微前端及所使用的组件Bit.dev 平台及其市场营销网站均使用 React 组件构建，并且由 Bit 自身维护。
用户在浏览网站查看其“原生服务”时，可停留在不同组件上。点击位于组件上方的名字，即可查看组件详情，进而安装到用户项目中。