一、BFF
在聊Serverless之前跟大家先談談BFF，BFF顧名思義就是Backend For Frontend，用中文解釋就是服務於前端的后端，那么為什么會有BFF？
在項目開發中，前后端分配的問題
“你自己請求2個接口再組裝不就行了嗎” - 后端同學
“少一次http請求啊，加一個接口有那么難嗎” - 前端同學
前端同學和后端同學都各有各的道理，有沒有一種解決方案可以化解這種尷尬的場景，於是就有了BFF
1、介紹
BFF層初衷是在后台服務與前端（客戶端）之間添加一層，接下來我們來看看下面這張圖
2、BFF到底發揮什么作用
答案是：用戶體驗適配層和API聚合層 : 主要負責快速跟進 UI 迭代，對后端接口服務進行組合、處理，對數據進行：裁剪、格式化、聚合等
在BFF層下面是各種后端微服務，在BFF上層則是各種前端應用（多端應用），向下調用后端為服務，向上給客戶端提供接口服務，后端為BFF層的前端提供的 RPC 接口， BFF 層則直接調用服務端 RPC 接口拿到數據，按需加工數據，來完成整個BFF的閉環（以Node+GraphQL技術棧為主）
3、BFF層誰來開發
遵循服務自治，誰使用誰開發的原則，也就意味着只能由前端同學來挑起這個重任，同時離“全棧工程師”又進一步了。
4、api網關
BFF和網關Gateway都是微服務架構中的重要的兩個概念，看下圖簡單的例子
分享一下螞蟻金服體驗技術部負責人玉伯，曾說的一句話：“BFF 模式不僅僅是一種技術架構，從社會分工角度講，BFF 更是一種多元價值導向的分層架構
5、BFF的優勢
主要有以下幾點優勢：
（1）可以降低溝通成本：后端同學追求解耦，希望客戶端應用和內部微服務不耦合，通過引入BFF這中間層，使得兩邊可以獨立變化
（2）多端應用適配：展示不同的（或更少量的）數據，比如PC端頁面設計的API需要支持移動端，發現現有接口從設計到實現都與桌面UI展示需求強相關，無法簡單適應移動端的展示需求 ，就好比PC端一個新聞推薦接口，接口字段PC端都需要，而移動端呢H5不需要，這個時候根據不同終端在BFF層做調整，同時也可以進行不同的（或更少的）API調用（聚合）來減少http請求
當你在設計 API 時，會因為不同終端存在不同的區分，它們對服務端提供的 API 訪問也各有其特點，需要做一些區別處理。這個時候如果考慮在原有的接口上進行修改，會因為修改導致耦合，破壞其單一的職責。
6、BFF的痛點
（1）重復開發：每個設備開發一個 BFF 應用，也會面臨一些重復開發的問題展示，增加開發成本
（2）維護問題：需要維護各種 BFF 應用。以往前端也不需要關心並發，現在並發壓力卻集中到了 BFF 上
（3）鏈路復雜：流程變得繁瑣，BFF引入后，要同時走前端、服務端的研發流程，多端發布、互相依賴，導致流程繁瑣
（4）浪費資源: BFF層多了，資源占用就成了問題，會浪費資源，除非有彈性伸縮擴容
總結BFF分層下“幸福的煩惱”：研發成本上升、流程繁瑣、運維經驗不足
7、有什么方案可以解決傳統BFF痛點
包括解決前端需要關心應用的負載均衡、備份冗災、監控報警等一些列運維部署的操作
如何統一管理和運維，提高發布速度、降低運維成本
答案是：Serverless
二、Serverless
我們可以將 Serverless 拆解為 server 和 less 兩個單詞，從字面上推斷詞意即為“少服務器的，亦或是無服務器的，弱化后端和運維概念，當前比較成熟的 Serverless 雲產品主要有 Amazon Lambda、Google Cloud Function、Azure Function、AliCloud Function Compute、Tencent CloudBase等
Serverless 的演變
1、什么是Serverless
Serverless = Faas (Function as a service) + Baas (Backend as a service)
2、雲函數（Faas）
FaaS（Function-as-a-Service）是服務商提供一個平台、提供給用戶開發、運行管理這些函數的功能，而無需搭建和維護基礎框架，是一種事件驅動由消息觸發的函數服務
前端同學調用Faas服務如同調用本地函數一樣簡潔，如下所示，是一個騰訊雲中一個簡單的小程序雲開發demo，cloudfunction是用來定義雲函數的方法
3、后端即服務（ BaaS）
BaaS（Backend-as-a-Service）后端即服務，包含了后端服務組件，它是基於 API 的第三方服務，用於實現應用程序中的核心功能，包含常用的數據庫、對象存儲、消息隊列、日志服務等等。
比如騰訊雲雲開發中下面的這些服務：
-
微信小程序的雲調用 wx-server-sdk
-
雲開發數據庫 wx.cloud.database
4、Serverless的架構
5、Serverless的優勢
- 環境統一: 不需要搭建服務端環境,, 保持各個機器環境一致 Serverless 的機制天然可復制
- 按需計費: 我們只在代碼運行的時候付費，沒有未使用資源浪費的問題
- 豐富的SDK: 有完善的配套服務, 如雲數據庫, 雲存儲, 雲消息隊列, 雲音視頻和雲 AI 服務等
- 彈性伸縮: 不需要預估流量, 關心資源利用率, 備份容災, 擴容機器 ，可以根據流量動態提前峰值流量
6、Serverless的缺點
- 雲廠商強綁定：它們常常會和廠商的其他雲產品相綁定，如對象存儲、消息隊列等，意味你需要同時開通其他的服務，遷移成本高，如果想遷移基本原有的邏輯不可服用，kennel需要重構
- 不適合長時間任務：雲函數平台會限制函數執行時間，如阿里雲 Function Compute 最大執行時長為 10 min
- 冷啟動時間：函數運行時，執行容器和環境需要一定的時間，對 HTTP 請求來講，可能會帶來響應時延的增加
- 調試與測試：開發者需要不斷調整代碼，打印日志，並提交到函數平台運行測試，會帶來開發成本和產生費用
7、Serverless的應用場景
（1）場景1: 負載有波峰波谷
波峰波谷時，機器資源要按照峰值需求預，比如醫院掛號這需求，假設在每天10點放號預約，那10點就會有峰值的出現，為了這個峰值並發的考慮，准備了相對應性能（固定）的服務器，然而在波谷時機器利用率又明顯下降，不能進行資源復用導致浪費，而serverless不用為了波峰去做准備，不用留住水位，支持彈性縮擴容，在你高峰時再在進行動態擴容
（2）場景2: 定時任務（報表統計等）
服務空閑時間來處理批量數據，來生成數據報表，通過Serverless方式，不用額外購買利用率並不高的處理資源，比如每日的凌晨，分析前一天收集的數據並生成報告
（3）場景3: 小程序開發（雲開發）
比如微信小程序開發m在實際開發中，如果我們不用雲開發的openid獲取流程，而用傳統的方式，你就知道openid的獲取是非常繁瑣的一個過程，前端需要通過wx.login獲取一個code值（具有時效性）再通過code值去后台用appsecret去調取openid。
而雲函數由於是部署在騰訊雲的關系，騰訊雲將雲調用將鑒權部分有效的封裝，讓你的接口很容易的實現了鑒權保護，無需維護復雜的鑒權機制，從而讓個人開發者和小團隊可以更容易地開發小程序