【文章內(nèi)容簡(jiǎn)介】 位一行，其中 columnFamilyDefinition 是 ColumnFamily 的定義，domainQueryCacheKey 是 ColumnFamily 的 Key,最后使用 putColumn 把一條數(shù)據(jù)放入 Cassandra 內(nèi) 這樣就實(shí)現(xiàn)了使用 Cassandra 作為中間的媒介進(jìn)行數(shù)據(jù)傳輸。系統(tǒng)會(huì)整合所有的需要計(jì)算的數(shù)據(jù)，然后生成一個(gè)專(zhuān)門(mén)的 ID 作為 Key，數(shù)據(jù)的具體屬性作為Column，保存在 Cassandra 的 Context 上， 然后僅僅傳遞給后臺(tái)一個(gè) ID。最后后臺(tái)計(jì)算引擎會(huì)根據(jù)這個(gè) ID 從 Cassandra 中取出相關(guān)的數(shù)據(jù)，然后進(jìn)行計(jì)算，隨后把計(jì)算出來(lái)的結(jié)果也保存在 Cassandra 中。這樣，系統(tǒng) 就不需要與計(jì)算引擎緊緊依賴(lài)，也不會(huì)由于數(shù)據(jù)量大而造成網(wǎng)絡(luò)的阻塞 在風(fēng)險(xiǎn)估值計(jì)算模塊，除了使用 Cassandra提高了系統(tǒng)的容錯(cuò)性和運(yùn)行速度，也是用了多線程技術(shù)提高了系統(tǒng)對(duì)于計(jì)算請(qǐng)求的吞吐量。通過(guò)線程池的原理接受不同的計(jì)算請(qǐng)求然后發(fā)送給不同的接收者，不僅如此依然采用多線程 Future 處理返回的結(jié)果集，進(jìn)一步提高了計(jì)算速度 設(shè)計(jì) 驗(yàn)證模塊 的輸入是用戶(hù)自定義的模擬交易數(shù)據(jù)，經(jīng)過(guò)不同驗(yàn)證規(guī)則的驗(yàn)證，輸出則是驗(yàn)證報(bào)表。在 V1 版本中，由于支持的金融產(chǎn)品種類(lèi)不多，在驗(yàn)證模塊實(shí)現(xiàn)的過(guò)程中，更多的是使用硬編碼的形式進(jìn)行邏輯處理。代碼中存在著過(guò)多的ifelse。隨著系統(tǒng)支持的產(chǎn)品和業(yè)務(wù)需求的不斷增加，使得目前的驗(yàn)證模塊 難 7 以編碼和維護(hù)，而且其結(jié)構(gòu)也不適于目前需求。目前驗(yàn)證模塊的主要需求是基于以下幾點(diǎn) 1 驗(yàn)證的級(jí)別。其中包括 Hard 警告和 Soft 警告。 Hard 警告表示數(shù)據(jù)的錯(cuò)誤致命的 ,用戶(hù)必須對(duì)數(shù)據(jù)進(jìn)行相應(yīng)的修改，否則無(wú)法進(jìn)行下一步操作。而 Soft警告是告訴 用戶(hù)有些數(shù)據(jù)的輸入不太正確，但這些數(shù)據(jù)不會(huì) 影響下一步的操作。這些警告將以報(bào)表形式通知用戶(hù) 2 產(chǎn)品的多樣化。隨著產(chǎn)品的增加，驗(yàn)證規(guī)則也呈幾何式遞增，如果繼續(xù)使用硬編碼 的形式，不僅難以開(kāi)發(fā)，而且將來(lái)也難以維護(hù)，不適合系統(tǒng)的發(fā)展空間 3 設(shè)計(jì)更靈活。將來(lái)有可能需要提供給用戶(hù)自定義驗(yàn)證規(guī)則的頁(yè)面。也就是說(shuō)驗(yàn)證規(guī)則處理除了需要支持正常的驗(yàn)證處理，還需要支持動(dòng)態(tài)的修改。這些將來(lái)的需求都要在目前的設(shè)計(jì)中加以考慮，其中有一個(gè)難點(diǎn)，就是如何保存這些動(dòng)態(tài)修改的數(shù)據(jù)以及 如何同步修改后的數(shù)據(jù) 根據(jù)對(duì) V1 版本的研究，目前的結(jié)構(gòu)已然不適 合目前的需求和將來(lái)的變動(dòng)，所以驗(yàn)證模塊的重構(gòu)勢(shì)在必行。在 V1 版本中，主要使用了 ApachemandChain來(lái)實(shí)現(xiàn)驗(yàn)證模塊，根據(jù)不同的條件，遍歷不同的 CommandChain(命令鏈 )。VaREligibleService 是驗(yàn)證的接口，在實(shí)現(xiàn)中定義了某個(gè)產(chǎn)品類(lèi)型和相關(guān)命令鏈的映射 VaRCommandMap，每一條命令鏈都會(huì)服務(wù)于某一個(gè)特定的產(chǎn)品并將驗(yàn)證的結(jié)果返回給接口并放到一個(gè)結(jié)果映射集中，最終解析這個(gè)結(jié)果映射集生成驗(yàn)證報(bào)告。其中驗(yàn)證規(guī)則都是硬編碼在系統(tǒng)里的，而且需要遍歷數(shù)據(jù)源同步的進(jìn)行驗(yàn)證。這里可以 得出，驗(yàn)證需要遍歷輸入數(shù)據(jù)源然后等待每一筆數(shù)據(jù)的結(jié)果，時(shí)間比較長(zhǎng)；因?yàn)橛簿幋a的問(wèn)題，使得產(chǎn)品驗(yàn)證的規(guī)則難以維護(hù)，無(wú)法抽象出通用的驗(yàn)證規(guī)則，基本無(wú)法實(shí)現(xiàn)數(shù)據(jù)驗(yàn)證規(guī)則的動(dòng)態(tài)修改 根據(jù)系統(tǒng)要求和業(yè)務(wù)需求，對(duì)系統(tǒng)中 驗(yàn)證模塊進(jìn)行了重構(gòu)。主要是基于SpringSPEL 表達(dá)式語(yǔ)言的一種驗(yàn)證。 Spring 表達(dá)式語(yǔ)言是一個(gè)功能強(qiáng)大的表達(dá)式語(yǔ)言，它支持在運(yùn)行時(shí)查詢(xún)和操縱的對(duì)象圖。驗(yàn)證模塊所有的驗(yàn)證最后將解析成 SpringSPEL 表達(dá)式進(jìn)行驗(yàn)證。首先會(huì)定義一個(gè)模板類(lèi)（ FilterTemplate） ,把所有產(chǎn)品驗(yàn)證規(guī)則抽象出來(lái)，做集中處理。這些驗(yàn)證規(guī)則會(huì)全部保存在數(shù)據(jù)庫(kù)并在系統(tǒng)啟動(dòng)的時(shí)候加載到 Cassandra 內(nèi)。 Build 類(lèi)，每一個(gè)產(chǎn)品都會(huì)有一個(gè)Build 類(lèi)，里面會(huì)定義其需要的所有驗(yàn)證規(guī)則，有效值以及錯(cuò)誤提示消息，規(guī)則 8 的定義必須與 Template 里定義的互相匹配。這些針對(duì)每個(gè)產(chǎn)品的驗(yàn)證規(guī)則會(huì)通過(guò) JavaAnnotation 解析成 XML 保存在數(shù)據(jù)庫(kù)內(nèi)，并加載到 Cassandra 內(nèi)。這里的思路基本是在 Annotation 基礎(chǔ)上，定義一套驗(yàn)證機(jī)制，針對(duì)不同 驗(yàn)證建立一系列內(nèi)置的驗(yàn)證規(guī)則，通過(guò) JAXBAnnotation 轉(zhuǎn)成 XML 格式保存在數(shù)據(jù)庫(kù)中，同時(shí)針對(duì)不同產(chǎn)品的有效值、驗(yàn)證值也根據(jù)產(chǎn)品對(duì)象上的 Annotation，通過(guò)JAXBAnnotation 轉(zhuǎn)成產(chǎn)品的樣板。這樣根據(jù)驗(yàn)證規(guī)則和產(chǎn)品樣板有效地解決了驗(yàn)證多樣化、驗(yàn)證規(guī)則多的情況。在進(jìn)行驗(yàn)證處理的時(shí)候，會(huì)把每一個(gè)產(chǎn)品的驗(yàn)證規(guī)則（ XML）和模板進(jìn)行匹配，最終解析成 SpringSPEL 表達(dá)式進(jìn)行處理。因?yàn)槊恳粋€(gè)產(chǎn)品的驗(yàn)證沒(méi)有依賴(lài)關(guān)系，使用了線程 池來(lái)調(diào)用驗(yàn)證服務(wù)來(lái)驗(yàn)證每一種產(chǎn)品，并通過(guò)線程的返回值組裝成可讀 報(bào)表。對(duì)于動(dòng)態(tài)修改驗(yàn)證規(guī)則，則是通過(guò)直接修改數(shù)據(jù)庫(kù)值并放到 Cassandra 內(nèi)來(lái)做到的，在引入 Cassandra 后， Cassandra會(huì)根據(jù)不同的策略進(jìn)行數(shù)據(jù)同步。所以在同步機(jī)制上不會(huì)存在問(wèn)題，同時(shí)由于Cassandra 節(jié)點(diǎn)獲取不同策略，使得系統(tǒng)在獲取數(shù)據(jù)可以實(shí)現(xiàn)一致性上。這樣設(shè)計(jì)的好處在于：驗(yàn)證規(guī)則集中化，便于管理；產(chǎn)品特定的規(guī)則邏輯獨(dú)立，互相沒(méi)有依賴(lài)；規(guī)則命名規(guī)范統(tǒng)一；數(shù)據(jù)規(guī)則最終保存在數(shù)據(jù)庫(kù)內(nèi)，拋棄了代碼級(jí)別的規(guī)則定義，便于動(dòng)態(tài)更改； Cassandra 的使用則加快了運(yùn)行速度，以及正常驗(yàn)證處理和動(dòng)態(tài)改動(dòng)之間的隔離 重構(gòu)后的驗(yàn)證模塊， ValidationService 是驗(yàn)證邏輯的入口，主要負(fù)責(zé)對(duì)輸入交易數(shù)據(jù)進(jìn)行分類(lèi)，根據(jù)交易產(chǎn)品的類(lèi)型，將交易數(shù)據(jù)放置在一個(gè) Map 對(duì)象內(nèi)。不同產(chǎn)品之間的驗(yàn)證沒(méi)有直接關(guān)系或者依賴(lài)，所以說(shuō)每一個(gè)產(chǎn)品的驗(yàn)證相對(duì)獨(dú)立。使用了一個(gè)線程池概念，線程池大小目前定義為產(chǎn)品種類(lèi)的數(shù)量，線程定義為實(shí)現(xiàn) Callable 接口 ,目的是為獲取返回值。 ExecutorCompletionService 可以將已完成任務(wù)與未完成的任務(wù)分離出來(lái) ,ExecutorCompletionService 會(huì)把那些已經(jīng)完成的任務(wù)的結(jié)果放在 LinkedBlockQueue 隊(duì)列上，并使用 take 方法獲取LinkedBlockQueue 隊(duì)列上任務(wù)結(jié)果。調(diào)用 submit 方法提交驗(yàn)證任務(wù)，其中使用ValidationProcess 根據(jù) Build 和 FilterTemplate 互相協(xié)作生成出最終的返回值。完成的任務(wù)會(huì)把返回值以 Future 類(lèi)的形式保存在隊(duì)列上，通過(guò) take 方法可以獲取到這個(gè) Future 對(duì)象，如果 take 方法獲取返回的結(jié)果與提交請(qǐng)求的數(shù)量不一致，說(shuō)明還有線程正在執(zhí)行，繼續(xù)等待。在驗(yàn)證過(guò)程中把不同的產(chǎn)品放置在不 9 同的線程中運(yùn)行，每一個(gè)線程會(huì)根據(jù)產(chǎn)品類(lèi)型獲取相關(guān)的驗(yàn)證服務(wù)，并最終把驗(yàn)證結(jié)果保 存到數(shù)據(jù)庫(kù)中并通過(guò) Future 類(lèi)把結(jié)果返回給 ValidationService。ValidationService 最后對(duì)數(shù)據(jù)進(jìn)行整合，生成相關(guān) 驗(yàn)證報(bào)告