第 9 章 微前端的后端模式 微前端的后端模式
本作品已使用人工智能进行翻译。欢迎您提供反馈和意见:translation-feedback@oreilly.com
你可能会认为,微前端只有在与微服务相结合时才可能是 ,因为我们可以拥有端到端的技术自主权。也许你会认为,你的单体架构永远不会支持微前端,甚至认为在 API 层上采用单体就意味着在前端也要照搬架构。 但事实并非如此。有几个细微差别需要考虑,微前端绝对可以与微服务和单体结合使用。
在本章中,我们将回顾前端层和后端层之间的一些可能集成。尤其是,我们将分析微前端如何与单体、微服务,甚至与后端换前端(BFF)模式结合使用。
此外,我们还将讨论与不同微前端实现集成的最佳模式,如垂直拆分、与客户端组合的水平拆分以及与服务器端组合的水平拆分。
最后,我们将探讨 GraphQL 如何作为 API 的单一入口,成为微前端的有效解决方案。
API 集成和微前端
让我们先来定义一下我们可能在网络应用中使用的不同 API 方法。如图 9-1 所示,我们将重点关注最常用和最著名的模式。
但这并不意味着微前端只能使用这些实现。例如,您可以为 WebSocket(通过单个 TCP 连接的双向计算机通信协议)或超媒体选择合适的方法。在超媒体的情况下--例如,在响应内容中使用带有超媒体链接的 REST--消费 API 的客户端可以通过遍历这些链接动态导航到相应的资源。关键是要学会如何使用 BFF、API 网关或服务字典模式。
图 9-1. 微前端和 API 层
本章我们将分析三种模式:
- 服务字典
-
服务字典只是供客户端使用的服务列表。它主要是在我们用单体或模块化单体架构开发 API 层时使用;不过,它也可以用带 API 网关的微服务架构等其他架构来实现。服务字典避免了在持续集成(CI)过程中创建共享库、定义环境变量或注入配置的需要,也消除了对前端代码库中所有端点进行硬编码的要求。当微前端加载时,字典会首次加载,允许客户端直接从服务字典中检索要使用的 URL。
- API 网关
-
众所周知,在微服务社区,API 网关是微服务架构的单一入口。客户端可以通过一个网关使用微服务内部开发的 API。API 网关还能实现一系列功能的集中化:
- 令牌验证,需要在将请求传递给微服务之前验证令牌的签名
- 可视性和报告,我们有一个集中的手段来验证所有入站和出站流量
- 速率限制:API 网关会在超过特定阈值后拒绝请求,例如,将来自客户端的请求设置为每秒 100 个,因此当超过阈值时,API 网关会返回错误,而不是调用微服务来满足请求。
- BFF
-
BFF 是 API 网关模式的扩展,为每种客户类型创建了一个单一入口。例如,我们可以为网络应用程序建立一个 BFF,为移动设备建立另一个 BFF,为我们正在商业化的物联网(IoT)设备建立第三个 BFF。BFF 减少了客户端和服务器之间的对话,聚合 API 响应并返回一个简单的数据结构,供客户端解析并在用户界面内呈现。这样就能在很大程度上自由塑造专用于客户端的 API,并减少客户端与后端层之间的往返次数。
这些模式也不是相互排斥的,它们可以组合在一起工作。
值得一提的另一种可能性是为客户端编写 API 端点库。不过,我不鼓励在微前端中采用这种做法,因为我们有可能在某些微前端中嵌入较旧版本的库,因此,用户界面可能会出现一些问题,比如信息过时,甚至由于某些 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access