Categories
程式開發

貝殼找房房源中台演進之路


引言

2019年底,由麥思博(msup)主辦的TOP100全球軟件案例研究峰會(TOP100Summit)在北京國際會議中心開幕,TOP100Summit是科技界一年一度的案例研究峰會,每年甄選有學習價值的100個技術創新/研發管理實踐,分享他們在本年度最值得總結、盤點的實踐啟示。

在“架構演進&工程實踐”專場,貝殼找房人店平台技術中心首次對外分享其中台建設的系統性技術方案,揭曉了房源系統如何從龐大單體應用逐漸向服務化、中台化演進的整個過程。作為行業領先的新居住服務平台,貝殼找房搭建出能力可複用的中台,推動業務迭代和數據應用,實現創新提效,並將充分對外賦能,為全行業的創新提效提供綜合解決方案。

貝殼找房房源中台演進之路 1

案例簡述

本案例將帶來貝殼找房支撐一線門店作業的B端房源系統如何從僅支持原鏈家直營的單體應用,逐步演進為支撐90多個城市,涵蓋二手、租賃、託管、商業地產等多種業務品類的房源中台系統。

其中面對複雜業務系統的服務化拆分,架構演進及如何以中台化為目標進行擴展點建設,都包含大量實踐案例,相信可以在業務系統治理,中台建設等方面給予大家一些啟發。

案例背景

2018年初,隨著貝殼找房的全面上線,原鏈家業務模式從單純自由直營模式向平台化、加盟化邁出重要一步。伴隨著加盟模式的開城擴張,鏈家在房產交易行業沉澱多年的經驗打法逐漸從一、二線城市向三、四線城市下沉。

在這個過程中,我們遇到了大量城市的特化需求,整個系統原有的業務規則甚至核心模型都受到了嚴重的衝擊。

貝殼找房產研團隊通過中台建設的方式,逐步完成了從被業務牽著鼻子走到能夠快速靈活主動的響應業務訴求的轉變。

案例執行

1 定位與目標

“中台”是近年互聯網行業討論非常火熱的話題,“中台”分成很多種:

貝殼找房房源中台演進之路 2

我們可以看到,有註重數據分析能力建設的數據中台,有專注於業務功能重用的業務中台,有提供基礎設施套餐化的技術中台,也有致力於策略算法服務化的算法中台,貝殼找房的“房源中台”的定位是“業務中台”。

“業務重用”是工程開發中非常樸素的訴求,貝殼找房的業務基本上都是圍繞房產交易展開的,其特點可以概括為“業務鏈路長,地域差異性明顯,後台支撐性服務眾多” ,基於以上的訴求和背景,我們的“房源業務中台”圍繞以下兩個切入點展開:

貝殼找房房源中台演進之路 3

一方面希望提升“房源”數據在整個冗長業務流中的流轉效率;另外一方面封裝後台、平台的若干複雜細節,屏蔽它們的複雜性,提升前台的接入效率。

2 領域架構分析

如果對於業務架構沒有清晰的藍圖,那後面的任何措施都將“如履薄冰”,甚至無從下手。業務中台建設的第一要務就是釐清業務:我們從領域架構分析入手,運用DDD(領域驅動設計)的相關方法論和工具去深入分析業務,拉開了中台化改造的序幕。

貝殼找房房源中台演進之路 4

可以看到,在前台業務層面,我們有二手房、租賃、託管、商業地產等若干業務線,在中台層面,我們梳理確立了“七縱兩橫”的領域架構:

  • “核心委託域”是整個“房源”業務的聚合根,是最核心的子域,對於房源的錄入、核銷等是其中最主要的事件;
  • “角色資源”和“標準作業”奠定了房源作業的最小功能子集,經紀人通過這些核心流程的作業獲取角色並最終分得業績;
  • “品質保證”、“作業提效”、“安全風控”、“協作撮合”都是支撐性的功能,它們的存在讓整個業務的完備性及經紀人的使用體驗進一步提升;
  • “權限規則”和“數據能力”是兩個通用域。 “權限規則”是被抽像出來的在當前業務背景下具備通用性的權限校驗模塊;“數據能力”負責組織散落在各個子域中的實體和值對象整體對外輸出。

我們旗幟鮮明的認為——“領域架構是系統設計、流程設計、組織分工需要遵循的最基本原則”。在一些架構書籍中會有類似觀點:“有什麼樣的組織架構就有什麼樣的系統架構”,對這種觀點我們持有批判性看法,在相對宏觀的層面,組織確實可以在一定程度上決定係統架構,但更合理的方式永遠都應該是“依據業務現狀合理的設計和調整組織”,這樣在業務真正推進的時候,團隊中的每一個成員才會覺得得心應手。

3 系統架構演進

3.1 數據服務下沉

貝殼找房房源中台演進之路 5

圖中左側為先前的架構,右側為階段性演進後的架構(後同)

在架構演進的第一階段,我們依照之前領域分析的結果將最底層的數據能力做了下沉,把早期的5個子域的數據訪問層拆分成獨立的服務,且基於當時“直營和加盟業務差異性較大”的判斷(後續證明這裡實際上走了彎路),搭建起了一套加盟房源前台。

貝殼找房房源中台演進之路 6

這樣做的收益主要有3點:

  • 業務快速發展上量,底層的數據訪問(例如MySQL)遇到了性能瓶頸,需要做大量性能優化且盡量對上層業務透明;
  • 針對模型的改造更標準、更徹底:在存儲模型和領域模型之間總是存在差異,這種差異帶來的轉換代碼隨著業務的變化是在時刻迭代的,分層的明確有利於將變化中代碼腐敗的可能性隔絕在底層,也更能明確這種修改什麼時候需要侵入到上層業務;
  • 最後也是最重要的一點:可以讓其他業務先依照中台的數據模型接入數據,為日後業務層的複用奠定了堅實的基礎。

當然這樣的做法也有一定的風險,最顯而易見的是兩方面問題:技術層面繞不開的分佈式事務問題及業務層面的數據隔離性問題。

針對分佈式事務的問題,在我們的業務場景下相對來講還是有一定容忍空間的,所以首要的處理原則是不能大幅增加系統的複雜度僅帶來收益有限的提升,在例如角色生成等關鍵環節,我們通過異步化、補償等常規機制來規避就能起到很好地效果;同樣在數據隔離性方面,我們通過一些簡單有效的手段來做有效的保障:例如將業務和房源類型對照,做統一且業務侵入可控的邏輯校驗。

3.2 領域服務重構

貝殼找房房源中台演進之路 7

在架構演進的第二階段,我們開始去處理業務邏輯,可以看到除了通用域的“權限規則”子域外,其他垂直業務功能領域都相應建成了“領域能力層”,將原來停留在大單體應用中復雜的業務邏輯做重構後的拆分和下沉。

貝殼找房房源中台演進之路 8

系統建設同樣遵循“攘外必先安內”的道理,對既有復雜業務系統處置的第一要務是做好防腐。

以“組對盤”系統為例:作為管理一線門店和樓盤、樓棟責任關係的最基礎權限系統,對其調用幾乎充斥在房源所有的功能模塊,所以直營和加盟模式下組對盤粒度的差異性需要萬分小心的處理,我們通過一個中間層來抹平這種差異性,確保上層業務不會出現“if直營else加盟”的腐敗代碼。

對於一個業務系統來講,“核心域”和“通用域”的腐敗是我們需要防微杜漸的,這應當是研發團隊在系統建設方面需要堅守的底線(無論業務的急迫度與優先級如何),否則長期積弊技術團隊將陷入“挖坑填坑,放火救火”的人力黑洞。

3.3 領域組件化拆分

貝殼找房房源中台演進之路 9

第三階段是值得大書特書的章節,在這個階段,我們的系統終於具備了“業務復用”的價值。

如圖所示,在宏觀層面我們做服務化的拆分:角色子域從愈發臃腫的委託核心域做了拆分;為了能夠快速響應系統在應對安全風險方面的需求,我們將安全子域從品質域中做了拆分。

隨後我們還合併了“直營+加盟”的房源前台,並跟隨業務腳步按照“二手+租賃”的業務類型維度重新拆分前台。

貝殼找房房源中台演進之路 10

宏觀層面的服務化拆分很難與“中台化”的目標直接契合,所以在這裡我們更希望強調的是微觀層面的“組件化”建設,以上圖的“房源錄入組件化改造”為例:

在架構優化層面我們通過異步化的拆分大幅提升的系統的吞吐量和可維護性;在中台能力層面我們拆分出了“房源錄入校驗組件”,該組件沉澱了關於房源唯一性、政府政策校驗等若干多業務可複用的能力。

通過一系列粒度合理的組件化拆分,我們真正做到了“兩翼齊飛”——既有效地改善了系統架構的合理性,又沉澱出了一系列業務可複用的中台組件。

貝殼找房房源中台演進之路 11

演進到這個階段,我們才認為自己基本實現了“幫助業務屏蔽後台/平台複雜度”的初衷,以上圖中“實勘組件”為例:作為一個典型的多後台服務交互業務,實勘的接入需要和攝影師系統、如視VR、樓盤字典、數據智能、運營平台(司南)等若干後台服務產生交互,一個新業務線完整接入公司級實勘的成本居高不下。

中台對這些後台服務的統一封裝有效的降低了業務接入的成本,實現了對接效率從“M * N”到“M + N”的提升。

貝殼找房房源中台演進之路 12

如何對複雜的後台/平台能力做封裝?

對外我們通過一系列梳理真正去找尋“前台業務觸點”,例如實勘流程中的下單、審核和物料展示三個環節,圍繞這些業務真正關注的節點做API設計;對內我們將精力重投入到擴展性,設計合理的流程框架並預留足夠的擴展點以支撐業務可能提出的特化需求。

貝殼找房房源中台演進之路 13

對於擴展點的建設,我們總結出了“多維度配置化責任鏈”的基本打法,以“實勘預約權限”為例:

在中台層面對於樓盤範圍、攝影師配置、錄入人保護期等規則是各方業務均接受和認可的通用規則,而對於成本的考量是某些業務部門的特殊擴展規則,“責任鏈模式”可以有序的將這些規則組織在一起並形成有效的沉澱和靈活的編排,另外一個潛在的收益是可以非常清晰的向業務表述中台與前台的邊界在哪。

“配置化”最基本的體現是在“規則節點的生效與否”,我們提煉出業務上最常發生變化的維度作為配置的維度,例如這個場景下的“城市+房源類型+實勘類型”,基於此可以靈活的上下線不同城市、不同房源類型、不同實勘類型的實勘預約規則。

3.4 接入能力建設

貝殼找房房源中台演進之路 14

如上圖中所示,作為公司最上游的業務系統,我們的數據會流轉到若干下游。

對於貝殼業務更全面和宏觀的思考促進了我們第四階段的演進——服務接入能力建設,這個階段可以說真正建成了“具有貝殼特色的業務中台”——提升房源數據在整個業務鏈路中的流轉效率。

貝殼找房房源中台演進之路 15

如圖所示,我們抽象提煉出了所有下游業務線對於房源數據的流轉訴求,通過建設“業務事件中心”、“數據開放平台”和“數據同步服務”這三位一體的服務完美覆蓋和滿足了它們。

業務事件中心:梳理出核心的業務事件,例如“房源錄入”、“角色生成”等,通過標準化的事件粒度和消息格式賦能(主動推送)下游具備“毫秒級感知業務事件發生”的能力;

數據開放平台:通過對房源數據的抽象分包,我們將房源近200個明細字段拆分到幾十個數據包中(內聚性越高的字段放在同一數據包),業務可自主申請自己需要的數據包,開放平台提供規範標準​​的可調用API;

數據同步服務:數據同步服務本質上是對事件中心和開放平台的“推拉結合”,由業務方自己進行“推拉結合”固然在效率和帶寬等若干方面能達到全局最優,但在部分場景下卻不適用,例如像21世紀對接這樣的外網場景,需要有更全面更徹底的隔離機制,在推拉數據流的基礎上我們疊加“文件生成”、“數據加密”等能力,來實現跨公司的數據交互。

4 复盤思考

4.1 中台的能力範疇

貝殼找房房源中台演進之路 16

我們的第一點總結可以概括為:業務中台應提供端到端全鏈路的能力支撐。

“數據存儲”->“業務規則”->“交互界面”的完整鏈路本身就可以看做是一個更宏觀的“責任鏈”,我們對鏈條中的節點承諾可替換,但通常優先級是這樣的:出於對數據的統一歸集和輸出,業務中台一般會首先要求業務統一落數據,不允許替換;在業務邏輯層面通常會是通用和特化並存的局面,所以關注的重點在流程框架和擴展點機制的設計;“交互界面”一般是業務特化最突出的環節,特別是像“房源詳情頁”這種業務上的主功能入口,通常業務很希望有自己的主控權,最常被替換。

但上面的觀點也不能一概而論,我這裡也舉一些反例:

  • 標籤中台:標籤中台最重要的點是“數據存儲”的可替換能力,即快速的數據源接入能力,因為通常標籤規則的計算都會用規則引擎、表達式引擎等方案來做泛化實現,數據接入的效率就成了標籤中台發揮價值的瓶頸;

  • 鑰匙組件:在用戶界面層面,像“鑰匙上傳表單”、“鑰匙管理列表”都具備很高的通用性,這種服務於具體組件的頁面通常沒有必要讓業務做重複建設,中台直接支持就可以了,在部分文案和鏈接上實現一些配置化的成本也很低。

總而言之,全鏈路的能力支撐應當是業務中台的決心,但涉及到具體的組件或場景,優先級是需要case by case仔細考量的。

4.2 中台的衍生路徑

貝殼找房房源中台演進之路 17

我們的第二個總結觀點是:中台建設的自然路徑是從公司核心業務不斷演化而來。

“二手”業務是公司最早的業務,GMV佔比和話語權相對來講也是最高的,後續細分業務在建設中會自然而然的參考二手的業務規則並加以簡化,這就給二手業務做中台製造了很多契機。

我們非常感謝租賃、商業地產在中台建設中給予我們的配合和支持,沒有這些業務的鞭策就很難有動力持續投入到二手的中台化改造中。

4.3 中台運營

貝殼找房房源中台演進之路 18

我們的最後一個思考總結是:技術運營是不可忽視的影響中台成敗的關鍵因素。

上圖列舉了我們做中台運營的一些措施,這裡面我們有些做的比較成功:例如中台發布會和BP機制,中台數據服務的第一次爆發式接入就是在做完第一次中台發布會後,公司內的客戶蜂擁而至,後續的BP機制和專項對接群是我們最終能夠另這些客戶滿意的關鍵。

有一些我們也做的不那麼盡如人意:在文檔建設和流程時效方面我們還有很大的進步空間,在文檔方面很多同學還是習慣於“WIKI管理、散點對接”的老方式,這塊還需要尋找更有效的改進抓手;在流程時效方面因為人力和二手前台的合用在很多時候也不能讓業務方那麼滿意,我們還在持續摸索“業務內聚、溝通效率與人力隔離”的平衡性,期望來年在組織架構層面能有更好的變化去契合中台戰略。

案例總結

1 成功要點

通過領域架構分析,釐清了系統中若干混亂模塊,建立起產研認知一致的領域邊界,為團隊高效的分工協作及流程、系統的設計原則奠定了基礎。

通過合理粒度的服務化拆分,在基礎架構較薄弱的情況下大幅改善了系統穩定性和迭代效率。

通過數據中心、業務中心和服務接入中心的逐步建設,不斷為中台贏得了客戶的信任,積累了多個前台最佳實踐,形成了“中台積澱、業務反哺”的正循環。

2 ROI分享

數據能力方面,房源中台通過開放平台+事件中心+同步服務三位一體的系統化建設,很好地串聯起公司若干業務線,整體提升了長業務鏈路上核心業務數據的流轉效率;

作業能力方面,新興業務品類大量復用了原有二手、租賃業務沉澱多年的業務規則,前台與後台直接的對接時效從M*N降低為M+N,大幅提升了研發效率,並可以基於框架流程靈活定制,具備很好的擴展性。

3 案例啟示

  • 複雜業務系統,需要做非常明確的領域架構分析,明確領域邊界,以保證產研團隊認知一致,分工明確;
  • 服務化拆分應結合業務現狀,公司基礎架構能力,研發團隊實際情況等方面做綜合考量,才能做到全局最優;
  • 業務中台需重視框架流程設計,強調框架思維,形成追求優雅設計的良好氛圍;
  • 前台對中台存在數據輸出、業務復用、接入自主等若干方面的訴求,需要有合理的優先級和取捨,才能逐一將它們滿足。

作者介紹

竇聖偉,曾先後就職於百度、豆瓣、美團等知名互聯網公司,擅長複雜業務系統的架構分析和演進,現任貝殼找房人店平台技術中心架構師。

本文轉載自公眾號貝殼產品技術。

原文鏈接

https://mp.weixin.qq.com/s/Hc9krVjlW3myc4hWvL5Lqg