途牛原创|基于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
蓝色
这番设计,两个益处。
省存储空间。
易动态扩展。
动态表单
我们的常规工作是静态表单,避免在Code Monkey的路,越走越远,我们需要改变。
设计动态表单模型,基本的思路应该是数据和表现显示的分离。抛开表现层,一个表单包含的若干个字段和填写的数据。所谓动态,就是这些字段名称可能改变,数量可能有增减。
配置字段(POI中文名称)
配置中。。。
见证奇迹的时刻。(表单自动生成)
这番设计,两个益处。
猴子做架构了(再也不用写FORM了)。
用户自定义。
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的自动化测试
美团供应链架构
关键字:eav, php, postman, mysql
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!