最近基于自己在项目上实践 BFF 后进行治理的一些相关经验,整理了一篇文章:BFF 治理与优化实践
不知道大家是否在实践 BFF 过程中也遇到过很多问题,欢迎留言讨论
1
afewok 2022-04-06 20:26:48 +08:00
BFF 与 20 年前的后端模板有啥本质区别?性能?效果还是效率??
|
3
Woood 2022-04-06 21:07:23 +08:00
见下图的图挂了
|
5
lotusp OP @afewok
同意 @zoharSoul ,这俩应该没啥关系 关于 BFF ,之前还写过一篇《 BFF 避坑指南》( https://maguangguang.xyz/backend-for-frontend ),里面也讲了下为什么会有 BFF ,欢迎讨论指正 |
6
RiceMarch 2022-04-06 22:22:45 +08:00
BFF 的应急响应能力(可能单纯是我司的技术问题
|
7
LichMscy 2022-04-07 00:53:36 +08:00
写得挺好
我们现在也在做 BFF 层到业务领域层的逻辑拆分,特别拆分 BFF 的表挺麻烦的 |
8
micean 2022-04-07 08:28:29 +08:00
文中的 5 个问题,我的理解本质上都是微服务划分的问题,如果把维修相关合并成一个维修服务,就变得简单很多
|
9
lotusp OP @RiceMarch 应急响应能力能详细说说吗?是 BFF 发生问题时快速解决效率不足,还是 BFF 快速响应业务的需求,开发效率上不去?
|
10
lotusp OP @LichMscy 一般情况下 BFF 应该主要是为前端服务,不太需要存储数据,请问您这边 BFF 的数据表主要是存些什么样的数据?
|
11
LichMscy 2022-04-07 14:15:54 +08:00
@lotusp #10 是这样 老的前后端分离中的后端服务作为 BFF ,目前处于将该 BFF 的逻辑拆分成多个业务领域层服务,在这个过程中比较难协调快速迭代和拆分这两个动作 我看您博客有提到建一个新库然后做同步的方案
|
12
lotusp OP @LichMscy #11 如果是拆分现有的后端服务,可以新建 BFF ,先将后端 API 都经过 BFF 透传。然后根据领域建模等手段分析后端服务该拆成几个微服务,当前后端服务可以作为一个核心微服务保留下来,其他的逻辑拆出去新建服务。这样的话 BFF 作为一个后端微服务拆分的隔离,可以通过 Toggle 等决定走原有的后端 API ,还是新拆出来的新 API ,切换也可以相对顺利可控一点。
|
13
dudubaba 2022-04-08 09:49:27 +08:00
我司之前有个 BFF 接服务端 dubbo ,半年不到沦落成一个复制粘贴代码库,当后端迭代未同步前端,或者前端没专人维护 BFF 时,这个套方案就成鸡肋了。
|