网关和BFF是如何演进出来的?
介紹
BFF(Backend for Frontend)和網(wǎng)關(guān)Gateway是微服務(wù)架構(gòu)中的兩個重要概念,這兩個概念相對比較新,有些開發(fā)人員甚至是架構(gòu)師都不甚理解。
本文用假想的公司案例+圖示的方式,解釋BFF和網(wǎng)關(guān)是什么,它們是怎么演化出來的。希望對架構(gòu)師設(shè)計和落地微服務(wù)架構(gòu)有所啟發(fā)。
服務(wù)化架構(gòu)V1
我們先把時間推回到大致2011年左右。假設(shè)有一家有一定業(yè)務(wù)體量的電商公司CoolShop,在這個時間點它已經(jīng)完成單塊應(yīng)用的解構(gòu)拆分,內(nèi)部SOA服務(wù)化已經(jīng)初步完成。這個時候它的無線應(yīng)用還沒有起步,前端用戶體驗層主要是傳統(tǒng)的服務(wù)端Web應(yīng)用,總體服務(wù)化架構(gòu)V1如下圖所示。
服務(wù)化架構(gòu)V2
時間轉(zhuǎn)眼來到2012年初,國內(nèi)的無線應(yīng)用開始起風(fēng),CoolShop公司也緊跟市場趨勢,研發(fā)自己的無線原生App。為了能盡快上線,公司的架構(gòu)師提出如下V2架構(gòu),讓App直接調(diào)用內(nèi)部的服務(wù):
這個架構(gòu)有如下問題:
- 聚合:某一個功能需要同時調(diào)用幾個后端API進行組合,比如首頁需要顯示分類和產(chǎn)品細節(jié),就要同時調(diào)用分類API和產(chǎn)品API,不能一次調(diào)用完成。
- 裁剪:后端服務(wù)返回的Payload一般比較通用,App需要根據(jù)設(shè)備類型進行裁剪,比如手機屏幕小,需要多裁掉一些不必要的內(nèi)容,Pad的屏幕比較大,可以少裁掉一些內(nèi)容。
- 適配:一種常見的適配場景是格式轉(zhuǎn)換,比如有些后臺服務(wù)比較老,只支持老的SOAP/XML格式,不支持新的JSON格式,則無線App需要適配處理不同數(shù)據(jù)格式。
服務(wù)化架構(gòu)V2.1
V2架構(gòu)問題太多,沒有開發(fā)實施。為解決上述問題,架構(gòu)師經(jīng)過思考決定在外部設(shè)備和內(nèi)部微服務(wù)之間引入一個新的角色~Mobile BFF。
所謂BFF其實是Backend for Frontend的簡稱,中文翻譯是為前端而開發(fā)的后端,它主要由前端團隊開發(fā)(后端微服務(wù)一般由后端團隊開發(fā))。BFF可以認為是一種適配服務(wù),將后端的微服務(wù)進行適配(主要包括聚合裁剪和格式適配等邏輯),向無線端設(shè)備暴露友好和統(tǒng)一的API,方便無線設(shè)備接入訪問后端服務(wù)。
新的V2.1架構(gòu)如下圖所以:
這個架構(gòu)的優(yōu)勢是:
- 后端如果發(fā)生變化,通過BFF屏蔽,前端設(shè)備可以做到不受影響。
- 前端如果發(fā)生變化,通過BFF屏蔽,后端微服務(wù)可以暫不變化。
- 當(dāng)無線App有新的需求時,通過BFF的屏蔽,可以減少前后端團隊的溝通協(xié)調(diào)開銷,很多需求由前端團隊在BFF上就可以自己搞定。
服務(wù)化架構(gòu)V3
V2.1架構(gòu)比較成功,實施落地以后支持了CoolShop公司早期無線業(yè)務(wù)的成長。隨著業(yè)務(wù)量進一步增長,投入無線研發(fā)的團隊也不斷增加,V2.1架構(gòu)也逐漸暴露出如下問題:
為了解決上述問題,架構(gòu)師經(jīng)過思考決定在外部設(shè)備和內(nèi)部BFF之間再引入一個新的角色~API Gateway,新的架構(gòu)V3如下圖所示:
新的架構(gòu)V3有如下調(diào)整:
- 路由,將來自無線設(shè)備的請求路由到后端的某個微服務(wù)BFF集群。
- 認證,對涉及敏感數(shù)據(jù)的API訪問進行集中認證鑒權(quán)。
- 監(jiān)控,對API調(diào)用進行性能監(jiān)控。
- 限流熔斷,當(dāng)出現(xiàn)流量洪峰,或者后端BFF/微服務(wù)出現(xiàn)延遲或故障,網(wǎng)關(guān)能夠主動進行限流熔斷,保護后端服務(wù),并保持前端用戶體驗可以接受。
- 安全防爬,收集訪問日志,通過后臺分析出惡意行為,并阻斷惡意請求。
在新的V3架構(gòu)中,網(wǎng)關(guān)承擔(dān)了重要的角色,它是解耦拆分和后續(xù)升級遷移的利器。在網(wǎng)關(guān)的配合下,單塊BFF實現(xiàn)了解耦拆分,各業(yè)務(wù)線團隊可以獨立開發(fā)和交付各自的微服務(wù),研發(fā)效率大大提升。另外,把跨橫切面邏輯從BFF剝離到網(wǎng)關(guān)上去以后,BFF的開發(fā)人員可以更加專注業(yè)務(wù)邏輯交付,實現(xiàn)了架構(gòu)上的關(guān)注分離(Separation of Concerns)。
服務(wù)化架構(gòu)V4
業(yè)務(wù)在不斷發(fā)展,技術(shù)架構(gòu)也需要不斷的調(diào)整來應(yīng)對需求的變化。近年,CoolShop公司技術(shù)團隊又迎來了新的業(yè)務(wù)和技術(shù)需求,主要是:
為滿足業(yè)務(wù)需求,架構(gòu)師對服務(wù)化架構(gòu)又進行了拓展升級,新的V4新架構(gòu)如下圖所示:
V4整體思路和V3類似,只是拓展了新的接入渠道:
V4是一個比較完整的現(xiàn)代微服務(wù)架構(gòu),從外到內(nèi)依次分為:端用戶體驗層->網(wǎng)關(guān)層->BFF層->微服務(wù)層。整個架構(gòu)層次清晰,職責(zé)分明,是一種靈活的能夠支持業(yè)務(wù)不斷創(chuàng)新的演化式架構(gòu)。
結(jié)論
總結(jié)
以上是生活随笔為你收集整理的网关和BFF是如何演进出来的?的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SpringBoot+Mybatis加载
- 下一篇: Elasticsearch(一)架构及一