了解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有什么優點了？最重要的一點在上文中已經提到了，它能夠滿足因不同客戶端特殊的交互引起的對新接口的要求，所以一開始就會針對相應的設備設計好對應的接口。如果使用單一、通用的API，我們一開始並沒有考慮到特殊需求，那么有新的請求需要出現時，可能會出現以下問題：
(1)如果添加新的接口，這樣容易造成接口的不穩定；
(2)如果考慮在原有的接口上進行修改，可能需要會產生一些的耦合，破壞單一職責。
考慮這樣一個簡單例子，因為移動APP的屏幕限制，在某一個列表頁我們只需要展示一些關鍵的信息，但是由於調用的是服務端提供統一的API，服務端在設計的時候只考慮到了web端，返回所有的字段信息，但這些對於移動端而言都是無用的。在優化性能時處理這樣的問題時，服務器端就需要新增接口或者通過引入相關耦合來解決這樣的問題。而使用BFF在很大程度能避免這樣的問題。
使用BFF的另一個優點就是當由於某一客戶端需要調用調用多個不同的服務端接口來實現某一功能時，可以直接在對應的BFF層編寫相應的API，而不會影響到基層的公共服務，且客戶端不用直接向多個后台發起調用，可以優化性能。
當然，凡事有利有弊，BFF帶來便利好處的同時也會引起一些問題，如代碼重復，加大開發工作量等。所以在使用時需要結合現實情況仔細斟酌，符合項目的應用開發背景。例如螞蟻財富使用BFF的場景如下。(沒有具體分析，有興趣的可以通過上面提供的鏈接和查閱相關資料進行研究)
