微服務之 BFF

網關是微服務架構不可或缺的一部分，作爲微服務架構的唯一入口，將所有請求轉發到後端對應的微服務上去，同時又可以將各個微服務中的通用功能集中到網關去做，而不是在每個微服務都實現一遍，比如權限校驗，限流，熔斷和監控等。

如圖所示，這是個典型的前後端分離的微服務架構，但這個架構在的問題是，一個接口無法同時滿足不同場景的業務。如移動端 APP，可能與 Web 端、OpenAPI 的需求不一樣，導致接口存在差異, 這時微服務就要對接不同的 API 需求，產生了各種各樣的問題。

有沒有更優雅的解決方式呢？那就是引入 BFF，這個詞是 2015 年 11 月 Sam Newman 在他的一篇博客中提出的。BFF 是 Backends for Frontends 的簡寫，爲了前端的後端。Sam Newman 的博客還有一個副標題：Single-purpose Edge Services for UIs and external parties，爲了用戶界面或外部方的單一目的的邊緣服務。用戶界面比如我們常見的網頁，或 App，外部方比如第三方 App，客戶 App，企業微信，小程序等。其實這中模式更早一點就出現了，淘寶在更早一點的時候就設立中途島項目，其主要內容就是 BFF。

BFF 也稱聚合層或者適配層，它主要承接一個適配角色：將內部複雜的微服務，適配成對各種不同用戶體驗（無線 / Web/H5 / 第三方等）友好和統一的 API。聚合裁剪適配是 BFF 的主要職責。

改造後的微服務架構如下圖:

引入 BFF 後，有如下好處:

  1. 聚合, 將後端多個請求合併成一個請求，以減少網絡傳輸時間。這些請求可能來自一個服務，也可能來自多個服務。

  2. 適配, 因爲遵守的接口規範不同，多個微服務和外部服務的接口可能有很多不同，在 BFF 層可以做一些適配，給前端代碼提供同一個的數據格式和接口格式。

  3. 裁剪, 同樣的信息在不同的客戶端有着不同的展現，比如手機屏幕尺寸較小，內存較小，CPU 性能較差，只能展示部分非常重要的信息，如果和電腦上使用同一個接口，勢必導致手機上頁面渲染變慢，還會浪費手機電量和網絡流量。

我們在看到 BFF 帶來的各種好處的同時，也要注意到它所帶來的代碼重複和工作量增加方面的問題。另外因爲增加了一層調用鏈，也會對響應時間稍有影響。

作者：九尾狐 0813
來源：https://www.cnblogs.com/tony0813/p/13296755.html

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

猜你喜歡