微服務的 API 網關與 BFF 前端之後端

單體應用很簡單。瀏覽器向 webapp 端點發送請求；後者從數據庫中獲取數據並返回響應。
移動客戶端與微服務的興起破壞了這種簡單性，這篇文章中討論一種處理複雜性的解決方案。

系統架構的複雜性增加
1、移動客戶端的顯示區域更小：平板電腦更小，手機更小。
一個可能的解決方案是返回所有數據並讓每個客戶端過濾掉不必要的數據。不幸的是，移動客戶端也受到帶寬較差的影響。並非每部手機都具有 5G 功能。
因此，過度獲取數據不是一種選擇。每個客戶端都需要不同的數據子集。使用單體，可以根據每個客戶端提供多個端點。
也可以在最前面設計一個具有特定層的網絡應用程序，這種層檢測發出請求的客戶端並過濾掉響應中的不相關數據，Web 應用程序中的過度獲取數據就能解決。
2、如今，微服務風靡一時。
微服務背後是兩個披薩團隊的想法。每個團隊都是自治的，負責單個微服務或單個前端應用程序。爲了避免開發工作之間的耦合，每個微服務團隊都會發布其 API 合約並非常小心地處理更改。
每個微服務都需要爲每種客戶端提供嚴格必要的數據，以避免上述過度獲取數據問題。微服務數量少，每一個都根據客戶端過濾數據很麻煩；微服務的數量就很多，這顯然是不可能的。
微服務數量和不同客戶端數量之間的笛卡爾因子使得每個微服務上的專用數據端點成倍地昂貴。

解決方案：後端之前端 BFF（Backend For Front-end）
BFF 背後的想法是將邏輯從每個微服務轉移到一個專用的 “可部署端點”，這個“可部署端點” 負責以下功能：

開發客戶端的同一個團隊開發客戶端及其相關的 BFF。
BFF 提供與微服務相同的權衡：通過增加系統複雜性來提高開發速度。

BFF 單獨的部署單元與 API 網關比較
API 網關是所有客戶端進入系統的單一入口點，而 BFF 是負責單一類型的客戶端。
但是，API 網關模式有時也稱爲 “前端之後端”
API 網關服務會根據客戶端應用程序的不同要求而不斷髮展，最終，由於這些不同的客戶端需求，它本身也會變得臃腫，就又變成一個大的單體服務，因此，建議將 API 網關拆分爲多個服務或多個較小的 API 網關，例如根據每個客戶端的類型對應一個，這樣 API 網關就變成了 BFF。
最關鍵的一點是，負責前端的團隊也要對 BFF 負責。無論是單獨的部署單元還是 API 網關配置的一部分，都是實現細節。
例如，使用 Apache APISIX，每個團隊都可以將他們的 BFF 代碼獨立部署爲單獨的插件。

結論
每個客戶短團隊負責他們專用的 BFF：當客戶端更改其數據需求時，團隊可以部署適應新需求的新 BFF 版本。
BFF 是一個概念性解決方案，它可以是 API 網關中的專用部署單元或插件。

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

猜你喜歡