架構(gòu)設(shè)計(jì):數(shù)據(jù)服務(wù)系統(tǒng)0到1落地實(shí)現(xiàn)方案
一、基于業(yè)務(wù)
數(shù)據(jù)服務(wù)通常有很多種業(yè)務(wù)模式,也就導(dǎo)致系統(tǒng)的架構(gòu)與業(yè)務(wù)都會很復(fù)雜,不同的業(yè)務(wù)都具有自身的能力和復(fù)雜度,數(shù)據(jù)管理本身就是一件不容易的事情,所以在系統(tǒng)架構(gòu)初期都會考慮服務(wù)能力的業(yè)務(wù)場景:
API服務(wù):基于Http模式的數(shù)據(jù)服務(wù),通過請求獲取數(shù)據(jù),例如風(fēng)控模型,評分,反欺詐等各種業(yè)務(wù);
平臺服務(wù):綜合性的服務(wù)能力集成系統(tǒng),客戶的自定義服務(wù)需求很低,具有完整流程的數(shù)據(jù)服務(wù)能力,例如自動化數(shù)字營銷平臺,提供營銷的全流程管理能力;
采集服務(wù):通常客戶以埋點(diǎn)的方式提交相關(guān)點(diǎn)擊事件,采集系統(tǒng)基于全渠道進(jìn)行匯總分析并向客戶反饋;
可視化分析:這里分為兩大塊,數(shù)據(jù)分析與可視化,數(shù)據(jù)可以加載多方數(shù)據(jù)源聯(lián)合分析,基于前端組件做高度自動化分析,例如常見的數(shù)據(jù)洞察系統(tǒng);
工具私有化:基于積累的技術(shù)能力,把數(shù)據(jù)管理的系統(tǒng)直接銷售給客戶,部署在客戶自己本地的服務(wù)上;
數(shù)據(jù)服務(wù)的場景,不同的業(yè)務(wù)需要各自場景下的數(shù)據(jù)支撐,但是不同的業(yè)務(wù)都需要相同的運(yùn)營,結(jié)算,訂單等基礎(chǔ)功能,理解不同的業(yè)務(wù)場景,需要找出共同點(diǎn)與不同點(diǎn),很簡單的思路:相同點(diǎn)在公共服務(wù)中開發(fā),業(yè)務(wù)不同點(diǎn)在獨(dú)立的服務(wù)中開發(fā),方便系統(tǒng)的不斷擴(kuò)展與演進(jìn)。
二、業(yè)務(wù)層架構(gòu)
不同的數(shù)據(jù)服務(wù)能力,最大的不同點(diǎn)就是需要依賴核心數(shù)據(jù)的支撐,從業(yè)務(wù)層面看系統(tǒng)架構(gòu)層,還需要的功能復(fù)雜公共功能,這些需要在架構(gòu)初期就考慮好,不然隨著業(yè)務(wù)發(fā)展很快就要面臨重構(gòu)問題。
客戶運(yùn)營:每個客戶的接入都需要一套完整的流程,服務(wù)說明,計(jì)費(fèi)規(guī)則,合同管理,充值,服務(wù)開通停用,賬單等一系列配套功能,通常都有兩個入口:客戶登錄端,服務(wù)方運(yùn)營端。
支付結(jié)算:功能最復(fù)雜的系統(tǒng)模塊,提供支付能力,例如聚合多個支付渠道,用來解決客戶的充值退款,或者服務(wù)方自己的支付需求,并提供各種結(jié)算賬單的數(shù)據(jù)輸出,對賬平賬能力。
訂單管理:客戶的每次請求,或者每個服務(wù)的使用,產(chǎn)生的計(jì)費(fèi)動作都需要詳細(xì)的訂單記錄,涉及單價,單號,時間很多關(guān)鍵因素,作為結(jié)算的核心依據(jù),也是業(yè)務(wù)數(shù)據(jù)最集中爆發(fā)的地方。
權(quán)限體系:在數(shù)據(jù)服務(wù)體系中,權(quán)限系統(tǒng)的設(shè)計(jì)更側(cè)重解決公司主體層面的需求,不同的商務(wù)團(tuán)隊(duì)負(fù)責(zé)不同的服務(wù)運(yùn)營,客戶管理等,所以需要清晰的體系化權(quán)限管理,給不同的角色的商務(wù)人員分配合理的權(quán)限。
日志集成:在詳細(xì)的日志體系中,正常的業(yè)務(wù)日志數(shù)據(jù)可以用來在服務(wù)異常時的數(shù)據(jù)補(bǔ)全分析,異常的日志數(shù)據(jù)可以給開發(fā)用來分析系統(tǒng)問題和瓶頸不斷的優(yōu)化服務(wù)能力。
基于業(yè)務(wù)場景做好服務(wù)的劃分和設(shè)計(jì),以及公共服務(wù)的基礎(chǔ)構(gòu)建,確保業(yè)務(wù)層的架構(gòu)合理且可擴(kuò)展,是否合理的基本考量就是,不斷的新增業(yè)務(wù)場景是否需要做系統(tǒng)的大刀闊斧的改版,如果服務(wù)能力不斷豐富,系統(tǒng)的改造成本很小,自然架構(gòu)合理。
三、數(shù)據(jù)中心
不同的業(yè)務(wù)服務(wù)場景需要依賴核心數(shù)據(jù)能力,這是服務(wù)賣點(diǎn),通常會把支撐服務(wù)能力的核心數(shù)據(jù)單獨(dú)部署并提供各種服務(wù)場景,通常理解為數(shù)據(jù)中心,同時業(yè)務(wù)服務(wù)自身也會產(chǎn)生各種數(shù)據(jù),這里會根據(jù)服務(wù)的部署方式獨(dú)立存儲。
服務(wù)能力:數(shù)據(jù)中心作為多個業(yè)務(wù)公共依賴,不但要提供數(shù)據(jù)基礎(chǔ)的查詢能力,在處理海量數(shù)據(jù)任務(wù)時,還需要提供一定的調(diào)度和計(jì)算機(jī)制。
部署方式:根據(jù)數(shù)據(jù)特點(diǎn)通常會以集群、分庫分表、OLAP引擎、數(shù)倉等多種方式存儲,并根據(jù)數(shù)據(jù)特點(diǎn)提供統(tǒng)一的服務(wù)能力對業(yè)務(wù)層開放。
數(shù)據(jù)更新:數(shù)據(jù)是需要實(shí)時或者定時更新,數(shù)據(jù)來源通常是經(jīng)過大數(shù)據(jù)計(jì)算和處理后的各種數(shù)據(jù),還有就是業(yè)務(wù)層校驗(yàn)有誤的數(shù)據(jù),或者在使用過程不斷優(yōu)化的數(shù)據(jù)。
數(shù)據(jù)中心的獨(dú)立架構(gòu)部署是非常有必要的操作,大部分的數(shù)據(jù)都是具有聯(lián)動性的,數(shù)據(jù)間的聯(lián)動處理完全不用耦合到業(yè)務(wù)層面,數(shù)據(jù)的流動校正安全性管理等等都可以在數(shù)據(jù)中心統(tǒng)一管理,規(guī)避掉數(shù)據(jù)混合部署帶來的系列復(fù)雜問題。
四、大數(shù)據(jù)底層
數(shù)據(jù)服務(wù)能力的最底層需要海量數(shù)據(jù)處理的能力做支撐,所以用到很多大數(shù)據(jù)組件技術(shù),對數(shù)據(jù)做存儲、計(jì)算、分析、搬運(yùn)等等操作。
數(shù)據(jù)存儲:大數(shù)據(jù)底層最常見的存儲就是文件形式,結(jié)構(gòu)化的數(shù)據(jù)庫存儲,半結(jié)構(gòu)化的日志型文件,還有一些非結(jié)構(gòu)化數(shù)據(jù)。
計(jì)算能力:對于海量數(shù)據(jù)的處理需要依賴各種并行計(jì)算,離線任務(wù),實(shí)時計(jì)算等多種方式,達(dá)到快速處理的目的。
數(shù)據(jù)搬運(yùn):數(shù)據(jù)處理完成之后并不會在底層直接提供服務(wù)能力,通常會把數(shù)據(jù)同步到上面數(shù)據(jù)中心,在對業(yè)務(wù)提供服務(wù)能力,這里搬運(yùn)可以是數(shù)據(jù)輸出,也可能是待處理的數(shù)據(jù)輸入。
大數(shù)據(jù)的底層組件則是系統(tǒng)的核心能力,對數(shù)據(jù)的精準(zhǔn)計(jì)算分析確保服務(wù)的能力,并且不斷的對現(xiàn)有架構(gòu)做自動化和工具化管理,這點(diǎn)非常重要,海量數(shù)據(jù)管理的流程人工介入越多則說明效率越低下,尤其在底層向數(shù)據(jù)中心推送數(shù)據(jù)或者數(shù)據(jù)接收的過程,需要約定好策略保證數(shù)據(jù)安全穩(wěn)定的自動傳輸。
五、整體考慮
對一個復(fù)雜系統(tǒng)的設(shè)計(jì),首先最關(guān)鍵的就是清晰的整理出業(yè)務(wù)模式,對業(yè)務(wù)模式進(jìn)行分析,根據(jù)業(yè)務(wù)特點(diǎn)做系統(tǒng)架構(gòu)可以避免很多彎路,例如上面的數(shù)據(jù)服務(wù)系統(tǒng):
首先從大的層面看,系統(tǒng)拆分業(yè)務(wù)服務(wù),數(shù)據(jù)中心,大數(shù)據(jù)底層能力這三大塊,并且要求各個大模塊之間不存在強(qiáng)耦合關(guān)系,確保模塊之間可以獨(dú)立的擴(kuò)展;
其次確定各個模塊需要的實(shí)現(xiàn)的核心功能,業(yè)務(wù)層保證基本的服務(wù)能力,然后把每個業(yè)務(wù)都需要的基礎(chǔ)功能向下抽取封裝,拆分出業(yè)務(wù)服務(wù)和公共服務(wù),支撐業(yè)務(wù)能力;
然后確定各個模塊之間協(xié)作的方式,例如業(yè)務(wù)與數(shù)據(jù)中心的通信能力,接口標(biāo)準(zhǔn),數(shù)據(jù)安全等細(xì)節(jié),或者數(shù)據(jù)中心與底層大數(shù)據(jù)之間的數(shù)據(jù)搬運(yùn)模式,確保數(shù)據(jù)流通能力;
最后各個模塊具體的細(xì)節(jié)實(shí)現(xiàn),這里需要考量的就是根據(jù)業(yè)務(wù)模式,如果可以選擇相同的組件和架構(gòu)方式,盡量統(tǒng)一架構(gòu)選型和組件依賴,降低不同模塊之間的壁壘;
上述完整的系統(tǒng)架構(gòu)從開始搭建到提供穩(wěn)定的服務(wù)能力,大概耗時七個月的時間,期間不斷的演進(jìn)和升級,并且不斷上線新的服務(wù)模塊并進(jìn)行系統(tǒng)監(jiān)控,直至業(yè)務(wù)服務(wù)相對完善和系統(tǒng)相對穩(wěn)定。
六、源代碼地址
GitHub地址:知了一笑
https://github.com/cicadasmile/spring-cloud-base
GitEE地址:知了一笑
https://gitee.com/cicadasmile/spring-cloud-base




































