背景
前后端分层协作的各种模式，协作的边界是数据，后端提供数据服务接口，前端消费数据实现人机交互。
在当今强调前后端分离的架构下，前后端要交互的就只有数据。虽然我们通过 node 层承载了部分后端服务的功能，但是大多数情况下，前端依赖的数据，还是由后端同学提供的 API 接口提供。
这种协作方式在一些情况下，会遇到以下问题：
- 服务层 API 相对稳定，体验者 API 经常变化
- 跨团队低效协作
- 资源协调困难
概念
BFF，全称Backend For Frontend，即服务于前端的后端。
Some strategies can be adopted to negate much of the negative points of this aspect of microservice architecture design. One method is to create a Backend for Frontend (BFF) shim to help organize microservice architectures and coordinate functionality across a diverse, wide system.
BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向终端设备暴露友好和统一的 API ，方便终端设备接入和访问后端服务。
BFF层通常来说，主要负责以下功能：
- 数据清洗：对后端 API 返回的数据进行聚合、转换和过滤，重新构建符合前端业务需求的数据结构，解除前后端在数据字段层面的隐形耦合。
- 多端应用：我们在设计 API 时会考虑到不同设备的需求，也就是为不同的设备提供不同的 API，虽然它们可能是实现相同的功能，但因为不同设备的特殊性，它们对服务端的 API 访问也各有其特点，需要区别处理。
- 服务聚合：随着微服务的兴起，原本在同一个进程内运行的业务流程被拆分到了不同的服务中。这在增加业务灵活性的同时，也让前端的调用变得更复杂。BFF 的出现为前端应用提供了一个对业务服务调用的聚合点，它屏蔽了复杂的服务调用链，让前端可以聚焦在所需要的数据上，而不用关注底层提供这些数据的服务。
- 访问控制：例如，服务中的权限控制，将所有服务中的权限控制集中在 BFF 层，使下层服务更加纯粹和独立。
- 应用缓存：项目中时常存在一些需要缓存的临时数据，此时 BFF 作为业务的汇聚点，距离用户请求最近，遂将该缓存操作放在 BFF 层。
- 第三方入口：在业务中需要与第三交互时，将该交互放在 BFF 层，这样可以只暴露必要信息给第三方，从而便于控制第三方的访问。
那么，BFF层从定义上来看，最大的受益者是前端，同时数据的定义也应该来自前端（页面数据/组件数据），所以在前端侧去搭建这一块逻辑层是合理的行为。
与网关的关系
BFF集群容易造成单点故障(Single Point of Failure)，严重代码缺陷或者流量洪峰可能引发集群宕机，导致所有终端应用都不可用。因此，大部分情况下，我们会在外部设备和内部BFF之间再引入一个新的角色 - API Gateway，如下图所示：
从外到内依次分为：端用户体验层->网关层->BFF层->微服务层。
网关在无线设备和BFF之间又引入了一层间接，让两边可以独立变化，特别是当后台BFF在升级或迁移时，可以做到用户端应用不受影响。
网关专注跨横切面(Cross-Cutting Concerns)的功能，包括：
- 路由，将来自无线设备的请求路由到后端的某个微服务BFF集群。
- 认证，对涉及敏感数据的API访问进行集中认证鉴权。
- 监控，对API调用进行性能监控。
- 限流熔断，当出现流量洪峰，或者后端BFF/微服务出现延迟或故障，网关能够主动进行限流熔断，保护后端服务，并保持前端用户体验可以接受。
- 安全防爬，收集访问日志，通过后台分析出恶意行为，并阻断恶意请求。
参考文章
https://cloud.tencent.com/developer/news/229123
https://mp.weixin.qq.com/s/IYddaaw2ps1wR2VT1dZWPg