基於函數計算的 BFF 架構

什麼是 BFF

BFF 全稱是 Backends For Frontends (服務於前端的後端)，起源於 2015 年 Sam Newman 一篇博客文章《Pattern: Backends For Frontends —— Single-purpose Edge Services for UIs and external parties》。

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

而後隨着移動端的興起，出現了 H五、iOS 和 Android 等多端並存的開發場景，因爲移動端的屏幕尺寸比較小，因此顯示的信息和傳統 Web 端會有較大的區別，並且移動端對於訪問鏈接數和數據量也有更高的要求。此時通用 API 層的開發就會碰到一些困境，好比須要爲不一樣的端提供不一樣的 API。而這些 API 的設計與不一樣端上的展現邏輯相關性較強，因此不太適合由後端團隊或者 API 團隊來負責。由於這些 API 的維護人員會夾在先後端之間去作協調和取捨，很是的心累。

Sam Newman 前後在 REA 和 SoundCloud 兩家公司實踐了爲不一樣的端作獨立的 Backend API，稱之爲 BFF。以解決不一樣端對 API 的差別化需求的問題。

BFF 的好處

歷史遺留業務支撐

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

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

端上變化快主要體如今兩個方面：

• 技術革新：端上的技術更新比較快，js 框架層次不窮。移動端也有不少選擇，有 H五、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 特別是函數計算，在應用部署以後，假如沒有訪問量就不會消耗計算資源，更不會產生費用。當訪問量增長之後，平臺會以百毫秒級別的速度對應用進行擴容，訪問量降低之後背後的計算資源（函數實例）也會隨之收縮。同時也給用戶提供了開箱即用監控報警和日誌檢索功能。

函數計算彈性伸縮、按量付費和免運維的優點正好是對應了傳統 BFF 的缺點。因此將 BFF 部署到函數計算平臺就能夠很是完美的解決上述 BFF 的問題。

當部署成本降低之後，也爲 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 工具把這些函數組織成若干個項目。項目的拆解能夠考慮按照維護的團隊進行拆分，不一樣的團隊維護不一樣項目，減小之間的交叉和衝突。

SFF 研發流程

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

本地研發

本地工程分爲三個部分

• APP/H5 - React Native 或者 Vue.js 等端側技術
• SFF - FC 函數，常見的有 express 或者 egg
• 中臺 API 接口 - 能夠選擇 API Mock 或者直連測試環境。

本地調試。偏好命令行的開發者可使用 funcraft工具經過 fun local start 本地啓動服務。偏好桌面 GUI 的開發者可使用函數計算提供的 VSCode Plugin。

單元測試能夠選中本身喜歡的測試框架：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 命令進行快速部署。

新手也能夠選擇去函數計算控制檯，使用 ZIP 文件包上傳的方式發佈。

對於更復雜的場景能夠配置 CI/CD。好比說代碼倉庫選擇 Gitlab/Github，構建系統選擇 Travis CI/Gitlab CI/Jenkins ，提交代碼到代碼倉庫自動觸發構建和發佈。更多細節能夠參考Serverless 實戰 —— Funcraft + OSS + ROS 進行 CI/CD

服務監控

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

成本優點

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

更具體的費用計算和成本優化方案能夠參考函數計算成本優化最佳實踐

小結

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

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」