BFF：优化前后端协作设计模式

BFF是什么

BFF即 Backends For Frontends (服务于前端的后端)。是一种介于前端和后端之间一种重要的通信设计模式。它旨在解决前端与后端协作中的复杂性问题。

背景

行业背景：传统前端应用（如Web应用、移动应用等）直接与后端API通信，这种情况下，前端往往需要处理大量的数据转换、组合和过滤操作，导致前端代码变得复杂难以维护
企业现状：根据具体情况梳理

解决什么问题

降低前后端耦合，简化前后端开发和代码量，允许前后端团队独立迭代
聚合服务数据，避免前端直接调用过多后端服务接口复杂性
个性化定制，传统服务端业务逻辑处理迭代不堪重负。自定义输出不够灵活
增强服务性能，可通过缓存、预拉取数据等方式减少服务请求
增强系统安全性，收拢统一处理身份验证、权限前端处理逻辑
支持多语言开发，服务发版影响线上业务操作

问题梳理

1. 耦合性问题

前后端耦合较深：存在不能独立发版，相互依赖
清晰功能API：设计API应当遵循一致性和可扩展性原则，简单易懂提供给开发者用来匹配业务需求
灵活定制化需求：增加开发灵活度，简化前后端开发和代码量

2. 性能问题

减少服务请求：可通过缓存、预拉取数据等方式减少服务请求
聚合服务数据：收纳接口，底层数据调用处理。减少前后端交互逻辑处理
无热更新：不同于传统后端服务发版过程中导致服务不可用的时间内影响业务使用

3. 安全问题

统一鉴权和验证：BFF层统一处理安全逻辑，保护数据安全，简化前端应用的安全处理。
拦截脚本攻击：统一拦截处理输入的接口内容的合法性，实现脚本拦截和异常数据处理

4. 扩展性问题

支持多语言扩展：现存后端接口基本上主要以java为主，但BFF支持Node.js、Java、Python等，一些低频、复杂场景需求可以交付前段来维护开发
统一监控日志处理：预置监控和日志记录，帮助发现和解决问题，同时提供有用的性能数据和统计信息
持续扩展优化投入大：保持BFF高效和可维护性，通过监视性能、定期更新技术栈、重构代码和修复缺陷等方式来实现

如果当系统中存在这些的情况，依赖传统开发对接模式，只会造成对业务业务逻辑越来越繁重，历史技术债更加突出。解耦部分服务端业务处理，让底层服务能力更纯粹单一。BFF解决逻辑处理各种自定义业务需求，简化各个流程，提升系统稳定性。

怎么解决

当了解BFF要解决的业务痛点后，接着了解BFF究竟是如何解决的。

1. 定位场景

首先要明确哪些场景需要适合BFF模式？任何模式和框架都有各自的局限性，BFF也不例外。在实际开发中，哪些场景和业务需求是最佳方案？

多个数据整合统一，提供前端应用所需完整api，避免直接调用过多后端服务接口的复杂性
自定义定制服务，避免灵活业务导致后端底层服务接口频繁改动，以及适配不同业务场景
统一鉴权、非法输入拦截等XSS等数据安全处理
轻业务形架构模式快速响应，让后端更专注底层服务能力的构建，灵活支持业务需求

通过架设BFF逻辑层处理，解决不同业务模式之间的耦合问题，提高代码的可维护性，灵活支持业务定制需求。

2. 使用BFF架构

传统模式

在这里插入图片描述

从上图可以看到：不同的客户端请求经过同一个网关后，它们都将分别重定向到为对应客户端设计的 API 服务中。因为每个 API 服务只能针对一种客户端，所以它们可以对特定的客户端进行专门优化。而去除了兼容逻辑的 API 显得更轻便，响应速度还比通用的 API 服务更快（因为它不需要判断不同客户端的逻辑）。

除此之外，每种客户端还可以实现自己发布，不需要再跟着其他客户端一起排期。

此时的方案挺完美了吧？还不完美，因为上面的方案属于一个通用架构。在实际业务中，我们还需要结合实际业务来定，下面我们深入说明一下实际业务需求。

前面我们列出了 5 种服务，实际上，整个供应链系统将近有 100 种服务。因为它是一个非常庞大的系统，且整个业务链条的所有工作都包含在这个系统中，比如新零售、供应链、财务、加盟商、售后、客服等，，这就需要几百号研发人员同时进行维护。

因为我们共同维护一个 App、PC 界面、新零售、售后、加盟商，还有各自的小程序和 H5，所以为了实现业务解耦和分开排期，每个部门需要各自维护自己的 API 服务，而且 App 与 PC 前端也需要根据部门实现组件化，此时的架构如下图所示。

BFF模式

在这里插入图片描述

归纳

在这里插入图片描述

3. 逻辑案例

在这里插入图片描述

BFF局限性

1. 增加微小延迟

BFF是在传统客户端和服务API之间的额外处理服务，对比前端发起的多个请求，中间层服务转发处理相对来说会有微小的服务延迟，但同时也会减少前端逻辑时间。

2. 增加系统复杂度

相较于传统后端服务+网关+前端的模式。BFF将多存在一个链路和代码，变成：后端服务+BFF+网关+前端或者后端服务+网关+BFF+网关+前端模式，抽离后的链路无疑会增加系统复杂度

3. 边界责任易混乱

每个人对一个技术认知是不同的。需要明确前端、BFF、后端服务三者的定位、职责、界限，以及相应的设计和编码规范。警惕业务逻辑无脑往BFF服务蔓延，不进行深入深入思考会将前后端责任划分容易混乱，造成BFF写入不必要的代码逻辑

设计原则

要构建一个高效的BFF，需要遵循一些设计原则，以确保其可维护性、可扩展性和性能。以下是一些关键的设计原则：

单一职责原则（Single Responsibility Principle）
BFF应该具有单一职责，即它只负责处理前端的请求和响应，不应该包含过多的业务逻辑。这有助于保持BFF的简洁性和可维护性。
API精细化
BFF应该提供精细化的API，每个API端点都应该对应一个特定的前端页面或组件。这有助于减少前端不必要的数据获取和减小数据传输的大小。
数据聚合与转换
BFF应该负责聚合来自多个后端服务的数据，并进行必要的数据转换，以满足前端的需求。这可以减少前端的数据处理工作，提高性能。
安全性
BFF应该负责实施安全性控制，包括身份验证和授权。它应该确保前端只能访问其有权访问的资源。
性能优化
BFF应该采取措施来优化性能，例如缓存、异步处理等。这可以减少前端应用的等待时间，提升用户体验。
版本管理
BFF应该支持API版本管理，以确保前端应用可以平稳升级而不受影响。

使用原则

多端应用
设计API时要考虑不同设备应用的需求，也就是为不同的设备提供不同的API，虽然他们可能会实现相同的工鞥，但因为不同系统、业务组、设备的特殊性，他们对服务端的API访问会各有特点，需要区别处理
聚合服务
同类的业务流程被拆分到不同的服务和业务组中，这在增加业务灵活性的同时，也让前端的调用变得复杂。BFF的出现为前端应用提供一个对业务服务的聚合API，减少复杂服务的调用链，让前端聚焦处理所需的数据，后端专注开发底层服务能力。减少前后端底层数据对接造成频繁改动的成本。
非必要不新增
BFF带来数据交互的好处同时，要注意它所带来代码重复和工作量增加方面的问题。如果有BFF功能类似，逻辑处理大致相同的服务API，一定要谨慎对待BFF行为。