🌍 译介 · 编译自 Nordic APIs

BFF:给每个前端配一个专属「翻译层」

微服务一多就互相依赖,单一大 API 既要伺候移动端、又要伺候桌面端和内部系统,结果又慢又肿。Backend for Frontend(BFF)用一层薄薄的「翻译垫片(shim)」把各异的调用转成统一通用调用,化解这种乱象。本文编译自 Nordic APIs《Building a Backend for Frontend》(2017-05-19,作者 Kristopher Sandoval),并补充 Sam Newman 与「表现层解耦」两篇的实践要点。

📅 更新于 2026-07-24 ⏱ 约 6 分钟阅读 🏷 译介
免费试用 YesApi Pro 查看全部定价 →
🌐本文由 YesApi Pro 团队编译Nordic APIs 的文章《Building a Backend for Frontend (BFF) For Your Microservices》,原作者 Kristopher Sandoval(原文发布于 2017-05-19)。版权归原作者所有,内容仅供学习参考。查看英文原文 →
📌 核心结论
BFF 是在「用户体验」和「背后资源」之间的一层翻译垫片:把 iOS/Android/桌面/内部的各异调用,翻译成统一的通用调用。它只是垫片不是微服务,别往里塞业务逻辑;数据裁剪(取 10/40/50 个字段)应在主 API 层按客户端类型做,而非在垫片里过滤。多端差异大、微服务多时才值得上,简单应用反而是负担。
📑 本文目录
  1. 什么是 BFF
  2. 三套架构对比:经典/微服务/BFF
  3. BFF 是怎么工作的
  4. 垫片最佳实践
  5. 何时该用、何时慎用
  6. 结论与平台落地
01

一、什么是 BFF

BFF(Backend for Frontend,为前端准备的后端)由 Phil Calçado 提出、Sam Newman 在 SoundCloud 实践成型:核心思想是为每种用户体验开发专属的「小后端」

它本质上是一块垫片(shim),填补 API 设计里固有的裂隙——位于「用户体验」和「它调用的资源」之间。移动端发请求时,先经过 BFF 翻译,再落到下层通用层。注意:垫片是很小的代码片段,远小于整个 API。

02

二、三套架构对比:经典 / 微服务 / BFF

以「3D 打印下单」为例,有三种形态:

形态调用方式问题
经典移动/桌面/内部三种调用,各自进「通用 Ordering API」的不同分支单一大 API 又慢又肿;同一数据要按端做重复「微调」
微服务各自有 Mobile API / Desktop API / Internal API三个 API 调同一套后端,代码功能大量重复;演进 overhead 高
BFF 垫片三种调用先被 mobile/desktop/internal 三个 shim 拦截,转成「通用调用」翻译层小、由各 shim 团队维护;吞吐更高效

BFF 不是微服务的换皮,而是翻译服务层:把「服务专属调用」翻译成「通用调用」,从而既消解大 API 的臃肿,又避免微服务各自为政的重复。

03

三、BFF 是怎么工作的

垫片做的事只有一件:「当这份数据返回时,把它从 A 类型转换成应用指定的 B 类型」。它是翻译层,不是自包含的全功能 API。

关键差异在调用处理:经典方案里一个 API 含「按来源区分的数据集变体」,每种来源都要专属调用、且 API 要先改数据再传;微服务方案各自为政、缺乏连续性;而 BFF 方案把各异调用统一翻译成一条通用调用,计算压力与责任分散到多个可由单一 shim 团队维护的服务上——相当于修了一条高速公路,绕开了满是收费站和匝道的旧路,吞吐更顺。

04

四、垫片最佳实践

① 别把垫片当微服务:垫片只做「类型转换」,不是全功能 API。硬往里塞业务,就背离了本意。

② 避免垫片膨胀:按体验类型而非来源拆垫片。iOS/Android/Windows Mobile 体验相近,多数可共用一个移动垫片,不必每个 OS 一个。

③ 别过度依赖垫片:别拿它当安全前置或功能扩展的拐杖。主 API 代码库仍须承担全部功能,垫片只补缺口、不增功能。

④ 只给所请求的数据:购物前台一条记录含 50 个对象,移动端只需 10 个、桌面需 40 个、内部要 50 个。别让垫片在传输中裁数据——那会把它推向「功能 API」。正确做法:数据裁剪在主 API 层用「来源触发器」做,每个垫片只告知客户端类型,API 只回该类型所需的数据集。这样更快、省带宽、体验更好。

05

五、何时该用、何时慎用

适合:多端应用(Web/iOS/Android 差异大)、微服务数量多且接口复杂、前端团队具备后端能力、对首屏速度与体验要求高。

慎用:单页简单应用(只会增加复杂度);团队规模小、维护成本高;把核心业务逻辑塞进 BFF(它应坚守「胶水层」定位)。BFF 不是银弹,而是一种以开发者体验与用户体验为中心的架构思维。

实践中常配合 API 网关使用:网关管路由/认证/限流(基础设施层),多个 BFF 管数据聚合/格式转换/业务裁剪(前端专属层),各司其职。

06

六、结论与平台落地

BFF 只是解决「普遍架构难题」的其中一种方案,面对复杂后端与差异化极大的用户体验时尤其有效。它不是微服务换皮,而是「异构 API 服务与体验之间的翻译层」。

落地时记住:垫片要小、要纯翻译、要按体验类型分组、数据裁剪回主 API 层做。当你的开放平台要同时服务 Web、App、第三方开发者等多种调用方时,BFF 思路同样适用——为不同接入方提供差异化的聚合与裁剪层,正是 YesApi Pro 这类开放平台「接口适配」能力的用武之地。

译者实战注 落地建议与延伸

需要快速落地?

YesApi Pro 私有部署、源码交付、当天上线,帮您把方案变为现实。

立即预约演示 →

常见问题

微服务是各自独立、功能完整的后端服务;BFF 是薄薄的翻译垫片,只把各异调用转成通用调用,不承载完整业务逻辑。

放在主 API 层,按客户端类型用来源触发器返回对应数据集;别让 BFF 垫片在传输中裁数据,否则垫片会退化成功能 API。

单页简单应用、团队小维护成本高、或把核心业务逻辑塞进 BFF 时都不该用——它只是胶水层,不是银弹。

开放平台要服务 Web/App/第三方等多种调用方,BFF 的「差异化聚合与裁剪」思路正对应 YesApi Pro 的接口适配能力,可为不同接入方提供专属聚合层。
📚

继续阅读