一、背景介紹

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

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

這種模式改變了原來的生產關系，令后端開發人員可以更專注于特定領域模型及服務的搭建，不必過多關注頻繁的UI層變動。而BFF開發人員則可以與前端開發人員更緊密的合作（甚至前端同時兼任BFF開發工作），提供更符合前端場景需求的接口及數據結構。BFF不是一項突破性的生產力變革，更多是一種生產關系變革，通過前后端協作模式的調整來適應互聯網領域的敏捷開發節奏。

傳統的API層包含了視圖邏輯和業務邏輯，統一由后端開發進行維護。BFF層承擔其中視圖邏輯的職責，而業務邏輯則“下沉”到領域微服務層進行維護。

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

1.1 一碼一端

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

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

1.2 一碼多端

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

從兩種模式的實踐結果來看，“一碼多端”的模式更符合微服務職責劃分的原則，也更有利于提高研發人效。因此，當前酒店的BFF層的實踐方向主要采用了“一碼多端”的模式。曾經采用“一碼一端”模式的BFF應用也將向“一碼多端”模式重構遷移。

二、基于NestJS的多端架構

前述已經談到了BFF的概念以及酒店業務BFF的微服務劃分方式，接下來談具體實現層面的問題。

首先，我們選擇了NestJS作為酒店BFF基礎框架進行二次開發。NestJS是一個用于構建高效、可擴展的 NodeJs服務器端應用的框架。它使用漸進式 JavaScript，構建并完全支持 TypeScript。并結合了 OOP（面向對象編程）、FP（函數式編程）的特點。相比其他框架，有如下一些優勢：

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

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

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

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

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

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

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

在Nest框架提供的IOC能力基礎上，酒店BFF研發組構建了專用于支持”一碼多端“研發場景的BFF服務框架，試圖通過統一的狀態數據管理及策略流程模式支持多端適配能力的開發：

1）提供了標準的開發模板，令多端處理邏輯的開發過程趨向標準化。

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

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

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

當前端請求到達BFF之后，BFF會解析參數并做出數據結構轉換來向下游微服務發起請求，獲得返回后再重復這一過程。

面對這樣的調用鏈路，非常容易寫成面向過程的邏輯代碼。通過一個個工具函數不停對入參/出參進行處理并傳遞給后一個下游服務接口。

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

但當多個端團隊共同維護"一碼多端"BFF應用時，針對同一個BFF接口服務的不同特性被耦合在一起，將導致團隊協作的困境：

1）下游傳參不一致：

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

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

2）調用鏈路不一致：

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

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

3）視圖模型不一致：

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

良好的代碼組織結構和清晰的調用鏈路帶來可讀性和可維護性，降低遷移重構過程中的摩擦成本。

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

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

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

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

在應用代碼重構的同時，攜程酒店BFF團隊與攜程公共平臺團隊合作，在他們的支持與幫助下實現了BFF的云函數化。

三、云函數平臺

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

輕量化運行時

云函數的輕量化主要體現在基礎鏡像、業務代碼、發布運維三個方面：

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

中間件能力

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

• 自動接入基礎能力，無需復雜接入和配置
• 精選常用組件SDK，無需安裝，開箱即用
• 運行時內置，減少項目安裝和構建時間
• 定期跟進維護組件升級，保障核心功能穩定性

函數中間件

由于函數代碼結構和傳統應用有較大差異，為了提升傳統應用遷移到云函數的效率，框架團隊設計了函數中間件機制，提供了將傳統的Web應用快速接入到云函數的能力。

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

3.1 函數能力

觸發器

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

層管理

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

彈性擴縮

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

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

版本和流量切換

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

微型實例

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

函數場景

云函數提供了豐富的函數場景和代碼模板，預先定義好的代碼和流水線模板可以使開發人員在創建函數后等待數分鐘即可在測試環境創建指定的場景函數。

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

在云平臺的函數場景能力支持下，前文提到的基于NestJS的多端BFF框架被標準化為云函數應用模板提供給其他BU開發者使用。

BFF云函數模板框架采用了分層架構風格：

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

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

3）最上層為業務模塊，使用公共模塊開發各BU具體API，實現各自業務邏輯；其中多端模塊可支持各端共用一套功能接口

使用方在實現業務邏輯的時候可以做到開箱即用，無需重復造輪子對接公共基礎設施。

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

在相同QPS的運行條件下，云函數應用的響應時間，內存占用，冷啟動時間都分別得到了不同程度的優化。

3.2 研發流程和函數生態

迭代管理

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

• 研發流程可視化

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

• 詳細的開發引導

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

• 更專一的開發體驗

創建 iDev 任務、創建分支、鏡像關聯 iDev 需求、分支合并等操作由系統接管，用戶可以更加專注于研發工作本身。

運維監控和故障診斷

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

云函數平臺集成Node.js Astro監控面板，提供為Node.js增強的監控數據和能力：

• 實時監測到js應用的運行情況、點火報告
• 查詢應用的node_modules依賴、Tripcore依賴、層依賴等
• 支持鏡像依賴和倉庫提交比對，快速定位因依賴和代碼變更引起的問題
• 支持實時的CPU性能分析和內存快照，快速排查性能和內存故障
• 支持在線斷點調試，使用開發人員熟悉的調試工具連接到函數實例
• 支持離線調試，將函數鏡像拉取到本地進行調試，定位發布環境的問題

Docker化本地開發

由于Node.js 函數內置了運行時和中間件，在本地開發時只能通過單元測試的形式測試業務邏輯。

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

使用Mars可以幫助開發人員更好地在本地進行云函數的開發調試工作。

四、前端動態化能力

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

動態網關層支持：跨應用接口組裝裁剪，白名單及灰度發布能力以及場景動態能力，支持針對不同參數維度組合場景來提供定制化的接口組裝服務，增強接口服務的靈活性和適配性。

“多端模式” + “動態網關”的組合架構模式，分別在應用內，應用間2個層級來處理多端的視圖控制邏輯差異，從架構維度再一次對多端的差異處理進行了解耦。

在攜程酒店某一級頁面技改項目中，為了能實現“一碼多端”的技術驗證目標，采用了”一碼多端“+“動態網關”的架構方案。目前C&T Web側共用一套BFF功能接口，通過在動態層對接口進行模塊化組裝來支持差異化的頁面UI數據需求。

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

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

五、One More Thing

前文已經講到了在“一碼一端”到“一碼多端”的前端能效變革背景下的BFF整體解決方案：應用內多端+動態網關+云函數能力。

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

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