微服务API聚合怎么做：BFF模式实战指南

一个电商首页，商品信息、用户偏好、促销活动、库存状态分散在四个微服务里。前端拿到这个需求的时候是崩溃的——发四个请求，自己拼数据，页面加载三秒起步。这就是BFF（Backend for Frontend）模式要解决的典型问题。

BFF不是多加一层那么简单

BFF的核心思路是：在微服务和前端之间放一个专属聚合层，由它来负责接口编排、数据裁剪和格式转换。前端只发一次请求，BFF内部并行调用多个微服务，合并后返回。听起来简单，但落地时有几个关键决策点。

第一个问题是BFF用什么技术栈。Node.js是高频选择，因为前端工程师可以直接上手写，沟通成本低。但如果你的聚合逻辑涉及复杂数据处理，Go或者Java可能更合适。判断标准很简单：聚合逻辑里有没有计算密集的操作？如果有，别用Node。

实际落地的三个步骤

第一步，梳理前端页面的数据依赖关系。把每个页面需要调用的API列出来，标注哪些是串行依赖、哪些可以并行。这一步决定了BFF里的聚合策略。比如商品详情页，商品基本信息和评价可以并行拿，但库存依赖商品ID，必须串行。

第二步，设计BFF的接口粒度。按页面维度设计，一个页面一个接口。不要按业务领域拆，否则又回到微服务那种细粒度调用的老路上了。接口返回的数据结构对齐前端组件的props，前端拿到就能直接渲染，不需要二次转换。

第三步，处理缓存和容错。BFF层应该对下游微服务做熔断和降级处理。商品评价服务挂了，不能让整个页面挂掉，返回空数据或者降级文案就行。缓存策略上，BFF层做短时缓存（5-10秒），配合ETag做条件请求，能有效扛住流量洪峰。

还有一点容易被忽略：BFF是按端区分的。移动端和PC端的数据需求不同，应该有各自的BFF实例。共用一个BFF看似省事，但很快会变成大杂烩，维护成本反而更高。