[微服务/API时代的前端开发] BFF进阶--实践中常见的3种反模式

1,339 阅读9分钟

译者按

译者在学习BFF时,有幸读到了作者古川陽介写的这一系列文章,收获颇多。由于在网上没有找到类似的中文资料,所以想将其翻译为中文,分享给小伙伴们。作者在这一篇强推了自家的Agreed,译者没有使用过,Open API Generator似乎可以做到同样的事,有兴趣的朋友不妨了解一下。

前言

上一篇介绍了BFF相关的5个使用案例。本篇将结合笔者在实际项目中多次采用BFF的经验来说明反模式出现的原因和相应的解决方法。

BFF 是一种架构模式,但并不是任何情况都适用。如果对它的优缺点了解不够透彻,就冒然采用的话,你可能会后悔。我在实际项目中多次采用了BFF,但并非所有项目都很成功。相反,由于引入的新的东西,从而产生了一些新的问题,而且责任范围的改变也造成了一些项目上的失误。

因此,这一篇,我将根据我的经验介绍以下三种BFF反模式。反模式名称是我自己取的,是为了方便起见,命名如下:

  • 导致沟通不畅的“稀疏沟通”
  • BFF处理过度的“Fat Front”
  • 最后阶段一次性发布的“Big Bang Joint” 反模式的原因通常是组织的问题和沟通的问题,当然我也会介绍如何避免这些问题。

【反模式1】导致缺乏沟通的“稀疏沟通”

由于使架构松散耦合(Sparse),沟通也变得“稀疏”的现象称为“稀疏沟通”。造成这种现象的原因包括不重视“报告、联系、咨询”和“因组织不同造成的沟通成本”。

BFF使得架构保持松散耦合,并不意味着前端工程师和后端工程师之间的沟通就可以忽略不计。在很多情况下,没有哪一个系统不需要沟通就可以创建。

加强对API的共同理解,并同时开发前端和后端

直接避免稀疏沟通的唯一方法是“沟通”。另一方面,可以通过技术减少对 API 认知差异。

一种做法是将前端和后端的代码放到同一个仓库,同时将基于“Swagger”或“Agreed”的API规格和源代码一起管理。当更改 API 规格时,也会提交PULL REQUEST请求,这样可以将API的变更通到给整个开发团队。

消费者驱动合约(Consumer Driven Contract)

作为另一种解决方法,可以先在后端确定好了 API 规格之后,前端再开始实现。这样做认知偏差发生的可能性较小,但前端的实现速度较慢。

因此,Recruit 正在研究一种称为“Consumer Driven Contract”的方法,以同时进行前端和后端的开发,并减少 API 的认知差异。

Consumer Driven Contract是前端主动决定API规格的一种方式。更多细节可以在“Consumer-Driven Contracts: A Service Evolution Pattern”中找到。

image.png

在常规方法中,后端即上图中的“Provider”定义API规格,前端即“Consumer”相应地创建客户端。具体来说,利用Recruit 开发的“Agreeed”,前端将率先决定API规格如下。

image.png

首先描述前端要发送的HTTP Request和要接收的HTTP Response的定义,称为“契约(Contract)”。之后,根据这个契约创建一个 API 模拟服务器。

经过一段时间的开发后,该契约可以成为测试后端的 API 客户端。

image.png

这样做,消费者和提供者都可以在减少 API 认知差异方面发挥作用。如果后端更改实现或前端更改 API 规格,则更改将以 Agreed 为中心传播。通过让后端测试失败或前端代码不工作,使得彼此对更改变得敏感,可以减少认知差异。

当然,漏洞很多,所以即使你采取了这个方法,交流也是必不可少的。

详情请参考《[Recruit Technologies Frontend Development 2016](yosuke-furukawa.hatenablog.com/entry/2016/…

【反模式2】BFF处理过度的“Fat Front”

前面系列已经讲过,通过设置BFF服务器,可以将各种处理转移到BFF上,不需要在后端管理会话等。但是,BFF 只是用于在前端创建网页和用户界面 (UI) 的服务器。如果从后端转移过来的处理过多,BFF的负载就会增加,从而导致整个服务的性能下降。

这种情况被称为“胖前端(Fat Front)”。

说到实际的问题,BFF出现了所谓的“N+1问题”的现象。用于搜索之类的列表查询的API过于简单,在一个处理中无法获取页面显示所需的信息,而是分割成两个处理:“列表查询(只列出ID)”和“详细信息查询(从id获取其他属性)”。结果,我们不得不发出多个请求。

情况如下。创建用户列表画面时,搜索“/users”,此时以JSON形式返回ID列表。

image.png

接下来出现了这样的一个现象,按照ID的数量发起“/users/{id}”请求,每次获取一个ID的详细信息。

image.png

这样一来,即使 API 可以高效并行执行,BFF 和从后端获取信息也会花费太多时间。理想情况下,如果从一开始就将详细信息包含在列表信息中,则可以通过单个 API 请求获取所需的信息,并且不会导致 BFF 过载。

明确 BFF 和后端职责

当BFF和后端的责任不明确,理解不够时,就会出现胖前端。

再一次强调,BFF是UI的服务器,主要作用是“显示”相关的处理。另一方面,后端主要负责提供独立于 UI 的“核心”功能,称为“领域逻辑”或“业务逻辑”。要想预防胖前端,首先这个共识很重要。

如果你觉得BFF处理在增加,你应该停下来考虑一下是否可以改变后端API。

【反模式3】 最后阶段一次性发布的“Big Bang Joint”

不限于BFF,在并行开发API和前端时,尽可能减少相互认知的差异很重要。因此,我介绍了Consumer Driven Contract方法和将API规格放到同一个代码仓库的方法。但是,无论如何努力,始终存在认知差异和BUG等不确定性。

发生这些并不是坏事。问题在于,不考虑这些不确定性,而在临近发布时,才将BFF和后端结合到一起。

留有余地很重要,要小心“突然的结合导致系统停滞”。

逐步结合BFF和后端

在我的团队中,我尝试在固定时间一点点地与后端结合,而不是突然结合。未实现的 API 使用 Mock ,并逐渐增加已实现的后端的比例。

image.png

此外,在逐步连接到真实后端的过程中,我们可以尽早发现不一致和错误。但是,前端还没有实现的部分是无法在页面上确认的。这部分的确认会延迟,当出现差异或错误时,需要考虑到这一点,同时最好从可能存在较多返工的部分优先开始着手。

即使采用逐步结合的模式,BFF和后端的结合也需要时间。所以建议充分预留缓冲时间。

组织问题与架构设计之间有着密切的关系

上面介绍了三种BFF反模式以及如何避免,感觉如何?

许多反模式根源于组织问题。首先,BFF 和微服务是根据组织的形态而演进出来的架构。组织面临的挑战与架构设计之间有着密切的关系。

架构本身并不能直接解决组织的问题。为了让组织的问题更好解决,需要采取“沟通”、“加深对BFF和后端的了解”、“制定时间表和工作开展方式”等方法。

如果你误以为“引入BFF可以解决组织问题,提高开发效率”,并不假思索地采用,那就解决不了问题。

前端开发的未来

最后,我将总结到目前为止在该系列中所讲的内容,并在可预测的范围内谈谈基于 BFF 的前端开发的未来。

BFF模式的产生是由于微服务的架构,一些服务于前端的功能被转移到特定服务器。在实践中,前端工程师不仅需要关注浏览器的行为,还需要对CPU和内存、调优、HTTP协议等服务器端资源监控有深入的了解。

前端工程师和后端工程师有分工,但也有很多需要共享的知识。前端工程师不能“因为BFF是服务器”而对BFF监控和调优无动于衷。另一方面,后端工程师也不应该回避说“BFF不是我的开发,前端代码不熟悉”。提高服务质量这一点上,前端和后端是相同的,都必须面对。

不知道未来BFF会不会成为前端和后端之间的桥梁,或者BFF本身的概念是否会被废除。从“技术在反复回旋中进步”的流程来看,可以想象,曾经因微服务而偏向松耦合的架构,将再次回归紧耦合。 从这个角度来看,与其说未来“前端与后端的距离在拉大”,倒不如说是“在靠近”。 为此,前端和后端都必须毫不犹豫地接受彼此领域的知识。

BFF架构模式是一种充当前端和后端之间桥梁的技术,我认为它是一种符合当前趋势的架构

相关文章