贝壳找房房源中台演进之路-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

引言

2019 年底，由麦思博（msup）主办的 TOP100 全球软件案例研究峰会（TOP100Summit）在北京国际会议中心开幕，TOP100Summit 是科技界一年一度的案例研究峰会，每年甄选有学习价值的 100 个技术创新/研发管理实践，分享他们在本年度最值得总结、盘点的实践启示。

在“架构演进 &工程实践”专场，贝壳找房人店平台技术中心首次对外分享其中台建设的系统性技术方案，揭晓了房源系统如何从庞大单体应用逐渐向服务化、中台化演进的整个过程。作为行业领先的新居住服务平台，贝壳找房搭建出能力可复用的中台，推动业务迭代和数据应用，实现创新提效，并将充分对外赋能，为全行业的创新提效提供综合解决方案。

案例简述

本案例将带来贝壳找房支撑一线门店作业的 B 端房源系统如何从仅支持原链家直营的单体应用，逐步演进为支撑 90 多个城市，涵盖二手、租赁、托管、商业地产等多种业务品类的房源中台系统。

其中面对复杂业务系统的服务化拆分，架构演进及如何以中台化为目标进行扩展点建设，都包含大量实践案例，相信可以在业务系统治理，中台建设等方面给予大家一些启发。

案例背景

2018 年初，随着贝壳找房的全面上线，原链家业务模式从单纯自由直营模式向平台化、加盟化迈出重要一步。伴随着加盟模式的开城扩张，链家在房产交易行业沉淀多年的经验打法逐渐从一、二线城市向三、四线城市下沉。

在这个过程中，我们遇到了大量城市的特化需求，整个系统原有的业务规则甚至核心模型都受到了严重的冲击。

贝壳找房产研团队通过中台建设的方式，逐步完成了从被业务牵着鼻子走到能够快速灵活主动的响应业务诉求的转变。

案例执行

1 定位与目标

“中台”是近年互联网行业讨论非常火热的话题，“中台”分成很多种：

我们可以看到，有注重数据分析能力建设的数据中台，有专注于业务功能重用的业务中台，有提供基础设施套餐化的技术中台，也有致力于策略算法服务化的算法中台，贝壳找房的“房源中台”的定位是“业务中台”。

“业务重用”是工程开发中非常朴素的诉求，贝壳找房的业务基本上都是围绕房产交易展开的，其特点可以概括为“业务链路长，地域差异性明显，后台支撑性服务众多”，基于以上的诉求和背景，我们的“房源业务中台”围绕以下两个切入点展开：

一方面希望提升“房源”数据在整个冗长业务流中的流转效率；另外一方面封装后台、平台的若干复杂细节，屏蔽它们的复杂性，提升前台的接入效率。

2 领域架构分析

如果对于业务架构没有清晰的蓝图，那后面的任何措施都将“如履薄冰”，甚至无从下手。业务中台建设的第一要务就是厘清业务：我们从领域架构分析入手，运用 DDD（领域驱动设计）的相关方法论和工具去深入分析业务，拉开了中台化改造的序幕。

可以看到，在前台业务层面，我们有二手房、租赁、托管、商业地产等若干业务线，在中台层面，我们梳理确立了“七纵两横”的领域架构：

“核心委托域”是整个“房源”业务的聚合根，是最核心的子域，对于房源的录入、核销等是其中最主要的事件；
“角色资源”和“标准作业”奠定了房源作业的最小功能子集，经纪人通过这些核心流程的作业获取角色并最终分得业绩；
“品质保证”、“作业提效”、“安全风控”、“协作撮合”都是支撑性的功能，它们的存在让整个业务的完备性及经纪人的使用体验进一步提升；
“权限规则”和“数据能力”是两个通用域。“权限规则”是被抽象出来的在当前业务背景下具备通用性的权限校验模块；“数据能力”负责组织散落在各个子域中的实体和值对象整体对外输出。

我们旗帜鲜明的认为——“领域架构是系统设计、流程设计、组织分工需要遵循的最基本原则”。在一些架构书籍中会有类似观点：“有什么样的组织架构就有什么样的系统架构”，对这种观点我们持有批判性看法，在相对宏观的层面，组织确实可以在一定程度上决定系统架构，但更合理的方式永远都应该是“依据业务现状合理的设计和调整组织”，这样在业务真正推进的时候，团队中的每一个成员才会觉得得心应手。

3 系统架构演进

3.1 数据服务下沉

图中左侧为先前的架构，右侧为阶段性演进后的架构（后同）

在架构演进的第一阶段，我们依照之前领域分析的结果将最底层的数据能力做了下沉，把早期的 5 个子域的数据访问层拆分成独立的服务，且基于当时“直营和加盟业务差异性较大”的判断（后续证明这里实际上走了弯路），搭建起了一套加盟房源前台。

这样做的收益主要有 3 点：

业务快速发展上量，底层的数据访问（例如 MySQL）遇到了性能瓶颈，需要做大量性能优化且尽量对上层业务透明；
针对模型的改造更标准、更彻底：在存储模型和领域模型之间总是存在差异，这种差异带来的转换代码随着业务的变化是在时刻迭代的，分层的明确有利于将变化中代码腐败的可能性隔绝在底层，也更能明确这种修改什么时候需要侵入到上层业务；
最后也是最重要的一点：可以让其他业务先依照中台的数据模型接入数据，为日后业务层的复用奠定了坚实的基础。

当然这样的做法也有一定的风险，最显而易见的是两方面问题：技术层面绕不开的分布式事务问题及业务层面的数据隔离性问题。

针对分布式事务的问题，在我们的业务场景下相对来讲还是有一定容忍空间的，所以首要的处理原则是不能大幅增加系统的复杂度仅带来收益有限的提升，在例如角色生成等关键环节，我们通过异步化、补偿等常规机制来规避就能起到很好地效果；同样在数据隔离性方面，我们通过一些简单有效的手段来做有效的保障：例如将业务和房源类型对照，做统一且业务侵入可控的逻辑校验。

3.2 领域服务重构

在架构演进的第二阶段，我们开始去处理业务逻辑，可以看到除了通用域的“权限规则”子域外，其他垂直业务功能领域都相应建成了“领域能力层”，将原来停留在大单体应用中复杂的业务逻辑做重构后的拆分和下沉。

系统建设同样遵循“攘外必先安内”的道理，对既有复杂业务系统处置的第一要务是做好防腐。

以“组对盘”系统为例：作为管理一线门店和楼盘、楼栋责任关系的最基础权限系统，对其调用几乎充斥在房源所有的功能模块，所以直营和加盟模式下组对盘粒度的差异性需要万分小心的处理，我们通过一个中间层来抹平这种差异性，确保上层业务不会出现“if 直营 else 加盟”的腐败代码。

对于一个业务系统来讲，“核心域”和“通用域”的腐败是我们需要防微杜渐的，这应当是研发团队在系统建设方面需要坚守的底线（无论业务的急迫度与优先级如何)，否则长期积弊技术团队将陷入“挖坑填坑，放火救火”的人力黑洞。

3.3 领域组件化拆分

第三阶段是值得大书特书的章节，在这个阶段，我们的系统终于具备了“业务复用”的价值。

如图所示，在宏观层面我们做服务化的拆分：角色子域从愈发臃肿的委托核心域做了拆分；为了能够快速响应系统在应对安全风险方面的需求，我们将安全子域从品质域中做了拆分。

随后我们还合并了“直营+加盟”的房源前台，并跟随业务脚步按照“二手+租赁”的业务类型维度重新拆分前台。

宏观层面的服务化拆分很难与“中台化”的目标直接契合，所以在这里我们更希望强调的是微观层面的“组件化”建设，以上图的“房源录入组件化改造”为例：

在架构优化层面我们通过异步化的拆分大幅提升的系统的吞吐量和可维护性；在中台能力层面我们拆分出了“房源录入校验组件”，该组件沉淀了关于房源唯一性、政府政策校验等若干多业务可复用的能力。

通过一系列粒度合理的组件化拆分，我们真正做到了“两翼齐飞”——既有效地改善了系统架构的合理性，又沉淀出了一系列业务可复用的中台组件。

演进到这个阶段，我们才认为自己基本实现了“帮助业务屏蔽后台/平台复杂度”的初衷，以上图中“实勘组件”为例：作为一个典型的多后台服务交互业务，实勘的接入需要和摄影师系统、如视 VR、楼盘字典、数据智能、运营平台（司南）等若干后台服务产生交互，一个新业务线完整接入公司级实勘的成本居高不下。

中台对这些后台服务的统一封装有效的降低了业务接入的成本，实现了对接效率从“M * N”到“M + N”的提升。

如何对复杂的后台/平台能力做封装？

对外我们通过一系列梳理真正去找寻“前台业务触点”，例如实勘流程中的下单、审核和物料展示三个环节，围绕这些业务真正关注的节点做 API 设计；对内我们将精力重投入到扩展性，设计合理的流程框架并预留足够的扩展点以支撑业务可能提出的特化需求。

对于扩展点的建设，我们总结出了“多维度配置化责任链”的基本打法，以“实勘预约权限”为例：

在中台层面对于楼盘范围、摄影师配置、录入人保护期等规则是各方业务均接受和认可的通用规则，而对于成本的考量是某些业务部门的特殊扩展规则，“责任链模式”可以有序的将这些规则组织在一起并形成有效的沉淀和灵活的编排，另外一个潜在的收益是可以非常清晰的向业务表述中台与前台的边界在哪。

“配置化”最基本的体现是在“规则节点的生效与否”，我们提炼出业务上最常发生变化的维度作为配置的维度，例如这个场景下的“城市+房源类型+实勘类型”，基于此可以灵活的上下线不同城市、不同房源类型、不同实勘类型的实勘预约规则。

3.4 接入能力建设

如上图中所示，作为公司最上游的业务系统，我们的数据会流转到若干下游。

对于贝壳业务更全面和宏观的思考促进了我们第四阶段的演进——服务接入能力建设，这个阶段可以说真正建成了“具有贝壳特色的业务中台”——提升房源数据在整个业务链路中的流转效率。

如图所示，我们抽象提炼出了所有下游业务线对于房源数据的流转诉求，通过建设“业务事件中心”、“数据开放平台”和“数据同步服务”这三位一体的服务完美覆盖和满足了它们。

业务事件中心：梳理出核心的业务事件，例如“房源录入”、“角色生成”等，通过标准化的事件粒度和消息格式赋能（主动推送）下游具备“毫秒级感知业务事件发生”的能力；

数据开放平台：通过对房源数据的抽象分包，我们将房源近 200 个明细字段拆分到几十个数据包中（内聚性越高的字段放在同一数据包），业务可自主申请自己需要的数据包，开放平台提供规范标准的可调用 API；

数据同步服务：数据同步服务本质上是对事件中心和开放平台的“推拉结合”，由业务方自己进行“推拉结合”固然在效率和带宽等若干方面能达到全局最优，但在部分场景下却不适用，例如像 21 世纪对接这样的外网场景，需要有更全面更彻底的隔离机制，在推拉数据流的基础上我们叠加“文件生成”、“数据加密”等能力，来实现跨公司的数据交互。

4 复盘思考

4.1 中台的能力范畴

我们的第一点总结可以概括为：业务中台应提供端到端全链路的能力支撑。

“数据存储”->“业务规则”->“交互界面”的完整链路本身就可以看做是一个更宏观的“责任链”，我们对链条中的节点承诺可替换，但通常优先级是这样的：出于对数据的统一归集和输出，业务中台一般会首先要求业务统一落数据，不允许替换；在业务逻辑层面通常会是通用和特化并存的局面，所以关注的重点在流程框架和扩展点机制的设计；“交互界面”一般是业务特化最突出的环节，特别是像“房源详情页”这种业务上的主功能入口，通常业务很希望有自己的主控权，最常被替换。

但上面的观点也不能一概而论，我这里也举一些反例：

标签中台：标签中台最重要的点是“数据存储”的可替换能力，即快速的数据源接入能力，因为通常标签规则的计算都会用规则引擎、表达式引擎等方案来做泛化实现，数据接入的效率就成了标签中台发挥价值的瓶颈；
钥匙组件：在用户界面层面，像“钥匙上传表单”、“钥匙管理列表”都具备很高的通用性，这种服务于具体组件的页面通常没有必要让业务做重复建设，中台直接支持就可以了，在部分文案和链接上实现一些配置化的成本也很低。

总而言之，全链路的能力支撑应当是业务中台的决心，但涉及到具体的组件或场景，优先级是需要 case by case 仔细考量的。

4.2 中台的衍生路径

我们的第二个总结观点是：中台建设的自然路径是从公司核心业务不断演化而来。

“二手”业务是公司最早的业务，GMV 占比和话语权相对来讲也是最高的，后续细分业务在建设中会自然而然的参考二手的业务规则并加以简化，这就给二手业务做中台制造了很多契机。

我们非常感谢租赁、商业地产在中台建设中给予我们的配合和支持，没有这些业务的鞭策就很难有动力持续投入到二手的中台化改造中。

4.3 中台运营

我们的最后一个思考总结是：技术运营是不可忽视的影响中台成败的关键因素。

上图列举了我们做中台运营的一些措施，这里面我们有些做的比较成功：例如中台发布会和 BP 机制，中台数据服务的第一次爆发式接入就是在做完第一次中台发布会后，公司内的客户蜂拥而至，后续的 BP 机制和专项对接群是我们最终能够另这些客户满意的关键。

有一些我们也做的不那么尽如人意：在文档建设和流程时效方面我们还有很大的进步空间，在文档方面很多同学还是习惯于“WIKI 管理、散点对接”的老方式，这块还需要寻找更有效的改进抓手；在流程时效方面因为人力和二手前台的合用在很多时候也不能让业务方那么满意，我们还在持续摸索“业务内聚、沟通效率与人力隔离”的平衡性，期望来年在组织架构层面能有更好的变化去契合中台战略。