前言
有人說過：“在以業(yè)務(wù)及運(yùn)營驅(qū)動的互聯(lián)網(wǎng)公司，唯一不變的就是業(yè)務(wù)需求的不斷變化”。作為在一個業(yè)務(wù)快速發(fā)展的互聯(lián)網(wǎng)公司的技術(shù)團(tuán)隊(duì)，尤其是公司的業(yè)務(wù)模式開始逐漸地穩(wěn)定時，應(yīng)該越來越注重“技術(shù)沉淀” --將各業(yè)務(wù)系統(tǒng)中的某些“通用能力”平臺化/中臺化（如，貨&車源信息的檢索平臺、數(shù)據(jù)中臺（產(chǎn)出諸如供需模型、‘相似度計(jì)算’模型實(shí)時計(jì)算的數(shù)據(jù)，供排序、推薦系統(tǒng)使用）、搜索與推薦策略平臺、交易引擎等等, ），且隨著系統(tǒng)的不斷深入，你會發(fā)現(xiàn)，這些系統(tǒng)有著諸多的‘架構(gòu)’相似之處。也唯有此，作為“兵工廠”的技術(shù)團(tuán)隊(duì)，才能在業(yè)務(wù)變化需求中快速組裝、提供源源不斷的“武器保障”。
01. 一個‘簡單’的數(shù)據(jù)產(chǎn)品架構(gòu)，是數(shù)據(jù)中臺、貨&車源搜索引擎的微觀版
這個數(shù)據(jù)產(chǎn)品的需求說起來比較簡單也很常見（相信每個公司都有一個類似的BI報(bào)表系統(tǒng)給各個‘老大’、運(yùn)營、產(chǎn)品看App端的用戶指標(biāo)變化、App界面中各‘元素’的流量變化），本質(zhì)上是Web端需要基于Echart 庫將App產(chǎn)品端的各個請求入口的流量數(shù)據(jù)，在服務(wù)端進(jìn)行統(tǒng)計(jì)計(jì)算輸出各個業(yè)務(wù)指標(biāo)（如，PV，UV，留存，轉(zhuǎn)化率等）后，以各種圖形報(bào)表展現(xiàn)。Echart Sample 如圖（真實(shí)產(chǎn)品的后端界面由于業(yè)務(wù)敏感，暫不貼出來了）：
其中，需求的復(fù)雜點(diǎn)（“相對來看”）在于，
- 業(yè)務(wù)數(shù)據(jù)指標(biāo)隨著產(chǎn)品的需求變化會越來越多（即，增加新的業(yè)務(wù)指標(biāo)，比如新增的數(shù)據(jù)主題，車貨匹配類、交易類、評論等等，都會有各自的指標(biāo)類別及計(jì)算）
- 前端展示的Echart 圖形類別也會不斷變化（可能為不同的數(shù)據(jù)指標(biāo)新增折線圖、餅圖、柱狀圖，亦或在現(xiàn)有圖形上增加新的維度）
因此，在后端的系統(tǒng)設(shè)計(jì)時，有如下架構(gòu)決策與實(shí)現(xiàn)：
- 服務(wù)端的數(shù)據(jù)查詢接口（當(dāng)各個報(bào)表圖形做數(shù)據(jù)查詢調(diào)用時）保持不變（即一個接口承接所有不同種類的數(shù)據(jù)查詢，減輕前端開發(fā)復(fù)雜度）
- 服務(wù)端查詢邏輯的編碼實(shí)現(xiàn)，采用‘事務(wù)腳本’設(shè)計(jì)模式，將查詢過程抽象成 -- ‘入?yún)⒉樵儣l件’的解析與轉(zhuǎn)換、‘SQL查詢模板的映射與變量替換’、‘SQL’執(zhí)行、‘抽取查詢結(jié)果集’，‘響應(yīng)數(shù)據(jù)補(bǔ)齊’、‘結(jié)果集排序’這幾個步驟.?
由此可以看出，從系統(tǒng)架構(gòu)角度，無論是這個簡單的BI報(bào)表系統(tǒng)，還是承接線上各業(yè)務(wù)應(yīng)用的‘?dāng)?shù)據(jù)中臺’系統(tǒng)（注：這類系統(tǒng)的成功踐行者可以參見阿里的數(shù)據(jù)平臺，有本書對此講的比較好《阿里巴巴大數(shù)據(jù)實(shí)踐》）、亦或‘貨&車’源信息檢索中臺，均有有很大的共通之處，如：
- 源數(shù)據(jù)可以任由業(yè)務(wù)方變化，服務(wù)層維護(hù)數(shù)據(jù)的元模型定義（元模型定義可能不同），而編程實(shí)現(xiàn)則基于元模型。舉個例子，‘?dāng)?shù)據(jù)中臺’里的元模型可以為邏輯表名稱、邏輯表可查詢字段、索引字段、過濾字段、物理數(shù)據(jù)源類型、物理庫、物理表....; ‘貨&車’源信息檢索中臺的元模型可以定義為‘索引名模板’、'索引時間后綴'、'索引Doc必填字段 - 如type: Cargo / Truck等等’, ‘索引Doc自定義檢索字段’ )
- 過濾與排序的DSL可配置，支持過濾條件與排序邏輯腳本化（如Groovy腳本）。報(bào)表系統(tǒng)中過濾與排序設(shè)置是在DB中存了一份JSON定義，定義了按哪個字段進(jìn)行過濾補(bǔ)齊以及排序，返回響應(yīng)數(shù)據(jù)時，按配置解析執(zhí)行；同樣的思想，也可以放到檢索平臺，在過濾與排序時，由端來傳入DSL，且可以引用和映射到后端填入的Groovy腳本來執(zhí)行過濾與排序的邏輯
可見，一旦這樣來設(shè)計(jì)實(shí)現(xiàn)，服務(wù)層的‘代碼擴(kuò)張’將是‘縱向’的，而‘橫向擴(kuò)張’的業(yè)務(wù)代碼將越來越少（侵入性降低，不會再見到服務(wù)層代碼里面各種業(yè)務(wù)VO對象了），從而也就能快速的支持業(yè)務(wù)擴(kuò)展與變化了。
“技術(shù)沉淀”后續(xù)系列文章，計(jì)劃從實(shí)際業(yè)務(wù)中的一些具有代表性的案例說開去。自我期待一下...
