作者簡介

佳璐，攜程研發(fā)總監(jiān)，專注大前端核心價值的構建和創(chuàng)新。

一、背景概要

參照Apple、Booking和AirBnB等一眾品牌在國際化的進程中始終保持品牌認知的一致性，Ctrip和Trip（以下簡稱為“C&T”）并駕齊驅的過程中，集團對于不同國度和不同客群的品牌效應有趨于統(tǒng)一的訴求。

研發(fā)的整體鏈路上同樣存在由于C&T相似需求導致的重復開發(fā)工作量，服務鏈路上并沒有完全做到抽象與統(tǒng)一，前端鏈路上存在復用率低以及缺失動態(tài)化能力的情況。

多終端存在功能不對齊的情況，造成用戶體驗不一致，結合C&T的場景進一步加劇了功能模塊復用率低以及研發(fā)資源利用率低的問題。

綜上三點，C&T一致與多端融合的問題等待技術給出答案。

二、調研分析

分析階段我們從品牌一致和多端一致兩個方面去探索技術可行性。

2.1 品牌一致

品牌一致性的源頭在于設計規(guī)范一致和功能實現(xiàn)一致。

設計規(guī)范一致：

• 對視覺元素進行細顆粒度的設計規(guī)范約束，形成一套或多套適應不同業(yè)務場景的設計規(guī)范。
• UED團隊與前端研發(fā)團隊通過設計規(guī)范與對應的工具庫，實現(xiàn)品牌語言的呈現(xiàn)與動態(tài)轉變能力。

功能實現(xiàn)一致：

• 統(tǒng)一用戶界面和交互流程，保證不同品牌的相同功能在用戶體驗方面達成一致。
• 對核心流程與常用功能進行功能一致性的設計，同時針對不同終端優(yōu)化交互體感。

在不解決品牌一致性的情況下，UED、產品和研發(fā)都需要付出雙倍或雙倍以上的工作量才能為兩個平臺的用戶提供服務。

2.2 多端一致

C&T和多終端在鏈路上幾乎都保持相對獨立的態(tài)勢。

目前多端不一致的現(xiàn)狀，從研發(fā)角度去分析體現(xiàn)在三個方面：

1）多終端隸屬于不同的研發(fā)團隊，研發(fā)資源的分配往往隨著訂單量的差異有所傾向。這種背景下會衍生出兩類問題：

• 多終端之間的需求迭代數量和頻率會出現(xiàn)“代差”，即功能的差異性和不一致，這種“代差”的絕對時間長度或在6個月以上。
• 不同終端的研發(fā)團隊的技術視野受限，降低了前端研發(fā)資源的可流通性。

2）各終端間的“代差”需要Controller層的服務做更多的兼容，隨著兼容代碼的增多，Controller按不同的終端訴求分裂成了一對一的架構形態(tài)，且公用的代碼部分也日益減少，進一步加劇了多端不一致的情況。

3）Controller層是由服務端開發(fā)負責，在多個Controller服務實例的場景下，由于“代差”的緣故，代碼的冗余（Controller層）與抽像邏輯的費力程度使得服務端的研發(fā)資源也成為了資源瓶頸。同時前后端代碼的分界線也缺少約束，加劇了多端整個鏈路的差異化和不一致性。

三、解決方案

3.1 品牌一致

3.1.1 設計規(guī)范一致

UED的設計風格分別屬于 TDS（Trip Design System）與 CDS（Ctrip Design System）兩個不同的設計體系，在諸多設計元素的運用上存在差異。

逐步實現(xiàn)品牌一致的大背景下，兩套存在差異的設計體系需要完成一些“相互認同”的妥協(xié)。

我們采用的方案：

1）通過設計團隊構建 Design System，由全體設計團隊在品牌主題和設計理念的指導下達成一致的共有設計原則集合體，如色彩的運用、字號的等級劃分等。達成一致的設計原則可以通過 Design Token 來定義相同元素在兩個不同設計風格中的狀態(tài)。

2）由于 Design System 中的 Design Token 是對元素級顆粒度的設計約束，同時功能頁面是通過無數個元素組合而成，故而 Design Token 可以通過配置化實現(xiàn)靈活性，也為UED與前端研發(fā)間建立了契約。

3）通過 Design System 構建出一套具有細顆粒度的設計規(guī)范約束，同時能夠適配當前Ctrip和Trip兩個品牌設計現(xiàn)狀，最后可以通過該套 Design System 低成本且靈活得支持品牌一致的最終目標。

3.1.2 功能實現(xiàn)一致

絕大部分的現(xiàn)狀中，不同的品牌面向的地區(qū)客群決定了視圖層面中設計語言的差異，而這些差異并不會導致業(yè)務功能實現(xiàn)上的區(qū)別，如“支付訂單”功能，在不同的地區(qū)客群中都有著明確且唯一的認知。

但從不同終端的角度上觀察，相同的功能實現(xiàn)在用戶的交互方面存在一些差異，如App與H5終端上對于明細信息的展現(xiàn)形式存在不同。

• App端會更傾向于使用蒙層或新開界面的展現(xiàn)形式，是因為可以通過左右滑動屏幕的手勢來關閉，給用戶一種單手交互的流暢感；
• 而H5端由于是通過手機瀏覽器App來承載，手機瀏覽器App作為容器，在左右滑動屏幕的手勢下會喚起瀏覽器回退網頁的操作，繼而影響交互目的。所以H5端會更多采用浮層的展現(xiàn)形式，通過點擊屏幕空白區(qū)域關閉的方式來減少用戶誤操作的情況。

基于上述分析，我們給出了建議方案：

1）服務側整理與抽象剝離功能模型與視圖模型，將Controller層中的業(yè)務功能邏輯下沉至Integrated Service層和Micro Service層，在技術底層實現(xiàn)功能實現(xiàn)的統(tǒng)一和收口。

2）視圖模型轉由BFF層來完成抽象與差異化定制，實現(xiàn)多終端的渲染共用一套BFF服務。

3）多終端的渲染通過前端業(yè)務組件庫承載，前端業(yè)務組件庫的作用是抹平各終端在交互操作上的差異，視圖模型作為銜接BFF服務與前端渲染的契約。

3.2 多端一致

分析了多端不一致的現(xiàn)狀后，倘若Controller服務層可以支持多終端復用，即在"功能實現(xiàn)一致"章節(jié)中提到的BFF層解決方案，則可以有效解決服務端研發(fā)資源瓶頸的問題。

同時，由于BFF層支持的是多終端，倘若拓展前端開發(fā)資源的能力至BFF層，既可以進一步釋放服務端研發(fā)資源壓力，還可以減少前后端研發(fā)資源的溝通成本。

隨著這種工作模式的推進，“代差”的問題終將被解決，研發(fā)資源的能效也會得到較大的提升。

3.2.1 BFF架構設計

在BFF模式中，不同的前端應用（如Web、移動端等）共享一套業(yè)務邏輯和視圖模型，支持獨立部署。這樣做的好處是，盡管不同的前端可能有不同的需求和特性，但它們可以利用同一個服務來處理視圖模型，同時還能根據各自平臺的特點進行必要的定制化處理。這種架構模式既保證了多端應用的一致性，又保留了靈活性和可擴展性。

架構設計方面需要從引擎、集成服務、BFF服務三層入手，分別代表：

• 引擎：負責底層數據的生產，不同的業(yè)務領域模型持有和加工層
• 集成服務：負責抹平C&T數據的差異性，不同業(yè)務領域模型的聚合層
• BFF服務：負責維護業(yè)務領域模型和視圖模型的關系，多終端與動態(tài)化能力的支持層

3.2.2 動態(tài)化能力

上圖的架構設計中可以發(fā)現(xiàn)在BFF層存在 Service Driven Layer，它的作用正是支持前端的動態(tài)化能力建設。我們從幾個方面來完整闡述實現(xiàn)的思路。

由于通過BFF層來統(tǒng)一處理視圖模型，但在不同的業(yè)務場景下，仍然會存在個性化的差異，這些差異通過Service Driven Layer與前端組件庫協(xié)同解決。

以實戰(zhàn)成果來舉例，酒店列表頁中的酒店卡片與酒店營銷頁中的酒店卡片在展現(xiàn)形式上存在將近70~80%的一致性，個性化部分將如何解決？

售賣主流程

營銷流程

在組件庫方面，我們將頁面拆解成模塊集的結構組合，將模塊拆解成組件集的結構組合，將組件結構拆解成元素集的結構組合，這樣的拆解鏈路可以提煉出多個維度的結構，這些結構（Structure）會幫助我們在編譯時與運行時，更加靈活且有規(guī)則的實現(xiàn)動態(tài)化能力。

樣式部分的處理運用了類似的思路產生（Style），再通過與UED團隊的Design System對接，實現(xiàn)從視覺設計到產品實現(xiàn)的全鏈路規(guī)范與動態(tài)化能力。

最后通過Service Driven Layer，BFF層除了下發(fā)模塊所需的視圖模型（ViewModel）數據之外，還會下發(fā)兩項可選的內容：

• 頁面與組件結構（Page/Component Structure）
• 動態(tài)樣式（Component Style）

通過這樣的組合，在不同的業(yè)務場景下，無論是靜態(tài)編碼還是動態(tài)下發(fā)，都可以遵循相同的理念去構建并渲染前端頁面，同時這些能力也將大幅提升研發(fā)資源的能效。

四、落地方式

我們逐步來解析落地過程：

1）圖中的左半部分為開發(fā)階段，前端部分的落地方式

• UED與前端通過Design System的Design Token作為契約進行交流
• 差異化需求的樣式兼容，需要通過Style Config來統(tǒng)一收口完成，其中一方面需要依賴Design Token，另一方面需要組件庫的建設和支持
• 相同的，差異化需求的結構組合，需要通過Structure Config統(tǒng)一收口完成

2） 圖中的右半部分為線上階段，服務部分的落地方式

• BFF Service完成多端一致的能力落地，將Intergrated 和 Micro Service中的業(yè)務模型轉換成視圖模型
• Style Config 與Structure Config 分別實現(xiàn)樣式與結構的動態(tài)化能力
• 通過Server Driven Layer聚合，通過終端代碼的運行時落

五、論證成果

從0到1落地BFF支撐C&T雙平臺、多終端和動態(tài)化，逐個項目論證技術可行性，搭建所需的技術支撐能力，同時清理歷史技術債，加快研發(fā)效能。

C&T Web 酒店詳情頁

目前C&T Web側酒店詳情頁均已支持該架構設計。共用一套BFF功能接口，實現(xiàn)模塊化功能接口。過程中完成了前端和服務端的雙端邏輯下沉工作，提升研發(fā)效率的同時拓展了前端職能。

改造范圍涉及Ctrip H5、小程序、Trip Online、Trip H5共5個終端，實現(xiàn)17個功能模塊接口的改造，多端功能模塊收口落地BFF層，實現(xiàn)多端一致和復用，提高研發(fā)能效。同時減少多個終端的前端Size 27~39%。

改造過程中實現(xiàn)了從業(yè)務領域模型轉換成抽象視圖模型，同時兼具了不同終端可能存在的個性化模塊和功能，從而驗證了該架構設計同時具備前端動態(tài)化能力。

C&T 多終端 酒店賣點頁

使用BFF服務結合攜程自研一碼多端框架xTaro，完成C&T共7個終端酒店賣點頁的落地工作。

該項目進一步論證了解決方案的可行性，大幅優(yōu)化了研發(fā)資源能效以及整體工作流，在多端一致的場景下，通過組件庫完成了一碼多端的能力落地。

結語

如此全鏈路的解決方案在落地過程中需要摸著石頭過河，大膽設想結合小心論證，時刻保持與相關團隊的溝通，為了一個共同的目標前行。

我們希望將這套方案中各環(huán)節(jié)的技術成果產品化，提供給更多具有相同需求的研發(fā)團隊，以此共勉。