背景及需求

之前提到我們模型驅(qū)動的實現(xiàn)選擇的是解釋型,需要模型的元數(shù)據(jù)信息,在接到請求后動態(tài)處理邏輯.

此外,應用的通用能力中還包括:頁面dsl查詢,菜單查詢等.

而且后期加入觸發(fā)器,用戶自定義api后,這些元數(shù)據(jù)也需要提供查詢服務.

所以我們需要一個元數(shù)據(jù)模塊,需要提供兩個基礎(chǔ)功能:加載元數(shù)據(jù)和提供元數(shù)據(jù)查詢服務.

??特殊說明:最開始的時候我們支持兩種源:本地和遠程,后期防止單獨部署網(wǎng)絡隔離問題把遠程邏輯去掉了.

第一版迭代處理的元數(shù)據(jù)有:模型,頁面dsl及菜單,后期加入觸發(fā)器,用戶自定義api,攔截器等,我們今天按照第一版迭代來討論設(shè)計及實現(xiàn).

模型元數(shù)據(jù)的需求是緩存一批模型元數(shù)據(jù),可以根據(jù)模型name獲取模型的具體信息.

頁面dsl的需求是緩存一批頁面dsl,根據(jù)dslId獲取頁面dsl信息.

菜單的需求比較簡單,緩存菜單列表和獲取菜單列表.

上邊說的是功能性需求,接著說下非功能性需求:

?性能,元數(shù)據(jù)的查詢特別頻繁,必須保證高性能,通常會使用緩存,這也是我們這個模塊的核心價值之一.

?數(shù)據(jù)要準確,從MetaStore獲取的數(shù)據(jù)不能有問題和差異.

?易于擴展,首先元數(shù)據(jù)不僅僅有根據(jù)id獲取的需求,可能還有其他查詢需求;其次后期加入其他元數(shù)據(jù)存儲的時候要改動小.

初版設(shè)計

設(shè)計思路

上邊說了需求,下邊我們開始正式的設(shè)計,先選一個具體場景來說:模型元數(shù)據(jù).

為了高性能肯定要使用緩存,開發(fā)中常用緩存方式有兩種:遠程和本地.

遠程通常使用NoSql的中間件,如Redis和MemCache,在這種場景下肯定不適合.

該場景最適合的方式是使用內(nèi)存緩存,查詢邏輯簡單:根據(jù)name或者id獲取,所以直接使用map的數(shù)據(jù)結(jié)構(gòu)即可.

元數(shù)據(jù)是在應用啟動時加載,不會再有變動(后期熱部署此處需要重構(gòu)),利用spring的啟動機制,也不用考慮線程安全問題,直接使用HashMap就可以,這里應該是利用的jvm的Happens-before原則.

到此,我們確定了緩存的數(shù)據(jù)結(jié)構(gòu)及接口:

??包含一個內(nèi)部變量cache是HashMAP類型,一個內(nèi)部方法去加載數(shù)據(jù),對外一個接口方法getByKey,功能比較內(nèi)聚,類設(shè)計是沒問題的,下邊我們看下具體的邏輯.

詳細邏輯

getByKey的邏輯是從緩存變量cache中獲取,直接使用map的get方法,不用贅述(此處有坑,下文會有說明),主要看下load加載數(shù)據(jù)的方法

??主要邏輯:

1.讀取指定的目錄,可以從配置中獲取,獲取不到使用默認值:models,讀取出目錄下所有文件.

2.開始循環(huán)處理每個文件,詳細步驟:

1.讀取出文件內(nèi)容:json格式.

2.json數(shù)據(jù)轉(zhuǎn)換成Model對象.

3.把Model對象放入到cache中,key是modelName,value是Model對象.

抽象

當具體方案確定后,如上邊所述的邏輯實現(xiàn)起來并不復雜,甚至可以說是簡單.

但我們在整體看下會發(fā)現(xiàn):模型和頁面dsl的元數(shù)據(jù)緩存邏輯相似度特別高!

再回頭看下上邊的邏輯流程圖,紫色的部分都是完全相同的,差異只存在與紅色的兩塊邏輯:"讀取指定目錄"和"解析成對象",我們可以把公共的邏輯抽象出去,做成抽象的父類讓子類去繼承,利用了繼承的代碼復用的場景,這是一個典型的模板模式的應用場景.

簡單說下模板模式的定義:在一個方法中定義一個算法骨架,并將某些步驟推遲到子類中實現(xiàn),讓子類在不改變算法整體結(jié)構(gòu)的情況下,重新定義算法中的某些步驟.

結(jié)合我們的場景來說下:算法骨架就是整體的加載數(shù)據(jù)流程和獲取元數(shù)據(jù)方法,子類(ModelMetaStore和PageMetaModel)需要實現(xiàn)骨架中的兩個擴展方法:"讀取指定目錄"和"解析成對象".

第一版設(shè)計重構(gòu)后,類圖如下

??說明:

?模型數(shù)據(jù)文件和頁面dsl文件都放到各自的目錄:models和dsls下,上邊兩個目錄是默認的,但可自定義配置.

?模型數(shù)據(jù)目錄下的文件類型都是json,文件名是模型名稱.

?頁面dsl目錄下的文件類型也都是json,文件名是page的id.

?抽象出一個父類AbstractDataStore<R>,泛型是子類的對象類型,包含核心邏輯和骨架.內(nèi)部有一個map類型的cache變量和一個load私有函數(shù)用于加載數(shù)據(jù),此外提供了兩個抽象方法,一個是directoryName:獲取文件所在目錄,另一個方式是parse:根據(jù)文件內(nèi)容解析成單個對象,這兩個抽象方法需要子類實現(xiàn),最后還有一個根據(jù)key獲取元數(shù)據(jù)的公共方法.

?ModelMetaStore和PageDataStore繼承了父類AbstractDataStore,泛型分別是ModelEntity和PageEntity,實現(xiàn)上述的兩個抽象方法:directoryName和parse,兩個方法的邏輯都特別簡單,第一個直接返回自己的目錄,第二個利用fastjson把字符串解析成指定對象.

組合

上面把模型和頁面的元數(shù)據(jù)緩存設(shè)計完成了,還有一個菜單的元數(shù)據(jù)緩存.

菜單的元數(shù)據(jù)結(jié)構(gòu)與上邊的兩個差異很大,每個應用中只會有一個菜單的元數(shù)據(jù)文件,所以無法使用上邊的模板模式,我們需要單獨去處理它的邏輯.

實際上菜單的元數(shù)據(jù)加載邏輯和其他兩個(更準確的說應該是抽象類)有一部分重疊:讀取文件的內(nèi)容,這里面需要判斷文件是否為空,讀取內(nèi)容字符串及io讀取報錯等.

這部分邏輯可以復制出來放到菜單的元數(shù)據(jù)緩存類中,但實際違背了DRY 原則:不要寫重復的代碼.

那么該如何解決這塊重復代碼的問題呢?有兩個方案:

第一個方案:使用繼承.

在AbstractDataStore<R>上再加一層抽象類,里面只包括一個方法:讀取文件內(nèi)容,新的菜單元數(shù)據(jù)緩存也繼承這個抽象類,把讀取文件內(nèi)容的方法移到最上層,類結(jié)構(gòu)圖如下:

??這個方案有兩個問題:

1.繼承層次太深,邏輯有點亂

2.最上層的抽象類很難起名

AbstractDataStore和MenuDataCache繼承LoadFileData從代碼上是可行的,但邏輯上不太合理,抽象繼承是is-a的關(guān)系,這里需要給LoadFileData一個合適的名字才滿足設(shè)計規(guī)范,而這個名字并不太好起.

第一個方案:使用組合.

這個方案實際上更合理一些,面向?qū)ο笤O(shè)計有一個原則:組合優(yōu)于繼承.

可以把讀取文件內(nèi)容的邏輯獨立出去作為一個新的幫助類DataLoadSupport,AbstractDataStore和MenuDataCache引入它就可以解決代碼重復問題.

初始化加載

上一步幾乎完成了所有邏輯,但是少了數(shù)據(jù)加載的觸發(fā),這個需要放到服務啟動的時候觸發(fā).

我們利用了spring的ApplicationListener,有一個細節(jié)問題要確定:如何實現(xiàn)ApplicationListener,是每一個類中單獨實現(xiàn),還是統(tǒng)一實現(xiàn).

為了邏輯的統(tǒng)一,還有后期其他服務需要啟動時加載的考慮,我選擇了統(tǒng)一實現(xiàn),具體邏輯和類圖如下:

具體邏輯:

?新增一個接口StartLoadListener:啟動加載監(jiān)聽,啟動時需要被觸發(fā)的操作類實現(xiàn)該接口.

?AbstractDataStore和MenuDataCache實現(xiàn)StartLoadListener接口,標記需要在應用啟動時觸發(fā),應用啟動后觸發(fā)自己的load方法.

?新增StartLoadListenerManager類,里面會自動注入所有實現(xiàn)StartLoadListener接口的對象,該類同時實現(xiàn)了spring的ApplicationListener接口,在spring啟動后被觸發(fā),觸發(fā)后調(diào)用所有的StartLoadListener的startLoad方法,完成所有需要啟動時觸發(fā)的操作.

類圖:

第二版設(shè)計

如文章開頭所說,從元數(shù)據(jù)緩存中使用key從map中獲取信息后直接返回是有問題的,開發(fā)完的時候也意識到了一些,但沒有去處理,直到某天雷真的炸了.

先說下問題出現(xiàn)的過程,初期功能簡單,低代碼平臺生成的應用都跑的好好的,迭代數(shù)次版本后,新增了權(quán)限能力:支持簡單的數(shù)據(jù)權(quán)限和菜單權(quán)限.

菜單權(quán)限的處理邏輯大體如下:

?從菜單緩存中直接獲取緩存的數(shù)據(jù).

?如果菜單列表為空,直接返回給客戶端空的列表,結(jié)束菜單查詢.

?查詢用戶有權(quán)限的菜單編碼列表(set),數(shù)據(jù)源頭是科技權(quán)限系統(tǒng),初期比較粗暴代碼耦合到菜單權(quán)限代碼中,但這不是今天討論的重點,后邊的文章會講到權(quán)限模塊的重構(gòu).

?如果用戶有權(quán)限的菜單編碼列表(set)為空,直接返回給客戶端空的列表,結(jié)束菜單查詢.

?遞歸處理獲取的緩存菜單,如果編碼在權(quán)限系統(tǒng)返回的編碼列表(set)中,遞歸處理子節(jié)點列表(菜單是樹形的),否則直接刪除該節(jié)點,返回到上級遞歸.

?循環(huán)上步操作,直到所有菜單節(jié)點校驗完成.

??邏輯并不太復雜,開發(fā)的時候特意重點關(guān)注了遞歸和權(quán)限系統(tǒng)查詢,本地測試沒什么問題,部署到測試環(huán)境也沒發(fā)現(xiàn)什么問題.

但最后要上線前測試發(fā)現(xiàn)了一個問題:切換賬號后,菜單不對,有權(quán)限的菜單變少了!!!

定位問題的時候,先排查權(quán)限系統(tǒng)的返回,結(jié)果沒問題;在把數(shù)據(jù)拿到本地走mock測試也沒有問題;在最后debug的時候發(fā)現(xiàn)了真正的問題,也就是之前意識到但沒有解決的問題:在菜單權(quán)限邏輯中操作的菜單列表和菜單元數(shù)據(jù)緩存的菜單列表是同一個對象!

在某個用戶處理完自己的權(quán)限菜單邏輯后,可能會移除一些節(jié)點,下一個用戶在獲取菜單的時候他的菜單元數(shù)據(jù)可能就是被處理過(在權(quán)限處理中被移除)的了.

元數(shù)據(jù)存儲實際上類似原型模型,原型模式的定義:如果對象的創(chuàng)建成本比較大,而同一個類的不同對象之間差別不大（大部分字段都相同）,在這種情況下,我們可以利用對已有對象進行復制（或者叫拷貝）的方式來創(chuàng)建新對象,以達到節(jié)省創(chuàng)建時間的目的.

我的實現(xiàn)只做了緩存,但沒有實現(xiàn)復制,使得同一對象被多個場景操作.最后導致數(shù)據(jù)的錯誤及混亂.

而復制一般也叫拷貝,分為兩類:

?淺拷貝:只會拷貝對象中的基本數(shù)據(jù)類型的數(shù)據(jù)（比如,int、long）,以及引用對象的內(nèi)存地址,不會遞歸地拷貝引用對象本身.

?深拷貝:不僅僅會復制索引，還會復制數(shù)據(jù)本身

我們肯定要選擇深拷貝,但出現(xiàn)問題的時候已經(jīng)有幾個元數(shù)據(jù)存儲了,特別是菜單數(shù)據(jù)的結(jié)構(gòu)復雜(樹形),短時間沒法完成深度復制,市面上的工具類通常只能復制一層,無法自動完成深層次的復制.

當時的解決方案比較粗暴:問題出現(xiàn)在菜單,那只在菜單權(quán)限處理的時候做手腳:定義一個新的菜單列表,有權(quán)限的菜單深度復制當前對象后加入到list;遞歸處理子節(jié)點.繼續(xù)重新定義一個list設(shè)置為上層節(jié)點的子節(jié)點,有權(quán)限的子節(jié)點放入到新的list,遞歸循環(huán)上述步驟.

表象的bug解決了,但實際問題還沒有解決,只是被遮蓋了,就拿菜單來說,我是在權(quán)限服務那處理了,但如果在其他地方使用呢,一樣會出現(xiàn)數(shù)據(jù)缺失的錯誤.

更嚴重的是在觸發(fā)器中提供了獲取模型元數(shù)據(jù)的接口,開發(fā)者獲取模型元數(shù)據(jù)后如果進行了修改,導致的錯誤會更加嚴重,也更加的難已排查,因為模型元數(shù)據(jù)的變更會導致模型通用接口邏輯的缺失或混亂,所以深度復制的功能一定要實現(xiàn).

深度復制的實現(xiàn)一般有兩種:

第一種序列化后反序列化,比如把數(shù)據(jù)序列化成json,在反序列化回來.該方案有兩個問題:(1)繼承的子類多態(tài)容易出問題(2)序列化和反序列化是有性能消耗的,在此處方案并不適合.

第二種是遞歸處理:遇到Collection和Map及javabean類型,進行遞歸的深度拷貝.該方案開發(fā)成本稍高,大量的遞歸需要特殊注意,此外一些特殊的bean也無法復制:如內(nèi)部變量是final類型,或者只支持構(gòu)造函數(shù)傳入.

我們使用的是第二種,這種方法純粹是算法類,不再細說,在中間碰到了一個坑:我有一個習慣遇到一些沒有數(shù)據(jù)需要返回空的list的時候我會直接使用Collections.emptyList(),在深度復制的時候根據(jù)構(gòu)造函數(shù)新建對象會直接報錯,修復方案是:如果是list或者map不是常見的對象類型直接使用常見的對象ArrayList和HashMap.

??實際上還有一種方案能解決數(shù)據(jù)修改問題,使用不變對象,不變對象就是對象在創(chuàng)建后,不可以被修改:沒有set方法,且內(nèi)部變量不會暴露,需要注意的是,內(nèi)部變量也要進行保護:不變或者深拷貝.

作者：京東科技 吳籽良

來源：京東云開發(fā)者社區(qū) 轉(zhuǎn)載請注明來源