系统服务构建-BFF助力前后端分离
专业术语
本文试图讲明白软件架构中的一个新概念 BFF，涉及到的几个技术概念先做一个前置约束和语意说明
前端应用：负责直接呈现给终端用户的应用系统，如网站，APP 等带有界面的软件系统。一般由 VUE PHP Node 语音开发
后端应用：负责从数据源获取数据，以 API 接口的形式对外输出数据的软件系统。一般由 Java PHP C# 语言开发
BFF 应用：Backend-For-Frontend，本文讨论的核心，为前端应用提供 API 接口的应用，数据源可以是后端基础应用接口，也可以是从数据库等数据层直接获取。
BFF 产生背景
在没有 BFF 架构之前，调用接口方式如下图所示，就是根据后端服务的常规调用
前后端调用
传统的接口调用
互联网应用在发展的过程中，随着业务体量的增大和人员组织结构的复杂，前端应用直接调用后端团队对外公开的业务接口显得越来越吃力。
主要表现在以下三个方面
数据裁剪
后端业务接口返回的业务字段比较完整，前端应用根据页面展示和业务需求，只需要部分读取字段的场景越来越多。
像 PC 端数据展示和手机端数据展示一定是有差别的。
由于客户端类型不同造成了访问接口的诉求不一样，移动端更倾向于较少的请求，较少的数据，以及个性化的数据呈现。
这个理解为数据裁剪。
数据聚合
从数据的来源来说，因为微服务的关系，后端应用的数据拆分的比较独立和分散，而前端应用往往需要一个完整的业务闭环。
一个业务需要从多个数据源获取数据，并进行简单的加工处理，比如时间格式显示，文案转换等。接口数量的合并和整合可以理解为数据聚合。
数据透传
透传全称是透明传输,在网络协议分层的数据链路层有提及，理解为传输的内容在从源到目的的过程中，底层协议不对业务数据内容做任何改变。
比如说微信生态下的业务域名回调，会有绑定域名数的限制。后端接口集中在一个域名下，会比较统一和方便。这个时候，前端应用直接对接的 BFF 服务，更多的起到数据透传的作用。
BFF
一定程度上前端开发者会喜欢这种透传模式，原因是排错简单。而开发透传应用的会觉得这样的工作内容比较枯燥和缺少意义。
实际开发中，前端开发最关心接口数据出了问题，我找谁可以解决。
同一个业务，我是找 BFF 开发者呢还是后端开发者，BFF 开发者会不会推脱到后端开发者，让整个问题的排查链路又长又复杂。
显然 透传最大优势，有问题就是后端的，透传么，只是通道而已。
不过，要简单，省心，前端还得依赖 BFF 的聚合裁剪。
BFF 层的职责
BFF
基于以上的讨论，我们可以归纳出 BFF 层的职责是：基于后端基础数据做业务，按需整合接口，服务于前端应用的需求多样性和快速迭代频率。
BFF 由谁来负责开发
如果 BFF 层是一个项目的话，这个项目一般由前端团队负责。
注意这里是一般，具体的度量标准就是看业务的体量。
简单的是一个项目，复杂的是一个层，在组织架构中就是用一个部门来承载。
Using one server-side BFF per user interface.png
BFF 优势
增加 BFF 层可以有哪些优势
我们可以把 BFF 层理解为经典的软件架构分层中的业务逻辑层。
这里的业务逻辑旨在减轻前端项目工作的压力，使前端专注于页面渲染和页面特效处理。
前端项目和后端服务更加独立，让前后端分离更加彻底。
按前后端的思路来，那前后端项目按需发布和分步迭代开发等分离的优势就显现出来了。
BFF 注意事项
❝详细的数据流日志 ❞
从数据的流向来看，BFF 属于数据使用的下游使用方，下游总是要依赖于上游的，涉及到数据源获取的功能块，需要做好输入输出日志。参考 系统化服务构建-调用链管理
日志的格式保留最原始的数据格式，包括参数格式和参数值。
一旦后续有疑问和问题，方便定位问题和责任切割。
❝识别核心业务 ❞
BFF 由于是中间层，所以会趋向于远离核心业务层。
在项目开发过程中，需要识别好核心业务是哪些，识别核心业务，有助于确定哪些字段不需要随意修改。减少对字段含义，命名格式的改变。
异构系统，代码规范，数据库字段约束，随处可见都会带来字段语义，形式的不同。不增加额外的维护成本是一个基本原则。参照我之前写的这篇经验文章
分工协作，守土有责
BFF 体现了分层设计的精髓，业务模块保持灵活，基础模块保持稳定。
深度前后端分离思想，体现在服务接口和页面展示深度分离，前端直接对接 BFF。
至此可见，BFF 的优势是分离了项目耦合度，项目独立整洁，缺点是增加了项目复杂度.所以就会有不同的声音。
❝一个人能干的活，现在需要三个人干？ ❞
对于这个疑问我想说的是，软件项目随着技术和时代的发展，已经过了一个人大包大揽的时代了。
❝分工协作，守土有责，各自负责一块功能，更科学的协作和推进，是现代软件开发正确的方式。 ❞
现实中的 BFF
在和别人聊天的过程中，BFF 这个概念还比较新颖和生涩。
实际上还是要依靠业务驱动，BFF 才能逐渐演化为一层项目的集合，把能力以服务化的形式共享到前端的多个应用。
这样 BFF 的作用会更明显，也会被更多的人接纳和使用。
我眼中的互联网乱像
不管是 BFF 还是中台，想要落地，最终是一个人和组织的问题。
项目多了，公司大了，人手充裕了，至于为什么会出现人们垢病的沟通协作慢，研发和产品相互为敌，人心不齐的现象，原因很复杂。
大致逃不过以下几点
利益不统一造成人心不齐
不信任害怕担责任
使命感不强，没法成就自己和成就团队。其中有这么一个观点
PHP 的机会在哪里
这一小节回答本文开始提出的疑问，PHP 开发者的机会在哪里？
从实际情况来看，一旦后端团队有 Java 的参与，那么 PHP 大多不存在或者隶属于前端。
他们的职责是调用后端接口，为前端提供一些中转和过度。
反过来，一个团队中没有 Java 语言，那么 PHP 便是真正的后端服务提供语言。
我们可以找到 PHP 工程师，也包括 Node 工程师 的定位，那就是 开发 BFF 应用。往前连着各个终端，往后对接业务系统暴露的微服务。
简化前端页面接入后端服务的 复杂度，根据不同的终端做针对性的数据适配。
总结
说了这么多 BFF 也可以认为是意识形态的东西，比如 对于 BFF 这个 架构层次或者命名，老板说叫什么就叫什么，不用纠结。
毫无疑问，BFF 也是一种架构设计，BFF 的定位和设计也要通过项目版本的迭代和业务驱动逐渐演化而来的。
最近看了一篇关于中台的文章，如果不是很严格的说，中台和 BFF 的职责还有部分重叠之处，不管是中台还是 BFF，择其优点而用之即可。
摘录资料中的一句话
❝历史总是螺旋式上升 ❞
Reference
[1]
Pattern: Backends For Frontends: https://samnewman.io/patterns/architectural/bff/
[2]
BFF-soundcloud: https://www.thoughtworks.com/insights/blog/bff-soundcloud