微服务下的前端 BFF 层设计

微服务架构下，前端往往要面对「一次页面请求需要聚合十几个后端接口」的困境。BFF 层正是为此而生。

前端面临的困境

微服务按业务域拆分，而前端页面是按用户场景组织的。这导致一个页面要请求多个微服务：

• 请求次数多，网络开销大；
• 数据结构不一致，前端要做大量拼接；
• 每个微服务的鉴权、限流逻辑重复处理。

BFF：前端的专属后端

BFF（Backend for Frontend）是在「前端与微服务之间」加的一层，为前端量身定制 API：

• 聚合多个微服务的数据，一次请求返回页面所需全部数据；
• 裁剪字段，只传前端需要的；
• 处理鉴权、协议转换、缓存等横切逻辑。

前端 → BFF → 微服务 A / 微服务 B / 微服务 C

BFF 的设计原则

• 按端设计：Web、移动端、小程序可有各自不同的 BFF；
• 薄而专注：BFF 做聚合与适配，不做业务逻辑；
• 避免过度抽象：不要为了「复用」而设计一个庞大的通用 BFF，反而失去灵活性。

与 GraphQL 的关系

GraphQL 是 BFF 的一种实现方式，让前端「声明式」地指定所需字段，天然擅长聚合与裁剪。但也带来缓存、安全等新复杂度，需权衡。

何时引入

• 页面需要聚合大量异构接口时；
• 不同端的数据需求差异大时；
• 需要统一鉴权、限流、日志时。

结语

BFF 的本质是「为消费方优化接口」，让前端专注于交互与体验，而非与复杂后端纠缠。它是微服务架构下，前端体验的重要保障。