編輯導(dǎo)語：中臺簡單地說，就是抽象和復(fù)用，類似軟件開發(fā)中“面向服務(wù)的體系架構(gòu)”的概念，中臺也有不同的分類，根據(jù)企業(yè)不同的需要搭建不同的中臺體系；本文作者根據(jù)自己搭建房源搜索中臺的案列進行經(jīng)驗分享和總結(jié)，我們一起來看一下。

中臺只是一種形式，歸根到底是需要解決真實的業(yè)務(wù)問題；為了中臺概念而打亂現(xiàn)有的業(yè)務(wù)部署，強行拆前臺搭中臺往往是得不償失的。

從19年初我接手房源搜索業(yè)務(wù)開始，不斷在內(nèi)部討論和推演是否要建立一個全局搜索配置中心（也就是現(xiàn)在所說的中臺），一直到19年底才正式確認(rèn)要搭建一個獨立的中臺系統(tǒng)。

目前已經(jīng)接近上線，回過頭來與大家分享下期間的經(jīng)驗和總結(jié)。

一、背景

1. 什么是中臺？

中臺這個概念在19年前后火遍互聯(lián)網(wǎng)，馬云參觀Suppercell后提出的“大中臺小前臺”戰(zhàn)略調(diào)整已經(jīng)被傳為佳話。

那么到底什么是中臺？網(wǎng)絡(luò)上已經(jīng)有各種角度的解讀，簡單地說就是：抽象和復(fù)用，類似軟件開發(fā)中“面向服務(wù)的體系架構(gòu)”的概念。

下面根據(jù)前人的總結(jié)和我自己的理解，簡單描述下典型中臺的三種分類：

1）數(shù)據(jù)中臺

數(shù)據(jù)中臺大多數(shù)情況都是作為BI產(chǎn)品的基礎(chǔ)，無論是面向外界的服務(wù)類產(chǎn)品還是服務(wù)于本身企業(yè)的內(nèi)部工具，數(shù)據(jù)中臺存在的意義就是整合和規(guī)范數(shù)據(jù)，方便業(yè)務(wù)方基于標(biāo)準(zhǔn)和統(tǒng)一的數(shù)據(jù)規(guī)范進行二次開發(fā)。

2）技術(shù)中臺

顧名思義，這類中臺主要是服務(wù)于技術(shù)人員的；對于業(yè)務(wù)方來說，除了服務(wù)穩(wěn)定性和接入方式，對原本的業(yè)務(wù)流程是沒有任何影響的，理論上最前端的業(yè)務(wù)人員是沒有任何感知的。

開發(fā)同學(xué)的工作也可以簡單概括為：抽象出可復(fù)用的功能模塊（接口），方便各個業(yè)務(wù)端快速的自主化配置并按需調(diào)用。

3）業(yè)務(wù)中臺

這類中臺就是產(chǎn)品同學(xué)感知最強的中臺類型了，業(yè)務(wù)中臺的搭建需要產(chǎn)品同學(xué)深刻地理解不同業(yè)務(wù)線之間的共性及差異，從上至下地推動業(yè)務(wù)中臺的搭建。

用業(yè)務(wù)的語言去描述我們期望搭建的組織能力，比如支付能力，直播能力，用戶管理能力等等。

如果用造房子來類比三種中臺之間的差異：

• “數(shù)據(jù)中臺”是給你標(biāo)準(zhǔn)的磚塊，水泥，鋼筋，讓你自己動手去建筑；
• “技術(shù)中臺”是給你一塊塊復(fù)合板材，你要做的事情和搭積木一樣，把他們按照標(biāo)準(zhǔn)裝配到一起；
• “業(yè)務(wù)中臺”則是給你一個個標(biāo)準(zhǔn)戶型的房間，你只需要決定我要用到哪幾個房間就可以了。

當(dāng)然有的時候技術(shù)中臺和業(yè)務(wù)中臺之間并沒有那么涇渭分明的界線，比如我們后面將要描述的商品搜索中臺就是。

2. 為什么我們要搭建中臺？

項目背景：我們的xxx產(chǎn)品給北美房地產(chǎn)中介（Agent）提供一站式服務(wù)，包括建立個人網(wǎng)站&網(wǎng)站管理系統(tǒng)（CMS），付費銷售線索（Lead）投放，以及銷售線索管理后臺（CRM）。

功能背景：整個產(chǎn)品線因為扎根于房地產(chǎn)行業(yè)，所以房源搜索和展示是貫穿各個業(yè)務(wù)線的核心功能；我們后面所說的房源搜索中臺就是服務(wù)于各個業(yè)務(wù)線的房源搜索功能。

業(yè)務(wù)背景：由于北美房地產(chǎn)的特殊性，我們需要集成多達400個不同的外部房源數(shù)據(jù)源（MLS：Multiple Listing Service；美國每個州，甚至每個城市都會有自己的獨立MLS），同時這個數(shù)量還在隨著我們業(yè)務(wù)的發(fā)展不斷增長；其中最核心的矛盾點在于不同MLS的字段集合完全不同。

未搭建中臺前主要面臨以下幾個問題：

1）服務(wù)邊界問題

前期業(yè)務(wù)發(fā)展時，我們服務(wù)的大多數(shù)客戶只會接入一個MLS，所以我們的房源搜索邏輯是根據(jù)不同MLS 配置的，完全不考慮多個MLS之間的搜索兼容。

這樣的好處是我們不用做數(shù)據(jù)清洗和規(guī)整的工作，同時客戶看到的搜索條件也和他在自己MLS后臺錄入商品時看到的條件完全一致，沒有認(rèn)知成本。

但是隨著越來越多的大客戶涌入，我們面臨需要給一個客戶接入多個MLS的情況?，F(xiàn)有的架構(gòu)完全無法支持，強行配上多個MLS的搜索，會出現(xiàn)大量重復(fù)的搜索條件。

客戶也無法理解為什么可用的搜索條件始終只對一部分商品生效，所以中臺的建立是幫我們擴展了服務(wù)大客戶的能力。

除非我們認(rèn)定為不需要接入大客，但事實上服務(wù)大客已經(jīng)成為我們產(chǎn)品業(yè)務(wù)的首要目標(biāo)。

2）服務(wù)效率問題

內(nèi)部開發(fā)損耗：由于整個產(chǎn)品線都離不開房源管理和營銷，所以各個業(yè)務(wù)端口都會或多或少地用到房源搜索和展示。

那么在中臺上線之前，都是由各個業(yè)務(wù)端自己調(diào)用最底層的房源數(shù)據(jù)封裝各自獨立的業(yè)務(wù)搜索邏輯，那么弊端也異常明顯：

• 1）開發(fā)內(nèi)耗，房源搜索邏輯大部分是可復(fù)用的，即使有一些業(yè)務(wù)端口需要特殊的搜索邏輯，那么也基本在當(dāng)前的搜索框架內(nèi)；
• 2）搜索邏輯不統(tǒng)一，由于各個業(yè)務(wù)端口自己整理搭建搜索功能，或多或少會有一些邏輯上的差異，所以客戶在不同端口使用相同業(yè)務(wù)條件搜索時，發(fā)現(xiàn)自己看到的房源結(jié)果會有細微的差異，給客戶帶來困擾。

外部服務(wù)支持：客戶一般會根據(jù)自己當(dāng)?shù)氐那闆r提出一些增減搜索的需求。

但是我們在給客戶配置時，會獲取到當(dāng)前400個MLS的所有可用搜索條件，比如我們要給客戶添加一個“掛牌狀態(tài)”條件，最夸張的情況下我們會看到400個相同名稱的“掛牌狀態(tài)”，對運營同學(xué)的配置成本極高。

另外由于在接入多個MLS的過程中，我們總結(jié)了一些相對比較通用的搜索條件（比如beds，baths這列非常通用的搜索），并在代碼層面做了統(tǒng)一默認(rèn)配置。

可以理解為我們有了一些對全局通用的搜索條件，但實際落到各個業(yè)務(wù)層面，還是需要根據(jù)客戶的需求做一些微調(diào)。

現(xiàn)有的流程只能先隱藏通用搜索，再單獨配置MLS層級搜索；這樣的流程非常不便捷，也很容易出現(xiàn)MLS層級搜索和全局搜索重復(fù)的情況。

以及像在“服務(wù)邊界問題”提到對大客戶的支持，我們目前都是采用開發(fā)定制的方案，可用性極差。

比如我們之前給分別給客戶定制過MLS 1 + MLS 2和MLS 2 + MLS 3的搜索，那么對于需要使用MLS 1 + MLS 3的客戶，我們還是需要重頭定制一遍，非常低效和浪費開發(fā)資源。

所以中臺的建立是從內(nèi)到外幫我們整個產(chǎn)品線提效；對開發(fā)而言，新的功能模塊想使用商品搜索也不必在從頭做起，只需要按照標(biāo)準(zhǔn)API調(diào)用即可；對客戶而言，整個交付速度大大提升，在各個業(yè)務(wù)端口的使用體驗也更加統(tǒng)一。

想清楚這兩點問題后，我們毫不猶豫的開始了中臺產(chǎn)品的構(gòu)思。

二、中臺設(shè)計

中臺設(shè)計最復(fù)雜的一個關(guān)鍵點在于，它是承上啟下的一個中間環(huán)節(jié)，所以我們制定的規(guī)范對前端業(yè)務(wù)和后端數(shù)據(jù)存儲都有影響。

好在我們已經(jīng)明確了自己的項目使命，所以剩下的就是搭建一個合理且高度可擴展的系統(tǒng)架構(gòu)。

1. 整體架構(gòu)設(shè)計

在開始構(gòu)思新的架構(gòu)前，我們需要重新梳理當(dāng)前的系統(tǒng)架構(gòu)，以史為鑒，明確當(dāng)前的不足才能指導(dǎo)我們設(shè)計出更優(yōu)的系統(tǒng)架構(gòu)。

1）改造前的系統(tǒng)架構(gòu)

改造前的系統(tǒng)是一個標(biāo)準(zhǔn)煙囪式的縱向架構(gòu)（見下圖），所有與房源相關(guān)的功能都和MLS強關(guān)聯(lián)，這里也很好的解釋了，為什么當(dāng)前的系統(tǒng)架構(gòu)是無法兼容多MLS的。

以及由于沒有統(tǒng)一的房源搜索服務(wù)，導(dǎo)致各個業(yè)務(wù)端需要各自構(gòu)建適合自己的搜索系統(tǒng)。

對于搜索服務(wù)而言，舊架構(gòu)是使用部分全局搜索字段+MLS定制搜索字段來服務(wù)于每個客戶的。

需要注意的是，這里的全局搜索和MLS定制搜索是完全沒有層級關(guān)聯(lián)的，這里也再次解釋了前文提到重復(fù)配置相同搜索條件的情況。

以及我們可以很快地發(fā)現(xiàn)，這個架構(gòu)并沒有客戶層級的定制搜索字段。

我們始終在用MLS層級的定制搜索解決客戶層級的定制需求，所以我們累加的MLS層級搜索字段越多，運營同學(xué)的搜索配置的成本越高。

2）如何改造？

我們這次搭建的中臺核心思想有兩個：

• 房源搜索字段與MLS解耦，建立我們統(tǒng)一的搜索字段集；
• 支持客戶層級的搜索定制，理清定制和通用的邊界。

所以在這個前提下，我們搜索的架構(gòu)基本就已經(jīng)確認(rèn)了，剩下的就是確認(rèn)上下游環(huán)節(jié)怎么配合我們的搜索中臺。

下游業(yè)務(wù)銜接：對于下游的業(yè)務(wù)端調(diào)用，中臺要做的就是同時提供通用和定制的能力。

唯一需要注意的就是中臺提供的定制能力是基于通用能力的，不能越過中臺提供的通用搜索字段，重新創(chuàng)造一個新的定制搜索字段給業(yè)務(wù)端定制使用。

如果客戶的確要求新增一個我們之前不支持的搜索字段，那對于新的中臺服務(wù)流程而言，要先在中臺配置新的通用搜索字段給到業(yè)務(wù)端的，然后由業(yè)務(wù)端決定是直接使用還是調(diào)用定制能力進行二次修改。

這樣的服務(wù)流程實際上是清晰地定義了通用能力和定制能力的服務(wù)邊界，將整個房源搜索字段完全可控化，方便PM去維護并統(tǒng)一房源搜索字段集。

同時業(yè)務(wù)端去拉取對應(yīng)搜索條件時，中臺也會根據(jù)當(dāng)前業(yè)務(wù)端請求的具體MLS編號，過濾掉無用搜索字段并回傳給業(yè)務(wù)端。

舉個例子：某個搜索條件我們只配置了MLS 1，MLS 2和MLS 3的映射關(guān)系，如果業(yè)務(wù)端只使用了MLS 4，中臺是不會把這個搜索條件回傳給業(yè)務(wù)端去搜索房源的。

所以我們說的“解耦”并不是完全把搜索條件與MLS完全脫鉤，而是將以前搜索字段和MLS字段1對1的關(guān)系，調(diào)整為了1對多，弱化了通用搜索字段跟單個MLS耦合的程度。

上游服務(wù)支撐：搜索服務(wù)是基于數(shù)據(jù)中心提供的字段搭建，想整合一套標(biāo)準(zhǔn)的搜索字段集。

我們有兩個選擇：

1. 數(shù)據(jù)庫字段不做統(tǒng)一規(guī)整，搜索字段支持映射對多個數(shù)據(jù)庫字段；
2. 數(shù)據(jù)庫字段統(tǒng)一規(guī)整，搜索字段只映射一個數(shù)據(jù)庫字段。

其實無論選擇方案1還是方案2，都可以解決我們這次搜索中臺想解決的問題。

考慮到我們現(xiàn)有的數(shù)據(jù)中心是沒有做字段規(guī)整的，所以如果選擇方案2，意味著我們有大量的數(shù)據(jù)清洗工作。

但是回過頭來看，想要做搜索的統(tǒng)一化，必然涉及到數(shù)據(jù)清洗和規(guī)整，只是看我們把這個工作放在解析層做，還是搜索層做。

舉個例子：比如我們要規(guī)整Garage（停車位）這個搜索條件，MLS 1給的是整型的字段（1，2，3…），MLS 2給的是枚舉型字段（One, Two, Three…）。

如果是老的架構(gòu)，我們就配置成兩個不同類型的搜索條件了；但是對于我們的中臺而言，肯定只有一個出口，比較理想的情況下我們會封裝成一個輸入?yún)^(qū)間的搜索條件，支持客戶自己去輸入一個大小范圍。

那么問題來了，方案1意味著我們在解析MLS字段到數(shù)據(jù)庫時，就把MLS 2的值做統(tǒng)一轉(zhuǎn)換處理了；方案2意味著我們在配置搜索條件時，需要把MLS 2的是枚舉值一一映射到整型值上，也就是類似方案1在解析時的處理。

那么現(xiàn)在讓我們對比下方案1和方案2的ROI：其實兩邊的配置成本是一模一樣的。

方案1的好處是對數(shù)據(jù)底層沒有調(diào)整，所以對整體的業(yè)務(wù)影響較少；而方案2雖然做了重新解析，但是涉及到底層數(shù)據(jù)庫字段的變更，有一些未知的潛在風(fēng)險。

那么收益呢？

這個時候讓我們考慮一下項目的演進方向，好的房源搜索是什么？搜索的本質(zhì)是什么？

是信息和人的匹配。所以回答第一個問題，好的搜索其實是推薦，信息找人，而不是人找信息。

那么用發(fā)展的眼光去看方案1和方案2，未來的收益就一目了然了；方案2的數(shù)據(jù)中心字段規(guī)整是未來房源推薦的大前提，統(tǒng)一的業(yè)務(wù)描述字段才能做數(shù)據(jù)分析和行為提取。

做業(yè)務(wù)架構(gòu)設(shè)計時，對未來業(yè)務(wù)發(fā)展的兼容性，是一個非常重要的考量指標(biāo)。

所以經(jīng)過權(quán)衡，我們選擇了方案2來改造中臺的上游支持服務(wù)——數(shù)據(jù)中心（這次改造后，它也更像一個真正的數(shù)據(jù)中心）。

好了，現(xiàn)在你也應(yīng)該大概知道我們新的架構(gòu)是什么樣子了。

3）改造后的系統(tǒng)架構(gòu)（中臺）

改造后的架構(gòu)是一個標(biāo)準(zhǔn)的橫向架構(gòu)（見下圖），各個業(yè)務(wù)層之間相互隔離。

比較重大的改變主要有兩個：

1. 數(shù)據(jù)源的規(guī)整，我們建立了內(nèi)部的房源數(shù)據(jù)字典；
2. 房源搜索功能的封裝，包括通用和定制搜索服務(wù)的能力。

數(shù)據(jù)源

整個架構(gòu)的最底部是我們所有的外部數(shù)據(jù)源，包括我們一直反復(fù)提到的MLS和一些三方數(shù)據(jù)來補充和擴展現(xiàn)有房源數(shù)據(jù)。

需要注意的是，這個數(shù)據(jù)源一定是會隨著業(yè)務(wù)擴展不斷變更和擴展的。

數(shù)據(jù)中心

倒數(shù)第二層是數(shù)據(jù)中心，也是我們這次重點整改的重點之一，核心思想就是將之前根據(jù)不同MLS分散的房源字段規(guī)整為我們系統(tǒng)定義的一套規(guī)范字段集。

之前對于單個MLS，我們的解析方式其實就是不處理，完全按照當(dāng)前MLS的數(shù)據(jù)規(guī)范移植到我們的數(shù)據(jù)中心，這樣的方式的確對于之前的業(yè)務(wù)更為方便和穩(wěn)妥。

因為節(jié)省了二次處理數(shù)據(jù)的時間，也不用擔(dān)心客戶會質(zhì)疑我們數(shù)據(jù)引用的準(zhǔn)確性。

但是這次重構(gòu)后，我們是優(yōu)先建立了一套標(biāo)準(zhǔn)的房源描述字段集，然后把每個MLS的字段向我們內(nèi)部的標(biāo)準(zhǔn)靠攏，同時按照自己的內(nèi)部經(jīng)驗和行業(yè)標(biāo)準(zhǔn)不斷維護和擴充這個標(biāo)準(zhǔn)房源描述字段集（見下圖）。

這樣處理的最大風(fēng)險是會有客戶質(zhì)疑我們處理數(shù)據(jù)的方式，這也是我們在業(yè)務(wù)層去MLS化不可避免的服務(wù)成本。

但是從結(jié)果導(dǎo)向看待這個問題，我們并不會影響任何業(yè)務(wù)上的流程，同時客戶的反饋也會促使我們不斷完善和優(yōu)化現(xiàn)有的標(biāo)準(zhǔn)房源描述字段集。

同樣這樣處理的好處在前文提到過，會便于我們后續(xù)的產(chǎn)品演進，因為統(tǒng)一的描述維度和字段是數(shù)據(jù)分析的基礎(chǔ)。

應(yīng)用層

倒數(shù)第三層是整個數(shù)據(jù)服務(wù)的應(yīng)用層，也是這次重構(gòu)的最核心內(nèi)容。

因為在數(shù)據(jù)層已經(jīng)做了MLS隔離，所以我們可以分別構(gòu)建出獨立于單個MLS的房源搜索服務(wù)和房源信息服務(wù)，整體架構(gòu)也更加一目了然。

房源搜索服務(wù)的重點是明確通用和定制搜索的系統(tǒng)層級和服務(wù)邊界。通用搜索服務(wù)是面向全局的搜索條件，對于不同的業(yè)務(wù)端而言通用搜索字段集是完全一致的。

定制搜索服務(wù)是面向每個租戶（產(chǎn)品客戶）的，有兩個原則：

• 定制搜索字段只能基于通用搜索字段調(diào)整，不允許新增；
• 定制搜索服務(wù)由業(yè)務(wù)端封裝以后只對單個客戶生效，由客戶自定義的各種搜索條件對其他客戶沒有任何影響。

如下圖所示，其實每個租戶都會按照我們的標(biāo)準(zhǔn)搜索字段集去初始化一套屬于他自己的定制搜索字段集，然后在一定范圍內(nèi)允許客戶去修改通用搜索條件的映射關(guān)系。

有點類似于模板（通用搜索）和實例（定制搜索）的關(guān)系。

業(yè)務(wù)層

對于最頂層的各個業(yè)務(wù)端口而言，這次重構(gòu)主要是技術(shù)側(cè)的優(yōu)化，將以前各自搭建的搜索服務(wù)（見下圖）統(tǒng)一整合到搜索服務(wù)中臺。

這樣各個業(yè)務(wù)端口看到的搜索條件集完全一致，且邏輯統(tǒng)一；提高了系統(tǒng)的穩(wěn)定行和可擴展性，同時避免了各個業(yè)務(wù)端口搜索邏輯不統(tǒng)一的問題。

整體來看，新的中臺是一個典型的高內(nèi)聚松耦合的系統(tǒng)架構(gòu)，各個業(yè)務(wù)層級內(nèi)部的功能高度聚合，層級之間的功能口徑統(tǒng)一，耦合較弱。

能夠非常完美地解決我們目前面臨的各種問題，同時為未來的產(chǎn)品擴展（房源推薦）留下了足夠的想想空間。

三、小結(jié)

以上是我們在切入中臺時，如何做架構(gòu)設(shè)計的整體思路；后續(xù)會繼續(xù)給大家分享中臺在開發(fā)時遇到的各種問題，包括如何高效且平穩(wěn)地推進中臺開發(fā)落地，以及對存量數(shù)據(jù)遷移采取的種種策略等等。

本文由 @One 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議