最近公司業務繁忙，全力以赴在做狐小E，一直沒時間做技術分享，現在上線了，終於有時間來寫點東西。
網關是微服務架構不可或缺的一部分，作為微服務架構的唯一入口，將所有請求轉發到后端對應的微服務上去，同時又可以將各個微服務中的通用功能集中到網關去做，而不是在每個微服務都實現一遍，比如權限校驗，限流，熔斷和監控等。
如圖所示，這是個典型的前后端分離的微服務架構，但這個架構在的問題是，一個接口無法同時滿足不同場景的業務。如移動端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后，有如下好處:
- 聚合, 將后端多個請求合並成一個請求，以減少網絡傳輸時間。這些請求可能來自一個服務，也可能來自多個服務。
- 適配, 因為遵守的接口規范不同，多個微服務和外部服務的接口可能有很多不同，在 BFF 層可以做一些適配，給前端代碼提供同一個的數據格式和接口格式。
- 裁剪, 同樣的信息在不同的客戶端有着不同的展現，比如手機屏幕尺寸較小，內存較小，CPU 性能較差，只能展示部分非常重要的信息，如果和電腦上使用同一個接口，勢必導致手機上頁面渲染變慢，還會浪費手機電量和網絡流量。
我們在看到 BFF 帶來的各種好處的同時，也要注意到它所帶來的代碼重復和工作量增加方面的問題。另外因為增加了一層調用鏈，也會對響應時間稍有影響。
狐小E, 企業數字化建設的全景攻略