通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

前端模式的后端

此模式介绍如何将后端服务与前端实现分离，以便为不同的客户端接口定制体验。 若要避免自定义提供多个接口的后端，此模式非常有用。 此模式基于由 Sam Newman 提出的前端反向代理模式。

上下文和问题

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

展示后端为前端模式上下文和问题的体系结构图。

后端服务经常遇到来自多个前端系统的竞争需求。 这些需求会导致频繁更新和潜在的开发瓶颈。 发生冲突的更新和保持兼容性的需求会导致对单个可部署资源产生过多的需求。

让单独的团队管理后端服务可以在前端和后端团队之间创建断开连接。 这种断开连接可能会导致在达成共识和平衡要求时出现延迟。 例如，在集成之前，必须先与其他前端团队验证一个前端团队请求的更改。

解决方案

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

此模式可自定义特定接口的客户端体验，而不会影响其他接口。 它还优化性能以满足前端环境的需求。 由于每个 BFF 服务比共享后端服务更小、更复杂，因此它可以使应用程序更易于管理。

前端团队独立管理自己的 BFF 服务，从而控制语言选择、发布节奏、工作负荷优先级和功能集成。 这种自主性使他们能够在不依赖于集中式后端开发团队的情况下高效运行。

许多 BFF 服务传统上依赖于 REST API，但 GraphQL 实现正在成为替代方法。 使用 GraphQL，查询机制无需单独的 BFF 层，这是因为它允许客户端无须依赖于预定义终结点就能请求所需的数据。

展示前端后端模式的架构图。

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

问题和注意事项

  • 根据相关成本来评估服务的最佳数量。 维护和部署更多服务意味着增加运营开销。 每个服务都有自己的生命周期、部署和维护要求和安全需求。

  • 添加新服务时，请查看服务级别目标。 延迟可能会增加，因为客户端未直接访问您的服务，新服务引入了额外的网络跳跃点。

  • 当不同的接口发出相同的请求时，评估是否可以将请求合并到单个 BFF 服务中。 在多个接口之间共享单个 BFF 服务可能会导致每个客户端的不同要求，这会使 BFF 服务的增长和支持复杂化。

    代码重复可能是此模式的结果。 评估代码重复与针对每个客户端的更定制体验之间的权衡。

  • BFF 服务应仅处理与特定用户体验相关的特定于客户端的逻辑。 应抽象化跨领域功能（如监视和授权），以保持效率。 BFF 服务中可能出现的典型功能使用 守护、 速率限制和 路由 模式单独处理。

  • 考虑学习和实现此模式如何影响开发团队。 开发新的后端系统需要时间和精力，这可能会导致技术债务。 维护现有后端服务会增加此挑战。

  • 评估是否需要此模式。 例如，如果你的组织将 GraphQL 与前端特定解析程序一起使用，BFF 服务可能不会为应用程序增加价值。

    另一种方案是将 API 网关 与微服务相结合的应用程序。 对于通常建议使用 BFF 服务的一些方案，此方法可能已经足够了。

何时使用此模式

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

  • 共享或通用用途后端服务需要大量的开发开销来维护。

  • 你想要针对特定客户端接口的要求优化后端。

  • 对常规用途后端进行自定义以适应多个接口。

  • 编程语言更适用于特定用户界面的后端，但不适用于所有用户界面。

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

  • 接口向后端发出相同或类似的请求。

  • 只有一个接口与后端交互。

工作负荷设计

评估如何在工作负荷的设计中使用前端后端模式来解决 Azure Well-Architected Framework 支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。

支柱 此模式如何支持支柱目标
可靠性 设计决策有助于工作负荷在发生故障后 复原 ，并确保它在发生故障后 恢复到 正常运行状态。 将服务隔离到特定的前端接口时，可以控制故障。 一个客户端的可用性不会影响另一个客户端访问的可用性。 以不同的方式处理各种客户端时，可以根据预期的客户端访问模式确定可靠性工作的优先级。

- RE:02 关键流
- RE:07 自我保护
安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 此模式中引入的服务分离允许根据每个客户端的特定需求自定义服务层中的安全性和授权。 此方法可以减少 API 的接口暴露范围，并限制可能暴露不同功能的后端之间的横向流动。

- SE:04 分段
- SE:08 强化资源
通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 通过后端分离，可以采用共享服务层可能无法实现的方式进行优化。 以不同的方式处理单个客户端时，可以针对特定客户端的约束和功能优化性能。

- PE:02 容量规划
- PE:09 关键流

如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。

示例：

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

  • 授权。 确保只有具有正确访问令牌的已验证标识才能使用具有 Microsoft Entra ID 的 API 管理来调用受保护的资源。

  • 监测。 捕获请求和响应详细信息并将其发送到 Azure Monitor 以实现可观测性目的。

  • 请求缓存。 通过 API 管理的内置功能提供来自缓存的响应来优化重复的请求。

  • 路由和聚合。 将传入请求定向到相应的 BFF 服务。

每个客户端都有一个作为 Azure 函数运行的专用 BFF 服务，该服务充当网关和基础微服务之间的中介。 这些特定于客户端的 BFF 服务可确保为分页和其他功能定制体验。 移动应用优先考虑带宽效率，并利用缓存来提高性能。 相比之下，桌面应用程序在单个请求中检索多个页面，从而创建更沉浸式的用户体验。

显示 Azure BFF 服务体系结构的示意图，其中显示了 API 管理处理交叉问题。移动和桌面平台通过 BFF 服务中特定于客户端的 Azure Functions 检索数据。

来自移动客户端的第一页请求的流 A

  1. 移动客户端发送请求以获取页面 GET，并在授权标头中包含 OAuth 2.0 令牌。

  2. 请求会到达 API 管理网关，该网关会截获它并：

    1. 检查授权状态。 API 管理会深入实现防御，因此它会检查访问令牌的有效性。

    2. 将请求活动作为日志流式传输到 Azure Monitor。 记录请求的详细信息用于审核和监视。

  3. 强制执行策略，然后 API 管理会将请求路由到 Azure 函数移动 BFF 服务。

  4. 然后，Azure 函数移动 BFF 服务与必要的微服务交互，提取单页并处理请求的数据以提供轻量级体验。

  5. 响应将返回到客户端。

第一页来自移动客户端的缓存请求流 B

  1. 移动客户端再次发送对页面GET的相同1请求，包括授权标头中的 OAuth 2.0 令牌。

  2. API 管理网关识别出此前已经发出过该请求，并且：

    1. 政策已被执行。 然后，网关标识与请求参数匹配的缓存响应。

    2. 立即返回缓存的响应。 此快速响应无需将请求转发到 Azure 函数移动 BFF 服务。

来自桌面客户端的第一个请求的流 C

  1. 桌面客户端首次发送请求 GET ，包括授权标头中的 OAuth 2.0 令牌。

  2. 请求会到达 API 管理网关，其中会处理交叉问题。

    1. 授权： 始终需要令牌验证。

    2. 流式传输请求活动： 请求详细信息记录为可观测性。

  3. 强制实施所有策略后，API 管理会将请求路由到 Azure 函数桌面 BFF 服务，该服务处理数据密集型应用程序处理。 桌面 BFF 服务先通过调用基础微服务来聚合多个请求，然后以多个页面的形式向客户端响应。

设计

  • Microsoft Entra ID 充当基于云的标识提供者。 它为移动客户端和桌面客户端提供定制的受众声明。 然后，这些声明用于授权。

  • API 管理 充当客户端与其 BFF 服务之间的代理，用于建立外围。 API 管理配置了策略来 验证 JSON Web 令牌 ，并拒绝缺少令牌或包含目标 BFF 服务的无效声明的请求。 它还将所有活动日志流式传输到 Azure Monitor。

  • Azure Monitor 充当集中式监视解决方案。 它聚合所有活动日志，以确保全面的端到端可观测性。

  • Azure Functions 是一种无服务器解决方案，可有效地跨多个终结点公开 BFF 服务逻辑，从而简化开发。 Azure Functions 还可以最大程度地减少基础结构开销，并帮助降低运营成本。

后续步骤