共计 2992 个字符，预计需要花费 8 分钟才能阅读完成。
前言
BFF 是一种 Web 架构，全名为 Backends For Frontends，即为服务于前端的后端。这个词来源于 Sam Newman 的一篇文章：Pattern: Backends For Frontends[1]。BFF 个别指的是在前端与后端之间加减少一个中间层。为什么要在前端和后端之间减少一个 BFF 层呢？
计算机科学家 David Wheeler 已经说过一句话：All problems in computer science can be solved by another level of indirection. 计算机科学中的所有问题都能够通过加一层来解决。因而，须要应用 BFF 的场景，必定是一般的前后端开发模式遇到了局部问题。例如在 Sam Newman 的文章中就形容了 BFF 解决多个展现端的场景。
多端性能展现
在零碎一开始开发的时候只思考了 PC 网页端的设计，服务器端 API 是为了 PC 网页端而服务的。然而起初随着挪动互联网的衰亡，挪动端开始风行，决定在原有服务端的根底上开发挪动端 App，复用之前的 API，然而原有 API 是为了 PC 端设计的，并不合乎挪动端的需要。
PC 端的需要与挪动端并不一定完全相同，现有接口无奈满足所有挪动端的新需要。
PC 端电脑性能强，能够并发申请多个接口或进行局部较简单的数据处理，然而挪动端性能低，如果应用同样的多个接口，由前端组装数据，页面展现可能会呈现提早和卡顿景象。
PC 端的屏幕较大，展现内容较多且全面。然而挪动端屏幕小，展现内容较少。而且局部数据的获取并不容易，须要后端调用许多服务。如果挪动端复用 PC 端接口，会获取和传输局部无用数据，不仅耗费服务端资源，还节约网络带宽。
而且随着科技的倒退和用户的需要，不同的展现端越来越多，在不仅在手机上会辨别 Android 端，IOS 端，而且还会有平板电脑端，手机网页端，PC 网页端，PC 的 APP 端等等。这些端的页面设计各不相同，对于数据的需要也不雷同。假如咱们复用同一个服务端和 API 接口，如果呈现不满足需要的场景就加接口加字段，那么随着这些不同客户端的开发和迭代，服务端会变的大而臃肿，效率低下。而且同一个接口提供给太多前端调用，波及到太多的逻辑，复杂性越来越高。
因而，更好的形式是服务端对展现进行解耦，服务端只负责提供数据，有专门的展现端负责前端的展现业务。这里的展现端就是 BFF 层。
不同业务场景的展现模式差别
在某些业务中，客户端的类型只有一种，然而在不同的场景下，展现的模式有差别。比方在美团的 BFF 实际 [2] 中，不同行业的团购货架展现模块不同，是两套独立定义的产品逻辑，并且会各自迭代。
在这种业务场景下，尽管是同一个客户端，然而业务不同，需要的数据格式和类型也不同，因而遇到与下面多端展现相似的接口问题。
短生命周期的需要
还有一种情景，是闲鱼团队遇到的短生命周期的需要[3]。在一般的业务场景下，服务端失常稳固迭代开发。然而偶然会有一些非凡的经营流动，这种流动工夫较短，可能仅仅继续几天工夫。
如果仅仅为了这些几天的流动，每次都要开新 API，联调，甚至批改原有服务端的逻辑，老本较大，而且较为低效。如果加一层 BFF，让前端能够间接获取数据，那么开发和联调会变的简略很多。
业务整合须要
在某些情景下，业务后端和需要比较复杂，例如这篇文章波及到的场景[4]，有一个 Moments App, 蕴含了像用户治理，关系治理，信息，头像，点赞等多种多种后端微服务。这些服务在前端展现的逻辑耦合性较强。比方有些须要串行解决，例如失去服务 1 的后果才能够调用服务 2；有些则能够并行处理。而数据合并和整顿的逻辑额较为简单。
网易云音乐也应用 BFF 进行微服务的调度以及数据的组装和适配。
这时候能够设立一个 BFF 层，作为一个数据整合服务，将调用不同微服务接口，与数据处理的简单逻辑都在 BFF 端中实现，升高了前端的复杂度，也进步了响应效率。
解决局部展现相干的业务
在应用了 BFF 之后，局部页面展现相干的业务逻辑能够形象进去，交由 BFF 端解决。
例如数据导出 Excel 下载服务，输出导入 Excel 上传服务。BFF 层能够接管用导入的 Excel，解析并解决表格数据，而后提供给服务端。在导出时，也能够调用服务端 API 获取数据，由 BFF 端整合提供给前端下载。在这种情景下，服务端只须要提供一个展现接口，就能够满足页面展现和导出两种不同格局的展现需要。导入也是同理。而且假如表格与页面展现要求的数据格式不同，例如导入时局部字段值须要作转换，那么也能够由 BFF 端解决这种差别。
BFF 的类型
BFF 自身仅仅是一个概念，实现形式有多种，在理论中咱们要依据不同的场景选取不同的计划。依照大类分，次要有繁多 BFF 和多端 BFF。
繁多 BFF
繁多的 BFF 次要对接服务端，依据展现服务的需要组装数据提供给每个端或者每种业务进行展现。
很多繁多 BFF 都会用到 GraphGL，他是由 Facebook 开发的数据查问工具。通过该工具，能够将不稳固的数据组装局部从稳固的业务数据逻辑中剥离，使数据管制逻辑前移，开发模式由“下发数据”转变成“取数据”的过程。
例如美团，闲鱼，网易云音乐等的 BFF，都提供了按需查问能力，一个 BFF 对接多种客户端或者多种业务的需要。下图是美团应用的 BFF 架构设计。
多端 BFF
多端 BFF 是指每种业务或者每种客户端采纳本人独立的 BFF 层，这样每种客户端的服务更加灵便，不同的 BFF 端对于展现服务解耦性更高。
前端 BFF 与后端 BFF
从技术上分，BFF 又能够分为前端 BFF 和后端 BFF。即 BFF 层由前端团队主导或者后端团队主导。前端团队的 BFF 个别应用 Node.js，后端团队则会应用 Java 或者其余服务端语言。
如果应用前端 BFF，能够实现谁应用谁开发，肯定程序生防止了前后端实现的上不必要的沟通老本。但须要前端团队有一服务端开发教训，对前端团队的技术建设有较高需要。然而前端也能更深刻的接触业务逻辑，对于重展现的业务需要有肯定劣势。例如淘宝的实际：大淘宝技术行业 FaaS 化实战经验分享[8]。
传统接口与按需查问
传统接口模式即失常开发接口，固定入参和返回数据格式，供前端调用。按需查问模式即前端调用接口时指定须要哪些数据，前端自主进行按需查问。GraphQL 即是应用按需查问的模式。
BFF 的其余特点
与 ServerLess 集成
应用前端 BFF 时，前端开发可能不足运维教训，而且在高可用，并发性等问题上可能会遇到挑战。如果联合 Serverless 实现主动扩容，弹性伸缩等性能，能够解决一些 BFF 的问题。
BFF 与网关
网关能够提供路由，认证，监控，日志等服务。网关能够与 BFF 集成在一起，也能够作为独立的一层来实现。如果业务简单，还能够在不同的 BFF 下层配置不同的网关。
FF 的劣势
通过下面的的各种问题和场景，置信咱们曾经晓得了 BFF 能够解决很多场景的问题，这里总结一下 BFF 的劣势：
服务端对数据展现服务进行解耦，展现服务由独立的 BFF 端提供，服务端能够聚焦于业务解决。
多端展现或者多业务展现时，对与数据获取有更好的灵活性，防止数据冗余造成耗费服务端资源。
对于简单的前端展现，将数据获取和组装的负责逻辑在 BFF 端执行，升高前端解决的复杂度，进步前端页面响应效率。
局部展现业务，能够形象进去利用 BFF 实现，对于服务端实现接口复用。
升高多端业务的耦合性，防止不同端业务开发相互影响。
其余劣势，包含数据缓存，接口平安校验等。