途牛原創｜基於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的自動化測試
• 美團供應鏈架構