[翻譯] Backend for Front-End (BFF)
--
原文：Discussing Backend for Front-end — DZone
作者：Nicolas Fränkel
在過去的日子，應用程式非常簡單。瀏覽器向網絡應用程式端點發送請求，後者從資料庫中提取數據並返回響應。
移動客戶端的興起和與其他應用程式的集成破壞了這種簡單性。在本文中，我將討論處理這種複雜性的解決方案。
系統架構的增加複雜性
首先，讓我們模擬上述簡單的架構。
移動客戶端改變了這種方法。移動客戶端的顯示區域較小：對於平板電腦而言稍小，對於手機則更小。
一種可能的解決方案是返回所有數據，並讓每個客戶端過濾掉不必要的數據。不幸的是，手機客戶端的帶寬也較低。並非每部手機都具有5G功能。即使如此，如果它位於連接點僅提供H+的偏遠地區，這些功能也無法使用。
2023年微服務和容器化的前景
微服務和容器化
DZone的2022年微服務和容器化趨勢報告探討了雲架構和設計原則的交集，深入介紹了微服務的編排技術、微服務的設計模式、容器的安全性、服務網格等等！
因此，過度提取並不是一個選項。每個客戶端需要不同的數據子集。對於巨石應用，可以根據每個客戶端提供多個端點，這是可管理的。
可以設計一個具有特定前端層的網路應用程式。該層檢測請求的來源客戶端並在響應中過濾掉不相關的數據。網路應用程式中的過度提取不是問題。
現在，微服務風行一時。每個人和他們的鄰居都想實施微服務架構。
微服務背後的理念是小型團隊，每個團隊都是自主的，負責一個微服務 — 或者一個前端應用程式。為了避免開發工作之間的耦合，每個微服務團隊都會發布其API合約並非常謹慎地處理變更。
每個微服務都需要為每種客戶端嚴格提供所需的數據，以避免上述過度提取問題。對於少數微服務，讓每個微服務根據客戶端過濾數據是可行的；對於大量微服務來說，則根本不可能。因此，微服務的數量和不同客戶端之間的笛卡爾乘積使得每個微服務上的專用數據端點成本呈指數增長。
解決方案：面向前端的後端（BFF）
BFF的理念是將每個微服務中的邏輯移至一個專用的可部署端點。後者負責：
- 從每個所需微服務中獲取數據
- 提取相關部分
- 聚合它們
- 最後以特定客戶端相關的格式返回它們
同一團隊開發客戶端和相關的BFF。BFF提供與微服務相同的權衡：通過增加系統複雜性來提高開發速度。
獨立部署單元 vs. API 網關
有關BFF的文獻意味著專用的部署單元，如上圖所示。有些文章，比如這篇文章，將BFF與API網關進行對比。但是，概念上的圖表不一定要與部署圖表一一對應。
與許多領域一樣，人們應該更多關注組織方面，而不是技術方面。在這種情況下，最關鍵的一點是負責前端的團隊也負責BFF。它是作為獨立部署單元還是API網關配置的一部分是一個實現細節。
例如，使用Apache APISIX，每個團隊可以將其BFF代碼作為獨立的插件獨立部署。
性能考慮
對於巨石應用，情況如下：
- 客戶端到巨石應用的請求需要時間 T。它通過互聯網，而 T 可能很長。
- 與 T 相比，對數據庫的不同內部調用可以忽略不計。
一旦遷移到微服務，客戶端需要依次調用每個微服務。因此，時間變為順序調用的_T1、T2、Ti、Tn_之和_Σ(T1, T2, Ti, Tn)。由於這是不可接受的，通常客戶端使用並行調用，時間變為最大值 max(T1, T2, Ti, Tn)_。請注意，即使在這種情況下，客戶端仍需要執行_n_個請求。
在BFF的情況下，我們回到了一個請求，在 T 時間內，無論實現方式如何。與巨石應用相比，從BFF到微服務的額外請求t1、t2、ti、tn，但它們可能位於一起。因此，總體時間會比巨石應用更長，但由於每個t比T短得多，它不會對用戶體驗造成太大影響。
總結
你可能不應該實施微服務。如果你這樣做，微服務不應該返回所有數據並讓客戶端負責清理它們。因此，微服務需要根據客戶端返回精確的必要數據子集。這是這個故事的起點。
面向前端的後端(BFF)是一個解決方案，其中一個專用的後端端點負責從不同的微服務獲取數據、提取相關部分、聚合它們並返回客戶端所需的數據。
儘管BFF會增加系統複雜性，但它提供了開發速度的好處。同時，BFF使得數據提取集中化，並在性能方面提供了一些優勢。
然而，每個組織都有自己的特定情況和需求。因此，實施BFF之前，請仔細考慮您的架構、團隊組織和性能目標。
