微服务的想法最近引起了很多关注,许多公司正在使用它来消除大型的单一后端。
与前端走同样的路线对于许多企业来说仍然是一个挑战,即使这种构建 Web 应用服务器端的分布式方式在研究和执行方面或多或少是可靠的。
由于其紧密的依赖关系,客户端单体通常难以集成新功能、采用新技术和扩展单个组件。
这些和其他挑战促使前端开发人员使用微服务进行调查。
因此,开发了一种称为微前端的全新架构策略,用于创建网站和基于 Web 的应用程序的前端层。
该术语于 2016 年首次使用,从那时起,它就因为一个好的原因而引起了很多关注。
本文将大致了解什么是微前端以及它们解决的问题。 它的工作,以及利弊。
微前端架构介绍
一种称为微前端架构的当代前端开发方法划分了一个 Web应用程序 分成小的、独立的部分。
对最终用户来说,这些部件似乎是一个单元,即使它们是独立构建然后组合在一起的。
由于微前端与在线解决方案的客户端而不是服务器端有关,它们的基本原理与微服务相同。
使用微前端方法时,制作复杂的基于 Web 的产品最有意义。
与更传统的前端单体相比,微前端使许多团队能够在各种软件项目上单独协作。
使用这种架构设计,程序员可以更快地创建 Web 应用程序,并具有更高的可扩展性和可维护性。
简而言之,每个微前端只是网页不同组件的一段代码。
这些功能由不同的团队控制,每个团队都专注于某个行业或目标。
单体 vs 微服务 vs 微前端架构
考虑搬家。 将所有东西组织到一些经过专业标记的小盒子中并单独重新安置每个人,或者将整个员工打包到一个巨大的盒子中并将其运送到新位置,是否会更简单?
显而易见的解决方案就在那里。
这个类比比较了两种不同的 Web 应用架构,单体和微服务(也称为微前端)。
单体架构
当一个完整的应用程序被创建为一个单一的、有凝聚力的实体时,您可能会回忆起“过去的美好时光”。 这种方法称为巨石,是大石块的旧称。
这很有道理。
单体系统具有相互依赖的元素。 因此,如果您想修改某些内容或添加新功能,整个系统可能会崩溃。
尽管它已经过时,但它偶尔仍然存在。 是的,我们知道您目前的表达方式。
随着新技术的开发和软件产品变得越来越复杂,将代码库概念划分为两个不同的组件——前端(客户端)和后端(服务器端)变得不可避免。
现在最流行的操作方法是分离最终用户与之交互的表示层和后台发生的所有事情之间的关注点。
它需要两个软件工程团队,前端团队构建可视化组件,后端团队构建 Web 服务、业务逻辑、数据访问、集成等。
然而,尽管有这种分离,但这种策略本质上仍然是单一的。
主要的变化是我们现在有两个相当大的代码块——前端和后端——而不是一个巨大的应用程序。 单体架构不一定很糟糕; 他们有一些好处,包括
- 具有单一源代码库和非常简单的设计的小型应用程序的简单快速开发;
- 测试和调试非常简单,因为所有代码都在一个位置,使团队更容易跟踪请求的流程并识别错误;
- 在应用程序开发的早期,费用更便宜,因为在添加新功能之前不会产生基础设施成本和开发成本。
这种策略的弊端体现在
- 部署灵活性受限——如果团队中只有少数人在处理项目,并且每次更新代码时都需要新的部署,则团队必须等待;
- 采用新技术具有挑战性,因为这样做需要重写很大一部分,如果不是整个项目的话。
- 当开发人员数量增加时,代码系统变得紧密相连、复杂且难以管理和理解。
- 组织问题——每个团队成员必须使用相同版本的库并报告任何更改,如果许多团队正在处理一个单一项目。
- 对可扩展性的担忧——由于项目的组件是相互关联的,因此单独扩展它们会带来困难,从而导致大量停机和更高的支出。
- 新团队成员可能难以理解该项目的复杂逻辑,尤其是在最初从事该项目的工程师不再受雇的情况下。
微服务及其近亲和微前端的开发解决了单体系统的主要问题。
微服务架构
称为微服务的架构方法允许创建许多松散链接且可独立部署的较小组件或服务,这些组件或服务构成应用程序后端。
每个服务都有自己的代码库、CI/CD 管道、DevOps 程序和运行它们的流程。
通过查看上图,您可以看到单体后端团队被划分为独立的团队。
每个都分别关注应用程序的不同方面(例如产品服务、搜索服务和支付服务)。
服务之间的通信通过称为 API 的既定协议进行,例如使用同步请求-回复模式的轻量级 REST API 协议。
另一种选择是使用 Kafka 等软件使用异步通信,该软件提供发布/订阅通信结构和事件。
微服务通过前端 (BFF) 服务的后端或通过网络的 API 网关与前端集成。 BFF 为每个客户端提供定制的 API,而 API 网关为一组微服务提供单点访问。
但即使有自主的后端组件和它们提供的所有优势,前端仍然是一个整体。
因此,这就是微前端有用的地方。
微前端架构
与微服务类似,松散链接的组件由多个团队管理,微前端架构将这一概念应用于浏览器。
这些 Web 应用程序用户界面遵循这种结构,它由一些自治的组件组成。
团队也是根据客户需求或用例而不是特定的专业知识或技术创建的。
因此,团队参与了微服务和微前端项目。
- 垂直切片——因为有前端开发人员、数据专家、后端工程师、QA 工程师等也在从事同一个项目,他们从 用户界面 到数据库; 和
- 跨职能——每个团队成员都为团队贡献他们的专业知识。
团队还可以选择最适合其特定业务线的技术堆栈。
一个团队可以使用 React 对其片段进行编程。 另一个团队创建了一个新的 Angular 版本。 Vue.js 就是这样一个例子。
微前端与相关微服务结合使用,以解决开发团队通常在单体应用中遇到的问题。 该策略具有以下优点。
- 技术自由:前端工程师可以根据公司的需求选择替代的 JavaScript 框架、运行时环境和整个技术堆栈。 在过时的架构之上,可能会应用一个新的框架。
- 由于每个微前端都是独立的,可以单独开发、测试、部署和升级,因此可以实现更大程度的灵活性。 因此,如果一个团队正在开发一个特性并且已经推送了一个错误修复,而另一个团队必须添加自己的特性,他们不需要等待第一个团队完成他们的任务。
- 自治团队和系统:每个产品团队以及每个功能都可以在几乎不依赖其他团队的情况下运行,即使附近的组件不可用,它也能继续工作。
- 多个更小的代码库:每个微前端都有自己的、更易于管理、更小的代码库。 更少的人会专注于特定的 UI 组件、简化代码审查并改善整体组织。
- 简单的应用程序扩展:微前端的另一个好处是能够单独扩展每个功能。 与单体应用相比,每次添加新功能时都必须扩展整个程序,这使得整个过程在时间和金钱方面都更加高效。
微前端如何工作?
正如我们之前所说,团队在微前端架构中是垂直组织的,这意味着他们被领域知识或目的分开,并从头到尾对特定产品负责。
它可以有一个或两个后端微服务以及一个小型前端。 更详细地,让我们检查一下这个视觉元素的特征、与其他 UI 组件的交互以及与主页的结合。
微前端可以
- 整个页面(例如,产品详细信息页面)或
- 其他团队可以使用的页面部分,例如页眉、页脚和搜索栏。
您可以将一个大型网站划分为多种页面类型,并将每种类型分配给特定的员工进行处理。
但是,多个页面上经常出现多个组件,例如页眉、页脚、建议块等。例如,建议块可以包含在主页、产品详细信息页面甚至结帐页面上。
从本质上讲,团队可以创建其他团队可以在他们的页面上使用的片段。
然而,微前端可以作为不同的项目单独部署,而不是可重用组件。
所有这些听起来都很棒,但是要创建一个统一的界面,页面和片段必须以某种方式组合在一起。
这需要前端集成,可以通过多种策略来实现,包括路由、组合和通信(见上图)。
路由
当需要来自一个团队控制的页面的服务来访问另一个团队拥有的页面时,路由对于页面级集成很有用。
每个微前端都作为单页应用程序处理。 简单的 HTML 链接可用于提供路由。
用户可以强制浏览器从服务器下载目标标记并通过单击超链接将当前页面替换为新页面。
应用程序外壳是支持 UI 的 HTML、CSS 和 JavaScript 的最低限度。 即使从服务器请求的内容数据仍在等待,用户也会立即收到一个静态显示的页面。 中央应用程序外壳用作各个团队创建的单页应用程序的父应用程序。
无论使用什么库或框架,元框架都可以将各种页面融合为一个页面。
组成成分
构图是排列碎片以使其适合页面上适当空间的过程。 在大多数情况下,部署页面的团队不会立即获取片段的内容。
相反,它会在片段应该在标记中的位置放置一个占位符或标记。
使用不同的组合过程,完成最终的组装。 该组合可以分为两个基本类别:客户端和服务器端。
客户端组合:网络浏览器用于创建和编辑 HTML 标记。 每个微前端都能够独立于页面的其余部分更改和显示其标记。
例如,Web Components 允许您执行这种类型的构造。
计划是将每个片段变成一个 Web 组件,可以作为 a.js 文件独立安装,之后应用程序可以在主题布局中为它们指定的空间中加载和呈现它们。
Web 组件依赖于其他前端框架可以使用的 HTML 和 DOM API,以及通过 props 和事件发送和接收数据的标准方法。
服务器端组合:通过这种设计,UI 部分在服务器上进行组合,从而将完整的页面发送到客户端,从而加快加载速度。
组装通常由位于 Web 浏览器和 Web 服务器之间的单独服务执行。 CDN 是服务(内容交付网络)的一个实例。
您可以根据自己的需要选择一种或两种组合。
微前端通信模式
当各种组件之间几乎没有交互时,微前端架构效果最好。 微前端有时需要相互交谈并共享信息。 以下是一些可能导致这种情况的潜在模式。
- 网络工作者:在线工作者是一种机制,它使 Web 内容能够在后台运行 JavaScript,独立于其他脚本,并且不会影响页面的速度。 将为每个微应用提供一个独特的工作者 API。 这样做的好处是可以在不同的线程中完成耗时的工作,从而使 UI 线程能够继续进行而不会减慢或停止。
- 事件发射器:在这种情况下,许多组件通过侦听和操作它们订阅的组件中的任何状态更改来相互通信。 订阅了该特定事件的其他微前端会在微前端触发该事件时做出响应。 已在每个微前端中引入的事件发射器使这成为可能。
- 回调和道具:在本节中,您定义了一个父组件和子组件。 通信被组织成树状结构。 父组件利用 props 将数据作为函数沿着组件树传递给子组件。 反过来,孩子可以通过响应回调来有效地在他们的状态发生任何事情时提醒父母。 React 采用了这种模式。
微前端的优点
快速自治团队的发展
使用微前端方法时,独立团队可以创建 Web 应用程序或网站的每个部分。
每个团队都是完全自主的,这意味着它负责整个组件开发周期,从概念到发布和后期制作。
此外,这意味着各个团队可以在同时处理同一个项目的同时无缝协作。
因此,发布周期比前端单体应用要快得多。
单个微前端的较小代码库导致代码更简洁
单体前端拥有庞大、笨拙的代码库,随着时间的推移,这些代码库变得越来越混乱和难以管理。
微前端解决了这个问题。 每个微前端的源代码更小、更简单、更紧凑,因此更易于管理。
因此,整个 Web 解决方案受益于更简洁的代码。
由于松散耦合,提高了应用程序的稳定性
一个 Web 解决方案很少能被分成完全独立的部分。 因此,微前端确实可以相互交流。
然而,尽管连接松散,组件之间的每个链接都很重要。
一个组件的故障对所有其他组件的运行几乎没有影响,这提供了 Web 解决方案的增强稳定性。
测试单个功能变得更简单
这种好处源于微前端的特性。 基于这种架构设计,Web 解决方案的客户端是模块化的,每个模块都是自治的。
因此,对一个团队来说,单独评估一小部分用户界面比测试一个庞大的单体更容易。
减少捆绑包大小导致更快的页面加载
在功能丰富的单体 Web 系统中,延迟加载时间的主要原因之一是 JavaScript 包的大小。 另一方面,微前端方法可以更轻松地减少页面加载时间。
浏览器不必重复下载不需要的代码,因为一个网页是由几个小包组成的。 因此,页面性能和加载时间都会增加。
技术独立
多 前端框架 开发人员可以使用它来创建具有微前端架构的单一在线解决方案。
由于每个组件都是自主的,因此可以使用最适合团队任务的任何技术来构建它。
当然,程序员在为他们负责的软件项目选择框架时应该谨慎,并且仍然强烈建议与其他团队协商。
但是,在应用程序的生命周期内,您被迫使用旧框架的可能性为零。
微前端的缺点
完整的复杂 Web 解决方案测试
当使用微前端架构时,测试 Web 解决方案的各种模块很容易。 但是,它不同于评估整个 Web 应用程序。
在继续之前验证所有部件是否按预期工作。 这可能很困难,因为微前端独立运行并具有单独的交付流程。
昂贵的初始投资
微前端开发通常需要大量的财务支出。 组建和维持许多前端团队的成本很高。
此外,您需要管理人员来组织工作,确保一切协调一致,并保证良好的团队沟通。
开发和部署的复杂性
由于微前端设计,开发和部署过程可能会变得更加复杂。
例如,在同一项目上工作的独立开发团队可能会使解决方案包含过多的组件,这可能会导致部署阶段出现问题。
正确组装所有模块并将它们顺利集成到整体方案中也并不总是那么简单; 这项工作通常需要彻底了解所有依赖项。
保持用户体验一致性的问题
当团队在软件的多个部分单独工作时,保持一致的用户界面是一项挑战。
Web 解决方案应该由项目的所有开发人员共享。 否则,沿途可能会出现很多矛盾。
结论
微前端,一种当代的架构设计,可以极大地提升基于微服务的大型 Web 开发项目的性能。
它使程序员能够将完整的解决方案划分为可以由多个自治团队创建的离散部分。 这带来了许多好处,包括更快的功能推出、更轻松的单个模块测试以及更无缝的升级。
但是微前端也存在一些困难。
例如,应用程序的综合测试可能具有挑战性。
此外,由于需要一个庞大的工程师和管理员团队,微前端项目非常昂贵。
因此,在做出决定之前,您必须考虑业务案例的所有组成部分。
弗拉基米尔·卡马吉
不知何故,我不明白前端各个组件之间的通信是根据什么原理进行的。 我不明白您希望如何连接在不同框架中创建的组件。 文章中没有任何相关内容。 对我来说,事件和听众的系统就像人间地狱。 我们应该如何想象呢?