关于 BFF 架构设计的胖瘦之争

hello，大家好，我是张张，「架构精进之路」公号作者。

前段时间，整理过一篇《应该如何正确理解BFF架构设计？》的文章，最近又做了进一步研究，发现业界还存在BFF架构的胖瘦之争，大家纠结的点到底是什么？今天我们一起来聊聊吧。

1. 什么是BFF？

最开始，我们还是先明确下BFF是什么吧，由于前文已经做过介绍了，这里就简单的提一下。

BFF：Backends For Frontends（服务于前端的后端）。

BFF是一种Web架构，微服务设计系列丛书的作者 Sam Newman曾在他的博客中写了一篇相关文章《Pattern: Backends For Frontends》。

BFF 的概念最初就是来源于此。

服务端设计API时会考虑到不同设备的需求，即为不同设备提供不同API接口，虽然它们可能实现相同功能，但因不同设备的特殊性，它们对服务端的API访问也各有其特点，需区别处理。在计算机科学中，所有问题都可以通过加一层来解决，于是 BFF 架构设计应运而生。

2. BFF的胖瘦之争

在现代软件开发中，服务化可能是解决大型复杂应用的必然之路，BFF 架构已成为构建高效、灵活前端应用的重要手段之一。

在服务化的系统中规划阶段，有一些必然会被讨论的话题：

要不要 BFF 层? 要不要编排层？

要不要网关？什么是网关？

应用网关和网关的区别是什么？

后端（领域服务）服务之间要不要互相调用？

要不要使用 BFF 来编排后端服务？

BFF 是不是编排层？

BFF 能不能宏观上对应 DDD 的应用层？

......

在上面这些问题中，最让人关心的问题倒不是响应用户请求流量的服务叫是 ServiceA 还是 ServiceB，而是它应该直接转发数据还是需要为每个 API 重新编写一次实现，并调用后端 API。

然而，对于 BFF 架构的设计，存在着 "胖" 与 "瘦" 的不同考量，这会决定我们在 BFF 中是否需要编写大量代码，所以我把它们的区别称之为"胖瘦 BFF"。

概括而言：不同 BFF 的考量会决定微服务架构的两种形态。

3. 胖 BFF

在有一些架构形态中，BFF 会有以下职责：

鉴权
限流、熔断、服务降级、灰度路由等
接入多种协议和设备，比如 MQTT 服务、WebSocket 等
编排领域服务，尽量避免后端服务之间互相依赖，统一由 BFF 处理
不同类型的客户端一套 BFF
非常接近 DDD 四层架构中的应用层，处理面向场景的业务

因为它的职责比较多，我们暂且称其为：胖 BFF。

胖 BFF 的特点是：

强大的业务逻辑处理能力：胖 BFF 架构不仅可以进行数据转换，还可以承担更多的业务逻辑处理。它可以整合多个后端服务的数据，进行复杂的计算和业务规则校验。
高度定制化：能够根据不同的前端需求进行深度定制，为不同的用户界面提供个性化的数据和服务。
更好的性能优化：可以对数据进行缓存、预取等优化操作，提高前端应用的性能。

胖 BFF 的好处是：

可以对不同类型的客户端定制一套 API，且各自之间不受干扰
领域服务可以设计得比较原子化，比较少的侵入特定场景信息到领域服务中
容易适配更多类型的客户端
比较容易实现个性化的鉴权、特定用户群的交互逻辑
方便实现准确、统一的 API 文档

但是这类架构也有非常多的弊端，导致很多架构师非常抗拒：

破坏了端到端交付能力，如果按照上下文划分微服务，刚好这些微服务和前端业务和需求对应，那么跨功能团队的交付效率会更高
重复劳动，一些接口的模型不仅在领域服务实现一次，还需要在 BFF 做一次
难以分工，维护后端服务的人员都会和这个服务集成

在海外的一些文章和书籍中，他们也会有类似的困惑。很多架构师把这种结构叫做编排（Orchestration）。

4. 瘦 BFF

相对而言，瘦 BFF 架构，其职责可能更少：

鉴权
透明转发流量到后端服务
和胖 BFF 类似，也有限流、熔断、服务降级、灰度路由等职责

瘦 BFF 的特点：

简洁高效：瘦 BFF 架构专注于将后端服务的数据进行轻量级的转换和适配，以满足前端的需求。它通常只进行必要的数据筛选、格式转换和简单的业务逻辑处理。
快速响应：由于功能相对简单，瘦 BFF 可以快速响应前端的请求，减少延迟，提高用户体验。
易于维护：代码量较少，结构清晰，使得维护成本相对较低。开发人员可以更容易地理解和修改代码，快速定位和解决问题。

瘦 BFF 的好处是：

端到端交付，前端开发人员直接使用后端领域服务的 API 文档
开发效率高，避免多编写一层 BFF
减少一次集成

对应的，瘦 BFF 的弊端可想而知：

没有编排层，服务之间相互依赖
编排行为落入前端或者领域服务，拓展性差
领域服务之间调用关系复杂
领域服务职责过多，侵入业务场景，难以被复用

这样的话，BFF 仅仅扮演转发的作用，也就成了我们口中的网关。

5. 两种形态的权衡

那么在什么场景下，更合理的选择这两种结构之一呢？

业务需求

如果业务逻辑简单，数据交互相对较少，瘦 BFF 可能就足够满足需求。但如果业务复杂，需要进行大量的业务逻辑处理和数据整合，胖 BFF 则更为合适。

开发团队规模和技能

瘦 BFF 相对容易开发和维护，适合小型开发团队或技术能力有限的团队。而胖 BFF 需要更高的技术水平和更多的开发资源，适合有经验的大型开发团队。

项目周期和迭代速度

对于短期项目或需要快速迭代的项目，瘦 BFF 可以更快地实现并投入使用。而胖 BFF 的开发周期可能较长，但在长期运行中可以提供更好的性能和可维护性。

可扩展性

考虑未来业务的发展和扩展需求。如果预计业务会不断增长，功能会逐渐复杂，选择胖 BFF 可以为未来的扩展提供更好的基础。

6. 总结

总之，BFF 架构的胖瘦之分并没有绝对的标准，需要根据具体的项目需求、业务特点和开发团队情况进行综合考虑。

无论是胖瘦 BFF，其实都是基于场景对单体系统拆分的结果，非常依赖于所属场景。

在实际应用中，可以根据不同的阶段和需求，灵活地调整 BFF 的设计，以实现最佳的用户体验和系统性能，这也解释了关于 BFF 为什么目前还没有形成统一的技术方案和观念。

·END·

希望今天的讲解对大家有所帮助，谢谢！

Thanks for reading!

作者：架构精进之路，十年研发风雨路，大厂架构师，CSDN 博客专家，专注架构技术沉淀学习及分享，职业与认知升级，坚持分享接地气儿的干货文章，期待与你一起成长。

关注并私信我回复"01"，送你一份程序员成长进阶大礼包，欢迎勾搭。