前端模式的后端：一种优化现代软件架构的设计模式

前端模式的后端：一种优化现代软件架构的设计模式

在现代软件架构中，如何平衡不同前端接口的需求与后端服务的开发效率是一个重要挑战。"前端模式的后端"（Backends for Frontends，简称BFF）模式提供了一种解决方案，通过为每个前端接口定制专门的后端服务，实现更灵活和优化的系统设计。本文将详细介绍这一模式的背景、解决方案、适用场景以及具体的工作负荷设计。

上下文和问题

请考虑最初使用桌面 Web UI 和相应的后端服务设计的应用程序。 随着业务要求随时间的变化，添加了移动接口。 这两个接口都与同一后端服务交互，但移动设备的功能与桌面浏览器在屏幕大小、性能和显示限制方面有很大的不同。

后端服务通常面临来自不同前端的竞争需求，从而导致开发过程中频繁的更改和潜在瓶颈。 发生冲突的更新和保持兼容性的需要会导致单个可部署资源过度工作。

让单独的团队管理后端服务可以在前端和后端团队之间创建断开连接，从而延迟获得共识和平衡要求。 例如，在集成之前，必须先与其他前端团队验证一个前端团队请求的更改。

解决方案

引入仅处理特定于接口的要求的新层。 此层称为后端 for-frontend （BFF） 服务，位于前端客户端和后端服务之间。 如果应用程序支持多个接口，请为每个接口创建 BFF 服务。 例如，如果你有 Web 界面和移动应用，则为每个服务创建单独的 BFF 服务。

此模式为特定接口定制客户端体验，而不会影响其他接口。 它还微调性能，以最符合前端环境的需求。 由于每个 BFF 服务较小且不太复杂，因此应用程序在一定程度上可能会获得优化优势。

前端团队在自己的 BFF 服务上具有自主性，从而在语言选择、发布节奏、工作负荷优先级和功能集成方面具有灵活性，而无需依赖于集中式后端开发团队。

尽管许多 BF 依赖于 REST API，但 GraphQL 实现正在成为替代方法，这消除了 BFF 层的需求，因为查询机制不需要单独的终结点。

有关详细信息，请参阅模式：前端的后端。

问题和注意事项

• 评估最适合的服务数，因为这将产生相关的成本。 维护和部署更多服务意味着增加运营开销。 每个服务都有自己的生命周期、部署和维护要求和安全需求。
• 添加新服务时，请查看服务级别目标（SLO）。 延迟可能会增加，因为客户端未直接联系服务，并且新服务引入了额外的网络跃点。
• 当不同的接口发出相同的请求时，评估是否可以将请求合并到单个 BFF 服务中。 在多个接口之间共享单个 BFF 服务可能会导致每个客户端的不同要求，这会使 BFF 服务的增长和支持复杂化。
• 代码重复可能是此模式的结果。 评估代码重复与每个客户端的更定制体验之间的权衡。
• BFF 服务应仅处理与特定用户体验相关的特定于客户端的逻辑。 应抽象化跨领域功能（如监视和授权），以使 BFF 服务保持精简。 BFF 服务中可能出现的典型功能分别处理守护、速率限制、路由等。
• 在学习和实施此模式时，请考虑对开发团队的影响。 构建新后端需要时间和精力，在维护现有后端服务的同时，可能会产生技术债务。
• 评估是否需要此模式。 例如，如果组织将 GraphQL 与特定于前端的解析程序一起使用，BFF 可能不会向应用程序增加价值。
• 另一个示例是将API 网关与微服务相结合的应用程序。 对于以前建议使用 BFF 的一些情况，此方法可能已经足够了。

何时使用此模式

在以下情况下使用此模式：

• 必须保持共享或常规用途后端服务，且开发开销很大。
• 你想要针对特定客户端接口的要求优化后端。
• 对常规用途后端进行自定义以容纳多个接口。
• 编程语言更适用于特定用户界面的后端，但不适用于所有用户界面。

此模式可能不适用于以下情况：

• 当接口向后端发出相同或类似的请求时。
• 仅当一个接口用于与后端交互时。

工作负荷设计

架构师应评估前端模式的后端在工作负荷的设计中如何使用这些模式来解决 azure Well-Architected 框架支柱中涵盖的目标和原则。 例如：

支柱 此模式如何支持支柱目标
可靠性设计决策有助于工作负荷在发生故障后复原，并确保它在发生故障后恢复到正常运行状态。 具有特定于特定前端接口的单独服务包含故障，因此一个客户端的可用性可能会影响另一个客户端访问的可用性。 此外，以不同的方式处理各种客户端时，可以根据预期的客户端访问模式确定可靠性工作的优先级。-RE:02 关键流-RE:07 自我保护
安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 由于此模式中引入的服务分离，支持一个客户端的服务层中的安全性和授权可以针对该客户端所需的功能进行定制，从而可能会减少 API 的外围应用，以及可能公开不同功能的不同后端之间的横向移动。-SE：04 分段-SE:08 强化资源
性能效率通过在缩放、数据和代码方面进行优化， 帮助工作负荷高效地满足需求。 通过后端分离，可以采用共享服务层可能无法实现的方式进行优化。 以不同的方式处理单个客户端时，可以针对特定客户端的约束和功能优化性能。-PE:02 容量规划-PE：09 关键流

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

示例

此示例演示了具有两个不同的客户端应用程序的模式的用例：移动应用和桌面应用程序。 这两个客户端都与充当抽象层的 Azure API 管理（数据平面网关）交互，处理常见的交叉问题，例如：

• 授权– 确保只有具有正确访问令牌的已验证标识才能使用具有 Microsoft Entra ID 的 Azure API 管理（APIM）调用受保护的资源。
• 监视– 捕获和发送请求和响应详细信息，以便将可观测性目的发送到 Azure Monitor。
• 请求缓存– 使用 APIM 内置功能提供来自缓存的响应来优化重复的请求。
• 路由 & 聚合– 将传入请求定向到适用于前端（BFF）服务的相应后端。

每个客户端都有一个作为 Azure 函数运行的专用 BFF 服务，该服务充当网关和基础微服务之间的中介。 这些特定于客户端的 BFF 可确保为分页和其他功能定制体验。 虽然移动更具带宽意识的应用和缓存可提高性能，但桌面在单个请求中聚合多个页面，从而优化更丰富的用户体验。

该图分为四个不同的部分，说明请求、身份验证、监视和客户端特定的处理流。 在最左侧，两个客户端设备启动请求：一个针对高效带宽用户体验进行优化的移动应用程序，以及一个提供功能齐全的界面的 Web 浏览器。 箭头从这两个设备扩展到中心入口点，即 Azure API 管理网关，指示所有请求都必须通过此层。 在第二部分的虚线矩形中，该体系结构分为两个水平组。 左侧组表示 Azure API 管理，负责处理传入请求并确定应如何处理它们。 两个箭头从此数据平面网关向外扩展：一个指向Microsoft Entra ID，用于管理授权，另一个箭头指向负责日志记录和可观测性的 Azure Monitor。 此外，箭头从网关循环回到移动客户端，表示重复相同的请求时缓存的响应，从而减少不必要的处理。 虚线矩形中的右组侧重于根据发出请求的客户端类型定制后端响应。 它具有两个单独的前端后端客户端，这两个客户端都使用 Azure Functions 进行无服务器计算，一个专用于移动客户端，另一个专用于桌面客户端。 两个箭头从网关扩展到这些后端前端客户端，说明每个传入请求将转发到相应的服务，具体取决于客户端类型。 在此层之外，虚线箭头向右扩展，将后端前端客户端连接到处理实际业务逻辑的各种微服务。 若要可视化此图，请想象一个从左到右流，客户端请求从移动客户端和 Web 客户端移动到网关。 此网关在将身份验证委托给标识提供者并向下登录到监视服务时处理每个请求。 在此处，它会根据请求源自移动客户端或桌面客户端，将请求路由到相应的后端前端客户端。 最后，每个前端后端客户端将请求转发到专用微服务，这些微服务执行所需的业务逻辑并返回必要的响应。 如果缓存响应可用，网关将截获请求，并将存储的响应直接发送到移动客户端，从而阻止冗余处理。

流 A：移动客户端 - 第一页请求

2. 移动客户端向页面发送
   GET
   请求，
   1
   在授权标头中包含 OAuth 2.0 令牌。
3. 请求会到达 Azure APIM 网关，这会截获该网关并：
4. 检查授权状态 – APIM 实现深度防御，因此它会检查访问令牌的有效性。
5. 将请求活动作为日志流式传输到 Azure Monitor – 记录请求的详细信息进行审核和监视。
6. 强制执行策略，然后 Azure APIM 将请求路由到 Azure Function Mobile BFF。
7. 然后，Azure Function Mobile BFF 与必要的微服务交互，提取单个页面并处理请求的数据，以提供轻量级体验。
8. 响应将返回到客户端。

流 B：移动客户端 - 第一页缓存请求

2. 移动客户端为页面发送相同的
   GET
   请求，
   1
   再次在授权标头中包含 OAuth 2.0 令牌。
3. Azure APIM 网关可识别此请求之前和之前已发出：
4. 强制执行策略，并在之后标识与请求参数匹配的缓存响应。
5. 立即返回缓存的响应，无需将请求转发到 Azure Function Mobile BFF。

流 C：桌面客户端 - 第一个请求

2. 桌面客户端首次发送
   GET
   请求，包括授权标头中的 OAuth 2.0 令牌。
3. 请求会到达 Azure APIM 网关，处理类似的交叉问题：
4. 授权 – 始终需要令牌验证。
5. 流式传输请求活动 – 记录请求详细信息以便观察。
6. 强制实施所有策略后，Azure APIM 会将请求路由到 Azure Function Desktop BFF，后者负责处理数据密集型应用程序处理。 桌面 BFF 使用基础微服务调用聚合多个请求，然后再使用多个页面响应响应客户端。

设计

• Microsoft Entra ID充当基于云的标识提供者，为移动客户端和桌面客户端颁发定制受众声明，这些声明随后会用于授权。
• Azure API 管理充当客户端与其添加外围的 BBF 之间的代理。 它配置了策略来验证 JSON Web 令牌（JWT），拒绝在没有令牌的情况下到达的请求或声明对目标 BFF 无效。 此外，它还将所有活动日志流式传输到 Azure Monitor。
• Azure Monitor作为集中式监视解决方案，聚合所有活动日志，以确保全面、端到端的可观测性。
• Azure Functions是一种无服务器解决方案，可跨多个终结点无缝公开 BFF 逻辑，实现简化的开发、降低基础结构开销和降低运营成本。

后续步骤

• 模式：前端的后端