一、背景介紹

隨著互聯(lián)網(wǎng)和移動設(shè)備的普及，用戶對于應(yīng)用的需求也越來越多樣化和個性化，這就要求應(yīng)用程序在不同的端類型上表現(xiàn)出差異化的交互和UI。同時，在后端微服務(wù)化的變革浪潮下，后端開發(fā)人員需要專注在領(lǐng)域服務(wù)及建模的工作中。而交互/UI的變更頻率往往要高于領(lǐng)域服務(wù)及相關(guān)模型，加之前/后端本身的差異性也會無形中加重后端開發(fā)人員的心智負擔(dān)。這就使得后端開發(fā)人員既無法專注于領(lǐng)域模型的抽象，又無法敏捷靈活地適應(yīng)不同的用戶界面差異，限制了整體的研發(fā)效率提升。

為了解決這個問題，BFF作為一種研發(fā)模式被提出。其作為“面向前端的后端服務(wù)”，作為中間層在軟件架構(gòu)上隔離了領(lǐng)域服務(wù)層及前端UI層。隨著架構(gòu)被隔離，相關(guān)的開發(fā)人員及開發(fā)角色也隨之被清晰的分開：前端研發(fā)負責(zé)BFF的視圖邏輯，后端研發(fā)則可以專注在領(lǐng)域服務(wù)層當(dāng)中。

這種模式改變了原來的生產(chǎn)關(guān)系，令后端開發(fā)人員可以更專注于特定領(lǐng)域模型及服務(wù)的搭建，不必過多關(guān)注頻繁的UI層變動。而BFF開發(fā)人員則可以與前端開發(fā)人員更緊密的合作（甚至前端同時兼任BFF開發(fā)工作），提供更符合前端場景需求的接口及數(shù)據(jù)結(jié)構(gòu)。BFF不是一項突破性的生產(chǎn)力變革，更多是一種生產(chǎn)關(guān)系變革，通過前后端協(xié)作模式的調(diào)整來適應(yīng)互聯(lián)網(wǎng)領(lǐng)域的敏捷開發(fā)節(jié)奏。

傳統(tǒng)的API層包含了視圖邏輯和業(yè)務(wù)邏輯，統(tǒng)一由后端開發(fā)進行維護。BFF層承擔(dān)其中視圖邏輯的職責(zé)，而業(yè)務(wù)邏輯則“下沉”到領(lǐng)域微服務(wù)層進行維護。

在現(xiàn)代微服務(wù)架構(gòu)模式下，BFF作為一類后端服務(wù)也被部署在微服務(wù)架構(gòu)中。它作為整個架構(gòu)中前/后端應(yīng)用的中間層，也需要考慮其內(nèi)部各個BFF應(yīng)用的職責(zé)分工問題。通常，可以按照‘領(lǐng)域驅(qū)動設(shè)計’來進行微服務(wù)職責(zé)的劃分：把特定領(lǐng)域范圍內(nèi)的功能劃分到一個微服務(wù)上做到聚合，把彼此關(guān)聯(lián)性較小的功能劃分到不同的服務(wù)上滿足解耦。在攜程酒店業(yè)務(wù)BFF架構(gòu)實踐過程中，針對BFF微服務(wù)職責(zé)的劃分問題，出現(xiàn)過2種模式：“一碼一端”和“一碼多端”。

1.1 一碼一端

這個模式針對特定客戶端提供一個單體BFF應(yīng)用，該應(yīng)用提供整個酒店預(yù)定主流程的全部服務(wù)能力。為各端提供了充分的控制端差異的能力，獨立開發(fā)獨立部署。在Ctrip小程序端的BFF上有過使用，特點是能夠快速部署，獨立迭代，適合小團隊運維和快速上線。

但缺點是出現(xiàn)了單體巨型應(yīng)用，在一個服務(wù)內(nèi)承載了列表/詳情/填寫全流程的前端服務(wù)能力，整個應(yīng)用架構(gòu)顯的臃腫。并且針對同一個產(chǎn)品需求，各端的BFF應(yīng)用內(nèi)部需要各自實現(xiàn)相似的視圖控制邏輯，在實現(xiàn)業(yè)務(wù)需求的時候存在重復(fù)開發(fā)的弊端，不利于提高人效。

1.2 一碼多端

這個模式將預(yù)定主流程劃分為若干關(guān)鍵階段，分別由不同的BFF提供服務(wù)，且一個BFF俱備服務(wù)多端的能力并在內(nèi)部處理不同端的差異性，避免了重復(fù)開發(fā)，從而提升研發(fā)側(cè)整體的生產(chǎn)效率。且由于按頁面流程維度進行了微服務(wù)劃分，架構(gòu)上更為清晰，迭代也更加靈活。

從兩種模式的實踐結(jié)果來看，“一碼多端”的模式更符合微服務(wù)職責(zé)劃分的原則，也更有利于提高研發(fā)人效。因此，當(dāng)前酒店的BFF層的實踐方向主要采用了“一碼多端”的模式。曾經(jīng)采用“一碼一端”模式的BFF應(yīng)用也將向“一碼多端”模式重構(gòu)遷移。

二、基于NestJS的多端架構(gòu)

前述已經(jīng)談到了BFF的概念以及酒店業(yè)務(wù)BFF的微服務(wù)劃分方式，接下來談具體實現(xiàn)層面的問題。

首先，我們選擇了NestJS作為酒店BFF基礎(chǔ)框架進行二次開發(fā)。NestJS是一個用于構(gòu)建高效、可擴展的 NodeJs服務(wù)器端應(yīng)用的框架。它使用漸進式 JavaScript，構(gòu)建并完全支持 TypeScript。并結(jié)合了 OOP（面向?qū)ο缶幊蹋?、FP（函數(shù)式編程）的特點。相比其他框架，有如下一些優(yōu)勢：

1）強大的模塊化和可擴展性：使用模塊化的結(jié)構(gòu)來組織代碼，這使得代碼更易于組織和維護。此外，NestJS還提供了一種插件系統(tǒng)，允許開發(fā)者擴展框架的功能。

2）內(nèi)置的依賴注入容器：內(nèi)置了一個強大的依賴注入（DI）容器，使得服務(wù)和控制器之間的解耦變得簡單，同時也提高了代碼的可測試性。

3）TypeScript的支持：基于TypeScript編寫的，這意味著可以利用TypeScript的靜態(tài)類型檢查和最新的ECMAScript特性。也可以使用純JavaScript。

4）裝飾器和元數(shù)據(jù)反射：大量使用了裝飾器，這使得代碼更易于理解和維護。同時，通過元數(shù)據(jù)反射，NestJS可以自動處理很多常見的模式，如路由、依賴注入等。

5）支持微服務(wù)：提供了一套完整的微服務(wù)解決方案，包括消息模式、傳輸策略等。

6）測試工具：提供了一套強大的測試工具，使得單元測試和端到端測試變得簡單。

7）與其他庫的集成：可以輕松地與其他流行的JavaScript庫和工具集成，如TypeORM、Passport.js、GraphQL等。

在Nest框架提供的IOC能力基礎(chǔ)上，酒店BFF研發(fā)組構(gòu)建了專用于支持”一碼多端“研發(fā)場景的BFF服務(wù)框架，試圖通過統(tǒng)一的狀態(tài)數(shù)據(jù)管理及策略流程模式支持多端適配能力的開發(fā)：

1）提供了標(biāo)準(zhǔn)的開發(fā)模板，令多端處理邏輯的開發(fā)過程趨向標(biāo)準(zhǔn)化。

2）幫助開發(fā)者在編寫接口時通過流程的橫向拆分和數(shù)據(jù)組件的模塊化提高代碼可維護性。

3）通過框架模板的約束，促使開發(fā)者在系統(tǒng)設(shè)計之初就考慮如何處理一致性與差異性。

具體來說，BFF層作為前后端中間層主要的作用是調(diào)用下游微服務(wù)接口并進行請求參數(shù)的處理并最終組裝出視圖模型數(shù)據(jù)返回給前端，典型的模式是：

當(dāng)前端請求到達BFF之后，BFF會解析參數(shù)并做出數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換來向下游微服務(wù)發(fā)起請求，獲得返回后再重復(fù)這一過程。

面對這樣的調(diào)用鏈路，非常容易寫成面向過程的邏輯代碼。通過一個個工具函數(shù)不停對入?yún)?出參進行處理并傳遞給后一個下游服務(wù)接口。

整個程序控制流通過工具函數(shù)及函數(shù)傳參被耦合在一起，這種模式在”一碼一端“下由單一團隊維護尚能接受，同一批開發(fā)人員確保自己端的BFF鏈路不出錯即可。

但當(dāng)多個端團隊共同維護"一碼多端"BFF應(yīng)用時，針對同一個BFF接口服務(wù)的不同特性被耦合在一起，將導(dǎo)致團隊協(xié)作的困境：

1）下游傳參不一致：

由于下游領(lǐng)域服務(wù)針對各端可能存在特殊邏輯配置，因此給下游的傳參因端而異。

這一點通過IF/ELSE/SWITCH在BFF層面控制差異尚且能夠接受，但多個端的BFF開發(fā)人員需要共同修改同一段分枝邏輯。

2）調(diào)用鏈路不一致：

各端會存在調(diào)用時序差異，例如端A某接口強依賴獲取用戶等級，而端B某接口僅依賴用戶是否登陸，端C同時依賴用戶登錄態(tài)和用戶等級。

這種程序控制流程的差異相比與參數(shù)的差異更難以處理，可能需要更大更復(fù)雜的代碼塊分枝處理來解決，并更容易引起沖突提高協(xié)作成本。

3）視圖模型不一致：

由于各個端的BFF在不同的時間由不同的團隊開發(fā)維護，各個版本BFF的接口契約難免存在差異，當(dāng)“一碼一端”合并為“一碼多端”時，為了視圖模型的一致性，必須將（1）（2）中的不一致在BFF層處理為一致的視圖模型。

良好的代碼組織結(jié)構(gòu)和清晰的調(diào)用鏈路帶來可讀性和可維護性，降低遷移重構(gòu)過程中的摩擦成本。

為了降低“一碼多端”遷移過程中的協(xié)作成本，降低各端分支邏輯之間的耦合性，我們嘗試提出一種BFF的多端開發(fā)模式：

通過多端策略模式將不同端的處理邏輯在接口內(nèi)進行分流，并將一個接口邏輯內(nèi)原本對下游的整體鏈路橫向拆分為互不耦合的獨立邏輯處理實例，讓每一個實例僅需關(guān)注自身與下游服務(wù)的調(diào)用關(guān)系。且針對不同端的差異處理可以被文件級的分開，很大程度減少了沖突的發(fā)生。基于這個架構(gòu)，多個端側(cè)團隊可以高效安全的進行協(xié)同開發(fā)。

多個調(diào)用下游的邏輯實例可以被并行執(zhí)行，多個并行階段可以被串行，數(shù)據(jù)流最終到達裝飾器實例被處理后返回給前端。

在攜程酒店某二級頁面BFF一碼多端項目中，采用前文提到的多端架構(gòu)模式對原本多套BFF應(yīng)用進行了合并及重構(gòu)，將原本分散的視圖控制邏輯整合收口到了一個BFF應(yīng)用內(nèi)，大幅減少了后續(xù)的迭代維護成本，提升了研發(fā)效率。原本由多個BFF分別來支持多個端，通過多端開發(fā)模式重構(gòu)之后，多個BFF合并成為一個，內(nèi)部通過多端策略實例來支持各端。原本的過程化代碼被橫向解耦并拆分成可復(fù)用的數(shù)據(jù)組件被這多個策略分別組合調(diào)用，最后再通過視圖模型變化映射成統(tǒng)一的視圖模型返回給各端。

在應(yīng)用代碼重構(gòu)的同時，攜程酒店BFF團隊與攜程公共平臺團隊合作，在他們的支持與幫助下實現(xiàn)了BFF的云函數(shù)化。

三、云函數(shù)平臺

攜程Node.js云函數(shù)平臺從2021年正式立項已開始第四個年頭。俱備輕量化的運行時，中間件能力及其他豐富的函數(shù)中間件接入能力。

輕量化運行時

云函數(shù)的輕量化主要體現(xiàn)在基礎(chǔ)鏡像、業(yè)務(wù)代碼、發(fā)布運維三個方面：

• 云函數(shù)的基礎(chǔ)鏡像相比傳統(tǒng)應(yīng)用更加輕量化，在最新迭代的函數(shù)鏡像中僅包含微型系統(tǒng)、js運行時、函數(shù)運行時。相比此前的最小化鏡像大小減少59%，這有利于函數(shù)平臺更快速的拉起函數(shù)鏡像和實例。
• 云函數(shù)的代碼結(jié)構(gòu)相比傳統(tǒng)應(yīng)用更為簡化，只需在定義json中定義函數(shù)入口。函數(shù)內(nèi)置的運行時將啟動一個監(jiān)聽服務(wù)器，將必要的請求負載交由函數(shù)入口文件運行，并將處理后的函數(shù)返回以響應(yīng)負載的形式返回給客戶端。
• 函數(shù)開發(fā)平臺提供開箱即用的基礎(chǔ)設(shè)施建設(shè)、管理與運維，幫助用戶脫離繁冗的開發(fā)配置工作，只需關(guān)注業(yè)務(wù)代碼邏輯的編寫即可快速上線業(yè)務(wù)服務(wù)。

中間件能力

云函數(shù)運行時集成了 Tripcore 核心中間件集，并為云函數(shù)自動啟用部分基礎(chǔ)能力，由云函數(shù)接管核心中間件的升級和維護，具有以下優(yōu)勢：

• 自動接入基礎(chǔ)能力，無需復(fù)雜接入和配置
• 精選常用組件SDK，無需安裝，開箱即用
• 運行時內(nèi)置，減少項目安裝和構(gòu)建時間
• 定期跟進維護組件升級，保障核心功能穩(wěn)定性

函數(shù)中間件

由于函數(shù)代碼結(jié)構(gòu)和傳統(tǒng)應(yīng)用有較大差異，為了提升傳統(tǒng)應(yīng)用遷移到云函數(shù)的效率，框架團隊設(shè)計了函數(shù)中間件機制，提供了將傳統(tǒng)的Web應(yīng)用快速接入到云函數(shù)的能力。

使用@ctrip/serverless-app模塊可以將常見的Express、Koa、Nest.js、Egg.js、NFES、Remix、GraphQL等Web框架的應(yīng)用使用云函數(shù)進行部署，而無需對應(yīng)用代碼進行大刀闊斧的改動。

3.1 函數(shù)能力

觸發(fā)器

云函數(shù)通過觸發(fā)器提供給外部服務(wù)進行調(diào)用。在部署函數(shù)時即可生成函數(shù)URL，用戶可以直接使用函數(shù)URL訪問云函數(shù)進行測試。此外云函數(shù)平臺還提供了定時觸發(fā)器、QMQ消息隊列觸發(fā)器、SLB觸發(fā)器、SOA觸發(fā)器滿足多種業(yè)務(wù)場景需求。

層管理

層提供了一種全新的管理依賴和靜態(tài)文件的方法。通過將不經(jīng)常變更的依賴庫打包成層，可以減少部署鏡像的大小，并加快代碼的部署速度。目前在云函數(shù)平臺上提供了AlmaLinux的常用運維工具層、Puppeteer和Playwright層、FFCreator層等，并提供相關(guān)能力的解決方案，幫助開發(fā)人員快速上線業(yè)務(wù)功能，而無需過分關(guān)注這些依賴庫在Linux上運行的各種問題。

彈性擴縮

云函數(shù)產(chǎn)品支持快速彈性伸縮能力，能幫助業(yè)務(wù)提升資源利用率，在業(yè)務(wù)流量高峰時，業(yè)務(wù)的計算能力、容量自動擴容，承載更多的用戶請求，而在業(yè)務(wù)流量下降時，所使用的資源也能同時收縮，避免資源浪費。

云函數(shù)平臺支持基于RPS和并發(fā)度指標(biāo)進行彈性擴縮，相比傳統(tǒng)應(yīng)用只能按照QPM指標(biāo)和CPU指標(biāo)進行分鐘級擴容，云函數(shù)平臺依靠底層流量監(jiān)測組件，對流量變化的響應(yīng)時間最快達到秒級，可以最大限度提升資源利用率。云函數(shù)平臺支持最小可以將實例縮容到零，在請求到達時，云函數(shù)平臺掛起請求，并實時拉起函數(shù)，待函數(shù)實例就緒后再將請求發(fā)送給函數(shù)實例進行處理。這對于一些不需要一直運行的函數(shù)或者對響應(yīng)時間不敏感的非業(yè)務(wù)核心應(yīng)用來說，可以最大化節(jié)省資源。

版本和流量切換

• 云函數(shù)使用藍綠部署幫助業(yè)務(wù)提升系統(tǒng)可用性。藍綠部署時，并不停止掉老版本，而是直接部署一套新版本，等新版本運行起來后，再將流量切換到新版本上。使用藍綠部署可以更平滑地進行流量切換。
• 云函數(shù)支持快速更改堡壘流量指向，便于開發(fā)測試人員在上線前進行堡壘驗證。在正式發(fā)布前，通過堡壘測試工具驗證和觀察預(yù)發(fā)布版本的各項業(yè)務(wù)與性能指標(biāo)。
• 云函數(shù)支持灰度發(fā)布，通過預(yù)先設(shè)置的灰度批次和流量比例，云函數(shù)可以實現(xiàn)無人值守的灰度發(fā)布，在監(jiān)控到發(fā)布產(chǎn)生異常告警時可自動執(zhí)行發(fā)布剎車并通知開發(fā)人員進行排查。
• 云函數(shù)支持多集群部署，通過部署在不同地域和機房實現(xiàn)容災(zāi)。在單個集群因演練、發(fā)布或其他原因?qū)е鹿收蠒r，可在函數(shù)平臺進入流量切換頁面更改流量指向。

微型實例

云函數(shù)平臺的實例規(guī)格最小可以到0.125C和128MB內(nèi)存，可以根據(jù)實際業(yè)務(wù)需求指定不同的實例規(guī)格。云函數(shù)鼓勵通過更精細化的資源管理和快速彈性能力相結(jié)合來提升資源利用率。

函數(shù)場景

云函數(shù)提供了豐富的函數(shù)場景和代碼模板，預(yù)先定義好的代碼和流水線模板可以使開發(fā)人員在創(chuàng)建函數(shù)后等待數(shù)分鐘即可在測試環(huán)境創(chuàng)建指定的場景函數(shù)。

目前提供的基礎(chǔ)場景有 SOA微服務(wù)、NFES Web應(yīng)用函數(shù)、QMQ消息隊列函數(shù)、定時函數(shù)等，此外還有酒店、度假、火車票等業(yè)務(wù)BU提供的定制化函數(shù)場景可供選擇。

在云平臺的函數(shù)場景能力支持下，前文提到的基于NestJS的多端BFF框架被標(biāo)準(zhǔn)化為云函數(shù)應(yīng)用模板提供給其他BU開發(fā)者使用。

BFF云函數(shù)模板框架采用了分層架構(gòu)風(fēng)格：

1）最底層為公司基建，包括SOA、Clog、NodeJS基礎(chǔ)設(shè)施、存儲模塊等

2）在公司基建之上，通過NestJS模塊化組織方式，封裝常用NPM PKG，PKG可拓展，方便業(yè)務(wù)定制；支持Template和腳手架等提效工具，實現(xiàn)開箱即用

3）最上層為業(yè)務(wù)模塊，使用公共模塊開發(fā)各BU具體API，實現(xiàn)各自業(yè)務(wù)邏輯；其中多端模塊可支持各端共用一套功能接口

使用方在實現(xiàn)業(yè)務(wù)邏輯的時候可以做到開箱即用，無需重復(fù)造輪子對接公共基礎(chǔ)設(shè)施。

前文提到的某二級頁面BFF上云之后在性能方面獲得了一定的提升，云函數(shù)的基礎(chǔ)能力有效提高了BFF應(yīng)用的資源利用率。

在相同QPS的運行條件下，云函數(shù)應(yīng)用的響應(yīng)時間，內(nèi)存占用，冷啟動時間都分別得到了不同程度的優(yōu)化。

3.2 研發(fā)流程和函數(shù)生態(tài)

迭代管理

云函數(shù)迭代管理是具有探索性的一種研發(fā)流程一體化的實現(xiàn)方式，旨在為研發(fā)人員提供更便捷和靈活的研發(fā)流程體驗。

• 研發(fā)流程可視化

將開發(fā)流程所涉及的各個節(jié)點，以流水線的方式展示給用戶，使用戶能夠清楚地知曉整個開發(fā)流程所需要經(jīng)歷的節(jié)點。

• 詳細的開發(fā)引導(dǎo)

在開發(fā)過程中，用戶可以清晰地知曉當(dāng)前進度。在開發(fā)過程的不同階段，系統(tǒng)都會提供詳細的指導(dǎo)，在遇到發(fā)布卡點時可以明確告知用戶接下來應(yīng)該做什么，用戶只需按照指引一步一步操作，即可完成整個開發(fā)流程。

• 更專一的開發(fā)體驗

創(chuàng)建 iDev 任務(wù)、創(chuàng)建分支、鏡像關(guān)聯(lián) iDev 需求、分支合并等操作由系統(tǒng)接管，用戶可以更加專注于研發(fā)工作本身。

運維監(jiān)控和故障診斷

云函數(shù)平臺提供的監(jiān)控面板包含系統(tǒng)指標(biāo)、Node.js運行時指標(biāo)等。開發(fā)人員可以實時觀測到各個函數(shù)實例的基本情況，也可以通過Web控制臺遠程登錄機器后進行調(diào)試。

云函數(shù)平臺集成Node.js Astro監(jiān)控面板，提供為Node.js增強的監(jiān)控數(shù)據(jù)和能力：

• 實時監(jiān)測到j(luò)s應(yīng)用的運行情況、點火報告
• 查詢應(yīng)用的node_modules依賴、Tripcore依賴、層依賴等
• 支持鏡像依賴和倉庫提交比對，快速定位因依賴和代碼變更引起的問題
• 支持實時的CPU性能分析和內(nèi)存快照，快速排查性能和內(nèi)存故障
• 支持在線斷點調(diào)試，使用開發(fā)人員熟悉的調(diào)試工具連接到函數(shù)實例
• 支持離線調(diào)試，將函數(shù)鏡像拉取到本地進行調(diào)試，定位發(fā)布環(huán)境的問題

Docker化本地開發(fā)

由于Node.js 函數(shù)內(nèi)置了運行時和中間件，在本地開發(fā)時只能通過單元測試的形式測試業(yè)務(wù)邏輯。

因此框架團隊提供了 Mars – Docker化本地開發(fā)工具，Mars利用Docker 容器能力在本地完全模擬了函數(shù)實例真實在CI流水線和測試環(huán)境的運行情況，

使用Mars可以幫助開發(fā)人員更好地在本地進行云函數(shù)的開發(fā)調(diào)試工作。

四、前端動態(tài)化能力

在上述的BFF單體應(yīng)用多端框架能力的基礎(chǔ)上，大前端團隊還在客戶端和BFF微服務(wù)群中間設(shè)計了動態(tài)業(yè)務(wù)網(wǎng)關(guān)。如果說多端框架在應(yīng)用內(nèi)進行賦能，提供了支持多端UI差異的能力，這種差異我們可以稱之為“接口內(nèi)邏輯差異”。那么動態(tài)網(wǎng)關(guān)層則提供了處理“接口間組合差異”的能力。

動態(tài)網(wǎng)關(guān)層支持：跨應(yīng)用接口組裝裁剪，白名單及灰度發(fā)布能力以及場景動態(tài)能力，支持針對不同參數(shù)維度組合場景來提供定制化的接口組裝服務(wù)，增強接口服務(wù)的靈活性和適配性。

“多端模式” + “動態(tài)網(wǎng)關(guān)”的組合架構(gòu)模式，分別在應(yīng)用內(nèi)，應(yīng)用間2個層級來處理多端的視圖控制邏輯差異，從架構(gòu)維度再一次對多端的差異處理進行了解耦。

在攜程酒店某一級頁面技改項目中，為了能實現(xiàn)“一碼多端”的技術(shù)驗證目標(biāo)，采用了”一碼多端“+“動態(tài)網(wǎng)關(guān)”的架構(gòu)方案。目前C&T Web側(cè)共用一套BFF功能接口，通過在動態(tài)層對接口進行模塊化組裝來支持差異化的頁面UI數(shù)據(jù)需求。

改造范圍涉及Ctrip H5、小程序、Trip Online、Trip H5(CSR/SSR)共5個終端，實現(xiàn)17個功能模塊接口的改造，多端功能模塊收口落地BFF層，實現(xiàn)多端一致和復(fù)用，提高研發(fā)能效。

各平臺流量在動態(tài)層入口處通過請求參數(shù)進行分流到不同的BFF編排邏輯中，動態(tài)層會根據(jù)編排配置訪問BFF接口。

五、One More Thing

前文已經(jīng)講到了在“一碼一端”到“一碼多端”的前端能效變革背景下的BFF整體解決方案：應(yīng)用內(nèi)多端+動態(tài)網(wǎng)關(guān)+云函數(shù)能力。

這套方案除了能夠用來支持將多個BFF合并為1個之外，還能夠提供更強大的UI動態(tài)化能力：

結(jié)合酒店前端團隊正在研發(fā)的跨端組件庫，能夠支持以極少的代碼量支持多種用戶場景，做到組件的跨場景復(fù)用，跨端復(fù)用。