引言

在最近的一次技术分享会上，我们深入探讨了公司项目架构的核心理念。会议的焦点之一是BFF架构，这是一种在微服务架构之上新增的层次结构。此外，我们还讨论了DDD（领域驱动设计）思想，它在订单、用户等业务中台的构建中扮演着关键角色。

这是我首次接触架构设计，虽然理解起来有些挑战，但我还是尝试着对这些概念进行了简单的梳理。

BFF

定义

BFF，即Backend For Frontend，是一种专为前端服务的后端架构。它位于客户端和服务端之间，充当中间件的角色，我更倾向于将其视为前端与后端之间的桥梁。

应用动机

BFF是近年来新兴的一种开发模式，也可以看作是一种适配系统。它的出现是为了解决微服务架构下前端和后端接口调用混乱的问题。

在微服务架构流行的今天，大型系统被划分为数十个服务模块，如商品、门店、运费、红包、订单、优惠券、CMS、用户、搜索、推荐、广告等。前端则包括小程序、APP、网页等多种形态。这种架构带来了一系列挑战：

• 前端挑战：开发过程中，前端需要与多个系统对接以确认接口信息，不同数据来源需要查询不同的系统，导致开发和调试效率极低。
• 后端挑战：后端同样需要为前端包装数据，重心转向如何为前端提供数据。由于需要根据不同版本、客户端、用户、定位等特征进行适配，很多时间被浪费在展示层，而非业务逻辑处理。每个后端系统都有自己的接口规则，历史版本问题难以统一，导致系统间严重耦合。
• 变更不灵活：产品需求更新时，小改动可能需要在多个系统间协调，大部分系统都需要重新上线。

下图展示了未使用BFF架构时，前后端沟通的复杂性。

BFF的网关角色

为了解决上述问题，我们需要一个中间层来适配前后端服务，BFF应运而生。它负责统一调用所有下游后端接口，这些接口只需提供RPC接口供网关使用。BFF网关提供Web接口供前端调用，并根据前端需求组装和拼接数据。

因此，BFF的核心角色是：“统一下游接口，为前端提供定制化服务”。

只有深刻理解服务的本质，才能有效地构建BFF网关系统。其他系统可能会推卸责任，但BFF网关不能。它的使命是连接前后端，处理所有不合理、不合适和繁琐的逻辑。后端只需专注于业务逻辑，前端专注于展示，其他任务可以交给BFF网关处理。

BFF网关的特性

作为一种特殊的网关，BFF具有以下特点：

复杂性

BFF网关主要服务于前端，前端不关心版本、客户端、定位、用户身份等细节，只接收渲染数据。这些逻辑都需要集成到BFF网关中，以版本、客户端、定位、用户等特征为维度。其中，版本是最为复杂的分支，可能需要兼容数十个版本类型，同时还要满足不同客户端的展示要求和用户特征。因此，BFF网关需要进行大量的判断分支，根据上百种情况组合生成唯一的数据结构。

数据管理

BFF不需要数据库，这一点将在下文解释。因此，许多数据需要以静态变量的形式存储在代码中，或使用配置中心动态配置，如图片地址、颜色值、模块固定文本、处理标识等。这些琐碎的数据都存储在BFF网关中进行维护。如果放在前端，修改时必须发版，周期太长；而放在后端，又会分散数据，无法集中管理。

逻辑处理

如前所述，BFF网关作为下游接口的聚合器，每次流程需要调用数十个后端接口，再根据版本、端、用户进行逻辑处理。历史逻辑与新需求混杂在一起，实现新功能的同时要不断兼顾历史逻辑，导致需要加入大量的分支判断，最终形成复杂的逻辑结构。

性能考量

BFF网关的耗时主要分为两部分：

• 内部处理耗时
• 下游RPC接口耗时

作为与前端直接交互的接口，BFF的耗时直接影响用户体验。因此，BFF