BFF 避坑指南

BFF —— Backends for frontends（服務於前端的後端），是爲了讓後端 API 滿足不同的前端使用場景，而演進出來的一種模式。BFF 在改善前端用戶體驗上起到了非常大的作用，但因爲介於前端和後端之間，在落地實施過程中很容易踩坑，在這篇文章中，我們看看在實施 BFF 的過程中可能遇到哪些 “坑”。爲了幫助快速理解後面講到的問題，我們先來簡單回顧下 BFF 的由來和應用場景。

BFF 的由來

隨着移動設備的快速發展以及產品對用戶交互體驗的關注度增強，前後端分離的架構模式也逐漸被大多數企業所採用。在這種模式下，統一的後端 API 很難滿足在不同場景下對用戶體驗的不同需求。

BFF 模式應運而生，一方面 BFF 隔離了前端 UI 展示對後端 API 的需求，企業可以專注在後端構建核心業務能力，另一方面，BFF 根據已有的後端 API，快速滿足前端在 UI 展示上的需求，來不斷提升用戶體驗；

從知識管理的角度，BFF 模式讓知識邊界定義得更清晰，後端專注於構建業務能力，不需要考慮前端各種場景適配的問題；而前端更關注用戶體驗，可以隨時獨立發佈更新。

BFF 的應用場景

BFF 應用場景（圖片來自 BFF@SoundCloud）

面向前端

BFF 爲前端而生，隨着前端技術（iOS、Android、小程序、Web 等）的不斷髮展，不同前端對後端要求有很大差異，後端服務很難提供滿足多個前端的統一接口，BFF 則可以針對前端的特定需求，作出適配：

• 針對前端 UI 展示邏輯的不同，對後端 API 返回的數據進行裁剪和重新組織，提供面向前端的定製化格式的數據。

• 根據前端業務需求，對後端多個 API 返回的數據進行聚合。

• 對一些特定場景的數據進行緩存，提高性能，進而提升用戶體驗。

面向後端

BFF 隔離了前端 UI 展示對後端 API 的定製化需求，可以很好地支持後端服務的演進：

• 從單體應用遷移到微服務架構，後端架構的演進可以通過 BFF 來進行隔離，參見《前後端分離演進：不能微服務，那就 BFF 隔離》。

• 微服務架構內部的演進，微服務的拆分，也可以藉助 BFF 來減少對前端的影響，參見我的另外一篇文章《迭代開發中的微服務拆分》。

BFF 實踐的三大問題

BFF 模式在前後端分離的架構模式下的確有很多好處，完美隔離了前後端，貌似從此以後前端幹前端的，後端幹後端的，大大降低前後端之間的衝突和依賴。然而事實並非如此，在實施 BFF 的過程中，大家仍然會遇到各種問題，我總結了實施落地 BFF 三大常見問題如下：

問題一：重複代碼

通常情況下我們會爲每個不同的前端構建一個 BFF，還可能會爲一些特定的場景建立 BFF（如對第三方系統提供 API），不可避免地，多個 BFF 之間會出現大量的重複代碼，比如可能會存在相同的數據轉換邏輯，相同的 API 數據聚合邏輯等等。

重複代碼通常被認爲是一種壞味道，但在 BFF 這個場景下，這些重複的代碼是爲了某一個特定的前端服務的，因此處理這個重複要相對謹慎，如果一味粗暴地去掉這些重複，很有可能引發某一個前端需求變化會影響到其他前端應用的情況。

如果確實有些代碼重複且相對穩定，可以嘗試採取下面的方法來消除重複：

• 共享庫，將重複的代碼抽取出來放到共享庫中，不同的 BFF 通過依賴共享庫來達到代碼複用，但要考慮哪些代碼能夠抽取到共享庫中，可以參考我之前的文章《消滅微服務的壞味道 之 共享庫》。

• 將重複的代碼放到後端服務中，這種方法適用於重複的代碼實際承載了真實的業務邏輯，而不只是在做簡單的數據聚合和數據格式轉換，那麼應該把這些重複的代碼下沉到指定的後端服務中。

問題二：滑向 ESB（Enterprise Service Bus，企業服務總線）

除了大量的重複代碼，在微服務架構下，另外一個問題通常會出現在業務演進過程中。當新的業務需求產生時，具體要在哪個後端服務中實現有時候不是一個很容易回答的問題，特別是不同的服務有不同的團隊歸屬時，如果每個服務的歸屬團隊都認爲新的業務需求不是自己服務的業務範疇，最可能的結果就是讓 BFF 負責幫忙組合各個服務的功能，完成這個新的業務需求。漸漸地，BFF 朝着 ESB 的方向發展，變成了集成各個微服務，對外提供新能力的中間件。

這種趨勢某種程度上違背了 BFF 設計的初衷，BFF 爲了適配前端而生，更關注解決前端的用戶體驗問題，而真實的業務能力應該由後端服務來承接，而不是 BFF。

要解決這個問題，首先要清晰地定義每個服務的業務職責，爲了避免服務過多很難劃分清晰邊界，最開始服務儘量不要拆得太小；另外要建立規則來處理新的需求，哪些需求屬於 BFF 的範疇，哪些屬於業務能力，業務能力應該下沉到後端服務中，如果現有服務無法承載這種能力，可以考慮新增服務，而不是寫在 BFF 中。

問題三：性能問題

第三個比較常見的問題就是性能問題，相信你一定遇到過下面的場景，既然有了 BFF，前端的設計開始放飛自我，可以把想展示的信息一股腦都放在一起展示，極端情況下 BFF 可以獲取到任意服務的數據進行組合，我曾見過在一個 BFF 接口中調用了後端服務幾十次來拼湊前端需要的數據，可想而知這個接口的性能一定很差。

爲了解決這種情況帶來的性能問題，通常會採用併發獲取數據然後拼裝的方式，這明顯增加了代碼實現和維護的複雜度，往往會引發新的問題。

因此，在實際開發過程中要非常警惕這種問題的發生，如果一個 BFF 接口調用了 3 個以上接口，那就要警惕了，需要分析下後端服務拆分得合不合理，前端 UI 展示的數據是否有必要放在一起，否則性能問題會逐漸成爲一個不可避免的問題。

小結

架構設計是通過合理的組件拆分以及定義組件之間的關係，將系統整體的複雜性分散到不同的組件中，在更低的維度上解決問題，分而治之。BFF 在前後端分離的架構模式下隔離了前端和後端的關注點，特別是在多個前端或第三方的情況下，BFF 都是非常好的選擇。然而，在實施過程中，仍然要時刻警惕，明確 BFF 設計的初衷，避免因引入 BFF 而帶來了更多的問題。

參考資料

• Pattern: Backends For Frontends 

• BFF @ SoundCloud

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/IZ5wD2Dc5k83dP6dR8M9xg