BFF架构：优化前后端协作设计模式
BFF架构：优化前后端协作设计模式
BFF（Backends For Frontends）架构是一种介于前端和后端之间的通信设计模式，旨在优化前后端协作效率。通过聚合服务数据、降低耦合度、增强性能和安全性，BFF架构为现代软件开发提供了一种新的解决方案。本文将深入探讨BFF架构的核心概念、应用场景及其优缺点。
BFF架构：优化前后端协作设计模式
BFF是什么
BFF即 Backends For Frontends (服务于前端的后端)。这是一种介于前端和后端之间的重要通信设计模式。它旨在解决前端与后端协作中的低效问题，结合正向和逆向信息架构，灵活组合任务，降低人员维护和开发成本，优化体验并改变已有的产品迭代模式。
背景
行业现象：
在日常的业务开发中，后端同学在定义微服务接口时，为了保证接口的通用性，往往不希望把接口设计为专门供某个页面或系统使用。这种情况下，前端往往需要处理大量的数据转换、组合和过滤操作，导致前端代码变得复杂难以维护。公司现状：
在很多项目存在单页面调用大量零散接口拼接数据展示；一些功能页面太过零散；新入职和转岗员工权限角色快速授权运维问题，以及应用交互定制化必须后端服务开发介入的情况等
解决什么问题
- 降低前后端耦合：简化前后端开发和代码量，允许前后端团队独立迭代
- 聚合服务数据：避免前端直接调用过多后端服务接口导致项目复杂性提升
- 个性化定制：传统服务端业务逻辑处理迭代不堪重负。自定义输出不够灵活
- 增强服务性能和系统安全：可通过缓存、预拉取数据等方式减少服务请求；收拢统一处理身份验证、权限前端处理逻辑
- 多语言开发和稳定迭代：常见的java、nodejs、Python、php开发迭代，云函数发版保障系统更稳定
聚合优化API问题
- 前后端耦合较深：存在不能独立发版，相互依赖
- API不够简易清晰：设计API应当遵循一致性和可扩展性原则，简单易懂提供给开发者用来匹配业务需求
- 定制化需求不够灵活：增加开发灵活度，简化前后端开发和代码量
性能和安全问题
- 服务请求较多：可通过缓存、预拉取数据等方式减少服务请求
- 聚合服务数据：收纳接口，底层数据调用处理。减少前后端交互逻辑处理
- 热更新迭代：不同于传统后端服务发版过程中导致服务不可用的时间内影响业务使用
- 统一鉴权和防护：BFF层统一处理安全逻辑，保护数据安全，简化前端应用的安全处理，拦截脚本攻击和内容不合法数据的输入
扩展性问题
- 多语言开发：现存后端接口基本上主要以java为主，但BFF支持Node.js、Java、Python等，一些低频、简易业务场景可以交付前端node来维护开发
- 统一监控日志处理：预置监控和日志记录，帮助发现和解决问题，同时提供有用的性能数据和统计信息
如果当系统中存在这些的情况，依赖传统开发对接模式，只会造成对业务业务逻辑越来越繁重，历史技术债更加突出。解耦部分服务端业务处理，让底层服务能力更纯粹单一。BFF解决逻辑处理各种自定义业务需求，简化各个流程，提升系统稳定性。
怎么解决
当了解BFF要解决的业务痛点后，接着了解BFF究竟是如何解决的。
传统通用模式
采用【正向的信息架构模式】，建立严谨的功能分类标准和线性流程逻辑来支持业务的需求
- 不同的客户端请求同一个网关后，分别重定向到为对应客户端设计的 API 服务中。
- 每个 API 服务基本上只能针对一种客户端，所以它们可以对特定的客户端进行专门优化，响应速度还比通用的 API 服务更快（因为它不需要判断不同客户端的逻辑）。
- 每种客户端还可以实现自己发布，不需要再跟着其他客户端一起排期。
缺点：
在复杂中后台的场景下，这种叙事方式将每个最小的任务事件以架构的方式天然被组合或被隔离，当两个事情在某个场景，或者规则发生变化而需要建立联系时，两个事件需要变成一个闭环事件时，但是又被架构隔离。导致：
- 各个应用程序内提供的接口是有业务针对性开发，很难适用其他系统应用
- 高度耦合，各业务组各自为战，造成一定重复功能开发和资源浪费
BFF协作模式
泳道图说明
售后业务BFF泳道图示例
场景案例简述
案例：老项目问题
描述
订单查询功能在很多系统内有使用，依A系统的订单详情页和B系统订单详情页为例：
底层数据源是一样的，各自业务组开发对应服务接口，最终返回的内容大体相同。重复开发、联调、测试造成资源的浪费。高耦合的服务不利于后期迭代维护，导致两个业务组都需要投入相应人员。且无法提供给其他业务组和项目使用。
BFF解决方案
- 服务端开发底层功能和API
- BFF聚合API实现业务功能，解耦前后端逻辑关系
- 减少人员的投入和时间
案例：运维问题
描述
- 新员工，如何一键给新员工A赋相同人员B的角色权限功能？
- 离职人员，如何快速一键操作关闭用户各类权限、vpn、账号等工作？
BFF解决方案
- 定制化处理相关服务，组合处理形成全新的功能API
- 传统后端开发不介入下，前端开发人员也能独立支持业务需要
案例：新需求支持
描述
业务组定制流程工作台中BFF能做哪些事，比如业务工作台？
BFF解决方案
- 集成统计任务数据：聚合业务组原项目内数据API，形成统一接口给客户端使用，简化对接过于繁杂
- 老接口适配：人员身份分类问题可用BFF基于group/userGroupTreeData处理，返回用户所在部门和组信息
- 定制化新API：个人常用功能信息存储，BFF直接增删查改数据库维护
最佳实践场景分析
首先要明确哪些场景需要适合BFF模式？任何模式和框架都有各自的局限性，BFF也不例外。在实际开发中，哪些场景和业务需求是最佳方案？
- 多个数据整合统一，提供前端应用所需完整api，避免直接调用过多后端服务接口的复杂性
- 自定义定制服务，避免灵活业务导致后端底层服务接口频繁改动，以及适配不同业务场景
- 统一鉴权、非法输入拦截等XSS等数据安全处理
- 轻业务形架构模式快速响应，让后端更专注底层服务能力的构建，灵活支持业务需求
通过架设BFF逻辑层处理，解决不同业务模式之间的耦合问题，提高代码的可维护性，灵活支持业务定制需求。
局限性
增加微小延迟
BFF是在传统客户端和服务API之间的额外处理服务，对比前端发起的多个请求，中间层服务转发处理相对来说会有微小的服务延迟，但同时也会减少前端逻辑处理时间
增加系统复杂度
相较于传统后端服务+网关+前端的模式。BFF将多存在一个链路和代码，变成：后端服务+BFF+网关+前端或者 后端服务+网关+BFF+网关+前端模式，抽离后的链路无疑会增加系统复杂度
边界责任易混乱
每个人对一个技术认知是不同的。需要明确前端、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行为。
参考文档：
- 基于 Node.js 的 Serverless 架构实践
- 微服务 BFF 架构设计
- BFF 模式介绍
- 我们应该如何理解BFF架构设计？
- BFF治理与优化实践
- 打破传统叙事逻辑，构建基于原子化任务的人机交互