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