從單體架構(gòu)演化為微服務架構(gòu)后，架構(gòu)者的期望是“模塊A”+“模塊B” = “后端服務”按傅。
場景一
Web端和Mobile端都有一個詳情頁面鞠评，需要調(diào)用模塊A的getDetail接口獲取數(shù)據(jù)谷炸。假設Web端實際需要展示的字段是20個，Mobile端實際需要展示的字段是10個扬舒，對應的數(shù)據(jù)表字段為30個。
方案一：
為Web端和Mobile端提供不同的接口返回各自實際所需的字段凫佛。如：getDetailForWeb讲坎、getDetailForMobile；
方案二：
Web端和Mobile端復用同一個getDetail接口愧薛，返回字段取兩端所需的并集晨炕；
方案三：
Web端和Mobile端復用同一個getDetail接口，返回數(shù)據(jù)表中的所有字段毫炉，各端自取所需瓮栗，以后業(yè)務上可能會再出來小程序端、xx端等則可“復用”瞄勾，可“擴展”遵馆；
方案一的囧境：
- 模塊A承擔了多端業(yè)務變化的適配工作，端上的業(yè)務調(diào)整都會引起模塊A的變化丰榴；
方案二货邓、方案三的囧境：
- 接口返回太多無用字段導致接口響應變慢并增加了前端同學理解接口的難度；
- 因為接口被多端使用會給后續(xù)維護同學增加重構(gòu)的心理壓力四濒，結(jié)果就是隨著業(yè)務的發(fā)展接口返回字段變得越來越多换况；
場景二
前端有個頁面需要同時展示模塊A接口和模塊B接口的數(shù)據(jù)职辨。
方案一：
前端分別調(diào)用模塊A和模塊B的接口并展示；
方案二：
前端調(diào)用模塊A接口戈二，模塊A調(diào)用模塊B獲取數(shù)據(jù)并組裝后返回給前端舒裤；
方案一的囧境：
- 當頁面依賴的模塊不多時不會有什么問題，當依賴的模塊很多時會影響響應（瀏覽器對同一域名有最大請求并發(fā)限制）觉吭；
方案二的囧境：
- 模塊A和模塊B耦合在了一起腾供，并很可能出現(xiàn)雙向依賴的情況；
- 模塊A和模塊B之間的邊界開始模糊鲜滩；
場景三
前端有個頁面需要根據(jù)模塊B getType接口的返回伴鳖，來篩選展示模塊A getDetail返回的內(nèi)容。
方案一：
前端分別調(diào)用模塊A和模塊B的接口徙硅，然后根據(jù)type來篩選展示榜聂；
方案二：
前端只調(diào)用模塊A getDetail接口，模塊A去調(diào)用模塊B getType接口并過濾數(shù)據(jù)返回給前端嗓蘑；
方案一的囧境：
- 長期發(fā)展會導致前端邏輯越來越重须肆，還可能出現(xiàn)同一個功能邏輯散落在前端和后端；
方案二的囧境：
- 同場景二的方案二桩皿；
優(yōu)化方案
增加BFF（Backend For Frontend）層豌汇，這樣職責就清晰了。
前端：專注于交互泄隔、展示拒贱；
BFF層：專注于為各端提供接口服務；
能力層（模塊A梅尤、模塊B）：專注于領域內(nèi)的事情柜思；
