介绍 AWS 微前端架构指南

2024年8月28日

💎 加入 E+ 成長計畫 與超過 400+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

前阵子 AWS 的前端架构团队,释出了《AWS Prescriptive Guidance: Understanding and implementing microfrontends on AWS》指南 (连结),谈了一些微前端的架构与实务技术考量,在本篇文章将为大家摘要其中设计理念区块的重点。

image
圖片來源:AWS Prescriptive Guidance: Understanding and implementing microfrontends on AWS

微前端架构

微前端是一种目前业界相当流行的前端架构,这个架构模式的重点是「微」,而这个「微」是借镜于微服务 (micro-service) 的架构模式。就像是微服务会把原本单体 (monolith) 拆成多个微小的服务,微前端也是采用类似的形式。

微前端架构把前端拆解成多个不同的应用程式,每个前端应用程式都可以独立开发、独立部署。当把前端拆成多个不同应用程式后,商业逻辑也能够被封装,进而减少彼此的相互依赖。

当采用微前端的架构,团队能获得以下的好处:

  • 开发者的自主性提升:在微前端架构下,因为商业逻辑被封装在子应用中,只要是不涉及主应用的部分,子应用可以自己决定实作细节,想怎么开发就怎么开发 (例如这个子应用选 React,另一个觉得更适合用 Vue,两边可以独立选择)
  • 部署能够独立进行:当某个子应用要更新时,版本控制、建构、部属都能独立,交付功能的迭代速度因而获得提升
  • 故障隔离:当某个子应用出问题时,可以确保问题的影响范围,会限缩在该子应用中,只要不是涉及主应用的错误,都不会影响到其他的子应用

启发微服务的设计理念

前面提到,微前端的「微」是借镜于微服务 (micro-service) 的架构模式。事实上,微前端不只借镜于微服务架构。从技术设计的角度来看,微前端还受其他的设计理念启发。

领域驱动设计 (domain-driven design)

第一个有借助的设计理念是领域驱动设计 (domain-driven design),俗称 DDD。

DDD 是由 Eric Evans 提出的一种设计理念。在该设计理念下,软体开发应该是由商业驱动 (by business concern),而不是由技术驱动 (not by technical concern)。 在商业驱动下,应用的领域划分,会是以商业的需求来划分。

具体来说,而在微前端的架构下,不同的子应用,会是用领域 (domain) 的角度来拆分。举例来说,在电商的应用中,商品、订单、支付、物流等不同的领域,会被拆成不同的子应用来维护。

对比来看,在单体前端 (monoliths) 的架构下,由于不同领域的程式码,都会在同一个程式码库中,如果没有特别细心地维护,很容易把不同程式码写得彼此耦合,导致可维护性大幅降低 (备注:虽然理论上可以避免,但在实务中,这是很常见到的问题)。

不过你可能会问,如果想把一个单体前端,拆成微前端,该如何拆呢? 在 AWS 团队分享的指南中提到,可以从依赖的角度看,在拆分时,要让分出来的子应用之间,彼此做到依赖最小化 (minimal dependencies),所以如果在拆的时候,发现两个子应用还彼此有依赖,那可能拆法就需要调整。

上面提到的依赖,是指彼此之间的依赖。但很可能这些不同的子应用,都需要共同用某个元件,这时从架构的角度,可以另外切分出工具 (widget) 来做到共用。在指南中有用下面这张图视觉化呈现,可以看到两个子应用都有用到 Map View (或说都依赖 Map View),这时 Map View 元件应做为工具,由第三方团队来开发与维护。

模组化 (modularization)

除了借助于 DDD,微前端还受模组化 (modularization) 的设计所启发。还记得在 [微前端架构 — 微前端的技术细节] 一文中,我们有谈到模组联邦 (Module Federation),并谈到在微前端的架构下,我们可以把主应用当成本地模组,来消费不同的远端模组,而这些远端模组正是指不同的子应用。

模组化的概念,跟 DDD 的理念不谋而合。在 DDD 的框架下,系统中的每个子应用都是不同的模组,都专注于解决特定的商业领域 (意即某个子领域) 的问题,并在清楚界定好的范围中独立运作,不依赖于其他领域的模组。这种切分方法,让整体架构更清楚,且更能对应到商业逻辑。

在这个概念下,微前端架构也更偏好尽可能做到不共享 (share nothing, where possible)。不同的子应用是独立建构、独立部署,换句话说可能两个子应用有重复安装某个两边都有用的套件,这虽然是种冗余 (因为在单体架构下,只需用安装一次,不用两边都安装),但这是微前端架构做的取舍。换句话说,虽然这样有冗余,但因为能让不同模组独立性提高、相互依赖减少,冗余成为取舍下选择接受的成本。

阅读更多

如果你对为前端的架构、技术细节,以及更完整的 AWS 微前端指南摘要感兴趣,我们在 E+ 当中有更完整的版本。

本文为 E+ 成长计划的深度内容,截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們