让我们用通俗易懂的方式理解BFF和API Gateway的区别:
类比解释:餐厅系统
想象一个餐厅的运作流程:
-
API Gateway 像餐厅的 门卫+前台:
- 职责:接待所有客人、检查预约(认证)、安排座位(路由)、控制人流(限流)。
- 不关心客人具体吃什么,只负责统一管理入口流量。
-
BFF 像 专属服务员:
- 职责:根据不同客人需求提供定制服务。比如:
- 为儿童推荐儿童套餐(移动端需要简洁数据)。
- 为素食者过滤菜单(Web端需要详细数据)。
- 服务员会去后厨(微服务)协调多个菜品(聚合数据),最终给客人一个整合好的结果。
- 职责:根据不同客人需求提供定制服务。比如:
技术视角:分工与协作
API Gateway(全局入口)
- 做什么:
- ✅ 统一认证(比如校验Token)
- ✅ 路由请求(比如
/order
请求转到订单服务) - ✅ 限流熔断(防止系统过载)
- ✅ 日志监控(记录所有请求)
- 特点:
- 所有请求的 第一道关卡,不关心业务逻辑。
- 通常全公司 只有一个(或按环境拆分)。
BFF(定制适配层)
- 做什么:
- ✅ 为特定前端定制API(比如为手机APP设计专用接口)
- ✅ 聚合多个微服务的数据(比如调用用户服务+订单服务,合并返回)
- ✅ 数据裁剪(比如Web端需要更多字段,APP端需要更少)
- 特点:
- 每个前端可能对应 一个BFF(如
BFF-Mobile
,BFF-Web
)。 - 处理业务适配,不负责流量管控。
- 每个前端可能对应 一个BFF(如
举个实际例子 🌰
假设有一个「用户主页」需求:
- 手机APP需要:用户昵称 + 头像 + 最近1笔订单。
- Web端需要:用户昵称 + 头像 + 所有订单 + 会员等级。
流程:
- 请求先到达 API Gateway,完成认证和路由。
- API Gateway将请求转发给对应的BFF:
- APP请求 →
BFF-Mobile
- Web请求 →
BFF-Web
- APP请求 →
- BFF分别调用下游服务:
BFF-Mobile
调用 用户服务 + 订单服务(取1条),合并数据返回。BFF-Web
调用 用户服务 + 订单服务(取全部) + 会员服务,合并数据返回。
关键区别总结
维度 | API Gateway | BFF |
---|---|---|
核心职责 | 流量管控(认证、路由、限流) | 业务适配(数据聚合、裁剪) |
数量 | 通常全局1个 | 按前端类型多个(如Mobile/Web) |
层级 | 所有请求的第一层 | 位于API Gateway和微服务之间 |
是否改代码 | 配置化(如Nginx/YAML) | 需要写业务逻辑代码 |
一句话记忆
- API Gateway:系统的「守门员」,不问业务只管安全通行。
- BFF:前端的「贴心助理」,帮你跑腿整合数据。
两者通常 配合使用:客户端 → API Gateway → BFF → 微服务
。