什么是微前端
Martin Fowler将微前端架构定义为“一种独立可交付前端应用程序被组成的建筑风格”。简单地,微前端是网页的一部分(不是整页)。在微前端架构中,有一个“主机”或“容器”页面,可以托管一个或多个微前端。主机/容器页面还可以共享一些自己的微前端组件。
好处:组织灵活性和一致性
微前端的支持者强调它能像微服务那样减少团队间的依赖,提升组织灵活度。微前端的其他好处有:
- 独立部署不同的服务
- 实现自治团队,具备独立迭代和创新的能力
- 能够围绕业务部门或产品来打造团队
这些都是很有价值的优势,对于大型和复杂的项目尤其明显;但即使是较小的应用程序项目也可以受益于独立部署等微前端特性。
当我在 2010 年开始开发电子商务应用(那时微服务还没出现)时,我一直担心无关变量以某种方式破坏结账流程。我们建立了覆盖广泛的测试框架来预防这种情况,但回想起来,这种场景正是独立服务 + 微前端大显身手的好去处。
不足:操作复杂性
我们现在不仅要编辑静态文件,还要完成诸如构建复杂系统、转换和大型框架等任务,所以想要实现正常运行的前端环境需要一系列复杂的工作。微前端让前端环境变得更加复杂了。如今在整个应用中进行任何类型的测试都可能需要多个前端协作,更不用说将这些前端组装在一起所需要的各种工具了。
经历微服务的开发者会很熟悉下面这些挑战:
- 需要在开发中运行许多不同的应用来测试完整的应用体验
- 跟踪和调试整个系统的问题
- 应付整个系统的版本控制任务
本质上来说,我们是在用整个系统的复杂度代价换取单个前端的简洁度。
缺陷:性能、不连贯的体验
Twitter 上有很多对微前端的批判。
下面的问题看来是非常严重的:
- 每个团队都有自己的技术选择,浏览器最终可能需要下载很多框架和重复代码。
- 用户是把你的公司和产品看作一个整体的。所以这也是反对完全独立组件的一个论据——如果团队也完全独立开来,问题会更加严重。
- 微前端的一些实现(特别是嵌入 iframe)可能会导致严重的可访问性问题。
虽然微前端的支持者争辩说这些问题不一定会出现,但这种方法似乎确实让这些问题出现的可能性增加了。
妥协:微前端体验的界限
微前端能否做到利大于弊,具体取决于你的情况和条件。对于小型、高度协作的团队和相对简单的产品来说,微前端的优势相比代价来说就很不明显了;而对于大型、功能众多的产品和许多较独立的团队来说,微前端的好处就会更突出。
还有一系列方法可以在避开所有缺点的前提下获得许多好处。
只要坚持使用一种框架,并利用像 single-spa.js(
https://single-spa.js.org/)这样的协作框架,你就可以通过资源共享和只需下载一次的公共代码来避免大多数性能损失。
可以使用共享组件库来消除许多不一致的用户体验。
当然,这些方法都需要你放弃一定程度的独立性。到某种程度之后,你的架构就根本不再是微前端架构了。具体怎样取舍也是取决于你的产品和组织情况的。
重点就是——工程就是权衡的艺术,而微前端为你提供了另一个可以做权衡的维度。