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

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

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

目前已經接近上線，回過頭來與大家分享下期間的經驗和總結。

一、背景

1. 什么是中臺？

中臺這個概念在19年前后火遍互聯網，馬云參觀Suppercell后提出的“大中臺小前臺”戰略調整已經被傳為佳話。

那么到底什么是中臺？網絡上已經有各種角度的解讀，簡單地說就是：抽象和復用，類似軟件開發中“面向服務的體系架構”的概念。

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

1）數據中臺

數據中臺大多數情況都是作為BI產品的基礎，無論是面向外界的服務類產品還是服務于本身企業的內部工具，數據中臺存在的意義就是整合和規范數據，方便業務方基于標準和統一的數據規范進行二次開發。

2）技術中臺

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

開發同學的工作也可以簡單概括為：抽象出可復用的功能模塊（接口），方便各個業務端快速的自主化配置并按需調用。

3）業務中臺

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

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

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

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

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

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

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

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

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

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

1）服務邊界問題

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

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

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

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

除非我們認定為不需要接入大客，但事實上服務大客已經成為我們產品業務的首要目標。

2）服務效率問題

內部開發損耗：由于整個產品線都離不開房源管理和營銷，所以各個業務端口都會或多或少地用到房源搜索和展示。

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

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

外部服務支持：客戶一般會根據自己當地的情況提出一些增減搜索的需求。

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

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

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

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

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

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

所以中臺的建立是從內到外幫我們整個產品線提效；對開發而言，新的功能模塊想使用商品搜索也不必在從頭做起，只需要按照標準API調用即可；對客戶而言，整個交付速度大大提升，在各個業務端口的使用體驗也更加統一。

想清楚這兩點問題后，我們毫不猶豫的開始了中臺產品的構思。

二、中臺設計

中臺設計最復雜的一個關鍵點在于，它是承上啟下的一個中間環節，所以我們制定的規范對前端業務和后端數據存儲都有影響。

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

1. 整體架構設計

在開始構思新的架構前，我們需要重新梳理當前的系統架構，以史為鑒，明確當前的不足才能指導我們設計出更優的系統架構。

1）改造前的系統架構

改造前的系統是一個標準煙囪式的縱向架構（見下圖），所有與房源相關的功能都和MLS強關聯，這里也很好的解釋了，為什么當前的系統架構是無法兼容多MLS的。

以及由于沒有統一的房源搜索服務，導致各個業務端需要各自構建適合自己的搜索系統。

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

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

以及我們可以很快地發現，這個架構并沒有客戶層級的定制搜索字段。

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

2）如何改造？

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

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

所以在這個前提下，我們搜索的架構基本就已經確認了，剩下的就是確認上下游環節怎么配合我們的搜索中臺。

下游業務銜接：對于下游的業務端調用，中臺要做的就是同時提供通用和定制的能力。

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

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

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

同時業務端去拉取對應搜索條件時，中臺也會根據當前業務端請求的具體MLS編號，過濾掉無用搜索字段并回傳給業務端。

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

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

上游服務支撐：搜索服務是基于數據中心提供的字段搭建，想整合一套標準的搜索字段集。

我們有兩個選擇：

1. 數據庫字段不做統一規整，搜索字段支持映射對多個數據庫字段；
2. 數據庫字段統一規整，搜索字段只映射一個數據庫字段。

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

考慮到我們現有的數據中心是沒有做字段規整的，所以如果選擇方案2，意味著我們有大量的數據清洗工作。

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

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

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

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

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

方案1的好處是對數據底層沒有調整，所以對整體的業務影響較少；而方案2雖然做了重新解析，但是涉及到底層數據庫字段的變更，有一些未知的潛在風險。

那么收益呢？

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

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

那么用發展的眼光去看方案1和方案2，未來的收益就一目了然了；方案2的數據中心字段規整是未來房源推薦的大前提，統一的業務描述字段才能做數據分析和行為提取。

做業務架構設計時，對未來業務發展的兼容性，是一個非常重要的考量指標。

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

好了，現在你也應該大概知道我們新的架構是什么樣子了。

3）改造后的系統架構（中臺）

改造后的架構是一個標準的橫向架構（見下圖），各個業務層之間相互隔離。

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

1. 數據源的規整，我們建立了內部的房源數據字典；
2. 房源搜索功能的封裝，包括通用和定制搜索服務的能力。

數據源

整個架構的最底部是我們所有的外部數據源，包括我們一直反復提到的MLS和一些三方數據來補充和擴展現有房源數據。

需要注意的是，這個數據源一定是會隨著業務擴展不斷變更和擴展的。

數據中心

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

之前對于單個MLS，我們的解析方式其實就是不處理，完全按照當前MLS的數據規范移植到我們的數據中心，這樣的方式的確對于之前的業務更為方便和穩妥。

因為節省了二次處理數據的時間，也不用擔心客戶會質疑我們數據引用的準確性。

但是這次重構后，我們是優先建立了一套標準的房源描述字段集，然后把每個MLS的字段向我們內部的標準靠攏，同時按照自己的內部經驗和行業標準不斷維護和擴充這個標準房源描述字段集（見下圖）。

這樣處理的最大風險是會有客戶質疑我們處理數據的方式，這也是我們在業務層去MLS化不可避免的服務成本。

但是從結果導向看待這個問題，我們并不會影響任何業務上的流程，同時客戶的反饋也會促使我們不斷完善和優化現有的標準房源描述字段集。

同樣這樣處理的好處在前文提到過，會便于我們后續的產品演進，因為統一的描述維度和字段是數據分析的基礎。

應用層

倒數第三層是整個數據服務的應用層，也是這次重構的最核心內容。

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

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

定制搜索服務是面向每個租戶（產品客戶）的，有兩個原則：

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

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

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

業務層

對于最頂層的各個業務端口而言，這次重構主要是技術側的優化，將以前各自搭建的搜索服務（見下圖）統一整合到搜索服務中臺。

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

整體來看，新的中臺是一個典型的高內聚松耦合的系統架構，各個業務層級內部的功能高度聚合，層級之間的功能口徑統一，耦合較弱。

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

三、小結

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

本文由 @One 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議