BFF的学习途径
部门分享知识的题目为：BFF是什么，怎么使用？
看到这个题目时，我是非常懵逼的，因为之前的工作中并没有涉及到过，所以这对我来说是一个未知的领域。没有办法，那就自己探索吧，也能让自己扩展一下知识面。
首先，遇到一个新知识，肯定先请教一下有经验的老师，所以我就抱着试一试的心态看B站上有没有详细讲解BFF的，确实是个冷门知识，没有。那只能通过一些博客去了解啦，于是又查看了一些博客，，例如：CSDN，知乎，掘金等等，其实博客的学习范围也是有限的，一般就几个原创理解，其他都是转载；
在浏览了有十几篇文章后，其实我只能知道大概是做什么用的，具体为什么要这样，它内部怎么实现的，还真需要再深层次探索，其实BFF这个东西并不难理解，只是与很多我之前没有听到过得知识点有很大的关联使用，例如：网关，微服务架构，GraphQL技术等等，
BFF产生背景
问题一：
相信大家工作中也会遇到这种情况，然后便开始了下面的对话：
小李：“前端请求2个接口再组装不就行了吗？”–后端追求服务下沉和解耦
小红：“少一次http请求啊，再加个接口有那么难吗？”–前端追求更好的用户体验
问题二：
正常情况下，不考虑任何性能问题，后端的一个接口，不同的终端都能使用，但是pc端主要以操作为主，涉及增删改查，需要的返回的数据多，而大家都知道移动手机端，一般都是作为展示信息为主，并且屏幕有限，需要的可能就是四五个字段。其他拿到的数据没有任何作用，也会占用网速，加大延迟
BFF是什么？
这个时候我们就需要用到BFF了；
我们要聊的是BFF层，即 Backend For Frontend（服务于前端的后端）；不是一门技术，也通常叫做适配层或者聚合层；
那为什么叫适配层和聚合层呢？
BFF的作用就是用户体验适配层和API聚合层 : 主要负责快速跟进 UI 迭代，对后端接口服务进行组合、处理，对数据进行：裁剪、格式化、聚合等
相当于前后端之间的一个和事佬。后台服务与前端之间 添加一层BFF层后，把所有要请求多个微服务的数据聚合任务在它这里做了，它本身也是一个微服务，所以可以对外提供一个接口就行了，这样app就不用请求多次了
下面这张图是一个成型的微服务架构模式，大家可以看到，BFF层很类似api网关，也可以有多个分别服务于不同的终端；
BFF层的应用场景
1.多端应用和聚合服务
目前我们有甚多终端设备，像Android，iOS移动端还有pc端，同时需要后端服务的一个接口，终端不一样，后端接口也不太一样；
假如编写一个公用接口，返回所有的数据，移动手机端的屏幕窄只需要展示几个字段就行，全部展示造成消耗内存，加大延迟；pc端一般做的事增删改查，需要的获取数据多，还可以；所以为了适应多端应用和方便日后维护，我们就需要 BFF 作为中间件。在这个中间件上我们将做一些业务逻辑处理；
2.应用缓存
项目中时常存在一些需要缓存的临时数据，而BFF层作为业务的汇聚点，距离用户请求最近，所以可以将缓存操作放到该层；
3.第三方交互
在业务中需要与第三方交互时，将该交互放在BFF层，这样可以只暴露必要信息给第三方，从而便于控制第三方的访问；
BFF 的优势
- 可以降低沟通成本：后端同学追求解耦，希望客户端应用和内部微服务不耦合，通过引入BFF这中间层，使得两边可以独立变化
- 多端应用适配：展示不同的（或更少量的）数据，比如PC端页面设计的API需要支持移动端，发现现有接口从设计到实现都与桌面UI展示需求强相关，无法简单适应移动端的展示需求，就好比PC端一个新闻推荐接口，接口字段PC端都需要，而移动端呢H5不需要，这个时候根据不同终端在BFF层做调整，同时也可以进行不同的（或更少的）API调用（聚合）来减少http请求
BFF 的缺点
- 重复开发：每个设备开发一个 BFF 应用，也会面临一些重复开发的问题展示，增加开发成本
- 维护问题：需要维护各种 BFF 应用。以往前端也不需要关心并发，现在并发压力却集中到了 BFF 上
- 链路复杂：流程变得繁琐，BFF引入后，要同时走前端、服务端的研发流程，多端发布、互相依赖，导致流程繁琐
- 浪费资源: BFF层多了，资源占用就成了问题，会浪费资源
BFF分层下的“幸福烦恼”：
