對于微服務，常見的架構模型就是API網關+服務。
API網關實作鑒權、負載均衡、中間件等公共入口邏輯。
服務實作具體的業務功能。
那麼，API網關設計中又有什麼坑呢？
直接将服務穿透到外網。
API層隻是套了殼，加了鑒權、中間件而已。具體傳回值由服務定。
用戶端到微服務直接通信，強耦合。根本不敢重構，一改結構用戶端就崩了。
需要多次請求，用戶端聚合資料，工作量巨大，延遲高。
缺乏統一的文檔。
如果一個頁面由多個服務組成，比如商品、優惠券、相關推薦、評價。用戶端要請求多個接口，命名規則還不一樣。
有的接口成功，有的接口失敗，需要用戶端自己做降級。
協定不利于統一，各個部門間有差異，需要用戶端端來相容。
面向“端”的API适配，耦合到了内部服務。
每個服務都要為不同的裝置做适配代碼。
多終端相容邏輯複雜，每個服務都需要處理。
統一邏輯無法收斂，比如安全認證、限流。
這樣就導緻了用戶端、服務端都累得要死，誰都不讨好。
而我們的架構設計應該前輕後重的，面向業務場景設計接口，而不是面向資料資源。（不要讓用戶端做組裝）
架構就是一層加一層。
添加了一個BFF層，backend for forntend，專門做适配。
我們新增了一個 app-interface 用于統一的協定出口，在服務内進行大量的 dataset join，按照業務場景來設計粗粒度的 API，給後續服務的演進帶來的很多優勢：
輕量互動：協定精簡、聚合。
差異服務：資料裁剪以及聚合、針對終端定制化API。
動态更新：原有系統相容更新，更新服務而非協定。
溝通效率提升，協作模式演進為移動業務+網關小組。
對接：
大前端---網關，隻用對接資料結構。面向業務場景提供接口。
網關---服務，隻需要對接服務接口。
BFF可以認為是一種适配服務，将後端的微服務進行适配(主要包括聚合裁剪和格式适配等邏輯)，向無線端裝置暴露友好和統一的 API，友善無線裝置接入通路後端服務。
針對頁面提供接口，比如商品頁面，就一個接口，然後BFF層去調用多個服務，在這裡做降級，比如優惠券服務沒有傳回就不顯示就完了。
用戶端隻用和BFF層溝通，什麼适配、協定、相容、定制都是這一層來做。用戶端感覺很爽。
服務端也隻用提供基礎資料，不用關心業務邏輯，不用管适配，傳回的接口是什麼結構。服務端也很爽。
BFF層隻做了資料裁剪，相容之類的邏輯，輕不輕松？也很輕松。
BFF單點了，single point of failure（單點故障）。也就是所有的流量都會到這一層， 如果有流量洪峰或者代碼有bug，全盤當機。
将BFF根據業務拆分，比如檢視商品一個，訂單頁面一個。這樣一個挂不會影響全局。
單個子產品也會導緻後續業務內建複雜度高，根據康威法則，單塊的無線BFF和多團隊之間就出現不比對問題，團隊之間溝通協調成本高，傳遞效率低下。
很多跨橫切面邏輯，比如安全認證，日志監控，限流熔斷等。随着時間的推移，代碼變得越來越複雜，技術債越堆越多。
有沒有發現：
分久必合、合久必分。 分開了就有不能統一的地方，合并了就會單點故障。
跨橫切面(Cross-Cutting Concerns)的功能，需要協調更新架構更新發版(路由、認證、限流、安全)，是以全部上沉，引入了 API Gateway，把業務內建度高的 BFF 層和通用功能服務層 API Gateway 進行了分層處理。
在新的架構中，網關承擔了重要的角色，它是解耦拆分和後續更新遷移的利器。
在網關的配合下，單塊 BFF 實作了解耦拆分，各業務線團隊可以獨立開發和傳遞各自的微服務，研發效率大大提升。
BFF的劃分：
重要性
垂直業務，閉環
流量大小
另外，把跨橫切面邏輯從 BFF 剝離到網關上去以後，BFF 的開發人員可以更加專注業務邏輯傳遞，實作了架構上的關注分離(Separation of Concerns)。
我們業務流量實際為：
<code>移動端 -> API Gateway -> BFF -> Mircoservice</code>
在 FE Web業務中，BFF 可以是 nodejs 來做服務端渲染(SSR，Server-Side Rendering)，注意這裡忽略了上遊的 CDN、4/7層負載均衡(ELB)。
将通用邏輯做到了API網關層，BFF層專注于業務邏輯。
API層采用Nginx這種高可用的軟體，基本不會挂，挂了重新開機即可，限流、負載等邏輯用子產品實作，友善部署。
這一層完全和業務無關。
總結
當耦合性太高的時候，就加一層，作為緩沖。
當合并有單點的時候，就分開。當分開有不能統一的時候，就合并。
盡量讓專門的人做專門的事情。減少業務對技術的耦合。