途牛原创｜基于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的自动化测试
• 美团供应链架构