【译文】BFF模式介绍

原文链接：传送门。

想象下这个场景：你需要使用微服务架构来构建一个电子商务应用。你会有一些微服务来服务于顾客，订单，产品，购物车，等等。这些微服务暴露被前端系统消费的各种API。

然而，微服务返回给前端的数据并不会根据前端系统要呈现数据的精确方式进行格式化或者过滤。在这种情况下，前端系统本身需要一些逻辑来再次格式化这些数据。而在前端系统具有这些逻辑会占用更多的浏览器资源。

在像这样的情况下，我们可以使用BFF来将这些前端逻辑移动到一个中间层。这个中间层就是BFF。这样，当前端系统请求一些数据时，它其实会调用BFF中的API。

如上所描述的，BFF会做以下事情：

• 调用相关的微服务API并获取到所需的数据。
• 基于前端展示来格式这些数据。
• 将格式化后的数据返回给前端。

这样的话，前端页面都会具有尽可能少的逻辑。因此BFF可以帮助将数据流水线化的进行展示，并承担了为前端提供了有侧重的API的职责。

另一个可以简化你的前后台关系的重要方式是通过在它们之间共享类型来实现。具体可以参考这里。

BFF如何适配电子商务示例？

下图展示了微服务如何通过BFF与前端系统进行交互。

BFF的角色

如同我们已经叙述的，BFF在微服务和前端系统之间扮演了一个简单接口的角色。理想情况下，前端项目组也会负责管理BFF。

一个单独的BFF侧重于一个UI，并仅仅只是那个UI。因此，其会帮助我们保持前端系统的简洁并通过后台看到一个统一的数据视图。

这带来了另一个问题，我们可以为多个UI构建多个BFF么？我们将在此文的后续章节回答这个问题，请继续阅读。

BFF会增加延迟么

现在我们知道BFF类似于一个在客户端和其他外部API，服务之间的一个代理服务器。如果请求必须经过另一个组件，其必定会增加延迟。然而，如果我们需要与多个未曾为前端进行优化的服务一起工作时，相比于浏览器的高资源使用来说，这些延迟是微不足道的。

构建一个BFF允许你很聪明的对其他后台服务/API进行批量调用并一次性的返回数据，或者通过转化或者格式化数据来返回一个更方便的展示形式。

这个对于在2G/3G的移动客户端来说是很有用的，因为在这种情况下会需要好几秒（甚至更久）来建立连接。

什么时候可以为你的应用使用BFF

像很多其他模式一样，在你的应用中是否使用BFF取决于你打算要遵循的上下文和架构。举个例子，如果你的应用是一个简单的单体应用，那么BFF是没有必要的，它不会为应用增加价值。然而，如果你的应用依赖于微服务，并且消费了很多其他的外部API及服务，我们最好可以用BFF来流水线化数据流并提升我们应用的效率。

进一步的，如果你应用需要为一个特定的前端开发一个优化后的后台或者你的客户端消费的数据需要大量的聚合计算，那么，BF是一个合适的选项。

我们可以有多个BFF么？

当然了，这正是具有一个BFF的完整点。

传统的实践（没有BFF的应用）针对于所有的客户仅仅只有一个API网关。

 

 

然而，使用BFF的目的是为你的客户端提供一个有侧重的接口来与之连接。举个例子，移动UI的数据消费可能会与浏览器的数据消费有所不同。在这种情况下，为了更好的数据展示，我们可以使用两个BFF。让我们来看看使用多个BFF的应用架构图。

 

 

 

如你所见的，每一个客户端都会有一个BFF，他们会帮助优化来自于服务的都响应。

使用BFF的优势

使用BFF的几个优势列举如下：

• 概念分离：前端需求与后台概念分离，这更容易维护。
• 更容易的维护和修改APIs：客户端应用会更少的知道后台架构，这会使得对API的修改变得更有弹性。
• 前端页面更好的进行错误处理：大多数时候，服务端错误对于前端用户来说是没有意义的，没有直接返回服务端发送的错误，BFF将需要展示给用户的错误进行了映射处理。这会改进用户体验。
• 多个设备类型可以并行调用后台：当浏览器对浏览器BFF发送请求时，移动设备可以做相同的处理，这可以帮助更快的从服务的获取相应。
• 更好的安全性：一些敏感数据可以被隐藏，而且当发送响应给前台时，对前端来说不需要的数据可以被忽略。这个抽象可以使得攻击者更难定位到你的应用。
• 对于组件的共享的团队拥有权限：应用的不同部分可以被不同的团队更容易的处理。前端团队乐于拥有他们的客户端程序以及底层的资源消费层。导致了更快的开发效率，下图展示了一个团队隔离的示例。

 

BFF最佳实践

到现在为止我们所看到的一切很让我惊奇，然而，BFF可以减少错误么？

答案是否定的。像任何一个其他的技术或者模式一样，即使是BFF也有陷阱，为了避免这些，我们需要遵从最佳实践。

• 避免与自包含的API一起实现BFF：你的自包含的API应该在微服务层。很多开发者忘记了这一点，开始在BFF层也实现了服务层的API。你应该始终记得BFF是客户端和服务端之间的一个转化层。当数据从服务API返回时，BFF的目的就是将其转化为客户端指定的数据格式。
• 避免BFF逻辑重复：需要注意的一个关键点是单个的一个BFF应当关注与特定的用户体验，而不是设备类型。举个例子，大多时候，所有的移动设备共享同样的用户体验，在这种情况下，对于所有的操作系统来说一个BFF是足够的。我们没有必要为IOS建立一个BFF，而为安卓建立另一个BFF。
• 避免过度依赖BFFs：BFF仅仅只是一个转化层。是的，它也给应用程序提供了一定级别的安全。但是你不应该依赖比你应该依赖的更多。你的API层和前端层应该照看所有的功能和安全方面的事情而不管是否有BFF的出现。因为BFF应该填充缝隙，而不应该向应用添加功能或者服务。

总结

BFF不仅仅帮助开发，也能显著的提升用户体验。因此，当保证BFF侧重于其前端的同时，考虑数据优化和聚合是很关键的。

除此之外，如果你之前还没有用过BFF模式，现在是开始的时候了。之后，让我也知道你的体验和意见。

标签：服务,BFF,一个,前端,模式,API,译文,客户端
来源： https://www.cnblogs.com/qianxingmu/p/16030910.html