作者 |  黃逸偲

BFF — Backend For Frontends，經典分布式架構設計模式之一。我在學習和工作經驗累積中，逐漸加深了對 BFF 的理解。作為一種模式，它具有一些更加確切的使用場景，和一些能匹配的特定問題。

在本篇文章中，你們會與我一起穿越回BFF誕生的歷史中，尋找其起源。并一同探索和學習這個在分布式系統中出鏡率極高的架構模式。

尋找歷史的線頭

在毫無頭緒的情況下，我們可以首先從Thoughtworks技術雷達中 BFF 的條目入手，去找到一些歷史的蛛絲馬跡。BFF 條目的發布時間是在 2015 年 11 月10 日。從這個信息我們可以獲知，BFF 在歷史嶄露頭角應該是在 2015 年 。

緊接著，在谷歌搜索關鍵字Backend for Frontends 以及將時間范圍限定在 2015 年 1 月 1 日到 2015 年 11 月 10 日。通過對比搜索結果的時間，我們可以輕易發現最早出現 Backend for Frontends 詞條的文章。文中提到，BFF 這個名字是由當時團隊 Tech Leader Nick Fisher首次提出，通過投票獲得了內部團隊的認可。好了，我們現在獲得了一個非常具體的證據。作為嚴謹的技術工作者，我們找到其他的交叉證據，提高這個結論的置信度。

非常幸運的是，在另一篇2015 年的 Thoughtworks 洞見文章中也提到了與上面證據相同的內容。終于，我們可以說 BFF 模式是在解決 SoundCloud的分布式系統問題中首次出現。下面，讓我們一起回到BFF第一次發揮威力的現場吧。

神功初成

為了能讓大家更容易了解到SoundCloud 當年究竟遇到了什么樣的挑戰，我會在下面通過分類分項來列舉情況以及進行分析。

背景：

• SoundCloud主要是通過付費訂閱與廣告進行盈利（也就是說，越多的曝光渠道，會給SoundCloud 帶來更多的盈利）
• SoundCloud 是一個單體系統，通過暴露共享 API 的方式為 Web 客戶端、Android 和 iOS 應用程序以及互聯網、合作伙伴等渠道提供服務。這些共享 API 隨著功能和特性一起增長，最終變成了平臺與客戶端之間的集成點。
• 將 2007 年開始運行的 SoundCloud 從單體模式轉變至微服務模式， 這里是具體改造過程。此時，單體服務已經被拆分為多個微服務。
• 支持在 iOS 平臺上新增的應用程序（原來的產品主要是在 Web 端提供服務）

主要動機：

• 減少產品發布上線的時間
• 支持 iOS 平臺新的應用程序，隔離新用戶體驗設計帶來的風險。
• 增加后端團隊與客戶端團隊合作的節奏，提高工作效率。

挑戰：

• 為了讓第三方開發人員能更自由地集成，需要 API 設計不對數據的使用方式做出任何假設。所以，為了提供簡單的體驗，也需要許多不同的 HTTP API 提供具有高數據寬容度的服務。最終，獲取構建一個簡單的頁面的數據，也需要上百個 API 請求。
• 當團隊需要變更現有 API 時，需要確保不會破壞現有的任何客戶端以及重要的第三方集成。所以，一旦需要添加新內容，都必須投入巨大工作量來確保新功能不只適用于特定客戶端。上面這些情況使協調日常工作變得更加困難，最終導致了新功能發布緩慢。
• 開始準備開發新 iOS 應用程序， 新平臺上應用程序的用戶體驗會全部被重塑

通過分析上面的各種情況，可以得出當時SoundCloud 后端團隊面對如下幾個問題：

• 問題一：需要為第三方客戶提供合適粒度的 API，結果提供的 API 數據粒度過細，導致想完成一個業務服務需要請求的 API 太多。
• 問題二：對外 API 與特定的使用方耦合嚴重，邊界模糊，復雜度高導致維護 API 的工作量巨大，新功能發布緩慢。
• 問題三：iOS 平臺新客戶端改 進了用戶體驗和交互方式，需要隔離新App帶來的風險，并且還要找到與多個客戶端團隊更好的合作方式。

這三個問題在后端團隊進行微服務改造中往往也會遇到。讓我們一起看看，當年的 SoundCloud 團隊在面臨同樣的問題時，是如何一步步見招拆招，摸索出 BFF模式 這個內功心法的。

演進之路

接下來，BFF 模式演進這一分是由客戶端團隊獲得的。由于他們是 API 的消費者， 可以將不同服務進行多次邏輯調用，混合到后端的用戶配置（UserProfile）文件中。這樣避免了對后端服務多次不同的調用，實現客戶端對單個資源的簡單請求。這將簡化客戶端代碼并提高整體性能，例如：

• GET /user-profile/123.json

后端團隊接受了這個邏輯，并開始試驗這個方式。他們在 BFF 中編寫了很多 Presentation Model。在完成一部分任務后，后端團隊突然意識到 BFF 不只是被客戶端使用的 API ，它本身就是申請的一部分。BFF 新的形態出現了，具體如下圖所示：

隨著時間推移，SoundCloud 的 BFF 也在增加。他們已經在生產環境同時維護著 5 個 BFF 了。為了進一步提高生產力，減少不必要的重復。用戶配置（User Profile） 被從每個不同的微服務中抽取出來，變成一個獨立的在 Services 與 BFF 之間的應用服務（Application Service）。

SoundCloud 的 BFF 依然隨著時間在橫向增長，不同的是這種橫向增長不會再引起任何問題了。最終，BFF 模式的架構演變成與我們現在使用的幾乎一致了。架構如下圖：

總結

我們在維護和使用分布式架構，同時面對多客戶端時，BFF 模式提供了一種很好的架構模式，使后端團隊在構建面向客戶端的復雜需求時，能夠掌控自己的命運。并且，這種自主性對于快速迭代的客戶端應用程序，能夠提供快速而良好的體驗。通過支持持續的演進和變化，這種模式可以將相同變化趨勢的消費者行為，限制在一個可控范圍內。使他們變得更容易合作和改變，并且更好滿足不同客戶端的特性需求。

在系統架構中，因為離需求頻繁變化的前端比較近（網絡和組織架構上），BFF很容易野蠻生長，成為各種“妥協”的自留地，在使用的過程中，我們需要明確架構中各層相關的職能和邊界。同時，如果確實有不得不去做的一些“妥協”，我們也一定要用技術債的方式，繼續跟蹤和管理，避免“妥協”越來越多以后，BFF從一個解決不同變化速率和需求的適配器，變成分布式單體的一個轉化器。

我們往往會在系統設計之初犯下一個錯誤，那便是希望所有東西在一開始都是可復用的。這種思路會給系統后續的開發和維護帶來巨大的挑戰，挑戰可能是來自應用間的協調，也可能是兼顧復用帶來的高工作量。特別是在維護多個客戶端或消費者的場景下會帶來更大的困難。我們應該在考慮通用用法之前，先專注于功能和特定用例。在了解系統現狀的主次和具體情況后，再針對性地區分需要通用和特殊處理的部分。這種系統設計和開發的思路和方式，使我們能夠擁抱變化，立于演進的不敗之地。