譯者 | 康少京

審校 | 墨色

策劃 | 信遠(yuǎn)

在過去，應(yīng)用程序很簡(jiǎn)單。瀏覽器向web應(yīng)用端點(diǎn)發(fā)送請(qǐng)求，后者從數(shù)據(jù)庫中獲取數(shù)據(jù)并返回響應(yīng)。移動(dòng)客戶端的興起以及與其他應(yīng)用的集成打破了這種簡(jiǎn)單性。本文將討論一種處理復(fù)雜性的解決方案。

?增加系統(tǒng)架構(gòu)的復(fù)雜性

首先，我們需要對(duì)上述簡(jiǎn)單的體系結(jié)構(gòu)進(jìn)行建模。

?移動(dòng)客戶端改變了這種方法。移動(dòng)客戶端的顯示區(qū)域更小，例如：平板電腦，手機(jī)。有一種可能的解決方案是返回所有數(shù)據(jù)，并讓每個(gè)客戶端過濾掉不必要的數(shù)據(jù)。不幸的是，手機(jī)客戶端也受到帶寬不足的影響，并非所有手機(jī)都具備5G功能。即使是這樣，如果它位于偏僻的地方，連接點(diǎn)只能提供H+，那也沒用。

因此，不能過度抓取。每個(gè)客戶端需要不同的數(shù)據(jù)子集。使用單體，可以根據(jù)每個(gè)客戶端提供多個(gè)端點(diǎn)。

?可以設(shè)計(jì)一個(gè)在最前端具有特定層的網(wǎng)絡(luò)應(yīng)用程序，該層檢測(cè)發(fā)出請(qǐng)求的客戶端，并過濾掉響應(yīng)中的無關(guān)數(shù)據(jù)，web應(yīng)用程序中的過度抓取不是問題。

如今，微服務(wù)風(fēng)靡一時(shí)，每個(gè)人及其鄰居都想實(shí)現(xiàn)一個(gè)微服務(wù)架構(gòu)。

微服務(wù)背后是“兩個(gè)披薩團(tuán)隊(duì)”的理念。每個(gè)團(tuán)隊(duì)都是自主的，負(fù)責(zé)一個(gè)微服務(wù)或一個(gè)前端應(yīng)用程序。為了避免開發(fā)工作之間的耦合，每個(gè)微服務(wù)團(tuán)隊(duì)發(fā)布其API合同并非常謹(jǐn)慎地處理更改。

每個(gè)微服務(wù)都需要為每種客戶端提供嚴(yán)格必需的數(shù)據(jù)，以避免上面的過度抓取問題。對(duì)于少量的微服務(wù)，讓每個(gè)微服務(wù)根據(jù)客戶端過濾數(shù)據(jù)很麻煩，數(shù)量眾多，這顯然是不可能的，因此，微服務(wù)數(shù)量與不同客戶端數(shù)量之間的笛卡爾因子使得每個(gè)微服務(wù)上的專用數(shù)據(jù)端點(diǎn)的成本成倍增長(zhǎng)。

解決方案：Backend for Front-End

BFF背后的想法是將邏輯從每個(gè)微服務(wù)轉(zhuǎn)移到一個(gè)專用的可部署端點(diǎn)。后者負(fù)責(zé)：

• 從每個(gè)所需的微服務(wù)中獲取數(shù)據(jù)
• 提取相關(guān)部分
• 聚合它們
• 最后以一種與特定客戶相關(guān)的格式返回

同一個(gè)團(tuán)隊(duì)開發(fā)客戶端及其相關(guān)的BFF。BFF提供了與微服務(wù)相同的權(quán)衡：通過增加系統(tǒng)復(fù)雜性來提高開發(fā)速度。

獨(dú)立部署單元與API網(wǎng)關(guān)

關(guān)于BFF的文獻(xiàn)暗示了專用部署單元，如上圖所示。有些文章，比如本篇，反對(duì)使用API網(wǎng)關(guān)的BFF。但概念圖不一定與部署圖一一對(duì)應(yīng)。

與許多領(lǐng)域一樣，人們應(yīng)該更多地關(guān)注組織方而不是技術(shù)方面的問題。在這種情況下，最關(guān)鍵的一點(diǎn)是，負(fù)責(zé)前端的團(tuán)隊(duì)也要對(duì)BFF負(fù)責(zé)。無論是單獨(dú)的部署單元還是API網(wǎng)關(guān)配置的一部分，都是一個(gè)實(shí)現(xiàn)細(xì)節(jié)。

例如，使用Apache APISIX，每個(gè)團(tuán)隊(duì)都可以將他們的BFF代碼獨(dú)立部署為單獨(dú)的插件。

性能考慮

對(duì)于單體，情況如下：

• 從客戶端到單體的請(qǐng)求需要一個(gè)特定的時(shí)間T。它經(jīng)過互聯(lián)網(wǎng)，T可能很長(zhǎng)。
• 與T相比，對(duì)數(shù)據(jù)庫的不同內(nèi)部調(diào)用可以忽略不計(jì)。

一旦遷移到微服務(wù)，客戶端就需要依次調(diào)用每個(gè)微服務(wù)。因此，對(duì)于順序調(diào)用，時(shí)間變?yōu)椤疲═1、T2、Ti、Tn）。由于這是不可接受的，客戶端通常使用并行調(diào)用。時(shí)間變?yōu)樽畲螅═1、T2、Ti、Tn）。注意，即使這樣，客戶端也需要執(zhí)行n個(gè)請(qǐng)求。

在BFF的情況下，無論實(shí)現(xiàn)的是什么，我們都會(huì)在T時(shí)間內(nèi)返回一個(gè)請(qǐng)求。與單體相比，從BFF到微服務(wù)還有額外的請(qǐng)求t1、t2、ti、tn，但它們可能位于一起。因此，整體時(shí)間會(huì)比單體更長(zhǎng)，但由于每個(gè)t都比T短得多，因此不會(huì)對(duì)用戶體驗(yàn)產(chǎn)生太大影響。

結(jié)論?

你可能不應(yīng)該實(shí)現(xiàn)微服務(wù)。如果你這樣做，微服務(wù)不應(yīng)該返回整個(gè)數(shù)據(jù)，而是讓客戶端負(fù)責(zé)清理這些數(shù)據(jù)。因此，微服務(wù)需要根據(jù)客戶端返回所需的確切數(shù)據(jù)。它在微服務(wù)與客戶端之間引入了強(qiáng)耦合。你想移除這個(gè)耦合。為實(shí)現(xiàn)這一點(diǎn)，Backend For Front-end方法將清理邏輯從每個(gè)服務(wù)中提取到一個(gè)專用組件中，該組件還負(fù)責(zé)聚合數(shù)據(jù)。每個(gè)客戶團(tuán)隊(duì)還負(fù)責(zé)其專用的BFF：當(dāng)客戶更改其數(shù)據(jù)需求時(shí)，團(tuán)隊(duì)可以部署適應(yīng)新需求的新BFF版本。

BFF是一個(gè)概念解決方案。沒有什么要求提取/清理/聚合邏輯位于特定位置。它可以是專用部署單元，也可以是API網(wǎng)關(guān)中的插件。

在之后的文章中，將會(huì)展示本文中所描述的不同步驟。

原文鏈接：https://dzone.com/articles/discussing-backend-for-front-end

譯者介紹

康少京，51CTO社區(qū)編輯，目前從事通訊類行業(yè)，底層驅(qū)動(dòng)開發(fā)崗位，研究過數(shù)據(jù)結(jié)構(gòu)、Python，現(xiàn)對(duì)操作系統(tǒng)和數(shù)據(jù)庫等相關(guān)領(lǐng)域感興趣。