什么是 BFF

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

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、柳林網(wǎng)站維護(hù)、網(wǎng)站推廣。

微服務(wù)和前后端分離的流行，在后端服務(wù)邊界上通常會(huì)有一個(gè) API 層，向下調(diào)系統(tǒng)內(nèi)的多個(gè)微服務(wù)，經(jīng)過聚合、適配和裁剪等一些列的處理后，向上為前端提供 HTTP 協(xié)議的 API。

然后隨著移動(dòng)端的興起，出現(xiàn)了 H5、iOS 和 Android 等多端并存的開發(fā)場景，由于移動(dòng)端的屏幕尺寸比較小，所以顯示的信息和傳統(tǒng) Web 端會(huì)有較大的區(qū)別，而且移動(dòng)端對于訪問連接數(shù)和數(shù)據(jù)量也有更高的要求。此時(shí)通用 API 層的開發(fā)就會(huì)碰到一些困境，比如需要為不同的端提供不同的 API。而這些 API 的設(shè)計(jì)與不同端上的展示邏輯相關(guān)性較強(qiáng)，所以不太適合由后端團(tuán)隊(duì)或者 API 團(tuán)隊(duì)來負(fù)責(zé)。因?yàn)檫@些 API 的維護(hù)人員會(huì)夾在前后端之間去做協(xié)調(diào)和取舍，非常的心累。

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

BFF 的好處

歷史遺留業(yè)務(wù)支撐

一些老系統(tǒng)的接口規(guī)范可能比較陳舊，比如說不是 Restful 的。借助于 BFF 層做一些接口轉(zhuǎn)換，更好的適配端上技術(shù)發(fā)展的需求。

協(xié)調(diào)穩(wěn)定的中臺(tái)和多變的端需求

端上變化快主要體現(xiàn)在兩個(gè)方面：

• 技術(shù)革新：端上的技術(shù)更新比較快，js 框架層次不窮。移動(dòng)端也有很多選擇，有 H5、Java/OC、Kotlin/Swift、React Native、Flutter等等。
• 業(yè)務(wù)變化：前端的產(chǎn)品變化往往會(huì)比后端的業(yè)務(wù)變化更頻繁。

補(bǔ)齊端側(cè)的差異化投放能力

有些產(chǎn)品在投放到不同的國家、語種、人群中時(shí)，可以在 BFF 層做一些轉(zhuǎn)換，比如后端的報(bào)錯(cuò)可以在這里做一些和用戶語種相關(guān)的翻譯。

橫向聚合和基于聚合的優(yōu)化

有一些產(chǎn)品模塊會(huì)涉及到多個(gè)中臺(tái)服務(wù)，BFF 可以作為邊緣服務(wù)層，起到聚合 API 的作用。

端上的業(yè)務(wù)效能評(píng)估

在端上嘗試一種新的體驗(yàn)難免要改變 API。如果沒有 BFF，為了 A/B 測試需要同時(shí)修改前端和 API。假如移動(dòng)和 Web 團(tuán)隊(duì)都需要跑 A/B 測試怎么辦？一個(gè)團(tuán)隊(duì)可能需要等待另一團(tuán)隊(duì)。

BFF 讓不同團(tuán)隊(duì)可以獨(dú)立的進(jìn)行試驗(yàn)。您可能會(huì)發(fā)現(xiàn)，首先在 BFF 中實(shí)施實(shí)驗(yàn)性 API 更改，然后將試驗(yàn)移植到 A/B 測試中，然后再將其移植到核心 API 中，更為方便。

BFF 的一些問題

資源成本高

不管 BFF 多簡單，都需要提供一臺(tái)服務(wù)器運(yùn)行，嚴(yán)格一點(diǎn)的話，還需要提供幾套環(huán)境部署。比如一些大公司內(nèi)部
要求，不管多么簡單應(yīng)用都需要 4 臺(tái)服務(wù)器，并且服務(wù)器的審批流程可能會(huì)比較慢長。

并發(fā)性難以保障

BFF 層一般由前端的同學(xué)開發(fā)，然而保證 BFF 高可用，對前端的同學(xué)往往是個(gè)挑戰(zhàn)。當(dāng)訪問量突增時(shí)，可能出現(xiàn) BFF 這層先被打爆，導(dǎo)致整個(gè)系統(tǒng)架構(gòu)可用性被拉低。

運(yùn)維困難

誰開發(fā)誰運(yùn)維，然后前端的同學(xué)可能缺乏運(yùn)維線上應(yīng)用經(jīng)驗(yàn)，BFF 的運(yùn)維也是個(gè)很大的問題。

Serverless For Backend

由于 Serverless 特別是 函數(shù)計(jì)算，在應(yīng)用部署之后，假如沒有訪問量就不會(huì)消耗計(jì)算資源，更不會(huì)產(chǎn)生費(fèi)用。當(dāng)訪問量增加以后，平臺(tái)會(huì)以百毫秒級(jí)別的速度對應(yīng)用進(jìn)行擴(kuò)容，訪問量下降以后背后的計(jì)算資源（函數(shù)實(shí)例）也會(huì)隨之收縮。同時(shí)也給用戶提供了開箱即用監(jiān)控報(bào)警和日志檢索功能。

函數(shù)計(jì)算彈性伸縮、按量付費(fèi)和免運(yùn)維的優(yōu)勢正好是對應(yīng)了傳統(tǒng) BFF 的缺點(diǎn)。所以將 BFF 部署到函數(shù)計(jì)算平臺(tái)就可以非常完美的解決上述 BFF 的問題。

當(dāng)部署成本下降以后，也為 BFF 拆解得更小提供了可能性。此時(shí)端側(cè)可以按照業(yè)務(wù)模塊來組織對應(yīng)的 BFF 模塊。比如說，運(yùn)營平臺(tái)的前端開發(fā)自己負(fù)責(zé)對應(yīng)的 BFF 模塊開發(fā)，設(shè)備中心的前端負(fù)責(zé)自己的 BFF，相互之間可以少一些沖突，真正做到 誰享受誰負(fù)責(zé)。

基于函數(shù)計(jì)算的方案

函數(shù)計(jì)算平臺(tái)的 BFF 架構(gòu)方案有四層：端側(cè)、網(wǎng)關(guān)層、BFF 層和中臺(tái)服務(wù)。

端側(cè)可以保持自己熟悉的技術(shù)方案進(jìn)行開發(fā)。比如網(wǎng)頁端可以選擇 React 或者 Vue.js，移動(dòng)端可以選擇 Java/Kotlin 或者 Objective C/Swift。也可以選擇 React Native 或者 Flutter 這種跨多端的方案。

網(wǎng)關(guān)層有兩種選擇：API Gateway 和 HTTP Trigger。API Gateway 的功能豐富，支持限流，但是會(huì)產(chǎn)生額外的費(fèi)用。HTTP Trigger 支持簡單的路由映射，綁定域名，雖然不支持限流但是免費(fèi)的，適用于輕量級(jí)應(yīng)用。

BFF 層建議按照業(yè)務(wù)模塊進(jìn)行拆分，不同的功能模塊建不同的函數(shù)，如果不同端的模塊之間的接口差異較大也可以拆解成不同的函數(shù)。然后通過 Fun 工具把這些函數(shù)組織成若干個(gè)項(xiàng)目。項(xiàng)目的拆解可以考慮按照維護(hù)的團(tuán)隊(duì)進(jìn)行拆分，不同的團(tuán)隊(duì)維護(hù)不同項(xiàng)目，減少之間的交叉和沖突。

SFF 研發(fā)流程

下面我們從本地開發(fā)、發(fā)布流程和服務(wù)監(jiān)控三個(gè)方面看看 SFF 的研發(fā)流程怎么弄。

本地研發(fā)

本地工程分為三個(gè)部分

• APP/H5 - React Native 或者 Vue.js 等端側(cè)技術(shù)
• SFF - FC 函數(shù)，常見的有 express 或者 egg
• 中臺(tái) API 接口 - 可以選擇 API Mock 或者直連測試環(huán)境。

本地調(diào)試。偏好命令行的開發(fā)者可以使用 funcraft工具通過 fun local start 本地啟動(dòng)服務(wù)。偏好桌面 GUI 的開發(fā)者可以使用函數(shù)計(jì)算提供的 VSCode Plugin。

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

下面是一種建議的項(xiàng)目結(jié)構(gòu)

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 描述函數(shù)，使用 fun 工具進(jìn)行發(fā)布。

發(fā)布流程

日常開發(fā)建議使用命令行發(fā)布，安裝和配置 fun 工具以后，在 BFF 項(xiàng)目中放置一個(gè) template.yml 的 ROS 描述文件，然后借助于 fun deploy 命令進(jìn)行快速部署。

新手也可以選擇去 函數(shù)計(jì)算控制臺(tái)，使用 ZIP 文件包上傳的方式發(fā)布。

對于更復(fù)雜的場景可以配置 CI/CD。比如說代碼倉庫選擇 Gitlab/Github，構(gòu)建系統(tǒng)選擇 Travis CI/Gitlab CI/Jenkins ，提交代碼到代碼倉庫自動(dòng)觸發(fā)構(gòu)建和發(fā)布。更多細(xì)節(jié)可以參考 Serverless 實(shí)戰(zhàn) —— Funcraft + OSS + ROS 進(jìn)行 CI/CD

服務(wù)監(jiān)控

關(guān)于可觀察性方面，函數(shù)計(jì)算提供了開箱即用的監(jiān)控、日志和報(bào)警。

成本優(yōu)勢

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

更具體的費(fèi)用計(jì)算和成本優(yōu)化方案可以參考 函數(shù)計(jì)算成本優(yōu)化最佳實(shí)踐

小結(jié)

每個(gè)人對 Serverless 的定義和落地都可能有不一樣的理解。借助于函數(shù)計(jì)算帶來的 Serverless 優(yōu)勢，BFF 真正的做到了誰享受誰負(fù)責(zé)、低成本和免運(yùn)維。

“ 阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈?！?/p>

分享名稱：基于函數(shù)計(jì)算的BFF架構(gòu)-創(chuàng)新互聯(lián)
網(wǎng)址分享：http://weahome.cn/article/csgogi.html