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

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

我们的痛点

运营研发部对接三端(PC、M、APP)后台工作,劳心劳力。。。

  1. 头疼的稀疏表( 稀疏表通常会有很多列,但是每一行有值的列又比较少。)+头疼的各种表。

  2. 持续的迭(xu)代(qiu)升(bian)级(geng)(每一次功能升级,都需要变更表结构)。

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

  4. Code Monkey,熟悉的表+熟悉的套路(设计表单、设计字段、CRUD...)Boom!

漫漫选型路

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

  1. 可以舒服地给各种[途牛实体]打标签、扩展属性。

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

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

漫漫长路。。。

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

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

然而,

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

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

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

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

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

RBZ

系统代号:RBZ(肉包子)

系统构成:EAV+DF+AC+PHP+MYSQL

系统模块:

  1. 应用中心

  2. 属性中心

  3. 标签中心

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

  1. 通过[属性中心]配置和管理属性。

  2. 通过[标签中心]配置和管理标签。

  3. 通过[应用中心]选择[实体、属性、标签],自动生成表单,录入数据。

  4. 通过[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-应用

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

需求:

  1. 提取马尔代夫的所有岛屿(POI)

  2. 扩展岛屿属性(费用信息、岛屿星级、产品经理推荐)

  3. 给岛屿打标签(蜜月、亲子、一价全含、WIFI)

  4. 选岛工具

只需配置,无需研发

  1. 配置属性

  2. 配置标签

  3. 配置应用

选POI

  1. 编辑属性

  2. 编辑标签

灯灯灯灯。。。

筛选项:

实体:

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

RBZ-ROI

浅谈RBZ的回报率。

  1. 成就工作快,降成本,提效率。(之前这样的后台开发任务至少需要15人天)。

  2. 可能成为运营层数据字典

  3. 聚合页需求配置化

  4. 精细化运营:脱离底层数据,在运营层通过属性、标签配置,精细化呈现。

结论

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

应用实体-属性-值时,应考虑以下条件:

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

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

结束语

我们的终极目标是:

人人都是程序员。

  1. PHP-EAV

  2. 基于Postman的自动化测试

  3. 美团供应链架构

关键字:eav, php, postman, mysql

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部