BFF是近些年新衍生出来的一种开发模式，或者说是一种适配模式的系统，BFF全称为Backend OF Front意为后端的前端，为了适配微服务模式下前端后端系统接口调用混乱而出现的。在如今微服务盛行的趋势下，大型系统中划分出了数十个服务模块，例如商品，门店，运费，红包，订单，优惠券，CMS，用户，搜索，推荐，广告等等系统，前端也有小程序，APP，网页等端。由此产生了很多问题：
痛点
- 前端问题：每次需求开发前端要对接多个系统来确认接口信息，不同的数据要找不同的系统，各个接口散落一地，开发调试的效率极低。
- 后端问题：后端同样也需要各自包装数据信息来提供前端处理，重心变成如何为前端提供数据，因为需要根据不同的版本、客户端、用户、定位等特征来判别，很多时间浪费在展示层，而不能专注于业务逻辑处理，每个后端系统各自为战，都有自己的接口规则，各种历史版本问题都不能完全统一，所有系统都严重耦合了版本问题。
- 变更不灵活：当产品想要更新需求时，更是牵一发而动全身，某一块的小改动需要在各个系统之间找接口来回沟通，大部分系统都要重新上线一次。
如下面，前后端的沟通链路过多。
BFF网关定位
鉴于此痛点，需要一个中间层来适配前后端服务，BBF由此而生，它负责将所有下游后端接口进行统一调用，下游接口只需要提供RPC接口供网关使用，BFF网关提供WEB接口来让前端调用，最后将数据进行组装拼接，根据前端的需求来返回数据。
所以BFF的核心定位就是：“统一下游接口，为前端提供服务”。
只有把握好服务这个概念，才能做好BFF网关系统，其他系统可以扯皮甩锅，但BFF网关不可以，它与生俱来的使命就是把这两边拉扯起来，所有不合理不合适，繁琐无用的逻辑都需要BFF网关去处理，后端只要做好业务逻辑，前端做好展示，其他的都可以交给BFF网关。
BFF网关特点
琐碎
BFF网关主要为前端进行服务，前端不关心版本、客户端、定位、用户身份等情况，只接收渲染数据即可，而这些逻辑都需要耦合到BFF网关中，以版本、客户端、定位、用户等特征作为纬度，其中版本最为最复杂的分支，可能贯彻整个系统生涯几十个版本类型都需要做兼容，由此还需要兼顾不同客户端的展示要求和用户特征，所以BFF网关中必然需要做大量判断分支，根据上百种情况组合判断来生成-唯一版本-唯一端-唯一用户的数据结构。
数据琐碎
BFF不需要数据库，这点会在下面说明，所以有很多数据需要以静态变量的形式存放在代码里，或者是使用配置中心来动态配置，例如图片地址、各种色值、模块固定文字、处理标识等，这些琐碎的数据都会存放在BFF网关中进行维护，如果放在前端，修改时必须要进行发版，时间周期太长，而存放在后端的话，又会打散数据，不能从一个地方作为主要数据窗口进行管理。
逻辑琐碎
衍生第一点说到的，BFF网关作为下游接口的聚合，每次流程需要调用数十个后端接口，再根据版本、端、用户进行逻辑处理，历史逻辑与新需求杂糅在一起，实现新功能的同时要不断兼顾历史逻辑，只能是加入大量的分支判断，最后变成了if大爆炸，或者使用策略模式进行优化，但无论如何怎么包装都无法掩盖琐碎的逻辑。
性能
BFF网关的耗时主要有两部分
- 内部处理耗时
- 下游RPC接口耗时
BFF作为最直接和前端交互的接口，BFF的耗时将直接影响用户浏览体验，所以BFF性能一定要最优，不断压缩耗时来提高接口响应性能，内部逻辑优化时，首先观察下游接口耗时情况，各个模块之间难免重复调用接口，可以使用编排框架将下游接口调用进行优化。然后使用线程池进行并发处理，能够并发处理的一定要并发执行，这样可以极大降低下游接口耗时，提供接口处理能力。
缓存
切勿在BFF网关中使用缓存
此处指的缓存主要是Redis等中间件缓存，BFF网关主要数据来源都是通过调用下游接口获取，这里是最耗时的，如果想要减少下游接口耗时，应该使用并发或者编排能力，而不可以通过缓存下游接口数据来实现。
- 成本问题：下游接口数据会根据传入的定位、用户等信息查询，当系统用户量大、覆盖城市多时，需要缓存的数据量将剧增，而数据缓存后再次访问概率很低，造成严重的缓存空间浪费。
- 一致性问题：BFF网关的引入主要是为了统一后端接口，性能是网关的一大指标，但不能为了性能将所有下游接口数据进行缓存，从而牺牲数据一致性，后续展示时一旦出现问题，将增加排查难度。
降级
任何时候都不要将错误直接返回给用户，不论是下游的错误还是系统内部的错误，这一点完全可以交给BFF网关来做，这里降级可以分为两类型处理。
- 下游接口降级：当下游接口出现超时或数据异常时，一定要做好降级措施，例如增加接口超时时间判断，及时中断调用，不要因为某个下游接口而影响整体性能，当下游接口报错时，也要做好异常捕获，整体页面可以直接丢弃这部分数据不做展示，而不能完全不展示。
- 异常整体降级：在BFF网关内部处理逻辑中难免会有错误发生，或者下游核心的定位、商品等接口异常，这里就需要做整体降级，例如模拟一个友情提示页面等，提示用户稍等重新刷新，或者在未开通城市里可以引导用户切换地址，整体页面的降级尽量交给BFF网关来做，而不要分散到不同的前端来做。
BFF网关划分
接口粒度
如上图，BFF网关的下游接口较多，如何聚合下游接口进行划分是一个需要考虑的问题，这里提供的建议是按照页面来划分，例如在首页可以提供首页接口返回整体展示效果，购物车页面提供购物车接口，以页面为单位划分可以方便前后端的统一处理，当然如果页面内容太多时，BFF网关接口可能耗时较多，可以同页面拆分开来，让前端并行加载接口，这样既能降低整体页面加载时间，也能让BFF网关减少下游接口调用。
数据安全
BFF网关虽然也叫网关，但数据安全方面例如安全攻防等主要还是外层去做，BFF只负责数据的调用组装，不要再赋予其他太多功能，但BFF网关一定要有限流逻辑，可以采用Sentinel等框架实现，防止某个前端异常进行大量请求，打垮BFF网关导致所有前端异常。
上线注意
BFF网关较为单薄，没有依赖的数据库等大型中间件，可能只是用到比较轻量的配置中心和消息队列，所以上线时初始化参数较少，但因为BFF网关需要做版本、定位、客户端等特征的数据处理，所以一定要做好灰度上线，防止新功能影响到历史版本、不同定位下的用户浏览。
优势总结
BFF网关的引入：
- 降低后端开发联调成本：直接提供RPC接口将基础数据返回即可
- 降低前端开发联调成本：直接对接一两个接口就可以拿到全部数据，并且可以将很多前端写死的逻辑交给BFF网关做下发，提高前端展示的灵活性。
- 方便需求迭代升级：当大量前端逻辑移植到BFF网关，很多需求的上线不再依赖前后端发版，直接让BFF快速上线更新即可。
- 提高用户体验：BFF网关可以较低成本的做异常降级处理，为前后端包装错误提示，统一异常捕获类型。
- 提高系统性能：虽然引入BFF网关相当于多加了一层，但BFF网关可以通过并发调用下游接口，或者线程池的形式提高接口处理性能，而不需要像之前前端去逐个调用接口，规范了整体接口调用执行逻辑。
