微服务架构下大家都在实践 BFF，你的 BFF 都有哪些问题？

[lotusp]

最近基于自己在项目上实践 BFF 后进行治理的一些相关经验，整理了一篇文章：BFF 治理与优化实践

不知道大家是否在实践 BFF 过程中也遇到过很多问题，欢迎留言讨论

[afewok]

BFF 与 20 年前的后端模板有啥本质区别？性能？效果还是效率？？

[zoharSoul]

@afewok #1 这俩没什么关联吧? 你是不是把 ssr 和 bff 搞混了?

[Woood]

见下图的图挂了

[lotusp]

@Woood 多谢提醒，已修复

[lotusp]

@afewok
同意 @zoharSoul ，这俩应该没啥关系
关于 BFF ，之前还写过一篇《 BFF 避坑指南》（ https://maguangguang.xyz/backend-for-frontend ），里面也讲了下为什么会有 BFF ，欢迎讨论指正

[RiceMarch]

BFF 的应急响应能力（可能单纯是我司的技术问题

[LichMscy]

写得挺好
我们现在也在做 BFF 层到业务领域层的逻辑拆分，特别拆分 BFF 的表挺麻烦的

[micean]

文中的 5 个问题，我的理解本质上都是微服务划分的问题，如果把维修相关合并成一个维修服务，就变得简单很多

[lotusp]

@RiceMarch 应急响应能力能详细说说吗？是 BFF 发生问题时快速解决效率不足，还是 BFF 快速响应业务的需求，开发效率上不去？

[lotusp]

@LichMscy 一般情况下 BFF 应该主要是为前端服务，不太需要存储数据，请问您这边 BFF 的数据表主要是存些什么样的数据？

[LichMscy]

@lotusp #10 是这样 老的前后端分离中的后端服务作为 BFF ，目前处于将该 BFF 的逻辑拆分成多个业务领域层服务，在这个过程中比较难协调快速迭代和拆分这两个动作 我看您博客有提到建一个新库然后做同步的方案

[lotusp]

@LichMscy #11 如果是拆分现有的后端服务，可以新建 BFF ，先将后端 API 都经过 BFF 透传。然后根据领域建模等手段分析后端服务该拆成几个微服务，当前后端服务可以作为一个核心微服务保留下来，其他的逻辑拆出去新建服务。这样的话 BFF 作为一个后端微服务拆分的隔离，可以通过 Toggle 等决定走原有的后端 API ，还是新拆出来的新 API ，切换也可以相对顺利可控一点。

[dudubaba]

我司之前有个 BFF 接服务端 dubbo ，半年不到沦落成一个复制粘贴代码库，当后端迭代未同步前端，或者前端没专人维护 BFF 时，这个套方案就成鸡肋了。

[lotusp]

@dudubaba #13 感谢分享，看来方案实施是需要团队成员都认可的，否则很难推下去