瞭解BFF架構

參考文章：
     - http://samnewman.io/patterns/architectural/bff/
     - https://os.alipayobjects.com/rmsportal/WtUmBLJSmqtDHkvJzuzM.pdf
     - http://www.ouchangjian.com/article/58c5f48c887279691018ec66
     - http://coolhfei.blog.163.com/blog/static/221440652016931101647644/
     - https://www.thoughtworks.com/insights/blog/bff-soundcloud

BFF全稱是Backends For Frontends(服務於前端的後端)，Sam Newman曾在他的博客中寫了一篇相關的文章——Pattern: Backends For Frontends，在文章中Sam Newman詳細地說明了BFF。本文參考了幾篇不一樣博客和文章，簡單闡述一下本身對BFF的認識。

---

簡而言之，BFF就是服務器設計API時會考慮到不一樣設備的需求，也就是爲不一樣的設備提供不一樣的API接口，雖然它們多是實現相同的功能，但由於不一樣設備的特殊性，它們對服務端的API訪問也各有其特色，須要區別處理。所以出現了相似下圖一種設計方式。

以上兩張圖有類似點，也有不一樣之處。客戶端都不是直接訪問服務器的公共接口，而是調用BFF層提供的接口，BFF層再調用基層的公共服務，不一樣的客戶端擁有不一樣的BFF層，它們定製客戶端須要的API。圖一和圖二的不一樣之處在因而否須要爲類似的設備人，如IOS和android分別提供一個BFF，這個須要根據現實狀況決定，不一樣的項目環境解決手段不同。

---

那麼採用BFF架構與多端公用、單一的API有什麼優勢了？最重要的一點在上文中已經提到了，它可以知足因不一樣客戶端特殊的交互引發的對新接口的要求，因此一開始就會針對相應的設備設計好對應的接口。若是使用單1、通用的API，咱們一開始並無考慮到特殊需求，那麼有新的請求須要出現時，可能會出現如下問題：

(1)若是添加新的接口，這樣容易形成接口的不穩定；
   (2)若是考慮在原有的接口上進行修改，可能須要會產生一些的耦合，破壞單一職責。

考慮這樣一個簡單例子，由於移動APP的屏幕限制，在某一個列表頁咱們只須要展現一些關鍵的信息，可是因爲調用的是服務端提供統一的API，服務端在設計的時候只考慮到了web端，返回全部的字段信息，但這些對於移動端而言都是無用的。在優化性能時處理這樣的問題時，服務器端就須要新增接口或者經過引入相關耦合來解決這樣的問題。而使用BFF在很大程度能避免這樣的問題。
使用BFF的另外一個優勢就是當因爲某一客戶端須要調用調用多個不一樣的服務端接口來實現某一功能時，能夠直接在對應的BFF層編寫相應的API，而不會影響到基層的公共服務，且客戶端不用直接向多個後臺發起調用，能夠優化性能。

---

固然，凡事有利有弊，BFF帶來便利好處的同時也會引發一些問題，如代碼重複，加大開發工做量等。因此在使用時須要結合現實狀況仔細斟酌，符合項目的應用開發背景。例如螞蟻財富使用BFF的場景以下。(沒有具體分析，有興趣的能夠經過上面提供的連接和查閱相關資料進行研究)