目錄
-
- 一、微服務架構的特點
- 二、微服務接口類設計技巧
-
- 2.1、BFF(Backend For Frontend)
-
- 2.1.1、 服務分布式帶來的第一個挑戰導致的幾個典型問題
- 2.1.2、什么是 BFF
- 2.1.3、BFF 應用場景
- 2.1.4、BFF 落地經驗
-
- 2.1.4.1、前端負責 BFF 開發優缺點
- 2.1.4.2、后端負責 BFF 開發優缺點
- 2.1.5、什么時候用 BFF 來提供接口,什么時候直接訪問微服務
- 2.2、GraphQL
-
- 2.2.1、GraphQL 的概述
- 2.2.2、GraphQL 的基本原理
- 2.3、接口循環調用
本文來源:極客時間vip課程筆記
一、微服務架構的特點
-
服務分布式
原本由單體或者 SOA 系統提供的功能,現在由多個微服務來提供,不同微服務提供不同的功能。
-
數據分布式
原本由大一統的存儲系統(主要是關系數據庫 RDBMS)存儲的數據,現在分散存儲在多個獨立的存儲系統上,不同微服務可以根據數據特性,采用不同的存儲系統。
二、微服務接口類設計技巧
2.1、BFF(Backend For Frontend)
2.1.1、 服務分布式帶來的第一個挑戰導致的幾個典型問題
-
服務分布式帶來的第一個挑戰,就是前端(廣義上的前端,含 App/H5/ 桌面客戶端等,下同)原來可能只需要一個接口請求就能完成的功能,現在需要多次請求多個微服務不同的接口,尤其是一些復雜的頁面,需要請求的后端接口會更多。這就導致了幾個典型問題的出現。
-
第一個是請求性能問題。
這里的性能問題其實不是單個微服務接口處理的性能,而是前端和服務端來回請求的網絡消耗。當一個頁面需要請求多個接口獲取后端數據的時候,即便能夠并行發送多個請求,由于網絡尤其是移動端網絡的不穩定性,如果其中一個或幾個請求訪問慢的話,整個頁面就可能會加載緩慢,從而影響用戶體驗。
-
第二個是網絡帶寬問題。
雖然單個微服務接口請求的數據可能不大,但是由于網絡傳輸協議本身也需要占用不少字節空間(例如 HTTP 請求 header),大量的小請求會導致機房入口帶寬大大增加,從而增加企業網絡帶寬成本。
-
第三個是前端開發成本問題。
前端需要理解和對接多個后端微服務,開發工作量、聯調工作量都會增加不少。尤其是后端微服務經過演變,提供了多個版本接口時,多版本接口的選擇和適配會給前端開發人員帶來較大的理解和開發負擔。
2.1.2、什么是 BFF
-
BFF 技術就是應對上述挑戰的接口技術方案,全稱是 Backend For Frontend,中文一般翻譯為“前端專屬后端”或“服務前端的后端”。
-
結合上圖,接口訪問基本邏輯如下。
當用戶訪問一個普通不復