作者|黄一思BFF—BackendForFrontends，经典的分布式架构设计模式之一。我通过学习和工作经验的积累，逐渐加深了对BFF的理解。作为一种模式，它有一些更具体的使用场景，以及它可以匹配的一些特定问题。在这篇文章中，你将和我一起穿越回BFF诞生的历史，寻找它的源头。并探索和学习这种在分布式系统中接触率很高的架构模式。寻找历史线索在没有线索的情况下，我们可以先从Thoughtworks技术雷达中BFF的词条入手，寻找一些历史线索。BFF词条发表于2015年11月10日，从这些信息可以知道，BFF应该是在2015年载入史册的。接下来谷歌搜索关键字BackendforFrontends，将时间范围限定在2015年1月1日至11月10日,2015.通过对比搜索结果的时间，我们可以很容易地找到BackendforFrontends条目首先出现的文章。文中提到，BFF这个名字最先是由时任团队TechLeader的NickFisher提出，并通过内部团队投票通过的。好吧，我们现在有了一个非常具体的证据。作为严谨的技术工作者，我们找到了其他交叉证据来增加这个结论的可信度。非常幸运的是，在2015年的另一篇Thoughtworksinsight文章中也提到了与上述相同的证据。最后，我们可以说，BFF模型首先出现在解决SoundCloud的分布式系统问题上。接下来，让我们回到BFF第一次发威的场景。神工之初，会让大家更容易了解SoundCloud当年遇到了怎样的挑战。下面我将分类分项列出分析。背景：SoundCloud主要通过付费订阅和广告盈利（即更多的曝光渠道会给SoundCloud带来更多的利润）。SoundCloud是一个为Web客户端提供共享API的单一系统。、Android和iOS应用程序，以及互联网、合作伙伴和其他渠道提供服务。这些共享API随着功能和特性的增加而增长，最终成为平台和客户端之间的集成点。改造2007年开始运营的SoundCloud，从单体模式到微服务模式，下面是具体的改造过程。至此，单体服务已经拆分为多个微服务。支持iOS平台新应用（原有产品主要提供Web端服务）的主要动机是缩短产品发布上线时间，支持iOS平台新应用，隔离新用户带来的风险体验设计。增加后台团队与客户端团队的合作节奏，提高工作效率。挑战：为了让第三方开发者更自由地集成，API设计需要不对数据的使用方式做任何假设。因此，为了提供简单的体验，还需要许多不同的HTTPAPI来提供具有高数据容忍度的服务。最终，获取数据以构建一个简单的页面需要数百个API请求。当团队需要对现有API进行更改时，他们需要确保不会破坏任何现有客户端和重要的第三方集成。因此，每当需要添加新内容时，都必须投入大量工作来确保新功能不仅适用于特定客户端。以上所有这些都让协调日常工作变得更加困难，最终导致新功能的缓慢发布。开始准备开发一款新的iOS应用，应用在新平台上的用户体验将被彻底重塑。通过以上情况的分析，可以得出当时SoundCloud后端团队面临以下问题：问题一：需要第三方客户提供合适粒度的API。导致提供的API数据粒度太细，导致需要请求的API过多，才能完成一个业务服务。问题二：外部API与特定用户耦合严重，边界模糊。复杂度高导致API维护工作量大，新功能发布缓慢。问题三：iOS平台新客户端改进了用户体验和交互方式。需要隔离新App带来的风险，寻找更好的多客户团队合作方式。这三个问题在后端团队的微服务改造中经常会遇到。让我们一起来看看，当SoundCloud团队面临同样的问题时，他们是如何一步步取长补短，摸索出BFF模式的内功的。进化之路接下来，BFF模式进化点由客户团队获得。由于他们是API的消费者，他们可以对不同的服务进行多次逻辑调用，并混合到后端的用户配置文件（UserProfile）文件中。这样就避免了对后端服务的多次不同调用，实现了客户端对单一资源的简单请求。这将简化客户端代码并提高整体性能，例如：GET/user-profile/123.json后端团队接受了这个逻辑并开始试验这种方法。他们在BFF中写了很多PresentationModels。完成部分任务后，后台团队突然意识到，BFF不仅仅是客户端使用的API，它是应用程序本身的一部分。一种新的BFF形式出现了，如下图所示：随着时间的推移，SoundCloud的BFF也在不断增加。他们已经在生产中同时维护了5个BFF。为了进一步提高生产力，减少不必要的重复。用户画像（UserProfile）从各个不同的微服务中提取出来，成为Services和BFF之间独立的应用服务（ApplicationService）。随着时间的推移，SoundCloud的BFF仍然在横向增长，不同的是这种横向增长不再造成任何问题。最终，BFF模式的架构演变为与我们今天使用的架构几乎相同。架构如下图所示：综上所述，当我们维护和使用分布式架构，同时面对多个客户端时，BFF模型提供了一个很好的架构模型，使得后端团队在构建时能够自己控制面向复杂客户需求的命运。并且，这种自主性可以为快速迭代的客户端应用程序提供快速和良好的体验。通过支持不断的演进和变化，该模型可以将具有相同变化趋势的消费者行为限制在可控范围内。使他们更容易合作和改变，更好地满足不同客户的功能需求。在系统架构上，由于距离前端（在网络和组织结构上）比较近，需求变化频繁，BFF很容易野蛮生长，成为各种“妥协”的场所。在使用的过程中，我们需要明确架构中各个层次的相关功能和边界。同时，如果确实有一些不得不做的“妥协”，我们也要以技术债的形式继续跟踪管理，避免越来越多的“妥协”。适配器，成为分布式单体的转换器。我们在系统设计之初经常犯一个错误，就是一开始就希望一切都是可复用的。这种思路会给系统后续的开发和维护带来巨大的挑战。挑战可能来自应用程序之间的协调，也可能来自多路复用带来的高工作负载。尤其是在维护多个客户端或消费者的场景下，会带来更大的困难。在考虑一般用途之前，我们应该关注功能和特定用例。在了解当前系统状态的主次和具体情况后，有针对性地区分需要一般处理和特殊处理的部分。这种系统设计和开发的思路和方法，使我们能够拥抱变化，在进化中立于不败之地。
