这是一个创建于 961 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近基于自己在项目上实践 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 时，这个套方案就成鸡肋了。
|
Select Language