前言
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实现，对于服务端实现接口复用。

升高多端业务的耦合性，防止不同端业务开发相互影响。

其余劣势，包含数据缓存，接口平安校验等。