作者簡介

攜程前端框架團隊，為攜程集團各業(yè)務(wù)線在PC、H5、小程序等各階段提供優(yōu)秀的Web解決方案。當(dāng)前主要專注方向包括：新一代研發(fā)模式探索，Rust構(gòu)建工具鏈路升級、Serverless應(yīng)用框架開發(fā)、在線文檔系統(tǒng)開發(fā)、低代碼平臺搭建、適老化與無障礙探索等。

一、項目背景

2022，攜程PC版首頁終于迎來了首次改版，完成了用戶體驗與技術(shù)棧的全面升級。

作為與用戶連接的重要入口，舊版PC首頁已經(jīng)陪伴攜程走過了22年，承擔(dān)著重要使命的同時，也遇到了很多問題：

維護/更新困難

祖?zhèn)鞔a黑盒邏輯過多，產(chǎn)品也難以推動新需求的上線，舊版首頁已經(jīng)不能滿足高速發(fā)展的業(yè)務(wù)需求。

技術(shù)棧陳舊且不統(tǒng)一

互聯(lián)網(wǎng)技術(shù)日新月異，舊版首頁的整體架構(gòu)設(shè)計和技術(shù)棧都相對落后，且大首頁中各個組件的研發(fā)涉及多事業(yè)部合作，存在技術(shù)選型差異的問題，增加了維護成本。

用戶體驗有待改善

舊版攜程首頁的設(shè)計風(fēng)格沿用至今，在視覺和交互層面上，都已經(jīng)難以滿足用戶不斷提升的互聯(lián)網(wǎng)體驗和審美需求。

綜合上述情況，為了給用戶提供更好的服務(wù)，攜程首頁的整體改造迫在眉睫。

二、需求分析

攜程首頁改造需要考慮的核心問題包括以下幾個方面：

技術(shù)選型

為了優(yōu)化首屏性能，提升用戶體驗，攜程新版首頁采用服務(wù)端渲染模式。在技術(shù)選型上，考慮到我們希望應(yīng)用層是輕量的，只做頁面HTML拼接和響應(yīng)兩件事情，最終決定基于Node.js構(gòu)建應(yīng)用載體，客戶端則統(tǒng)一使用公司主流的React技術(shù)棧。

跨團隊合作

首頁作為攜程的重要門戶，涉及多業(yè)務(wù)線的流量入口。如圖1所示，我們可以將整個頁面進行切割，按業(yè)務(wù)線劃分成多個組件模塊。

圖1 攜程首頁業(yè)務(wù)模塊切分圖

可以看到，整個頁面的研發(fā)是需要框架部門和各個事業(yè)部業(yè)務(wù)團隊緊密合作才能完成的，這就需要一整套完善的跨團隊合作模式。其中，我們希望業(yè)務(wù)團隊只需要關(guān)注業(yè)務(wù)邏輯的實現(xiàn)，完成組件模塊的開發(fā)?？蚣軋F隊則負責(zé)提供：

• 組件模塊服務(wù)端/客戶端構(gòu)建方案
• 組件模塊服務(wù)端渲染方案
• 應(yīng)用層面，實現(xiàn)頁面組裝及響應(yīng)
• 組件模塊開發(fā)環(huán)境

監(jiān)控及維護

上線后，我們需要時刻關(guān)注應(yīng)用狀態(tài)，及時響應(yīng)異常情況。因此，需要對應(yīng)用及組件進行埋點監(jiān)控。除此之外，由于需要跨團隊合作，對于業(yè)務(wù)組件，我們希望各個業(yè)務(wù)團隊不僅可以實現(xiàn)開發(fā)/構(gòu)建自由，彼此獨立互不影響，在監(jiān)控及版本管理上也能實現(xiàn)自控。因此，我們將各個業(yè)務(wù)組件包裝成Node.js應(yīng)用，開發(fā)人員可以直接在發(fā)布系統(tǒng)查看組件版本，完成發(fā)布/回退，也可以通過應(yīng)用ID在埋點管理平臺查看組件的相關(guān)埋點。

三、整體架構(gòu)設(shè)計

圖2 攜程首頁架構(gòu)設(shè)計圖

基于上述需求分析，攜程新版首頁的整體架構(gòu)設(shè)計如圖2所示，可以分為四個部分：

業(yè)務(wù)模塊開發(fā)

我們將攜程首頁拆分為多個業(yè)務(wù)模塊，由各業(yè)務(wù)團隊負責(zé)完成相應(yīng)組件的開發(fā)。與常規(guī)React組件開發(fā)不同的是，首先，開發(fā)人員需要在配置文件中設(shè)置好模塊相關(guān)配置，如組件唯一ID；其次，組件開發(fā)需遵循一些規(guī)則，如為防止出現(xiàn)樣式污染，我們強制使用CSS Modules；最后，我們支持服務(wù)端渲染組件，可以在服務(wù)端生命周期中拉取數(shù)據(jù)，然后在服務(wù)端/客戶端使用。為了更好的輔助業(yè)務(wù)團隊完成組件開發(fā)，框架團隊會提供腳手架幫助創(chuàng)建組件模版，搭建開發(fā)環(huán)境，模擬完整首頁場景。

業(yè)務(wù)模塊構(gòu)建

業(yè)務(wù)模塊開發(fā)完成后，就需要構(gòu)建/發(fā)布至生產(chǎn)環(huán)境。整個構(gòu)建過程會在Pipeline中完成，開發(fā)人員git push代碼后會自動觸發(fā)?；诓煌膃ntry及配置，我們會使用webpack分別完成客戶端及服務(wù)端代碼的生產(chǎn)態(tài)構(gòu)建，并將客戶端構(gòu)建產(chǎn)物（js+css）上傳至靜態(tài)資源管理系統(tǒng)。

之后，我們會將服務(wù)端構(gòu)建產(chǎn)物（js）連同組件及靜態(tài)資源版本相關(guān)信息包裝成一個Job應(yīng)用，該應(yīng)用中會有一個定時任務(wù)負責(zé)推送當(dāng)前版本信息，觸發(fā)組件完成服務(wù)端渲染，這里我們是使用定時器來實現(xiàn)定時任務(wù)的管理。最后，需要由開發(fā)人員在發(fā)布系統(tǒng)中將構(gòu)建好的應(yīng)用鏡像部署到生產(chǎn)環(huán)境，完成組件的發(fā)布。

業(yè)務(wù)模塊服務(wù)端渲染

業(yè)務(wù)模塊的服務(wù)端渲染主要包括兩部分：

• 在沙盒中完成服務(wù)端渲染
• 將組件相關(guān)信息及渲染生成的html存到Redis中

我們將相關(guān)功能實現(xiàn)封裝成云函數(shù)，作為服務(wù)提供出去。由于部分組件對服務(wù)端渲染具有數(shù)據(jù)更新的需求。因此，上文我們提到過，Job應(yīng)用中會有一個定時任務(wù)，負責(zé)觸發(fā)組件進行服務(wù)端渲染，這里也就是會觸發(fā)云函數(shù)的調(diào)用。

應(yīng)用頁面組裝

最后，我們就需要在應(yīng)用中將所有的業(yè)務(wù)模塊拼裝起來，定時從Redis中獲取組件相關(guān)信息，組裝成首頁html返回到客戶端。

四、整體架構(gòu)的核心功能實現(xiàn)

對應(yīng)上述首頁架構(gòu)設(shè)計，我們簡要介紹下部分核心功能的實現(xiàn)：

4.1 搭建組件開發(fā)環(huán)境，模擬首頁場景

我們會在開發(fā)階段提供腳手架輔助業(yè)務(wù)團隊開發(fā)組件，其中一項重要功能就是搭建組件開發(fā)環(huán)境。常規(guī)的webpack搭建React開發(fā)環(huán)境我們這里就不贅述了，為了實現(xiàn)開發(fā)環(huán)境的統(tǒng)一標(biāo)準(zhǔn)化，我們還做了以下事情：

• 將webpack，babel的相關(guān)配置封裝到cli中，有選擇的提供可配置項，規(guī)范化組件開發(fā)環(huán)境
• 對entry進行收口。這里需要注意的是，服務(wù)端和客戶端的entry是不同的，對于客戶端entry，需要獲取服務(wù)端傳過來的數(shù)據(jù)，并通過調(diào)用ReactDOM.render()完成渲染：

import React from 'react'
import ReactDOM from 'react-dom'
import Comp from 'COMP_PATH'
const render = async() => {
let data
// 獲取服務(wù)端傳遞到客戶端數(shù)據(jù)
const container = document.getElementById('__MFE___MODULE___DATA__')
if (container && container.textContent) {
    try {
        data = JSON.parse(container.textContent)
    } catch(e) {
        console.log(e)
    }
}

const root = document.getElementById('__MODULE__')

// 客戶端渲染組件
if (module.hot) {
    ReactDOM.render(<Comp serverData={data} />, root)
} else {
    ReactDOM.hydrate(<ErrorBoundary><Comp serverData={data} /></ErrorBoundary>, root)
}
}
render()

對于服務(wù)端entry，則需要調(diào)用服務(wù)端生命周期拉取數(shù)據(jù)，并調(diào)用renderToString()完成渲染：

import React from 'react'
import { renderToString } from 'react-dom/server'
import Comp from 'COMP_PATH'
const render = async() => {
let data
// 執(zhí)行服務(wù)端生命周期
if (Comp.getInitialProps) {
data = await Comp.getInitialProps(_ctx)
}
// 沙盒中傳入setMfeData方法，見下文中服務(wù)端渲染組件實現(xiàn)
setMfeData(data)

// 服務(wù)端渲染組件，返回html
return renderToString(<Comp serverData={data} />)
}
export default render()

搭建首頁場景。我們希望開發(fā)人員在組件開發(fā)時，就可以看到其嵌入在整個首頁中的效果，而不是只能看到自己的組件。因此，我們在服務(wù)端處理頁面請求時，通過以下方式搭建了首頁場景：

• 讀取首頁html文件（首次從線上拉?。?/li>
• 解析/處理首頁html，移除當(dāng)前組件相關(guān)的線上script/link標(biāo)簽，添加開發(fā)態(tài)構(gòu)建產(chǎn)物
• 在沙盒中服務(wù)端渲染組件，替換首頁html中的組件html

4.2 SSR-Service 服務(wù)端渲染組件

我們會在沙盒中運行服務(wù)端構(gòu)建生成的代碼（可結(jié)合上文中服務(wù)端entry看），完成組件渲染，得到服務(wù)端生命周期中返回的數(shù)據(jù)及組件html。

const vm = require('vm')
const render = async ({content, request}) => {
// content即為服務(wù)端構(gòu)建生成的代碼
const script = new vm.Script(content)
let moduleObj = {
    exports: {}
}
let mfeEnv = 'prod'
let mfeData

// 基于云函數(shù)中的request模擬req
const _req = {
    url: request.rawPath,
    query: request.queryStringParameters,
    headers: request.headers
}

let sandBox = {
    ...global,
    process,
    require,
    module: moduleObj,
    console,
    _ctx: {
        req: _req,
        env: mfeEnv,
    },
    setMfeData: (data) => {
        mfeData = data
    }
}

// 沙盒中運行，執(zhí)行服務(wù)端渲染
const ctx = vm.createContext(sandBox)
script.runInContext(ctx)
const comp = await sandBox.module.exports.default

return {
    comp, 
    mfeData
}
}

4.3 整體頁面組裝

在首頁應(yīng)用中，我們會定時從redis中獲取組件相關(guān)信息，拼裝首頁html，在有客戶端請求進入時，直接返回緩存中的最新html。

let indexCache = ''
const renderPage = async (content) => {
// 加載首頁html
const $ = cheerio.load(content)
// 更新組件
for (let module of modules) {
    try {
        // moduleData為從redis取到的數(shù)據(jù)
        let data = moduleData[module] || ''
        if (!data) {
            continue
        }

        data = typeof data == 'string' ? JSON.parse(data) : data
        const {comp, version, mfeData, style} = data
        
        // 更新組件相關(guān)的html，link，script標(biāo)簽
        parse(module, comp, $, version, mfeData, style)
    } catch(e) {
        console.log(e)
    }
}

// 生成html
const payload = $.html()
if (!payload) {
    throw Error('renderPage error - html is null')
}

// 更新緩存
indexCache = payload
}

五、公共組件的渲染原理及技術(shù)細節(jié)

前面說的是島嶼式架構(gòu)之首頁的整體架構(gòu)和獨立組件渲染的核心實現(xiàn)，其中有些獨立組件（左側(cè)菜單欄，頭部等）除了在大首頁中使用，還會在其他的頁面中使用，這里就稱為公共組件。

5.1 公共組件需求點和痛點分析

在開始開發(fā)公共組件前，需要整理一下目前各個事業(yè)部的接入需求、成本及痛點。所以總結(jié)了以下問題點：

各個事業(yè)部的站點技術(shù)架構(gòu)不同

由于各個事業(yè)部的站點技術(shù)架構(gòu)不同。有的事業(yè)部可能是服務(wù)端渲染，有的可能為客戶端渲染 。在服務(wù)端渲染中，技術(shù)棧又可能出現(xiàn) JAVA 和NODE 。而在客戶端渲染中，各個事業(yè)部技術(shù)棧也不統(tǒng)一，有React、JQuery或者Vue等等前端框架。這里的問題是各個事業(yè)部的技術(shù)棧的錯綜復(fù)雜，如果分開維護會帶來不同的版本及很高的維護成本。

所有頁面中的公共組件有變更時能否統(tǒng)一熱更新

當(dāng)公共組件的改動或有問題需要修復(fù)時，不能讓所有的頁面都去變更公共組件，而是應(yīng)該我們變更后，所有頁面上的公共組件會靜默生效，各個事業(yè)部無需關(guān)心公共組件的變更。

公共組件的樣式如何不對頁面造成巨大影響

由于各個業(yè)務(wù)方的樣式風(fēng)格不同并且還存在一些全局的公共樣式，如何才能保證每個接入方為下圖的頁面布局方式，其頁面組成的方式為陰影部分是事業(yè)部所維護的組件，其他是公共組件。

由于歷史原因，舊版的公共組件已經(jīng)使用了很多年了，新版頭尾和舊版的頭尾布局構(gòu)造不同，要如何設(shè)計，才能使其改動最小，而不是去做很大的改動去適配公共組件。新舊版大首頁頁面布局變化如下圖：

公共組件的渲染性能問題

在背景中提到的不同形態(tài)的公共組件（比如有些不需要左側(cè)菜單或者頭部樣式的不同），如何在客戶端能第一時間展示給用戶相應(yīng)組件形態(tài)并且支持搜索引擎優(yōu)化(SEO)。當(dāng)多個公共組件在頁面中如何能快速進行加載及渲染。

5.2 解決公共組件問題和痛點

問題一：各個事業(yè)部的站點技術(shù)架構(gòu)不同

前面提到了各個業(yè)務(wù)支線的技術(shù)棧不統(tǒng)一的問題，并且還存在服務(wù)端和客戶端渲染的情況，如果為了多個技術(shù)棧去維護多個公共組件維護成本極高，且沒有辦法做到一套代碼多端使用。這里就從服務(wù)端和客戶端渲染分析，提供的相應(yīng)解決的方案

CSR(客戶端渲染)

在CSR中，技術(shù)棧也不同。由于有React、Vue、jQuery，所以我們需要提供的應(yīng)該是一個原生JS的公共組件，這樣能保證維護成本。但是大首頁的首屏技術(shù)棧已經(jīng)為React，再去開發(fā)及維護一套原生JS組件顯得冗余。所以需要一個方案來支持多技術(shù)棧運行，并且能夠兼容我們大首頁首屏的技術(shù)棧。

最終的方案是使用Preact，它很輕量，重點是它可以幫助我們解決多技術(shù)棧運行并且能夠兼容React?？扇f一有頁面同樣在使用 Preact 和我們沖突怎么辦? 這里將Preact單獨打包出來common包并且重名了全局的變量。這樣即使頁面使用了Preact也不會和我們有沖突，在webpack的 externals 的選項中可以配置組件需要的包名。

{
    //...
    externals: {
        preact: 'xxxxxx'
    }
    // ...
}

SSR(服務(wù)端渲染)

在SSR中，在技術(shù)棧上選擇了Preact，Preact 它同樣支持 SSR，可以構(gòu)建一個服務(wù)端的JS來支持SSR。因此我們的問題就迎刃而解了，我們在組件構(gòu)建的時候多生成一份 Preact 的 SSR 的 JS，用沙盒執(zhí)行服務(wù)端渲染輸出HTML并存儲。我們調(diào)研了以前的老的公共組件，全部攜程的業(yè)務(wù)線存在的技術(shù)棧只有兩種：JAVA、NODE，這樣就提供兩個接入方式的外殼即可——兩套不同語言的SDK及接入方式，其內(nèi)部都是獲取統(tǒng)一的公共組件HTML字符串供頁面使用。

{
        // ...
        resolve: {
            extensions: ['.ts', '.tsx', '.js'],
            alias: isPreact ? {
                "react": "preact/compat",
                "react-dom": "preact/compat",     // Must be below test-utils
                "react/jsx-runtime": "preact/jsx-runtime"
            } : {},
        }
        // ...
}

?（React輕松轉(zhuǎn)換Preact）

問題二：所有頁面中的公共組件有變更時能否統(tǒng)一熱更新

當(dāng)公共組件更新或者修復(fù)緊急的某些問題，不應(yīng)該影響業(yè)務(wù)方頁面，應(yīng)該是自動進行更新，當(dāng)用戶訪問頁面時，看到就是最新的公共組件，因此我們沒有做類似npm包多版本的方式進行管理。

基于問題一的基礎(chǔ)上：

SSR(服務(wù)端渲染)的情況

SSR的服務(wù)端的HTML從哪里來？HTML怎么樣才能是最新的？

我們需要構(gòu)建出來一份服務(wù)端的JS在沙盒中輸出HTML，存儲在了 Redis 中，將多個公共組件統(tǒng)一構(gòu)建出了多個HTML，分別存放在 Redis 里。業(yè)務(wù)方接入JAVA、NODE的SDK其實要做的只有一件事：守護進程定時的去 Redis 里拿到最新的 HTML 結(jié)果。

CSR(客戶端渲染)的情況

CSR如何保持為最新公共組件的？

需要一臺機器同多語言技術(shù)棧SDK一樣，定時從 Redis 里讀取數(shù)據(jù)，對外暴露一個接口，供客戶端的JS調(diào)用。這樣，每次用戶訪問頁面的時候，客戶端JS會發(fā)起請求，保證用戶所看到的的內(nèi)容永遠是最新的。

問題三：樣式問題

目前新版的相比之前舊版的公共組件在樣式和交互上更加復(fù)雜。由于左側(cè)菜單的存在，使得布局構(gòu)造不同，而且各個事業(yè)部的頁面樣式可能五花八門，很難保證不會影響自身樣式和事件等問題。

比如：如果使用flex的布局，需要在最外層套用一個div，如果不套用的話則需要在body元素上添加flex樣式，但是不能保證其他的事業(yè)部的頁面的 body 是否有其他的樣式，甚至body 內(nèi)是否存在其他的div元素等。還有很多事業(yè)部的頁面的類似滾動等事件監(jiān)聽都是在body上進行監(jiān)聽的，所以如果外層套取div，這種形式會讓原來頁面的事件監(jiān)聽滾動非常麻煩，各個事業(yè)部原來監(jiān)聽body的事件，需要一一進行改動。

觀察老項目發(fā)現(xiàn)，之前的公共組件骨架有個最外層的div元素，并且有一個名為"container"的id，我們要做的就是將左側(cè)的菜單 fixed 在左側(cè)就好了.關(guān)于css的fixed的兼容性：

（樣式屬性兼容情況）

但是此時有個問題是，我們的左菜單是可以展開或收起的。所以在展開和收起的時候需要一個全局的通信機制，當(dāng)左側(cè)的組件變化時，在組件的內(nèi)部應(yīng)該觸發(fā)全局的通信鉤子，通知 id 為container 的div元素跟隨左菜單變化，達到 flex 布局的效果。

（左側(cè)菜單展開）

（左側(cè)菜單收起）

問題四：性能問題

基于問題 1/2/3 大概已經(jīng)擬定了技術(shù)的方向，并且已經(jīng)能在各個事業(yè)部行的通了，證明思路是沒有問題的，但是還有些個瑣碎的問題需要考慮：

因為是定時從服務(wù)端里進行拉取，那么第一次沒有拉取時或者在客戶端渲染的情況下請求server是需要時間的，這樣請求回來HTML再進行異步渲染，是否時間過長？

為了解決上面的問題，我們考慮了先準(zhǔn)備一個預(yù)渲染的HTML占位，類似骨架屏的意思，此時就可以先進行骨架屏的渲染，之后再異步拉取渲染，來解決異步渲染白屏等待時間的問題。

多個公共組件的客戶端 JS 資源是否能夠合并，將Preact公共包也一起合并打包。

為了解決這個問題，我們的那臺跑沙盒JOB機器就可以繼續(xù)做這件事情。因為每個組件構(gòu)建后有資源的版本，我們需要將版本存儲一份，一旦新的組件構(gòu)建后，拉取其他公共組件的資源版本，將多個JS組裝在一起。同時因為我們用了 Preact ，抽取了 Preact 為一個共同依賴，將它放在最前面，保證它的最先執(zhí)行。

六、公共組件的數(shù)據(jù)動態(tài)配置系統(tǒng)

介紹完攜程新版大首頁的公共組件的渲染原理及技術(shù)細節(jié)，接下來就是公共組件中的數(shù)據(jù)如何支持動態(tài)配置。

6.1 為什么需要組件數(shù)據(jù)動態(tài)配置系統(tǒng)

攜程PC版首頁進行改版的過程中，按業(yè)務(wù)線將整個頁面劃分成了多個組件模塊，每個組件模塊內(nèi)都有需要展示的業(yè)務(wù)數(shù)據(jù)。而頁面上線之后，隨著產(chǎn)品需求的變更，業(yè)務(wù)數(shù)據(jù)會被頻繁的更新，如果每次更新數(shù)據(jù)都發(fā)布一次模塊代碼的話，這個成本和風(fēng)險很大。

因此，將代碼和數(shù)據(jù)分開發(fā)布是很有必要的，當(dāng)組件數(shù)據(jù)有改動時無需發(fā)布組件，搭建一個專門用于發(fā)布大首頁數(shù)據(jù)配置的管理系統(tǒng)勢在必行。

6.2 組件數(shù)據(jù)動態(tài)配置系統(tǒng)的需求分析

攜程大首頁數(shù)據(jù)配置管理系統(tǒng)的核心功能是完成數(shù)據(jù)配置的發(fā)布，并保證發(fā)布的可靠性和安全性，為了實現(xiàn)這個目標(biāo)，此管理系統(tǒng)應(yīng)制定一套完整的數(shù)據(jù)檢驗規(guī)范和發(fā)布流程，其中主要功能包括：

• 規(guī)范數(shù)據(jù)配置上傳格式，本地配置數(shù)據(jù)與線上配置數(shù)據(jù)差異對比
• 制定不同組件模塊的數(shù)據(jù)校驗規(guī)則，并以此校驗數(shù)據(jù)合法性
• 數(shù)據(jù)配置發(fā)布前效果預(yù)覽，確保與線上其他組件模塊之間相互不影響
• 更新線上頁面

6.3 組件數(shù)據(jù)動態(tài)配置系統(tǒng)架構(gòu)設(shè)計

圖1 大首頁數(shù)據(jù)配置管理系統(tǒng)架構(gòu)設(shè)計

數(shù)據(jù)配置管理系統(tǒng)的架構(gòu)設(shè)計 （如圖1 所示），為了實現(xiàn)需求分析中的四塊主要功能，整個管理系統(tǒng)主要搭建了兩個應(yīng)用：

前端應(yīng)用：以可視化界面的形式提供本地上傳配置文件，預(yù)覽數(shù)據(jù)效果以及更新頁面等功能，同時完成了數(shù)據(jù)校驗和預(yù)覽檢測。

Node服務(wù)：主要負責(zé)數(shù)據(jù)配置的處理及發(fā)布，將前端應(yīng)用上傳的數(shù)據(jù)配置保存到QConfig系統(tǒng)中。

其中，前端應(yīng)用提供的預(yù)覽功能的架構(gòu)設(shè)計如下圖2 所示：

圖2 預(yù)覽功能架構(gòu)設(shè)計

預(yù)覽功能的實現(xiàn)主要依賴三部分 （如圖2所示）：

前端應(yīng)用：負責(zé)提供數(shù)據(jù)配置和展示頁面效果。

服務(wù)端渲染應(yīng)用：調(diào)用組件渲染函數(shù)，根據(jù)數(shù)據(jù)配置渲染出當(dāng)前組件HTML，并從Redis拉取其他組件的HTML，而后組裝成一個完整頁面的HTML吐給前端應(yīng)用。

Redis：存儲所有組件模塊的HTML。

6.4 數(shù)據(jù)配置管理系統(tǒng)的核心功能實現(xiàn)

前面部分介紹了數(shù)據(jù)配置管理系統(tǒng)的架構(gòu)設(shè)計，這里就架構(gòu)中核心功能部分的實現(xiàn)進行詳細介紹，主要包括：

• 數(shù)據(jù)配置規(guī)范及校驗
• 組件及頁面預(yù)覽

數(shù)據(jù)配置規(guī)范及數(shù)據(jù)校驗

本地上傳的數(shù)據(jù)配置最終要傳給組件渲染出來，而數(shù)據(jù)配置的上傳者不一定是組件的開發(fā)者，上傳者并不一定清楚組件所需數(shù)據(jù)的類型和結(jié)構(gòu)，那么如何保證上傳的數(shù)據(jù)與組件要求的數(shù)據(jù)結(jié)構(gòu)保持一致呢？

這就需要管理系統(tǒng)制定一套數(shù)據(jù)配置規(guī)范來約束上傳的數(shù)據(jù)，然而不同的組件，其數(shù)據(jù)結(jié)構(gòu)是不同的，那么每個組件都應(yīng)有一套自己的規(guī)范。管理系統(tǒng)提供了兩種制定數(shù)據(jù)規(guī)范的方式：

• 錄入組件的基本信息，其中包括詳細的數(shù)據(jù)結(jié)構(gòu)：數(shù)據(jù)名稱，數(shù)據(jù)類型，必傳或可選等。
• 組件使用TypeScript（推薦的組件開發(fā)語言）語言開發(fā)時，可以上傳.d.ts聲明文件，系統(tǒng)會根據(jù)此文件解析出具體的組件信息及數(shù)據(jù)結(jié)構(gòu)。

規(guī)范制定完成之后管理系統(tǒng)會將其存儲起來，每次有上傳者上傳某一組件的數(shù)據(jù)配置后（為方便上傳者修改數(shù)據(jù)，管理系統(tǒng)規(guī)定數(shù)據(jù)配置以JSON文件的形式提供），系統(tǒng)會根據(jù)組件的數(shù)據(jù)規(guī)范校驗上傳的數(shù)據(jù)配置，如果校驗通過則會展示上傳數(shù)據(jù)與線上數(shù)據(jù)的差別，上傳者可進行預(yù)覽操作；如果校驗未通過，則提示未通過原因及具體的不規(guī)范數(shù)據(jù)，上傳者不可進行后續(xù)的預(yù)覽操作，需重新上傳數(shù)據(jù)配置，直到校驗通過。

組件及頁面預(yù)覽

此部分功能的核心實現(xiàn)在SSR Service 服務(wù)端渲染組件中（上文中有詳細介紹，這里不贅述），主要分為以下幾個步驟完成：

• 應(yīng)用的組件渲染函數(shù)在接收到符合組件數(shù)據(jù)規(guī)范的配置數(shù)據(jù)后，將數(shù)據(jù)通過Props傳給組件，進而render出當(dāng)前組件的HTML。
• 從Redis中取出其他模塊的HTML 與當(dāng)前組件HTML拼接在一起，為了保證預(yù)覽的可靠性（減少其他模塊出錯時對當(dāng)前組件的影響），其他模塊均使用生產(chǎn)態(tài)的HTML進行拼接。為什么一定要將其他模塊的HTML拼接在一起預(yù)覽呢？為了測試配置數(shù)據(jù)發(fā)布之后對其他組件模塊的影響，若有影響則不能發(fā)布，從而保證線上頁面的安全性。

七、總結(jié)

本文通過攜程新版首頁項目系統(tǒng)的介紹了其整體架構(gòu)設(shè)計，組件開發(fā)，數(shù)據(jù)配置的整個流程及實現(xiàn)原理，是對島嶼式架構(gòu)的一次實踐。希望能對大家今后跨團隊組件式開發(fā)的項目有所收獲。