BFF在SoundCloud中的实践(翻译)

文章目录

说明
名词解释
正文

为什么改造
改造方案
前端开发者编写后端代码
BFF 作为迁移的一部分
一个或者多个BFF
BFF的演化
结论

说明

这是一篇我翻译的文章，原文出处是：

https://www.thoughtworks.com/insights/blog/bff-soundcloud

翻译的原因无他，就是觉得文章写得好。

名词解释

BFF,backends for frontends，它是一种架构技术，一般指在微服务架构中根据客户端的不同，对后端接口进行分类支撑
SoundCloud，音频分享服务平台,是一个为喜欢音乐和爱好声音记录生活的人士打造的分享平台,用户可以上传音乐和音频文件,通过音频时间轴标记留言并分享
Rails，是一个使用 Ruby 语言写的开源 Web 开发框架
monolith，单体架构，相对于微服务架构
Finagle，一种微服务框架
strangler pattern，一种处理大型 Web 应用程序中的重构代码发布方式。Web 应用程序是通过将功能映射到业务领域的不同方面的 URL 来构建的 — 将应用程序拆分为不同的功能领域，并一次一个领域地将这些领域替换为基于微服务的新实现。

正文

我们几年前在SoundCloud的朋友开始了一次把他们的单体架构Rails应用微服务化的旅程。在该项目中，对他们来说特别有效的一件事是BFF模式，也就是backends for frontends。他们在BFF的实践和背后的成功故事可能有助于其他团队; 所以我们决定把它写下来。我们希望您觉得它很有用。

为什么改造

早期，SoundCloud是一个单体架构系统，公开了一套服务于Web客户端，Android和iOS应用程序以及互联网的API，里面各种混搭，协作等。这个共享API随着每个功能需求而不断增加，因为架构的原因这些改动贯穿整个平台和API的使用者。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-22ISzDQk-1572703807880)(https://insights-images.thoughtworks.com/BFF_18ab348d8f5e013b45101cd9ee27b01d.png)]

一段时间后，这种架构开始出现问题，无论是在添加新功能所需的时间方面，还是由于平台的不同需求。例如，对于移动API，应该比web API更小的数据和请求频次。现有的单体架构API没有考虑到这一点，因为是另一个团队开发的，他们并不知道移动端的需求。因此，每当应用程序增加一个新的访问点，首先前端团队要让后端确信这是真的需求，然后就是没完没了的沟通，开发的故事了。

问题很明显：不必要的摩擦，沟通开销和延迟。与此同时，后端团队开始遇到单体架构带来的问题，因为添加新功能变得更加困难，同时bug修复的工作越来越多。

改造方案

为了解决这些问题，SoundCloud决定每当实现一个功能需要一个特定的，经过微调的API时，驱动它的团队也能够实现API端点，从而决定从哪里获取数据以及如何聚合它，什么有效载荷需要传输等。此API端点将在整体应用程序之外创建，并充当特定于功能的接口。前端团队是这一层接口的所有者。

BFF诞生了，可以根据特定平台和功能（Android，iOS客户端，Web API和其他使用者）的需求进行调整。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3s2JCEUX-1572703807881)(https://insights-images.thoughtworks.com/BFF2_dda55fa4bab3599a8ff3911808b43bd3.png)]

前端开发者编写后端代码

这种转变意味着到目前为止主要依靠Android或iOS开发的主要专业知识来处理前端代码的人需要涉足后端：不同的技术栈和不同的挑战。为了解决这个问题，后端团队开发了一个轻量级库，可以更轻松地编写“边缘服务”，这种服务是负责警报，监控，遥测，身份验证以及应用速率限制和清理传入请求的最佳实践。这有助于标准化BFF的编写方式，因为它基于BFF框架更容易被使用(基于Finagle)，而不是从头开始做所有事情。

BFF 作为迁移的一部分

BFF的一个特点是它消除了外部到下游服务的任何直接调用。此模式的实现还实现了向基于微服务的体系结构的最小侵入式迁移，因为BFF隐藏了应用程序本身的任何潜在变化。新功能通过BFF成为新的微服务或整体。每当从整体中提取更多功能时，BFF就会被更改，而应用程序代码保持不变。人们可以看到与strangler模式的相似性，其中BFF正在扼杀单体架构提供的公共API。因此，引入了名为public-api-strangler的BFF来隐藏消费者的整体API。它最初只是将请求转发给整体的代理。随着时间的推移，来自整体的部件被提取出来，而public-api-strangler只是将请求重新路由到新的微服务。消除对整体API的直接消费者调用，简化了向基于微服务的系统的迁移过程。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sI9zMTUc-1572703807881)(https://insights-images.thoughtworks.com/One_or_more_BFFs_cf35965f5b900ae6d357e8a0a3ae7588.png)]

一个或者多个BFF

你应该选择多少个BFF？在移动平台上，由于时间和资源有限，SoundCloud一开始iOS和Android使用一个BFF。不过事后看来，为每个平台提供一个BFF会更好，因为Android和iOS应用程序的不同足以暴露不同的API需求。您还可以考虑为每个平台提供一个BFF，如果两个平台上都存在特定功能，则可以使用相同的BFF。 SoundCloud用户可以分为创作者和听众; 因此，为创作者提供一个BFF，为听众提供一个BFF也是有意义的，因为这些用户组也可以获得单独的应用程序。这是SoundCloud决定执行的思路。

人们可以尝试定义更细粒度的BFF，封装特定的功能，这将在BFF的发布周期上有更大的灵活性。但是，由于平台审核流程以及用户实际触发更新的意愿，应用程序发布周期更加“严格”，因此仍然与他们正在服务的应用程序紧密耦合，这部分是有争议的。

SoundCloud决定为每个上游用户创建一个BFF：它可能是一个服务于特定需求的应用程序（例如iOS监听器应用程序与iOS创建者应用程序）或用于嵌入式使用的API或面向Facebook，Twitter等战略合作伙伴的API。 BFF为不同需求带来的好处，特别是发布周期，足以证明这些努力的合理性。

目前，所有BFF都基于相同的核心库/框架（已在上面提到），每周发布时间表中更新。共享BFF也有它的问题，例如：

过快地向库中添加新功能，而不是让它稳定应用在某些服务中，可能导致所有BFF升级到错误或不稳定接口的版本
允许足够的灵活性和可配置性，会让我们错误的认为默认实现适用于每个BFF
保持库尽量小并且可组合，因此开发人员可以根据自己的喜好选择部件

BFF的演化

现在SoundCloud的BFF显然随着时间的推移而增长。应用程序获得了新功能，它要求新的BFF功能。这种横向增长不会引起任何问题。但是BFF也在深度（垂直）上增长，并且暴露了一些重复的功能被提取到核心库中。问题是哪些应该成为一个新的服务或库。指导规则是：如果要提取的功能不需要随时更新，则使用共享库，否则使用服务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tkAH2lcS-1572703807881)(https://insights-images.thoughtworks.com/EvolutionofBFF_8003911266125f52d2bffca7ac16fac3.png)]

说到重复和复用，不要试图从一开始就使一切都变得通用。如果在整个组织中尝试这样，它将导致矛盾，因为很多人都想要贡献自己的想法。考虑通用之前，请专注于您的功能和特定用例。 “通用的特殊功能优先”战略的效果要好得多。在考虑提取代码时，不要忘记有用的“三规则”。