途牛原創｜基於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的自動化測試

• 美團供應鏈架構