BFF es una arquitectura web, el nombre completo es Backends For Frontends, que es el backend que sirve al frontend. El término proviene de un artículo de Sam Newman: Pattern: Backends For Frontends . BFF generalmente se refiere a agregar una capa intermedia entre el extremo frontal y el extremo posterior. ¿Por qué agregar una capa BFF entre el extremo frontal y el extremo posterior?
El científico informático David Wheeler dijo una vez: All problems in computer science can be solved by another level of indirection.Todos los problemas en informática se pueden resolver agregando una capa. Por lo tanto, la escena que necesita usar BFF debe ser que los modelos de desarrollo front-end y back-end ordinarios han encontrado algunos problemas. Por ejemplo, el artículo de Sam Newman describe el escenario en el que BFF resuelve múltiples terminales de visualización.
Problema de visualización multiterminal
Cuando se desarrolló el sistema por primera vez, solo se consideró el diseño de la página web de la PC y la API del lado del servidor fue para la página web de la PC. Pero más tarde, con el auge de Internet móvil, el terminal móvil se hizo popular y se decidió desarrollar la aplicación móvil sobre la base del servidor original y reutilizar la API anterior, pero la API original estaba diseñada para el terminal de PC y no satisfacer las necesidades del terminal móvil.
- Los requisitos del terminal de PC no son necesariamente los mismos que los del terminal móvil, y la interfaz existente no puede satisfacer todos los nuevos requisitos del terminal móvil.
- El rendimiento de la terminal de PC es sólido y puede solicitar múltiples interfaces al mismo tiempo o realizar algún procesamiento de datos complejo, pero el rendimiento de la terminal móvil es bajo.Si se utilizan las mismas interfaces múltiples y los datos se ensamblan en la parte frontal, la visualización de la página puede retrasarse y atascarse.
- La pantalla del lado de la PC es más grande y el contenido de la pantalla es más completo. Sin embargo, la pantalla del terminal móvil es pequeña y el contenido de visualización es menor. Además, no es fácil obtener algunos datos y el backend necesita llamar a muchos servicios. Si el terminal móvil reutiliza la interfaz del terminal de PC, se adquirirán y transmitirán algunos datos inútiles, lo que no solo consume recursos del servidor, sino que también desperdicia ancho de banda de la red.
Además, con el desarrollo de la tecnología y las necesidades de los usuarios, cada vez hay más terminales de pantalla diferentes, no solo se distinguirán los terminales de Android e IOS en los teléfonos móviles, sino que también habrá terminales de tableta PC, páginas web móviles, PC web páginas y páginas web de PC Final de la aplicación y así sucesivamente. Los diseños de página de estos terminales son diferentes y los requisitos de datos también son diferentes. Suponiendo que reutilicemos el mismo servidor y la misma interfaz API, si hay una escena que no cumple con los requisitos, agregue la interfaz y agregue campos, luego con el desarrollo y la iteración de estos diferentes clientes, el servidor se volverá grande, inflado e ineficiente. . Además, se proporciona la misma interfaz para demasiadas llamadas front-end, lo que implica demasiada lógica y la complejidad es cada vez mayor.
Por lo tanto, una mejor manera es desacoplar la pantalla del servidor. El servidor solo es responsable de proporcionar datos, y una terminal de pantalla dedicada es responsable del negocio de la pantalla frontal. El lado de visualización aquí es la capa BFF.
Diferencias en los modos de visualización para diferentes escenarios comerciales
En algunas empresas, solo hay un tipo de cliente, pero en diferentes escenarios, los modos mostrados son diferentes. Por ejemplo, en la práctica BFF de Meituan , los módulos de visualización de los estantes de compra grupales en diferentes industrias son diferentes. Son dos conjuntos de lógica de producto definida de forma independiente, y se repetirán por separado.
En este escenario comercial, aunque es el mismo cliente, el negocio es diferente y el formato y el tipo de datos requeridos también son diferentes, por lo que se encuentra con un problema de interfaz similar a la pantalla multiterminal anterior.
necesidades de ciclo de vida corto
Otra situación son los requisitos de ciclo de vida corto que encontró el equipo de Xianyu . En escenarios comerciales comunes, el servidor se desarrolla normal y establemente de forma iterativa. Pero ocasionalmente habrá algunas actividades operativas especiales, que son de corta duración y pueden durar solo unos pocos días.
Aunque solo sea por las actividades de estos pocos días, es costoso e ineficiente abrir una nueva API, depurar conjuntamente o incluso modificar la lógica del servidor original cada vez. Si se agrega una capa de BFF para que el front-end pueda obtener datos directamente, el desarrollo y la depuración conjunta serán mucho más fáciles.
necesidades de integración empresarial
在某些情形下，业务后端和需求比较复杂，例如这篇文章涉及到的场景，有一个Moments App,包含了像用户管理，关系管理，信息，头像，点赞等多种多种后端微服务。这些服务在前端展示的逻辑耦合性较强。比如有些需要串行处理，例如得到服务1的结果才可以调用服务2；有些则可以并行处理。而数据合并和整理的逻辑额较为复杂。
图片来源：跨平台架构：如何设计 BFF 架构系统？
网易云音乐也使用BFF进行微服务的调度以及数据的组装和适配。
这时候可以设立一个BFF层，作为一个数据整合服务，将调用不同微服务接口，与数据处理的复杂逻辑都在BFF端中实现，降低了前端的复杂度，也提高了响应效率。
处理部分展示相关的业务
在使用了BFF之后，部分页面展示相关的业务逻辑可以抽象出来，交由BFF端处理。
例如数据导出Excel下载服务，输入导入Excel上传服务。BFF层可以接收用导入的Excel，解析并处理表格数据，然后提供给服务端。在导出时，也可以调用服务端API获取数据，由BFF端整合提供给前端下载。在这种情形下，服务端只需要提供一个展示接口，就可以满足页面展示和导出两种不同格式的展示需求。导入也是同理。而且假设表格与页面展示要求的数据格式不同，例如导入时部分字段值需要作转换，那么也可以由BFF端处理这种差异。
BFF的类型
BFF本身仅仅是一个概念，实现方式有多种，在实际中我们要根据不同的场景选取不同的方案。按照大类分，主要有单一BFF和多端BFF。
单一BFF
单一的BFF主要对接服务端，根据展示服务的需求组装数据提供给每个端或者每种业务进行展示。
很多单一BFF都会用到GraphGL，他是由Facebook开发的数据查询工具。通过该工具，可以将不稳定的数据组装部分从稳定的业务数据逻辑中剥离，使数据控制逻辑前移，开发模式由“下发数据”转变成“取数据”的过程。
例如美团，闲鱼，网易云音乐等的BFF，都提供了按需查询能力，一个BFF对接多种客户端或者多种业务的需求。下图是美团使用的BFF架构设计。
图片来源：GraphQL及元数据驱动架构在后端BFF中的实践
多端BFF
多端BFF是指每种业务或者每种客户端采用自己独立的BFF层，这样每种客户端的服务更加灵活，不同的BFF端对于展示服务解耦性更高。
前端BFF与后端BFF
从技术上分，BFF又可以分为前端BFF和后端BFF。即BFF层由前端团队主导或者后端团队主导。前端团队的BFF一般使用Node.js，后端团队则会使用Java或者其他服务端语言。
如果使用前端BFF，可以实现谁使用谁开发，一定程序生避免了前后端实现的上不必要的沟通成本。但需要前端团队有一服务端开发经验，对前端团队的技术建设有较高需求。但是前端也能更深入的接触业务逻辑，对于重展示的业务需求有一定优势。例如淘宝的实践：大淘宝技术行业FaaS化实战经验分享。
传统接口与按需查询
传统接口模式即正常开发接口，固定入参和返回数据格式，供前端调用。按需查询模式即前端调用接口时指定需要哪些数据，前端自主进行按需查询。GraphQL即是使用按需查询的模式。
BFF的其他特点
与ServerLess集成
使用前端BFF时，前端开发可能缺乏运维经验，而且在高可用，并发性等问题上可能会遇到挑战。如果结合Serverless实现自动扩容，弹性伸缩等功能，可以解决一些BFF的问题。
阿里云的云原生团队介绍了这一方法：基于函数计算的 BFF 架构（图片来源）
BFF与网关
网关可以提供路由，认证，监控，日志等服务。网关可以与BFF集成在一起，也可以作为独立的一层来实现。如果业务复杂，还可以在不同的BFF上层配置不同的网关。
这篇文章介绍了在不同场景下，BFF层与网关的应用。 微服务架构：BFF和网关是如何演化出来的？（图片来源）
BFF的优势
通过上面的的各种问题和场景，相信我们已经知道了BFF可以解决很多场景的问题，这里总结一下BFF的优势：
- 服务端对数据展示服务进行解耦，展示服务由独立的BFF端提供，服务端可以聚焦于业务处理。
- 多端展示或者多业务展示时，对与数据获取有更好的灵活性，避免数据冗余造成消耗服务端资源。
- 对于复杂的前端展示，将数据获取和组装的负责逻辑在BFF端执行，降低前端处理的复杂度，提高前端页面响应效率。
- 部分展示业务，可以抽象出来利用BFF实现，对于服务端实现接口复用。
- 降低多端业务的耦合性，避免不同端业务开发互相影响。
- 其他优势，包括数据缓存，接口安全校验等。
参考
- Pattern: Backends For Frontends
samnewman.io/patterns/ar… - GraphQL及元数据驱动架构在后端BFF中的实践 美团技术团队
mp.weixin.qq.com/s/mhM9tfWBl… - 高效研发-闲鱼在数据聚合上的探索与实践 闲鱼技术
mp.weixin.qq.com/s/9P_16cNEF… - 跨平台架构：如何设计 BFF 架构系统？
www.jianshu.com/p/bfc652bac… - 什么是 GraphQL？ 知乎
www.zhihu.com/question/26… - Serie DDD Artículo 10: Arquitectura BFF
www.cnblogs.com/arrowolf/ar… - Arquitectura BFF basada en computación funcional Alibaba Cloud Cloud Native
juejin.cn/post/684490… - Arquitectura de microservicio: ¿Cómo evolucionaron BFF y las puertas de enlace?
juejin.cn/post/684490… - Práctica de construcción BFF de música en la nube basada en GraphQL Equipo de tecnología de música en la nube de Netease
juejin.cn/post/718201 ... - Big Taobao industria de la tecnología FaaS experiencia práctica compartiendo
juejin.cn/post/714352...