原文連結：傳送門。

想象下這個場景：你需要使用微服務架構來構建一個電子商務應用。你會有一些微服務來服務於顧客，訂單，產品，購物車，等等。這些微服務會暴露被前端系統消費的各種API。

然而，微服務返回給前端的資料並不會根據前端系統要呈現資料的精確方式進行格式化或者過濾。在這種情況下，前端系統本身需要一些邏輯來再次格式化這些資料。而在前端系統具有這些邏輯會佔用更多的瀏覽器資源。

在像這樣的情況下，我們可以使用BFF來將這些前端邏輯移動到一箇中間層。這個中間層就是BFF。這樣，當前端系統請求一些資料時，它其實會呼叫BFF中的API。

如上所描述的，BFF會做以下事情：

• 呼叫相關的微服務API並獲取到所需的資料。
• 基於前端展示來格式這些資料。
• 將格式化後的資料返回給前端。

這樣的話，前端頁面都會具有儘可能少的邏輯。因此BFF可以幫助將資料流水線化的進行展示，並承擔了為前端提供了有側重的API的職責。

另一個可以簡化你的前後臺關係的重要方式是通過在它們之間共享型別來實現。具體可以參考這裡。

BFF如何適配電子商務示例？

下圖展示了微服務如何通過BFF與前端系統進行互動。

BFF的角色

如同我們已經敘述的，BFF在微服務和前端系統之間扮演了一個簡單介面的角色。理想情況下，前端專案組也會負責管理BFF。

一個單獨的BFF側重於一個UI，並僅僅只是那個UI。因此，其會幫助我們保持前端系統的簡潔並通過後臺看到一個統一的資料檢視。

這帶來了另一個問題，我們可以為多個UI構建多個BFF麼？我們將在此文的後續章節回答這個問題，請繼續閱讀。

BFF會增加延遲麼

現在我們知道BFF類似於一個在客戶端和其他外部API，服務之間的一個代理伺服器。如果請求必須經過另一個元件，其必定會增加延遲。然而，如果我們需要與多個未曾為前端進行優化的服務一起工作時，相比於瀏覽器的高資源使用來說，這些延遲是微不足道的。

構建一個BFF允許你很聰明的對其他後臺服務/API進行批量呼叫並一次性的返回資料，或者通過轉化或者格式化資料來返回一個更方便的展示形式。

這個對於在2G/3G的移動客戶端來說是很有用的，因為在這種情況下會需要好幾秒（甚至更久）來建立連線。

什麼時候可以為你的應用使用BFF

像很多其他模式一樣，在你的應用中是否使用BFF取決於你打算要遵循的上下文和架構。舉個例子，如果你的應用是一個簡單的單體應用，那麼BFF是沒有必要的，它不會為應用增加價值。然而，如果你的應用依賴於微服務，並且消費了很多其他的外部API及服務，我們最好可以用BFF來流水線化資料流並提升我們應用的效率。

進一步的，如果你應用需要為一個特定的前端開發一個優化後的後臺或者你的客戶端消費的資料需要大量的聚合計算，那麼，BF是一個合適的選項。

我們可以有多個BFF麼？

當然了，這正是具有一個BFF的完整點。

傳統的實踐（沒有BFF的應用）針對於所有的客戶僅僅只有一個API閘道器。

然而，使用BFF的目的是為你的客戶端提供一個有側重的介面來與之連線。舉個例子，移動UI的資料消費可能會與瀏覽器的資料消費有所不同。在這種情況下，為了更好的資料展示，我們可以使用兩個BFF。讓我們來看看使用多個BFF的應用架構圖。

如你所見的，每一個客戶端都會有一個BFF，他們會幫助優化來自於服務的都響應。

使用BFF的優勢

使用BFF的幾個優勢列舉如下：

• 概念分離：前端需求與後臺概念分離，這更容易維護。
• 更容易的維護和修改APIs：客戶端應用會更少的知道後臺架構，這會使得對API的修改變得更有彈性。
• 前端頁面更好的進行錯誤處理：大多數時候，服務端錯誤對於前端使用者來說是沒有意義的，沒有直接返回服務端傳送的錯誤，BFF將需要展示給使用者的錯誤進行了對映處理。這會改進使用者體驗。
• 多個裝置型別可以並行呼叫後臺：當瀏覽器對瀏覽器BFF傳送請求時，移動裝置可以做相同的處理，這可以幫助更快的從服務的獲取相應。
• 更好的安全性：一些敏感資料可以被隱藏，而且當傳送響應給前臺時，對前端來說不需要的資料可以被忽略。這個抽象可以使得攻擊者更難定位到你的應用。
• 對於元件的共享的團隊擁有許可權：應用的不同部分可以被不同的團隊更容易的處理。前端團隊樂於擁有他們的客戶端程式以及底層的資源消費層。導致了更快的開發效率，下圖展示了一個團隊隔離的示例。

BFF最佳實踐

到現在為止我們所看到的一切很讓我驚奇，然而，BFF可以減少錯誤麼？

答案是否定的。像任何一個其他的技術或者模式一樣，即使是BFF也有陷阱，為了避免這些，我們需要遵從最佳實踐。

• 避免與自包含的API一起實現BFF：你的自包含的API應該在微服務層。很多開發者忘記了這一點，開始在BFF層也實現了服務層的API。你應該始終記得BFF是客戶端和服務端之間的一個轉化層。當資料從服務API返回時，BFF的目的就是將其轉化為客戶端指定的資料格式。
• 避免BFF邏輯重複：需要注意的一個關鍵點是單個的一個BFF應當關注與特定的使用者體驗，而不是裝置型別。舉個例子，大多時候，所有的移動裝置共享同樣的使用者體驗，在這種情況下，對於所有的作業系統來說一個BFF是足夠的。我們沒有必要為IOS建立一個BFF，而為安卓建立另一個BFF。
• 避免過度依賴BFFs：BFF僅僅只是一個轉化層。是的，它也給應用程式提供了一定級別的安全。但是你不應該依賴比你應該依賴的更多。你的API層和前端層應該照看所有的功能和安全方面的事情而不管是否有BFF的出現。因為BFF應該填充縫隙，而不應該向應用新增功能或者服務。

總結

BFF不僅僅幫助開發，也能顯著的提升使用者體驗。因此，當保證BFF側重於其前端的同時，考慮資料優化和聚合是很關鍵的。

除此之外，如果你之前還沒有用過BFF模式，現在是開始的時候了。之後，讓我也知道你的體驗和意見。