作者 |  黃逸偲

BFF — Backend For Frontends，經(jīng)典分布式架構(gòu)設(shè)計(jì)模式之一。我在學(xué)習(xí)和工作經(jīng)驗(yàn)累積中，逐漸加深了對(duì) BFF 的理解。作為一種模式，它具有一些更加確切的使用場(chǎng)景，和一些能匹配的特定問(wèn)題。

在本篇文章中，你們會(huì)與我一起穿越回BFF誕生的歷史中，尋找其起源。并一同探索和學(xué)習(xí)這個(gè)在分布式系統(tǒng)中出鏡率極高的架構(gòu)模式。

尋找歷史的線頭

在毫無(wú)頭緒的情況下，我們可以首先從Thoughtworks技術(shù)雷達(dá)中 BFF 的條目入手，去找到一些歷史的蛛絲馬跡。BFF 條目的發(fā)布時(shí)間是在 2015 年 11 月10 日。從這個(gè)信息我們可以獲知，BFF 在歷史嶄露頭角應(yīng)該是在 2015 年 。

緊接著，在谷歌搜索關(guān)鍵字Backend for Frontends 以及將時(shí)間范圍限定在 2015 年 1 月 1 日到 2015 年 11 月 10 日。通過(guò)對(duì)比搜索結(jié)果的時(shí)間，我們可以輕易發(fā)現(xiàn)最早出現(xiàn) Backend for Frontends 詞條的文章。文中提到，BFF 這個(gè)名字是由當(dāng)時(shí)團(tuán)隊(duì) Tech Leader Nick Fisher首次提出，通過(guò)投票獲得了內(nèi)部團(tuán)隊(duì)的認(rèn)可。好了，我們現(xiàn)在獲得了一個(gè)非常具體的證據(jù)。作為嚴(yán)謹(jǐn)?shù)募夹g(shù)工作者，我們找到其他的交叉證據(jù)，提高這個(gè)結(jié)論的置信度。

非常幸運(yùn)的是，在另一篇2015 年的 Thoughtworks 洞見(jiàn)文章中也提到了與上面證據(jù)相同的內(nèi)容。終于，我們可以說(shuō) BFF 模式是在解決 SoundCloud的分布式系統(tǒng)問(wèn)題中首次出現(xiàn)。下面，讓我們一起回到BFF第一次發(fā)揮威力的現(xiàn)場(chǎng)吧。

神功初成

為了能讓大家更容易了解到SoundCloud 當(dāng)年究竟遇到了什么樣的挑戰(zhàn)，我會(huì)在下面通過(guò)分類(lèi)分項(xiàng)來(lái)列舉情況以及進(jìn)行分析。

背景：

• SoundCloud主要是通過(guò)付費(fèi)訂閱與廣告進(jìn)行盈利（也就是說(shuō)，越多的曝光渠道，會(huì)給SoundCloud 帶來(lái)更多的盈利）
• SoundCloud 是一個(gè)單體系統(tǒng)，通過(guò)暴露共享 API 的方式為 Web 客戶(hù)端、Android 和 iOS 應(yīng)用程序以及互聯(lián)網(wǎng)、合作伙伴等渠道提供服務(wù)。這些共享 API 隨著功能和特性一起增長(zhǎng)，最終變成了平臺(tái)與客戶(hù)端之間的集成點(diǎn)。
• 將 2007 年開(kāi)始運(yùn)行的 SoundCloud 從單體模式轉(zhuǎn)變至微服務(wù)模式， 這里是具體改造過(guò)程。此時(shí)，單體服務(wù)已經(jīng)被拆分為多個(gè)微服務(wù)。
• 支持在 iOS 平臺(tái)上新增的應(yīng)用程序（原來(lái)的產(chǎn)品主要是在 Web 端提供服務(wù)）

主要?jiǎng)訖C(jī)：

• 減少產(chǎn)品發(fā)布上線的時(shí)間
• 支持 iOS 平臺(tái)新的應(yīng)用程序，隔離新用戶(hù)體驗(yàn)設(shè)計(jì)帶來(lái)的風(fēng)險(xiǎn)。
• 增加后端團(tuán)隊(duì)與客戶(hù)端團(tuán)隊(duì)合作的節(jié)奏，提高工作效率。

挑戰(zhàn)：

• 為了讓第三方開(kāi)發(fā)人員能更自由地集成，需要 API 設(shè)計(jì)不對(duì)數(shù)據(jù)的使用方式做出任何假設(shè)。所以，為了提供簡(jiǎn)單的體驗(yàn)，也需要許多不同的 HTTP API 提供具有高數(shù)據(jù)寬容度的服務(wù)。最終，獲取構(gòu)建一個(gè)簡(jiǎn)單的頁(yè)面的數(shù)據(jù)，也需要上百個(gè) API 請(qǐng)求。
• 當(dāng)團(tuán)隊(duì)需要變更現(xiàn)有 API 時(shí)，需要確保不會(huì)破壞現(xiàn)有的任何客戶(hù)端以及重要的第三方集成。所以，一旦需要添加新內(nèi)容，都必須投入巨大工作量來(lái)確保新功能不只適用于特定客戶(hù)端。上面這些情況使協(xié)調(diào)日常工作變得更加困難，最終導(dǎo)致了新功能發(fā)布緩慢。
• 開(kāi)始準(zhǔn)備開(kāi)發(fā)新 iOS 應(yīng)用程序， 新平臺(tái)上應(yīng)用程序的用戶(hù)體驗(yàn)會(huì)全部被重塑

通過(guò)分析上面的各種情況，可以得出當(dāng)時(shí)SoundCloud 后端團(tuán)隊(duì)面對(duì)如下幾個(gè)問(wèn)題：

• 問(wèn)題一：需要為第三方客戶(hù)提供合適粒度的 API，結(jié)果提供的 API 數(shù)據(jù)粒度過(guò)細(xì)，導(dǎo)致想完成一個(gè)業(yè)務(wù)服務(wù)需要請(qǐng)求的 API 太多。
• 問(wèn)題二：對(duì)外 API 與特定的使用方耦合嚴(yán)重，邊界模糊，復(fù)雜度高導(dǎo)致維護(hù) API 的工作量巨大，新功能發(fā)布緩慢。
• 問(wèn)題三：iOS 平臺(tái)新客戶(hù)端改 進(jìn)了用戶(hù)體驗(yàn)和交互方式，需要隔離新App帶來(lái)的風(fēng)險(xiǎn)，并且還要找到與多個(gè)客戶(hù)端團(tuán)隊(duì)更好的合作方式。

這三個(gè)問(wèn)題在后端團(tuán)隊(duì)進(jìn)行微服務(wù)改造中往往也會(huì)遇到。讓我們一起看看，當(dāng)年的 SoundCloud 團(tuán)隊(duì)在面臨同樣的問(wèn)題時(shí)，是如何一步步見(jiàn)招拆招，摸索出 BFF模式 這個(gè)內(nèi)功心法的。

演進(jìn)之路

接下來(lái)，BFF 模式演進(jìn)這一分是由客戶(hù)端團(tuán)隊(duì)獲得的。由于他們是 API 的消費(fèi)者， 可以將不同服務(wù)進(jìn)行多次邏輯調(diào)用，混合到后端的用戶(hù)配置（UserProfile）文件中。這樣避免了對(duì)后端服務(wù)多次不同的調(diào)用，實(shí)現(xiàn)客戶(hù)端對(duì)單個(gè)資源的簡(jiǎn)單請(qǐng)求。這將簡(jiǎn)化客戶(hù)端代碼并提高整體性能，例如：

• GET /user-profile/123.json

后端團(tuán)隊(duì)接受了這個(gè)邏輯，并開(kāi)始試驗(yàn)這個(gè)方式。他們?cè)?BFF 中編寫(xiě)了很多 Presentation Model。在完成一部分任務(wù)后，后端團(tuán)隊(duì)突然意識(shí)到 BFF 不只是被客戶(hù)端使用的 API ，它本身就是申請(qǐng)的一部分。BFF 新的形態(tài)出現(xiàn)了，具體如下圖所示：

隨著時(shí)間推移，SoundCloud 的 BFF 也在增加。他們已經(jīng)在生產(chǎn)環(huán)境同時(shí)維護(hù)著 5 個(gè) BFF 了。為了進(jìn)一步提高生產(chǎn)力，減少不必要的重復(fù)。用戶(hù)配置（User Profile） 被從每個(gè)不同的微服務(wù)中抽取出來(lái)，變成一個(gè)獨(dú)立的在 Services 與 BFF 之間的應(yīng)用服務(wù)（Application Service）。

SoundCloud 的 BFF 依然隨著時(shí)間在橫向增長(zhǎng)，不同的是這種橫向增長(zhǎng)不會(huì)再引起任何問(wèn)題了。最終，BFF 模式的架構(gòu)演變成與我們現(xiàn)在使用的幾乎一致了。架構(gòu)如下圖：

總結(jié)

我們?cè)诰S護(hù)和使用分布式架構(gòu)，同時(shí)面對(duì)多客戶(hù)端時(shí)，BFF 模式提供了一種很好的架構(gòu)模式，使后端團(tuán)隊(duì)在構(gòu)建面向客戶(hù)端的復(fù)雜需求時(shí)，能夠掌控自己的命運(yùn)。并且，這種自主性對(duì)于快速迭代的客戶(hù)端應(yīng)用程序，能夠提供快速而良好的體驗(yàn)。通過(guò)支持持續(xù)的演進(jìn)和變化，這種模式可以將相同變化趨勢(shì)的消費(fèi)者行為，限制在一個(gè)可控范圍內(nèi)。使他們變得更容易合作和改變，并且更好滿(mǎn)足不同客戶(hù)端的特性需求。

在系統(tǒng)架構(gòu)中，因?yàn)殡x需求頻繁變化的前端比較近（網(wǎng)絡(luò)和組織架構(gòu)上），BFF很容易野蠻生長(zhǎng)，成為各種“妥協(xié)”的自留地，在使用的過(guò)程中，我們需要明確架構(gòu)中各層相關(guān)的職能和邊界。同時(shí)，如果確實(shí)有不得不去做的一些“妥協(xié)”，我們也一定要用技術(shù)債的方式，繼續(xù)跟蹤和管理，避免“妥協(xié)”越來(lái)越多以后，BFF從一個(gè)解決不同變化速率和需求的適配器，變成分布式單體的一個(gè)轉(zhuǎn)化器。

我們往往會(huì)在系統(tǒng)設(shè)計(jì)之初犯下一個(gè)錯(cuò)誤，那便是希望所有東西在一開(kāi)始都是可復(fù)用的。這種思路會(huì)給系統(tǒng)后續(xù)的開(kāi)發(fā)和維護(hù)帶來(lái)巨大的挑戰(zhàn)，挑戰(zhàn)可能是來(lái)自應(yīng)用間的協(xié)調(diào)，也可能是兼顧復(fù)用帶來(lái)的高工作量。特別是在維護(hù)多個(gè)客戶(hù)端或消費(fèi)者的場(chǎng)景下會(huì)帶來(lái)更大的困難。我們應(yīng)該在考慮通用用法之前，先專(zhuān)注于功能和特定用例。在了解系統(tǒng)現(xiàn)狀的主次和具體情況后，再針對(duì)性地區(qū)分需要通用和特殊處理的部分。這種系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)的思路和方式，使我們能夠擁抱變化，立于演進(jìn)的不敗之地。