全栈大前端

# BFF 基本概念

  • BFF
❝ 在聊Serverless之前跟大家先谈谈BFF，BFF顾名思义就是Backend For Frontend,用中文解释就是服务于前端的后端，那么为什么会有BFF？
1

前端同学和后端同学都各有各的道理，有没有一种解决方案可以化解这种尴尬的场景，于是就有了BFF

1.1 介绍

❝ BFF层初衷是在后台服务与前端（客户端）之间添加一层，接下来我们来看看下面这张图
1

❝ 啊宽同学提问：那BFF到底发挥什么作用？
1

答案是：用户体验适配层和API聚合层 : 主要负责快速跟进 UI 迭代，对后 端接口服务进行组合、处理，对数据进行：裁剪、格式化、聚合等

在BFF层下面是各种后端微服务，在BFF上层则是各种前端应用（多端应用），向下调用后端为服务，向上给客户端提供接口服务，后端为BFF层的前端提供的的 RPC 接口， BFF 层则直接调用服务端 RPC 接口拿到数据，按需加工数据，来完成整个BFF的闭环（以Node+GraphQL技术栈为主）

❝ 啊呆同学提问：那BFF层谁来开发？
1

遵循服务自治，谁使用谁开发的原则，也就意味着只能由前端同学来挑起这个重任，同时着离“全栈工程师”又进一步了。不知道 ‍♂️ 是应该庆幸还是苦恼咯

BFF是否可以由后端来做？当然可以，只是说带来新的问题，就总是包接口，会导致个人能力提升受限

❝ 啊宇同学提问：你是不是漏了api网关？
1

这个问题好 BFF和网关Gateway都是微服务架构中的重要的两个概念,看下图简单的例子

❝ 分享一下蚂蚁金服体验技术部负责人玉伯，曾说的一句话：“BFF 模式不仅仅是一种技术架构，从社会分工角度讲，BFF 更是一种多元价值导向的分层架构”
1
2
  • BFF的优势
  1. 可以降低沟通成本：后端同学追求解耦，希望客户端应用和内部微服务不耦合，通过引入BFF这中间层，使得两边可以独立变化
  2. 多端应用适配：展示不同的（或更少量的）数据，比如PC端页面设计的API需要支持移动端，发现现有接口从设计到实现都与桌面UI展示 需求强相关，无法简单适应移动端的展示需求 ，就好比PC端一个新闻推荐接口，接口字段PC端都需要，而移动端呢H5不需要，这个时候根据不同终端在BFF层做调整，同时也可以进行不同的（或更少的）API调用（聚合）来减少http请求
  • BFF的痛点
  1. 重复开发：每个设备开发一个 BFF 应用，也会面临一些重复开发的问题展示，增加开发成本
  2. 维护问题：需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上
  3. 链路复杂：流程变得繁琐，BFF引入后，要同时走前端、服务端的研发流程，多端发布、互相依赖，导致流程繁琐
  4. 浪费资源: BFF层多了，资源占用就成了问题，会浪费资源，除非有弹性伸缩扩容

  • 1.4 有什么方案可以解决传统BFF痛点？
  1. 包括解决前端需要关心应用的负载均衡、备份冗灾、监控报警等一些列运维部署的操作
  2. 如何统一管理和运维，提高发布速度、降低运维成本
  3. 使用ServerLess

← ServerLess →