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

中台化背景下的元数据驱动架构实践一、背景介绍为解决系统重复建设、能力复用性低的问题，携程启动了中台化建设步伐。

旅游行业的中台建设，携程并非从零开始，前期已经积累了行业中多个场景的业务和技术的中台能力。

因系统建设的复杂，亟需一个中台大脑站在全局视角进行公司中台能力的梳理和建设。

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类型的存储结构并不满足我们的需求。

如在中台概念中，我们一般会把前端应用按照“端”、“场景”属性进行分类，以端为例，我们可能需要三级级联的属性和属性值来组成“端”属性，三级级联属性分别为：第一级：online/offline，用于描述是外网应用还是内网应用；第二级：web/app/H5，用于描述前端应用触达用户的方式；第三级，则是按照行业业务归属进行的端的定义。

此类需求的难点在于，三级属性互相影响、互相依赖，如online和offline，以及不同的端类型，其对应的第三级属性的属性值，是完全不同的。

又如卖方在产品定义时，为了方便开发角色的用户在浏览产品时对接口等技术指标进行评估，可能需要对系统接口或者整体系统指标进行说明，需要一个表格类型的控件。

就这样一个简单的表格需求，对于我们类目属性的这套产品结构复杂度构成了指数级的挑战，这需要我们进行属性的层层嵌套，并且对前端页面更为友好的方式，将嵌套数据输出给前端页面。

除了结构的复杂度，我们还面临复杂结构下带来的性能、数据安全性等的挑战：（1）基于类目属性的产品结构中，因为产品属性并不是简单关系型数据库的行列，而是倒树形非关系型的结构以行列方式存储。

这对我们的查询性能造成了较大挑战。

在互联网应用对性能极致的追求下，网络连接是最“宝贵”的资源，我们需要尽可能节约前端请求数量，不可能用户每次点击属性都实时进行子属性和属性值的拉取。

所以在这种场景下，需要服务端能够一次输出该产品类目定义的所有属性和枚举的属性值、以及产品对应的属性值。

因产品属性的级联嵌套复杂度，其输出性能将会随着产品属性嵌套复杂度的提升而升高。

（2）类目、属性、规则等“描述数据的数据”（文中统一称为“元数据”），与应用运行过程中产生的产品等数据不同，元数据（如属性和规则等修改）的修改，将会影响到大批量下游数据的变更。

如果是因为人为或者程序的误操作导致元数据的错误变化，将会产生不可估量的业务后果。

3.1.3.模型元数据的技术方案为解决上述问题（1）的挑战，我们使用mysql作为存储数据库，底层数据结构：抽离一套类目属性表和类目属性值表，类目属性表描述属性的父子关系，而类目属性值表描述属性值的父子关系，即存储属性和属性值的两棵树。

再通过数据加工，组成一套产品属性模版数据和属性值关系数据。

如上面提到的“端”这个属性的例子，我们可以构造给前端应用这样一颗树及模版：树Template类在关系型数据库存储树形结构的问题，其实业界已经有一些可以参考的方法论，一般比较普遍的就是四种方法：（具体见《SQL Anti-patterns》这本书）•Adjacency List：每一条记录存parent_id•Path Enumerations：每一条记录存整个tree path经过的node枚举•Nested Sets：每一条记录存 nleft 和 nright•Closure Table：维护一个表，所有的tree path作为记录进行保存书中介绍的各种方法的常用操作代价见下图：我们的场景中，对于全树查询、插入、删除有较强的需求，根据以上表格的结论看起来Closure Table方案更好一点。

但其实需要考虑到：Closure Table需要额外维护一套全路径表，而存储路径本身就是一个不可预知的大字段。

考虑到未来的接入类目属性和SPU管理能力的数据量级、对db的读写压力以及分库分表等db的需求，我们最终选择的一个对mysql比较轻量的Adjacency List方案，为弥补此方案对全树查询的短板，做了以下两个措施：一是构建SPU树的模版，将类目属性和类目属性值相互独立，之间通过属性编码进行关联，同时构建出两条树形结构：类目属性和类目属性值。

类目属性绑定到模版，这样可以直接输出给前端应用使用，类目属性值则直接输出每一层级的数据，保证每次查询都是非常简单sql查询。

二是通过消息通知机制，尽及时做到若mysql的这两棵树有任何变更，将都能及时都获知并且更新模版及类目属性值。

上面的解决方案，解决了每个类目属性树的存储和查询的问题，我们称为类目属性模板。

模板的缓存为最终SPU树的输出性能提供了一部分保障，为了进一步解决性能问题和模板数据安全的问题，我们设计了以下方案：（1）为保证类目属性元数据模板的安全性，除按照上面陈述的存储和查询方案，我们多加了一层模板数据临时区（预览区）和正式区（运行区）的区分。

类目属性控制台可以实时修改类目的属性、属性值和规则，但是数据会保存在临时区。