BFF调研-1

已同步到个人博客，欢迎访问。

前端开发中存在的难问题

1. 多端应用，不同类型客户端对数据、API有个性化的需求
2. 服务聚合，单一后端为多个前端团队提供接口，导致跨团队协作低效，资源协调困难

问题：服务端设计的接口究竟是面向UI，还是面向通用服务？

BFF

解决方案： Backends For Frontends， 简称BFF。

BFF最适合的场景，为第三方提供定制API等差异化场景，每个用户体验（客户端）对应一个后端，

BFF作为用户体验适配层，对后端接口进行组合、处理，对数据进行：裁剪、格式化、聚合、编排。

BFF理念中，最重要的一点是：服务自治，谁使用谁开发，所以一般由前端维护。

BFF实现不限制具体技术，可以自由选型：Java/Node/PHP/Python，但大部分前端团队都会选择Node.js。

BFF的演化历程

BFF和网关（API Gateway）是微服务架构中两个重要概念，可以通过下面的例子讲解BFF的出现过程

服务化架构V1

实现单块应用的解构拆分，微服务初步完成，前端用户体验层主要是传统的服务端Web应用，服务化架构如下所示：

服务化架构V2

随着无线应用的流行，除了Web应用外，服务还需要为新的无线原生App来提供接口和数据，先采用下面的服务架构：

这样的架构的问题是：

1. 无线App与内部为微服务强耦合
2. 无线App需要知道内部服务的地址等细节
3. 无线App需要对接口数据进行大量的聚合剪裁和适配逻辑

服务化架构V2.1

为了解决这个问题，在用户体验层和内部微服务层之间引入了BFF层，将后端的微服务进行适配，想用户体验层暴露有号和统一的API，方便无线设备接入访问后端服务

这种架构解决了上面的问题：

1. 无线App与内部为微服务解耦，两边可以独立变化
2. 无线App只需要知道BFF的地址，并且服务接口统一，不需要关心内部复杂的微服务的地址和细节
3. 无线App需要不再需要聚合剪裁和适配逻辑，这些步骤都在BFF完成

但是随着接入设备的增加，也会有一些问题：

1. BFF只有一个，接入设备增加后导致要考虑匹配问题，团队之间沟通协调成本高
2. BFF中不仅包括了各个业务线的聚合剪裁、适配和业务逻辑，还需要引入很多跨横切面逻辑，比如安全认证、日志监控、限流熔断等，这些代码混在一起，导致代码复杂度提高
3. BFF如果出现错误，会导致所有应用都不可用

微服务架构V3

为了解决这个问题，引入API Gateway

在这种架构下：

1. BFF按团队和业务线进行解耦拆分，拆分成若干个BFF微服务，每个业务线并行开发和交付各自负责的BFF微服务
2. 网关，一般由独立的团队负责运维，专注跨横切面的功能，包括
   • 路由，将来自无线设备的请求路由到后端的某个微服务BFF集群
   • 认证，对涉及敏感数据的API访问进行集中认证鉴权
   • 监控，对API调用进行性能监控
   • 限流熔断，网关能够进行限流熔断，保护后端服务
   • 安全防爬，收集访问日志，通过后台分析恶意行为，阻断恶意请求
3. 网关在客户