中台化背景下的元数据驱动架构实践

中台化背景下的元数据驱动架构实践

一、背景介绍

为解决系统重复建设、能力复用性低的问题，携程启动了中台化建设步伐。旅游行业的中台建设，携程并非从零开始，前期已经积累了行业中多个场景的业务和技术的中台能力。因系统建设的复杂，亟需一个中台大脑站在全局视角进行公司中台能力的梳理和建设。Tripyun-携程云是中台团队打造的产品中台，采用独特的”电商开店“方式，鼓励各业务线发布具备中台能力的产品，管理产品的整个生命周期，包括产品的创建、展示、开通服务、产品需求、产品联通和度量，以此来吸引其他团队下单采用，并通过需求结构化、能力优化不断打磨各团队产品的中台能力。Tripyun-携程云最终将以全局视角，通过能力地图将旅游行业里的中台能力都呈现出来。为满足各团队在平台上对产品进行管理和“开店”的需求，我们为平台搭建了底层类目属性管理能力和SPU管理能力服务，满足了旅游行业特色的多样化中台产品和能力的发布需求。

本文以此中台能力的建设作为实操，详解我们探索中的中台建设的思路，重点介绍搭建类目属性和SPU中台能力过程中的技术实践，读者将了解到：

1）如何提升一个产品的中台能力；2）以一个具体案例了解什么是元数据驱动和其架构实践；3）Tripyun-携程云类目属性和SPU管理能力，可考虑使用我们的能力，共建行业类目属性库。

二、什么是元数据

元数据，是指一种结构化的信息，用于对某项信息资源进行描述、解释、定位，使其易于提取和使用。我们先看下在电商应用中商品领域中的元数据定义：

2.1 名词解释

（1）SPU：Standard Product Unit （标准产品单位），是用来聚合描述一种商品信息的单元。基于SPU的商品信息结构，可以实现丰富的应用，比如商品信息与资讯、评论、以及其它SPU的整合起来，就可以基于同一模型来满足多种场景的业务。

我们借鉴了电商中对于SPU的应用，即通过SPU的“类目属性”来描述Tripyun-携程云

上的一切业务数据，包括系统上的产品、团队、订单信息、能力信息等数据，都作为SPU 进行整合，进行了业务数据模型的统一。

（2）类目，也就是分类，分类是为了更好的管理商品（商品管理的核心就是分类）。

在Tripyun-携程云中，我们通过类目来分类产品、订单、能力、团队的类型。比如在产品上，通过类目把携程的基本产品做了基本分类，以满足不同类型的产品区分管理。

类目的设计主要从两个维度考虑，除了后台类目，还有前台类目，即给前端用户看的类目。电商应用在针对用户的展示或者营销过程中，往往会给商品划分一个只用于前端展示的类目，该类目可能由于运营的需要而进行调整。Tripyun-携程云平台也具有前台类目。（3）类目属性，就是某个商品的特性，属性值即属性的具体内容。对于电商来说，属性主要是商品的品牌、尺寸、大小、颜色等，对于品牌属性而言，其属性值可以为阿迪达斯、耐克、马自达等等。类目是为了分类商品，而属性是为了描述商品。

在Tripyun-携程云平台中，我们定义了一个”广义数据模型“的概念，把产品、订单、能力、团队等业务的模板都使用属性来定义。比如，把产品的中台能力定义为一个特殊的类目，而用户应该怎样描述自己的能力，则提供统一的属性定义页面，来允许用户定义复杂结构的属性集。

（4）SKU，大家都知道电商行业中的SKU（Stock Keeping Unit）是指库存量单位，即库存进出计量的单位，可以是以件、盒、托盘等为单位。

SKU是物理上不可分割的最小存货单元，而在Tripyun-携程云中，因为我们卖的不是货，而是中台能力，所以可以理解为我们让大家在平台上录入的能力即为SKU（可以直接”卖“给产品采用方的最小单元，可以是小到一个工具、一个框架、一个接口，或一组服务组成的应用，也可以大到一个产品线）。

对中台产品而言，能力除了可以作为SKU，还多了一层额外的意义——能力是中台产品可以被（个性化）复用的体现，由产品开放出来的互相解耦的能力选项而构成。

2.2 Tripyun-携程云中的元数据

为保证Tripyun-携程云上产品数据结构足够灵活，我们夯实了类目属性的底层数据结构，支持多种不限于K-V结构（包括表格、级联等复杂表单数据存储结构）的数据存储、查询、校验等需求。

这样的数据管理能力也可以支撑除了产品外很多其他领域的数据模型，目前这套能力已经为Tripyun-携程云平台提供团队管理、产品管理、能力（SKU）管理、服务单/调用单管理等多个业务场景的数据模型定义、动态表单生成、动态规则校验和动态业务数据的存储/查询了，实际上已经成为Tripyun-携程云平台所有模块的业务数据模型——支持通过不同的规则定义和流程扩展，来做不同场景下的个性化定制。

我们把这种描述业务数据的数据，统称为元数据。如上面提到的，元数据除了包含数据模型定义，还包含了业务规则定义、业务流程定义、业务配置（标）定义和面向前端的组件数据定义。

三、我们的实践

3.1 可自定义的产品结构和能力发布结构、满足全球化背景下可复用的数据多语言——数据模型

3.1.1.解决方案

我们认为业务中台化的一个重要措施是进行业务模型的抽象，将模型抽象为可统一表达的元数据模型，将非常有利于行业数据的标准化管理，进一步缩短基础数据管理的成本，而基础数据模型的统一也将为后续规则的统一和业务流程的标准化提供了可能性。

在搭建Tripyun-携程云平台的时候，我们将原本业务上很多互不相干的数据管理，如团队、产品、能力、服务单等模块的信息类数据抽象成了统一的模板元数据。而将随着业务不断变化的属性数据，如状态、活动标签、业务标记等使用业务配置（可以认为是动态的扩展字段，下一节介绍）的方式进行解耦和动态管理。

3.1.2.数据模型统一的困难

电商应用中的SPU属性，因商品本身普适性强，以及买方一般具备对商品一定的基本认知，可能K-V类型的存储结构满足大多数的应用场景，结构上并不复杂。

但是Tripyun-携程云的业务范围是描述“软件产品服务”类商品，且更多的是与具体业务相关的服务，软件类“商品”本身确实比一般性商品更加“复杂”，且用户在浏览Tripyun-携程云平台上发布的软件产品时，也没有普适性认知，所以我们需要足够灵活、方便的，不只是k-v结构的展示方式，所以仅仅K-V类型的存储结构并不满足我们的需求。如在中台概念中，我们一般会把前端应用按照“端”、“场景”属性进行分类，以