BFF (Backend for Frontend) 架构学习笔记

一、 什么是 BFF 架构？

• 全称: Backend for Frontend，即“服务于前端的后端”。
• 核心思想: 在前端（客户端）与后端（微服务）之间增加一个中间层。这个中间层是专门为某个特定的前端应用量身打造的后端服务。
• 技术实现: 通常由前端团队使用 Node.js 来构建，因为它能让前端开发者在自己熟悉的技术栈中完成开发。当然，也可以使用 Java 等其他后端语言实现。
• 目标用户: 主要应用于业务复杂、客户端类型多的大型公司或项目中。

---

二、BFF 架构解决的核心问题 (常见面试题)

BFF 主要解决两大经典场景下的痛点。

场景一：处理多端业务逻辑差异

1. 问题描述

当一个后端系统需要同时为多个客户端（如 PC 网页端、Mobile 移动端、iOS/Android App）提供服务时，不同客户端对数据的需求和业务逻辑往往是不同的。

2. 传统模式的痛点

• 后端逻辑臃肿: 如果直接在后端微服务中通过 if/else 判断客户端类型来兼容不同业务，会导致后端代码逻辑变得异常复杂、耦合度高，难以维护。
• 牵一发而动全身: 为了兼容移动端而修改某个接口，可能会无意中影响到 PC 端的功能，导致服务不稳定。

3. BFF 解决方案

• 引入中间层: 为每一种前端（或每一种类型的端）创建一个专属的 BFF 层。

  • PC 端请求 PC-BFF。
  • 移动端请求 Mobile-BFF。

• 职责划分:

  1. 客户端: 只与自己对应的 BFF 层进行通信。
  2. BFF 层: 接收来自特定客户端的请求，然后它作为客户端去请求后端的各个微服务。它负责处理该端特有的业务逻辑、数据聚合、裁剪和格式化，最后将最适合该端展示的数据格式返回。
  3. 后端微服务: 只提供原子化、标准化的数据接口，不再关心前端的类型和业务差异。

• 优势:

  • 关注点分离: 将多端差异化的逻辑从后端服务中剥离出来，实现了完美的隔离。
  • 提升迭代效率: 各个前端团队可以独立修改自己的 BFF 层，而不会影响到其他端和核心后端服务，使开发和维护更加高效、安全。

<br>

场景二：优化前端并发请求，提升性能

1. 问题描述

在一个复杂的页面中（如数据大屏），可能包含几十个图表，每个图表都需要通过独立的 API 请求来获取数据。

2. 传统模式的痛点

• 浏览器并发限制: 浏览器对同一个域名下的并发 TCP 连接数是有限制的（通常是 6 个）。
• 请求排队: 当页面同时发起大量（如 20 个）请求时，前 6 个会立即发出，而后续的请求则必须排队等待，直到前面的某个请求完成后才能继续。
• 用户体验差: 这种请求排队会导致页面整体加载时间变得非常长，出现数据迟迟刷不出来的卡顿现象。

3. BFF 解决方案

• 请求合并 (Aggregation):

  1. 前端: 将页面上所有图表需要的数据请求，打包成一个请求，发送给 BFF 层。这个请求包含了所有图表所需的参数。
  2. BFF 层:
     • 接收到这个聚合请求后，将其在服务端进行 拆分。
     • 并行地 向后端的各个微服务发送多个请求来获取数据。
     • 关键点: 服务器与服务器之间的通信 没有 浏览器那样的并发限制，可以瞬间发起大量请求。
  3. 数据聚合与返回:
     • BFF 层等待所有微服务的响应都返回后，将这些数据 组装成一个统一的、巨大的 JSON 对象。
     • 最后，将这个聚合后的数据 一次性 响应给前端。
  4. 前端: 收到这个完整的数据包后，将其分发给页面上的各个图表进行渲染。

• 优势:

  • 绕过浏览器限制: 将前端的 N 次请求优化为 1 次，从根本上解决了浏览器并发限制问题。
  • 提升加载性能: 大幅减少了网络请求的往返时间 (RTT)，显著加快了页面加载速度，优化了用户体验。

---

三、总结

BFF 架构是一个强大的设计模式，它充当了“适配器”和“协调者”的角色。

• 核心价值:
  1. 隔离差异: 优雅地处理多端业务逻辑的不同。
  2. 优化性能: 通过聚合请求，解决前端并发瓶颈。
• 本质: 它将原本属于后端但又与前端展示强相关的逻辑（数据裁剪、聚合、格式化），以及为了优化前端体验而产生的需求（请求合并），从通用后端服务中分离出来，形成一个更靠近前端的、可由前端掌控的服务层。