微服务之BFF

网关是微服务架构不可或缺的一部分，作为微服务架构的唯一入口，将所有请求转发到后端对应的微服务上去，同时又可以将各个微服务中的通用功能集中到网关去做，而不是在每个微服务都实现一遍，比如权限校验，限流，熔断和监控等。

如图所示，这是个典型的前后端分离的微服务架构，但这个架构在的问题是，一个接口无法同时满足不同场景的业务。如移动端APP，可能与Web端、OpenAPI 的需求不一样，导致接口存在差异, 这时微服务就要对接不同的API需求，产生了各种各样的问题。

有没有更优雅的解决方式呢？那就是引入BFF，这个词是 2015 年 11 月 Sam Newman 在他的一篇博客中提出的。BFF 是 Backends for Frontends 的简写，为了前端的后端。Sam Newman 的博客还有一个副标题：Single-purpose Edge Services for UIs and external parties，为了用户界面或外部方的单一目的的边缘服务。用户界面比如我们常见的网页，或 App，外部方比如第三方 App，客户 App，企业微信，小程序等。其实这中模式更早一点就出现了，淘宝在更早一点的时候就设立中途岛项目，其主要内容就是 BFF。

BFF也称聚合层或者适配层，它主要承接一个适配角色：将内部复杂的微服务，适配成对各种不同用户体验（无线/Web/H5/第三方等）友好和统一的API。聚合裁剪适配是BFF的主要职责。

改造后的微服务架构如下图:

引入BFF后，有如下好处:

1. 聚合, 将后端多个请求合并成一个请求，以减少网络传输时间。这些请求可能来自一个服务，也可能来自多个服务。

2. 适配, 因为遵守的接口规范不同，多个微服务和外部服务的接口可能有很多不同，在 BFF 层可以做一些适配，给前端代码提供同一个的数据格式和接口格式。

3. 裁剪, 同样的信息在不同的客户端有着不同的展现，比如手机屏幕尺寸较小，内存较小，CPU 性能较差，只能展示部分非常重要的信息，如果和电脑上使用同一个接口，势必导致手机上页面渲染变慢，还会浪费手机电量和网络流量。

我们在看到 BFF 带来的各种好处的同时，也要注意到它所带来的代码重复和工作量增加方面的问题。另外因为增加了一层调用链，也会对响应时间稍有影响。