BFF治理与优化实践

结合一个典型案例的BFF治理思考

在Thoughtworks的第25期 技术雷达中有一个主题:便利背后的陷阱,再次强调了软件开发的一种反模式:

开发团队一般为了图方便,而在其技术生态系统的复杂环节中,引入一些不合理的行为,从而欠下长期存在的技术债务,并会引发更糟的问题。这种例子不胜枚举,包括将数据库作为集成点,使用 Kafka 作为全局编排器,以及将业务逻辑代码混杂到基础设施代码中。

诚如雷达中所说,这种反模式在软件开发中不胜枚举,开发团队必须时刻警惕,精心设计,持续地进行软件架构治理活动,避免为图一时之便而选择不合理的设计,欠下更多难以偿还的 技术债

为了更深刻理解这种反模式带来的问题,我们先来看一个典型案例:

从一个BFF优化案例谈起

这个案例选择了一个在BFF(Backends For Frontends)中实现稍复杂的接口,但并不是最复杂的接口。接口的逻辑参见下图:

可视化永远是发现问题最好的手段,上图中描述的接口复杂度一目了然,甚至有点触目惊心,一个API背后的逻辑居然能复杂到这个程度,如果不加梳理并可视化出来我们可能没有这么直观的感觉。这是在BFF暴露给前端的接口,实现过程中需要调用后端10+个服务,进行几十次的服务间调用。在这几十次服务间调用过程中,有大量的读操作,以及近10次的跨服务写操作,读操作主要为了满足写操作的数据组装要求。

为了更清楚地理解这个接口设计背后的原因,我们再从业务逻辑的角度来看看这个接口都做了什么?这个接口有大量的写操作,可以从近10次的写操作中直观地看到一些端倪。通过上图中的时序,相信大家已经能看出一些问题了,咱们从业务和技术两个视角来一起看下这个接口:

  1. 业务视角 把上面的关键功能快速分类,可以分成两块:一块是更新维修项状态,以及由此触发的维修单状态和维修商品状态更新。另一块是根据更新后的状态,生成相关文档,并记录文档和维修项的关系。

    通常情况下,文档的打印都不是一次性的功能,会有多次打印的需求,但数据状态更新是一次性的,因此将这两大块功能放到一个逻辑背后是不合适的,使用频率不同,对失败的容忍程度也不同。

  2. 技术视角 技术上的问题比较突出,重点总结为以下几点:

    • 问题一、BFF承载了过多的业务。从上面的两大块业务功能来看,如果去掉这个BFF,后端是不具备完整的业务能力的。这正是我在《BFF避坑指南》中描述的一个BFF实施常见问题,将BFF实现成了企业级服务总线(ESB)。后端服务只需要具备必要的增删改查接口,BFF就可以完成前端的大部分需求。这样的BFF 以一己之力承载了前端所有的业务,最终一定会走向大泥球,成为架构中的瓶颈和脆弱点。
    • 问题二、后端服务接口设计不是面向业务能力,而是面向数据。在这个事例中,一个BFF接口中要调用3个维修单服务接口才能完成完整的逻辑,维修单服务并没有将完整的业务能力内化在自己的服务内,而是提供了一些可以组合的接口,这也是开发者将大量逻辑写到BFF中的众多原因之一,或者说是BFF这种实践思想的一种后果。
    • 问题三、后端服务间数据关系比较紧密,耦合较重。一个业务状态的更新会涉及三个后端服务数据的更新,这背后的坏味道就是服务间耦合较重,边界不清晰,会导致大量业务功能需要多个服务配合才能完成。
    • 问题四、一个接口完成多次写操作,很难保证数据一致性。任何一个写接口的失败都会中断整个流程,而中断点不同,产生的数据一致性问题也不一样,在不采用分布式事务的情况下,这个接口上线后一旦产生问题,都将是非常棘手的。
    • 问题五、接口逻辑过于复杂,很难保证性能,稳定性差。几十次的跨服务间调用,即便每个调用都是毫秒级响应,这个接口的性能最好也只有几百毫秒,稍有波动就会上升到秒级,甚至更差,很难保证线上的稳定性,在有网络波动或异常的情况下,用户体验极差。

BFF治理的原则与措施

上面的案例虽然不能覆盖BFF实践过程中的所有问题,但大部分典型的问题都暴露出来了。我们可以借着这个案例来讨论如何在实践中优化BFF的设计,达到治理的目的。

在给出改进方案之前,为了保证方向的正确性,我们先看下BFF的设计原则:

  • BFF为前端而生,关注点在提升前端用户体验。
  • BFF不承载业务能力,业务逻辑要下沉到合适的后端服务中。
  • BFF不承载特定技术能力,必要时可以建立专门的服务承载,如文档打印、Excel生成、算法逻辑等。
  • BFF不做后端服务的集成层,某个后端服务的数据变更需要同步到其他服务,不能通过BFF实现。

仍然以上面案例里的场景为例,经过上面的分析,关键的问题已经找到了,就可以对症下药了。还是分两个视角来看:

  1. 业务视角 从业务视角的优化显而易见,就是优化现有交互流程,将这一步操作改为两步,先完成业务数据的逻辑变更,再进行文档的逻辑处理。

  2. 技术视角 从分析中可以看到,BFF暴露出来的问题其实不仅仅是BFF自身的问题,也反映了后端服务的问题,因此要治理BFF,首先要对后端的服务进行优化治理,再调整BFF内部的问题:

    • 从业务能力出发,重新审视后端服务之间的边界,必要时将耦合紧密的服务进行合并。
    • 重构后端服务提供的接口,面向业务提供接口。比如案例中更新维修单状态后,需要记录维修历史,需要关闭维修单,这些逻辑都在维修单服务中通过逻辑的关联处理完成。
    • 将BFF中的业务逻辑下沉到合适的后端服务中,后端服务之间要保持有效的通信机制,保证数据变更引发的连锁更新可以有序准确地完成,而不是由BFF作为集成媒介,在有写操作的场景下,BFF只调用具备这个业务能力的后端服务接口,由这个后端服务负责处理所有相关数据的更新。在案例中,维修项和维修单的状态更新,应该根据前面的业务能力分析,放到某一个后端服务中来控制,或者放到二者合并后的服务中,最后再由这个后端服务负责完成与商品服务之间的数据更新。
    • 将BFF中的特定技术能力抽取成共享库,或者下沉建立服务。在案例中,生成文档的功能就可以建立一个单独的服务来处理,既解决BFF的问题,也能提供更好的复用能力。

在这些优化梳理和落地的过程中,一定还会发现其他相同或类似的问题,任何一个软件架构走到需要治理的地步都不是一个接口的问题,一定是一系列相互关联的问题,往往优化的过程中需要一起考虑,站在更高的视角来统一规划。

BFF治理的方向总结

在微服务架构下,BFF模式是非常必要的一种实践,特别是在微服务比较多的情况下,BFF分离了前后端,可以让前端和后端更专注在各自的领域。在软件架构中,边界的处理是最难的,BFF作为中间这一层,作用非同小可,其落地实践对架构的影响至关重要。BFF治理是微服务架构下的软件架构治理中非常重要的一部分,通过BFF治理也能发现很多前端或后端设计的问题。

经过上面案例的分析,总结一下BFF治理的主要方向:

  • 首先分析BFF问题背后是不是存在后端服务设计问题,优先解决后端服务的设计问题。
  • 从业务上分析BFF接口的职责,保证接口职责单一。
  • 将BFF中业务能力下沉到后端服务。
  • 将BFF中需要复用的技术能力抽取成共享库或下沉建立后端服务。
  • 避免一个BFF接口依赖过多的后端服务,根据系统复杂度来看,最多依赖不超过5个后端服务为宜。
  • 避免一个BFF接口多次写操作,不滥用BFF站在上帝视角所拥有的权利,各司其职。

BFF (Backends For Frontends)是为前端设计的后端,不可图一时之方便而越俎代庖,将大部分该由后端服务提供的能力据为己有,而更应该关注在前端的体验优化上,做好前后端的隔离,让前后端能够各司其职,合理高效协作。


相关文章推荐

All rights reserved
Except where otherwise noted, content on this page is copyrighted.