BFF架构：胖瘦之争与场景权衡

一、什么是 BFF

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

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

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

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

二、BFF 的胖瘦之争

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

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

• 要不要 BFF 层？要不要编排层？
• 要不要网关？什么是网关？
• 应用网关和网关的区别是什么？
• 后端（领域服务）服务之间要不要互相调用？
• 要不要使用 BFF 来编排后端服务？
• BFF 是不是编排层？
• BFF 能不能宏观上对应 DDD 的应用层？
• ……

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

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

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

三、胖 BFF

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

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

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

胖 BFF 的特点是：

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

胖 BFF 的好处是：

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

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

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

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

四、瘦 BFF

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

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

瘦 BFF 的特点：

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

瘦 BFF 的好处是：

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

对应的，瘦 BFF 的弊端：

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

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

五、两种形态的权衡

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

1. 业务需求

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

2. 开发团队规模和技能

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

3. 项目周期和迭代速度

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

4. 可扩展性

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

六、总结

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

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

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