编辑导语：中台简单地说，就是抽象和复用，类似软件开发中“面向服务的体系架构”的概念，中台也有不同的分类，根据企业不同的需要搭建不同的中台体系；本文作者根据自己搭建房源搜索中台的案列进行经验分享和总结，我们一起来看一下。

中台只是一种形式，归根到底是需要解决真实的业务问题；为了中台概念而打乱现有的业务部署，强行拆前台搭中台往往是得不偿失的。

从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这列非常通用的搜索），并在代码层面做了统一默认配置。

可以理解为我们有了一些对全局通用的搜索条件，但实际落到各个业务层面，还是需要根据客户的需求做一些微调。

现有的流程只能先隐藏通用搜索，再单独配置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协议