途牛原创｜基于EAV模型的运营系统架构实践

序

本文将介绍如何基于 EAV 模型，来构造一个准自动化的运营系统，服务运营研发部的相关工作。

我们的痛点

运营研发部对接三端（PC、M、APP）后台工作，劳心劳力。。。

• 头疼的稀疏表（ 稀疏表通常会有很多列，但是每一行有值的列又比较少。）＋头疼的各种表。

• 持续的迭(xu)代(qiu)升(bian)级(geng)（每一次功能升级，都需要变更表结构）。

• 基础数据的维护代码坑好多，打个标签加个属性，都好怕。

• Code Monkey，熟悉的表＋熟悉的套路（设计表单、设计字段、CRUD...）Boom！

漫漫选型路

其实我们的愿景很“简单”。

• 可以舒服地给各种［途牛实体］打标签、扩展属性。

• 可以简单地记录任何结构的新数据，而不需要修改任何数据结构。

• 可以极好地迅速扩展应用，因为它可以防止(属性)不断变化的后果。

漫漫长路。。。

为了高可用&扩展性，我们学习了Drupal的元数据操作、Magento的产品建模、以及各种CMS。

为了解决稀疏表，我们尝试基于 Column Family（列族）来处理，BigTable、Cassandra、HBase，曾经都是我们的“座上客”。（事实上，很多团队已经这样解决掉了）

然而，

踏破铁鞋无觅处，得来全不费工夫。

一种数据模型悄然而至，实体属性值模型。

来自百度百科：实体属性值模型（EAV）是一种用数据模型描述实体的属性（属性，参数），可以用来形容他们潜在巨大，但实际上将适用于给定的实体的数量是相对较少。 在数学中，这种模式被称为一个稀疏矩阵 。 EAV也被称为对象的属性值的模式，垂直的数据库模型和开放式架构。

这里不详细介绍EAV是什么，因为我们的设计在EAV之上。（站在巨人的肩膀上）

下面即将进入全文干货集中地段。^_^

RBZ

系统代号：RBZ（肉包子）

系统构成：EAV＋DF＋AC＋PHP＋MYSQL

系统模块：

• 应用中心

• 属性中心

• 标签中心

从技术角度描述RBZ的运转流程大致如下：

• 通过［属性中心］配置和管理属性。

• 通过［标签中心］配置和管理标签。

• 通过［应用中心］选择［实体、属性、标签］，自动生成表单，录入数据。

• 通过［CMS］动态模版输出给C端用户。

下面逐一讲解，他们分别是什么。：）无比接近干货地段了。

系统设计

架构

表结构

基于列模式的表设计。（我们常规的工作都是行模式）

举个栗子：A公司售卖鞋子和衣服。（比较极端，勿喷）

行模式（产品表）

PID	PNAME	类型	尺码	颜色
0001	鞋子1	1	42	黑色
0002	衣服1	2	XL	蓝色

列模式（属性表、实体表）

属性表（类型、排序、启用、默认值、可选值、必填...）

属性ID	属性名称	属性字段	数据类型	属性分组
1	尺码	size	input	鞋子
2	尺码	size	input	衣服
3	颜色	color	input	鞋子
4	颜色	color	input	衣服

实体表

ID	应用ID	实体ID	属性ID	属性值
1	1	0001	1	42
2	1	0001	3	黑色
3	1	0002	2	XL
4	1	0002	4	蓝色

这番设计，两个益处。

1. 省存储空间。

2. 易动态扩展。

动态表单

我们的常规工作是静态表单，避免在Code Monkey的路，越走越远，我们需要改变。

设计动态表单模型，基本的思路应该是数据和表现显示的分离。抛开表现层，一个表单包含的若干个字段和填写的数据。所谓动态，就是这些字段名称可能改变，数量可能有增减。

配置字段（POI中文名称）

配置中。。。

见证奇迹的时刻。（表单自动生成）

这番设计，两个益处。

1. 猴子做架构了（再也不用写FORM了）。

2. 用户自定义。

CMS

通过CMS定义RBZ标签，结合自定义样式模版，任意组合吐出数据。

用了一个叫 Mustache 的模版语言。

{{#cmsRbzItems}}
中文名称 {{attr_cnname}}
英文名称 {{attr_enname}}
岛屿图片 {{attr_pic}}
所属群礁 {{attr_class}}
酒店品牌 {{attr_hotel}}
费用信息 {{attr_price}}
产品推荐 {{attr_managerrecommend}}
岛屿星级 {{attr_islandstar}}
岛屿排序 {{attr_islandrank}}
上岛时间 {{attr_timecost}}
{{/cmsRbzItems}}

API

为确保RBZ接口的持续交付，我们选择用 Postman 来做接口的自动化测试工作。

某一个请求。

每一次发布。

RBZ－应用

处子秀：马尔代夫选岛工具

需求：

• 提取马尔代夫的所有岛屿（POI）

• 扩展岛屿属性（费用信息、岛屿星级、产品经理推荐）

• 给岛屿打标签（蜜月、亲子、一价全含、WIFI）

• 选岛工具

只需配置，无需研发。

• 配置属性

• 配置标签

• 配置应用

  • 选POI

  • 编辑属性

  • 编辑标签

灯灯灯灯。。。

筛选项：

实体：

在这里，代表官方，诚邀各种应用接入。

RBZ－ROI

浅谈RBZ的回报率。

• 成就工作快，降成本，提效率。（之前这样的后台开发任务至少需要15人天）。

• 可能成为运营层数据字典。

• 聚合页需求配置化。

• 精细化运营：脱离底层数据，在运营层通过属性、标签配置，精细化呈现。

结论

理解EAV模型确实需要时间。它有一个明确的学习曲线，使的初级开发人员在真正理解其概念前，需要为此付出更多的精力。

应用实体-属性-值时，应考虑以下条件：

• 数据是稀疏的、异构的，一个实体的属性范围较广，且常引入新的属性。

• 类的数量非常大，有许多实例类，即使属性是非稀疏的。

结束语

我们的终极目标是：

人人都是程序员。

• PHP－EAV

• 基于Postman的自动化测试

• 美团供应链架构