![5C2E790C-1486-49bf-86FA-418BF79C9682.png](https://ucc.alicdn.com/pic/developer-ecology/c02ff35cd25146bd8fb8315da1ec76c9.png)

## 什麼是 BFF

BFF 全稱是 Backends For Frontends (服務於前端的後端)，起源於 2015 年 Sam Newman 一篇部落格文章[《Pattern: Backends For Frontends —— Single-purpose Edge Services for UIs and external parties》](https://samnewman.io/patterns/architectural/bff/)。

微服務和前後端分離的流行，在後端服務邊界上通常會有一個 API 層，向下調系統內的多個微服務，經過聚合、適配和裁剪等一些列的處理後，向上為前端提供 HTTP 協議的 API。

![](https://img.alicdn.com/tfs/TB1zsGhzUT1gK0jSZFrXXcNCXXa-1222-904.png)
![](https://data-analysis.cn-shanghai.log.aliyuncs.com/logstores/article-logs/track_ua.gif?APIVersion=0.6.0&title=%E5%9F%BA%E4%BA%8E%E5%87%BD%E6%95%B0%E8%AE%A1%E7%AE%97%20BFF%20%E6%9E%B6%E6%9E%84&author=%E5%80%9A%E8%B4%A4&src=article)

然後隨著移動端的興起，出現了 H5、iOS 和 Android 等多端並存的開發場景，由於移動端的螢幕尺寸比較小，所以顯示的資訊和傳統 Web 端會有較大的區別，而且移動端對於訪問連線數和資料量也有更高的要求。此時通用 API 層的開發就會碰到一些困境，比如需要為不同的端提供不同的 API。而這些 API 的設計與不同端上的展示邏輯相關性較強，所以不太適合由後端團隊或者 API 團隊來負責。因為這些 API 的維護人員會夾在前後端之間去做協調和取捨，非常的心累。

Sam Newman 先後在 REA 和 SoundCloud 兩家公司實踐了為不同的端做獨立的 Backend API，稱之為 BFF。以解決不同端對 API 的差異化需求的問題。

![](https://img.alicdn.com/tfs/TB1AJemzKL2gK0jSZFmXXc7iXXa-1364-882.png)

## BFF 的好處

**歷史遺留業務支撐**

一些老系統的介面規範可能比較陳舊，比如說不是 Restful 的。藉助於 BFF 層做一些介面轉換，更好的適配端上技術發展的需求。

**協調穩定的中臺和多變的端需求**

端上變化快主要體現在兩個方面：
* 技術革新：端上的技術更新比較快，js 框架層次不窮。移動端也有很多選擇，有 H5、Java/OC、Kotlin/Swift、React Native、Flutter等等。
* 業務變化：前端的產品變化往往會比後端的業務變化更頻繁。

**補齊端側的差異化投放能力**

有些產品在投放到不同的國家、語種、人群中時，可以在 BFF 層做一些轉換，比如後端的報錯可以在這裡做一些和使用者語種相關的翻譯。

**橫向聚合和基於聚合的最佳化**

有一些產品模組會涉及到多箇中臺服務，BFF 可以作為邊緣服務層，起到聚合 API 的作用。

**端上的業務效能評估**

在端上嘗試一種新的體驗難免要改變 API。如果沒有 BFF，為了 A/B 測試需要同時修改前端和 API。假如移動和 Web 團隊都需要跑 A/B 測試怎麼辦？一個團隊可能需要等待另一團隊。

BFF 讓不同團隊可以獨立的進行試驗。您可能會發現，首先在 BFF 中實施實驗性 API 更改，然後將試驗移植到 A/B 測試中，然後再將其移植到核心 API 中，更為方便。

## BFF 的一些問題

**資源成本高**

不管 BFF 多簡單，都需要提供一臺伺服器執行，嚴格一點的話，還需要提供幾套環境部署。比如一些大公司內部
要求，不管多麼簡單應用都需要 4 臺伺服器，並且伺服器的審批流程可能會比較慢長。

**併發性難以保障**

BFF 層一般由前端的同學開發，然而保證 BFF 高可用，對前端的同學往往是個挑戰。當訪問量突增時，可能出現 BFF 這層先被打爆，導致整個系統架構可用性被拉低。

**運維困難**

誰開發誰運維，然後前端的同學可能缺乏運維線上應用經驗，BFF 的運維也是個很大的問題。

## Serverless For Backend

由於 Serverless 特別是[函式計算](https://statistics.functioncompute.com/?title=%E5%9F%BA%E4%BA%8E%E5%87%BD%E6%95%B0%E8%AE%A1%E7%AE%97%20BFF%20%E6%9E%B6%E6%9E%84&author=%E5%80%9A%E8%B4%A4&src=article&url=http%3A%2F%2Ffc.console.aliyun.com%2F%3Ffctraceid%3DYXV0aG9yJTNEJUU1JTgwJTlBJUU4JUI0JUE0JTI2dGl0bGUlM0QlRTUlOUYlQkElRTQlQkElOEUlRTUlODclQkQlRTYlOTUlQjAlRTglQUUlQTElRTclQUUlOTclMjBCRkYlMjAlRTYlOUUlQjYlRTYlOUUlODQ%3D)，在應用部署之後，假如沒有訪問量就不會消耗計算資源，更不會產生費用。當訪問量增加以後，平臺會以百毫秒級別的速度對應用進行擴容，訪問量下降以後背後的計算資源（函式例項）也會隨之收縮。同時也給使用者提供了開箱即用監控報警和日誌檢索功能。

函式計算彈性伸縮、按量付費和免運維的優勢正好是對應了傳統 BFF 的缺點。所以將 BFF 部署到函式計算平臺就可以非常完美的解決上述 BFF 的問題。

![](https://img.alicdn.com/tfs/TB1o4aOArr1gK0jSZR0XXbP8XXa-1218-816.png)

當部署成本下降以後，也為 BFF 拆解得更小提供了可能性。此時端側可以按照業務模組來組織對應的 BFF 模組。比如說，運營平臺的前端開發自己負責對應的 BFF 模組開發，裝置中心的前端負責自己的 BFF，相互之間可以少一些衝突，真正做到**誰享受誰負責**。

### 基於函式計算的方案

函式計算平臺的 BFF 架構方案有四層：端側、閘道器層、BFF 層和中臺服務。

端側可以保持自己熟悉的技術方案進行開發。比如網頁端可以選擇 React 或者 Vue.js，移動端可以選擇 Java/Kotlin 或者 Objective C/Swift。也可以選擇 React Native 或者 Flutter 這種跨多端的方案。

閘道器層有兩種選擇：API Gateway 和 HTTP Trigger。API Gateway 的功能豐富，支援限流，但是會產生額外的費用。HTTP Trigger 支援簡單的路由對映，繫結域名，雖然不支援限流但是免費的，適用於輕量級應用。

BFF 層建議按照業務模組進行拆分，不同的功能模組建不同的函式，如果不同端的模組之間的介面差異較大也可以拆解成不同的函式。然後透過 Fun 工具把這些函式組織成若干個專案。專案的拆解可以考慮按照維護的團隊進行拆分，不同的團隊維護不同專案，減少之間的交叉和衝突。

![](https://img.alicdn.com/tfs/TB1TaSTArY1gK0jSZTEXXXDQVXa-1850-874.png)

###  SFF 研發流程

下面我們從本地開發、釋出流程和服務監控三個方面看看 SFF 的研發流程怎麼弄。

#### 本地研發

本地工程分為三個部分

* APP/H5 -  React Native 或者 Vue.js 等端側技術
* SFF - FC 函式，常見的有 express 或者 egg
* 中臺 API 介面 - 可以選擇 API Mock 或者直連測試環境。

本地除錯。偏好命令列的開發者可以使用 [funcraft](https://github.com/alibaba/funcraft)工具透過 fun local start 本地啟動服務。偏好桌面 GUI 的開發者可以使用函式計算提供的 [VSCode Plugin](https://marketplace.visualstudio.com/items?itemName=aliyun.aliyun-serverless)。

單元測試可以選中自己喜歡的測試框架：Mocha 或者 Jest

下面是一種建議的專案結構

```
sffdemo
├── README.md
├── function
│   ├── package.json
│   ├── template.yml
│   └── user.js
├── package.json
└── src
    ├── component
    ├── layout
    ├── model
    ├── page
    └── service
```

src 目錄放置 APP 或者 H5 的程式碼。function 目錄放置 bff 程式碼，可以用 ROS 模板 template.yml 描述函式，使用 fun 工具進行釋出。

####  釋出流程

日常開發建議使用命令列釋出，安裝和配置 fun 工具以後，在 BFF 專案中放置一個 template.yml 的 ROS 描述檔案，然後藉助於 fun deploy 命令進行快速部署。

新手也可以選擇去[函式計算控制檯](https://fc.console.aliyun.com)，使用 ZIP 檔案包上傳的方式釋出。

對於更復雜的場景可以配置 CI/CD。比如說程式碼倉庫選擇 Gitlab/Github，構建系統選擇 Travis CI/Gitlab CI/Jenkins ，提交程式碼到程式碼倉庫自動觸發構建和釋出。更多細節可以參考[Serverless 實戰 —— Funcraft + OSS + ROS 進行 CI/CD](https://yq.aliyun.com/articles/727171)

![](https://img.alicdn.com/tfs/TB1aAe8ArY1gK0jSZTEXXXDQVXa-1063-492.png)

#### 服務監控

關於可觀察性方面，函式計算提供了開箱即用的監控、日誌和報警。

![](https://img.alicdn.com/tfs/TB1NNiPABv0gK0jSZKbXXbK2FXa-1838-928.png)

### 成本優勢

使用者的應用負載通常具備多種型別，對資源的規格和彈性要求各不相同。函式計算提供了預付費和後付費計量模式，幫助您在不同場景下獲得顯著的成本優勢。預付費是指使用者先判斷應用的資源需求，預先購買指定數量的資源消費券後再使用。預付費的優點是單價低，比後付費便宜 70% 左右；缺點是應用負載動態變化，按照峰值購買資源將導致較低的資源利用率。後付費是指使用者根據應用實際使用的資源按需付費。函式計算按量資源是根據例項執行請求的時間付費，精確到百毫秒。如果沒有請求，則無需付費。因此可以認為按量資源的利用率是 100%。後付費的優點是資源利用率高，缺點是單價高。函式計算的自動伸縮能夠讓您將預付費和後付費資源無縫結合起來，在不同場景下都能獲得有競爭力的成本。

![](https://img.alicdn.com/tfs/TB1B2KPAxz1gK0jSZSgXXavwpXa-1892-946.png)

更具體的費用計算和成本最佳化方案可以參考[函式計算成本最佳化最佳實踐](https://help.aliyun.com/document_detail/138831.html)

## 小結

每個人對 Serverless 的定義和落地都可能有不一樣的理解。藉助於函式計算帶來的 Serverless 優勢，BFF 真正的做到了誰享受誰負責、低成本和免運維。

>“[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

基於函式計算的 BFF 架構

相關文章