BFF架构笔记

了解BFF架构

微服务架构：BFF和网关是符合演化出来的？

1. 在微服务架构中，BFF(Backend for Frontend)也称聚合层或者适配层，它主要承接一个适配角色：将内部复杂的微服务，适配成对各种不同用户体验（无线/Web/H5/第三方等）友好和统一的API。聚合裁剪适配是BFF的主要职责。
2. 在微服务架构中，网关专注解决跨横切面逻辑，包括路由、安全、监控和限流熔断等。网关一方面是拆分解耦的利器，同时让开发人员可以专注业务逻辑的实现，达成架构上的关注分离。
3. 端用户体验层->网关层->BFF层->微服务层，是现代微服务架构的典型分层方式，这个架构能够灵活应对业务需求的变化，是一种支持创新的演化式架构。

BFF全称是Backends For Frontends(服务于前端的后端)，Sam Newman曾在他的博客中写了一篇相关的文章——Pattern: Backends For Frontends，在文章中Sam Newman详细地说明了BFF。本文参考了几篇不同博客和文章，简单阐述一下自己对BFF的认识。

简而言之，BFF就是服务器设计API时会考虑到不同设备的需求，也就是为不同的设备提供不同的API接口，虽然它们可能是实现相同的功能，但因为不同设备的特殊性，它们对服务端的API访问也各有其特点，需要区别处理。

客户端都不是直接访问服务器的公共接口，而是调用BFF层提供的接口，BFF层再调用基层的公共服务，不同的客户端拥有不同的BFF层，它们定制客户端需要的API。是否需要为相似的设备人，如IOS和android分别提供一个BFF，这个需要根据现实情况决定，不同的项目环境解决手段不一样。

 

那么采用BFF架构与多端公用、单一的API有什么优点了？最重要的一点在上文中已经提到了，它能够满足因不同客户端特殊的交互引起的对新接口的要求，所以一开始就会针对相应的设备设计好对应的接口。如果使用单一、通用的API，我们一开始并没有考虑到特殊需求，那么有新的请求需要出现时，可能会出现以下问题：

1. 添加新的接口，容易造成接口的不稳定性；

2. 在原来的接口上改，容易造成耦合，破坏单一职责。

 

考虑这样一个简单例子，因为移动APP的屏幕限制，在某一个列表页我们只需要展示一些关键的信息，但是由于调用的是服务端提供统一的API，服务端在设计的时候只考虑到了web端，返回所有的字段信息，但这些对于移动端而言都是无用的。在优化性能时处理这样的问题时，服务器端就需要新增接口或者通过引入相关耦合来解决这样的问题。而使用BFF在很大程度能避免这样的问题。  
使用BFF的另一个优点就是当由于某一客户端需要调用调用多个不同的服务端接口来实现某一功能时，可以直接在对应的BFF层编写相应的API，而不会影响到基层的公共服务，且客户端不用直接向多个后台发起调用，可以优化性能。

---

当然，凡事有利有弊，BFF带来便利好处的同时也会引起一些问题，如代码重复，加大开发工作量等。所以在使用时需要结合现实情况仔细斟酌，符合项目的应用开发背景。例如蚂蚁财富使用BFF的场景如下。(没有具体分析，有兴趣的可以通过上面提供的链接和查阅相关资料进行研究)

 

使用 BFF 的正确姿势

• 多端应用
  我们在设计 API 时会考虑到不同设备的需求，也就是为不同的设备提供不同的 API，虽然它们可能是实现相同的功能，但因为不同设备的特殊性，它们对服务端的 API 访问也各有其特点，需要区别处理。

• 服务聚合
  随着微服务的兴起，原本在同一个进程内运行的业务流程被拆分到了不同的服务中。这在增加业务灵活性的同时，也让前端的调用变得更复杂。BFF 的出现为前端应用提供了一个对业务服务调用的聚合点，它屏蔽了复杂的服务调用链，让前端可以聚焦在所需要的数据上，而不用关注底层提供这些数据的服务。

• 非必要，莫新增
  我们在看到 BFF 带来的各种好处的同时，也要注意到它所带来的代码重复和工作量增加方面的问题。如果与已有 BFF 功能类似，且展现数据的要求也相近的话，一定要谨慎对待新增 BFF 的行为。因此，建议非必要，莫新增。

实战中的玩法

• 访问控制
  例如，服务中的权限控制，将所有服务中的权限控制集中在 BFF 层，使下层服务更加纯粹和独立。

• 应用缓存
  项目中时常存在一些需要缓存的临时数据，此时 BFF 作为业务的汇聚点，距离用户请求最近，遂将该缓存操作放在 BFF 层。

• 第三方入口
  在业务中需要与第三交互时，将该交互放在 BFF 层，这样可以只暴露必要信息给第三方，从而便于控制第三方的访问。