房源搜索中台搭建实战.docxVIP

房源搜索中台搭建实战 中台只是一种形式，归根到底是需要解决真实的业务问题；为了中台概念而打乱现有的业务部署，强行拆前台搭中台往往是得不偿失的。 从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的情况。现有的架构完全无法支持，强行配上多个MLS的搜索，会出现大量重复的搜索条件。 客户也无法理解为什么可用的搜索条件始终只对一部分商品生效，所以中台的建立是帮我们扩展了服务大客户的能力。 除非我们认定为不需要接入大客，但事实上服务大客已经成为我们产品业务的首要目标。 2）服务效率问题 内部开发损耗：由于整个产品线都离不开房源管理和营销，所以各个业务端口都会或多或少地用到房源搜索和展示。 那么在中台上线之前，都是由各个业务端自己调用最底层的房源数据封装各自独立的业务搜索逻辑，那么弊端也异常明显： 1）开发内耗，房源搜索逻辑大部分是可复用的，即使有一些业务端口需要特殊的搜索逻辑，那么也基本在当前的搜索框架内； 2）搜索逻辑不统一，由于各个业务端口自己整理搭建搜索功能，或多或少会有一些逻辑上的差异，所以客户在不同端口使用相同业务条件搜索时，发现自己看到的房源结果会有细微的差异，给客户带来困扰。 外部服务支持：客户一般会根据自己当地的情况提出一些增减搜索的需求。 但是我们在给客户配置时，会获取到当前400个MLS的所有可用搜索条件，比如我们要给客户添加一个“挂牌状态”条件，最夸张的情况下我们会看到400个相同名称的“挂牌状态”，对运营同学的配置成本极高。 另外由于在接入多个MLS的过程中，我们总结了一些相对比较通用的搜索条件（比如beds，baths这列