一、什么是BFF
BFF：Backends For Frontends（服务于前端的后端）。
BFF是一种Web架构，微服务设计系列丛书的作者 Sam Newman曾在他的博客中写了一篇相关文章《Pattern: Backends For Frontends》。
BFF 的概念最初就是来源于此
服务端设计API时会考虑到不同设备的需求，即为不同设备提供不同API接口，虽然它们可能实现相同功能，但因不同设备的特殊性，它们对服务端的API访问也各有其特点，需区别处理。在计算机科学中，所有问题都可以通过加一层来解决，于是 BFF 架构设计应运而生。
二、BFF的由来
随着移动设备的快速发展以及产品对用户交互体验的关注度增强，前后端分离的架构模式也逐渐被大多数企业所采用。在这种模式下，统一的后端API很难满足在不同场景下对用户体验的不同需求。
BFF模式应运而生，一方面 BFF 隔离了前端UI展示对后端API的需求，企业可以专注在后端构建核心业务能力，另一方面，BFF根据已有的后端API，快速满足前端在UI展示上的需求，来不断提升用户体验；
从知识管理的角度，BFF模式让知识边界定义得更清晰，后端专注于构建业务能力，不需要考虑前端各种场景适配的问题；而前端更关注用户体验，可以随时独立发布更新。
三、BFF到底解决哪些问题？
在用户体验至关重要的今天，程序功能展示界面丰富多样。比如同一个界面可能同时存在社区版、极速版、专业版，一个界面要展示多种数据，要连接的设备也层出不穷如小程序、APP、网页、客户端等等。
归纳起来有这几类：
- 多端功能差异 App端往往只能展示少量信息，浏览器网页则需要全部信息，因此需要适配各端而裁减字段
- 不同业务场景展示差异 PC端的屏幕较大，展示内容较多且全面。但是移动端屏幕小，展示内容较少。一个页面要展示多个服务端的数据，因此需要聚合多个API的数据（串行或并行编排多个API）
- 历史版本数据维护成本过高 服务功能不断迭代，面对服务端不同的数据格式，甚至有历史遗留系统，需要适配成前端展示更友好的格式
- 不同业务试验效果 试验不同的展示方案效果，需要快速支持新业务方案上线
四、BFF的分类
增加一层永远是解耦的大招，但BFF本身仅仅是一个概念，实现方式有多种，在实际中我们要根据不同的场景选取不同的方案。
按照大类分，主要有单一BFF和多端BFF。
4.1 单一共用 BFF
此方式主要对接服务端，根据展示服务的需求组装数据提供给每个端或者每种业务进行展示。
针对多端共用服务接口的场景，我们将后端基础服务与服务调用方中间通过BFF进行分离。
- Service：基础服务仅提供数据的增删改查，并不过多涉及业务的判断处理；
- BFF：收揽把控所有业务判断处理，同时将一些业务逻辑异常也由BFF格式化处理后展示给访问端点。
这种设计方式虽然基础服务与BFF进行了分离，但同样存在一定的问题。
我们只需要在BFF层面进行业务判断处理，但是多个端共用一个BFF，也会导致代码编写复杂度增高、代码可阅读性降低、多端业务耦合。
4.2 多端独立 BFF
此方式是指每种业务或者每种客户端采用自己独立的BFF层，这样每种客户端的服务更加灵活，不同的BFF端对于展示服务解耦性更高。
我们为每一个端点都提供一个对应的 BFF，每个端点的BFF处理自身的业务逻辑，需要数据时从基础服务内获取，然后在接口返回之前进行组装数据用于实例化返回对象。
这样基础服务如果有新功能添加，BFF几乎不会受到影响，而我们如果后期对端点进行拆处理时，我们只需要对应调整（新增、删减）BFF 即可，基础服务同样也不会受到影响。
五、BFF 的优缺点
5.1 BFF 优
通过上面的各种问题和场景，相信我们已经知道了BFF可以解决很多场景的问题，这里总结一下BFF的优势：
- 服务端对数据展示服务进行解耦，展示服务由独立的BFF端提供，服务端可以聚焦于业务处理；
- 多端展示或者多业务展示时，对于数据获取有更好的灵活性，避免数据冗余造成消耗服务端资源；
- 对于复杂的前端展示，将数据获取和组装的负责逻辑在BFF端执行，降低前端处理的复杂度，提高前端页面响应效率；
- 部分展示业务，可以抽象出来利用BFF实现，对于服务端实现接口复用；
- 降低多端业务的耦合性，避免不同端业务开发互相影响；
- 其他优势，包括数据缓存，接口安全校验等。
5.2 BFF 缺陷
BFF 在解决了多业务场景职责划分问题，也同样带来了一些问题，主要如下所示：
- 模块和接口职责的划分与分工
- 业务模块在什么时机需要独立拆分出BFF？看起来只能凭经验，应根据实际需求开发过程中数据编排和加工的逻辑占比看
- 需要明确前端、BFF、后端微服务三者的定位、职责、界限，以及相应的保障措施比如设计和编码规范
- 警惕业务逻辑往BFF服务蔓延，前后端在责任划分时容易偷懒，不进行深入思考，往BFF写不必要的代码逻辑
- 响应时间延迟（服务如果是内网之间访问，延迟时间较低）
- 编写起来较为浪费时间（因为在基础服务上添加的一层转发，所以会多写一部分代码）
- 业务异常处理（统一格式化业务异常的返回内容）
- 分布式事务（微服务的通病）
六、结语
微服务化后需要尽可能地保持领域模型和领域接口的纯洁性和稳定性，如何应对多样化且高频的前端展示需求是一大挑战。
架构设计是通过合理的组件拆分以及定义组件之间的关系，将系统整体的复杂性分散到不同的组件中，在更低的维度上解决问题，分而治之。
引入BFF是一个解法，但架构需要权衡，BFF服务的存在本身有利有弊，BFF的不同落地实现也有利有弊。
- BFF在前后端分离的架构模式下隔离了前端和后端的关注点，特别是在多个前端或第三方的情况下，BFF都是非常好的选择。
- 然而，在实施过程中，仍然要时刻警惕，明确BFF设计的初衷，避免因引入BFF而带来了更多的问题。实践能出真知，但对所支撑业务的理解也很关键，很多时候还得回到业务和团队中去看。
·END·
代码语言：javascript复制相关阅读：私藏多年的系统性能优化十大绝招（万字干货）
面对复杂业务系统，通用架构设计法则
高可用高性能核心原理探究，Kafka 核心全面总结
服务接口优化的常见方案实战总结聊聊分布式服务下的八种异步实现方式
有没有那么一瞬间，你也曾有过“失业焦虑”？浅析分布式系统中的补偿机制设计问题聊聊分布式日志系统的设计与实践
执行个 DEL 竟然也会阻塞 Redis？深挖一下果然不简单
PHP 中数组是如何灵活支持多数据类型的？
一文带你看通透，MySQL事务ACID四大特性实现原理
通过alter table 来实现重建表，同事大呼开眼界了实习生疑问：为什么要在需要排序的字段上加索引呢？代码多版改造，应用责任链设计模式
