BFF，SFF 到底是什么？

BFF，SFF 到底是什么？

• BFF: Backend For Frontend

• SFF: Serverless For Frontend

关于 BFF 可以参考我的这篇笔记: 《微服务设计》中关于 BFF 内容的读后感

文章核心内容的总结：

至于 SFF，则是阿里 Egg 团队提出的一个新概念，那么为什么要提出 SFF 呢？这就要说说 SFF 的前任，也就是 BFF，它出了什么问题，Egg 团队认为 BFF 存在下面 3 个问题：

• 专业人才储备

  • 远远低估了前端的缺人程度，一将难求，无人可招。

  • 全栈人才的培养成本不低，包括前端需要学习后端 DevOps，后端需要学习前端的用户交互。

• 基建墙，各种流程太重

  • 不同的基建服务需要去不同的后台走申请流程，N 多个工单需等待审批。

  • 像 DRM 的配置、Mobilegw 的配置，需要在每种环境中单独配置一遍。

• 资源浪费

  • 在 BFF 场景下，服务器水位较低（10% ~ 30%），基于微服务的高可用诉求导致了服务器资源的浪费。

  • 譬如在蚂蚁容灾要求下，至少需要 11 台 4C8G 的容器。据此估算，支撑内部上千个中台应用，则就至少需要约 2000 台 32 核物理机！！！

而 SFF 的目标是 提升前端的研发效能，以一当百。

主要思路为：专业的人做专业的事，让业务开发者专注于业务本身的研发。

• 场景化：根据不同业务场景做垂直领域定制，减少不必要的干扰，专注于业务逻辑的开发。

• 轻流程化：打破基建墙，一站式的接入三方服务，减少各种不必要的流程和工单，以代码为中心，声明即接入。

• Serverless 化：让应用能利用云平台实现资源的按需分配和弹性伸缩，从而减少资源浪费。

• 自动化运维：DevOps → noops，减少研发对基础措施和运维的关注，交给我们这些专业的框架维护者。

一句话阐述：让纯前端开发者，只需写几个 Function 即可使用到后端相关的能力。

研发的角色将变为

一些思考与疑问：

回看 SFF 的整体概念，似乎 Egg 团队想表达的核心观点是： 将 BFF 这个层级做成 Serverless 的，这样做也有几个明显的好处：

• 在SFF的模式下，原先 BFF 层里的前端开发在获取后端业务信息时，借助 Serverless 的能力，只需要写一些函数（FaaS）或者直接调用一些基础服务（SaaS）就 ok 了

• 原先的 BFF 层里的服务器维护工作还是相对较重的，一旦 BFF 层级变成 Serverless 的形式，维护将变得更加容易

那么这些 SFF 这个概念对于 我们的 MBC 有一定指导意义么？

我觉得有，而且肯定有！

首先，SFF 提出的三个矛盾，我相信明眼人都可以看到，这就是未来 MBC 会遇到的问题，完全没毛病，但这些问题是现在还不是痛点或者痒点，但等体量大起来，这些问题就会暴露出来。

其次，试想一下在前端 Serverless 化的一个典型网站 CodePen ，如果说它是未来中台控制台的终极形态，也不为过，我们完全可以做到在 CodePen 上直接写几个简单函数，就实现了业务开发，而不再关注一切跟服务器相关的内容，那会多爽啊。这个模式没毛病，除非你非要折腾那些和业务没什么关系的代码。

最后，技术在发展，BFF 是 2015 年的概念了，这个架构关注的核心点是不同端上的差异问题（比如像 b 站 Android 和 iOS 的 app 设计体系是完全不同的两套，长得不一样，所以需要的 API 数据是极有可能不同的 ）和快速开发的问题（摆脱后端的发版依赖，将数据的控制权掌握在前端手里，后端只作为物料的供给方），而这些点已经不全是美团 app 所需要解决的核心问题了（例如美团 app 在 Android 和 iOS 上的样式是完全一致的，其实一套 API 就可以），MBC 在某种程度上将前端的主动权拿回到了自己的手里，也就是灵活性有了，所以研发效率会有一定的提升，那么未来到底怎么再提升研发效率，我想降低开发的门槛会是一个方向(在纯UI 方面，我们已经有了 MTFlexbox，好比你不会 iOS ，不会 Android 都可以，只要会 MTFlexbox 就行，从某种程度上就是降低了开发门槛), 也就是所谓的 Serveless，毕竟这样开发者不用懂太多的服务端知识，就可以马上开发。相信当我们的架构在灵活性和可操作性上都有了很好的平衡，整体的研发效率又会有一个提升。