[[383299]]

一、基于業(yè)務(wù)

數(shù)據(jù)服務(wù)通常有很多種業(yè)務(wù)模式，也就導(dǎo)致系統(tǒng)的架構(gòu)與業(yè)務(wù)都會(huì)很復(fù)雜，不同的業(yè)務(wù)都具有自身的能力和復(fù)雜度，數(shù)據(jù)管理本身就是一件不容易的事情，所以在系統(tǒng)架構(gòu)初期都會(huì)考慮服務(wù)能力的業(yè)務(wù)場(chǎng)景：

API服務(wù)：基于Http模式的數(shù)據(jù)服務(wù)，通過(guò)請(qǐng)求獲取數(shù)據(jù)，例如風(fēng)控模型，評(píng)分，反欺詐等各種業(yè)務(wù)；

平臺(tái)服務(wù)：綜合性的服務(wù)能力集成系統(tǒng)，客戶的自定義服務(wù)需求很低，具有完整流程的數(shù)據(jù)服務(wù)能力，例如自動(dòng)化數(shù)字營(yíng)銷平臺(tái)，提供營(yíng)銷的全流程管理能力；

采集服務(wù)：通?？蛻粢月顸c(diǎn)的方式提交相關(guān)點(diǎn)擊事件，采集系統(tǒng)基于全渠道進(jìn)行匯總分析并向客戶反饋；

可視化分析：這里分為兩大塊，數(shù)據(jù)分析與可視化，數(shù)據(jù)可以加載多方數(shù)據(jù)源聯(lián)合分析，基于前端組件做高度自動(dòng)化分析，例如常見(jiàn)的數(shù)據(jù)洞察系統(tǒng)；

工具私有化：基于積累的技術(shù)能力，把數(shù)據(jù)管理的系統(tǒng)直接銷售給客戶，部署在客戶自己本地的服務(wù)上；

數(shù)據(jù)服務(wù)的場(chǎng)景，不同的業(yè)務(wù)需要各自場(chǎng)景下的數(shù)據(jù)支撐，但是不同的業(yè)務(wù)都需要相同的運(yùn)營(yíng)，結(jié)算，訂單等基礎(chǔ)功能，理解不同的業(yè)務(wù)場(chǎng)景，需要找出共同點(diǎn)與不同點(diǎn)，很簡(jiǎn)單的思路：相同點(diǎn)在公共服務(wù)中開(kāi)發(fā)，業(yè)務(wù)不同點(diǎn)在獨(dú)立的服務(wù)中開(kāi)發(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)問(wèn)題。

客戶運(yùn)營(yíng)：每個(gè)客戶的接入都需要一套完整的流程，服務(wù)說(shuō)明，計(jì)費(fèi)規(guī)則，合同管理，充值，服務(wù)開(kāi)通停用，賬單等一系列配套功能，通常都有兩個(gè)入口：客戶登錄端，服務(wù)方運(yùn)營(yíng)端。

支付結(jié)算：功能最復(fù)雜的系統(tǒng)模塊，提供支付能力，例如聚合多個(gè)支付渠道，用來(lái)解決客戶的充值退款，或者服務(wù)方自己的支付需求，并提供各種結(jié)算賬單的數(shù)據(jù)輸出，對(duì)賬平賬能力。

訂單管理：客戶的每次請(qǐng)求，或者每個(gè)服務(wù)的使用，產(chǎn)生的計(jì)費(fèi)動(dòng)作都需要詳細(xì)的訂單記錄，涉及單價(jià)，單號(hào)，時(shí)間很多關(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)營(yíng)，客戶管理等，所以需要清晰的體系化權(quán)限管理，給不同的角色的商務(wù)人員分配合理的權(quán)限。

日志集成：在詳細(xì)的日志體系中，正常的業(yè)務(wù)日志數(shù)據(jù)可以用來(lái)在服務(wù)異常時(shí)的數(shù)據(jù)補(bǔ)全分析，異常的日志數(shù)據(jù)可以給開(kāi)發(fā)用來(lái)分析系統(tǒng)問(wèn)題和瓶頸不斷的優(yōu)化服務(wù)能力。

基于業(yè)務(wù)場(chǎng)景做好服務(wù)的劃分和設(shè)計(jì)，以及公共服務(wù)的基礎(chǔ)構(gòu)建，確保業(yè)務(wù)層的架構(gòu)合理且可擴(kuò)展，是否合理的基本考量就是，不斷的新增業(yè)務(wù)場(chǎng)景是否需要做系統(tǒng)的大刀闊斧的改版，如果服務(wù)能力不斷豐富，系統(tǒng)的改造成本很小，自然架構(gòu)合理。

三、數(shù)據(jù)中心

不同的業(yè)務(wù)服務(wù)場(chǎng)景需要依賴核心數(shù)據(jù)能力，這是服務(wù)賣點(diǎn)，通常會(huì)把支撐服務(wù)能力的核心數(shù)據(jù)單獨(dú)部署并提供各種服務(wù)場(chǎng)景，通常理解為數(shù)據(jù)中心，同時(shí)業(yè)務(wù)服務(wù)自身也會(huì)產(chǎn)生各種數(shù)據(jù)，這里會(huì)根據(jù)服務(wù)的部署方式獨(dú)立存儲(chǔ)。

服務(wù)能力：數(shù)據(jù)中心作為多個(gè)業(yè)務(wù)公共依賴，不但要提供數(shù)據(jù)基礎(chǔ)的查詢能力，在處理海量數(shù)據(jù)任務(wù)時(shí)，還需要提供一定的調(diào)度和計(jì)算機(jī)制。

部署方式：根據(jù)數(shù)據(jù)特點(diǎn)通常會(huì)以集群、分庫(kù)分表、OLAP引擎、數(shù)倉(cāng)等多種方式存儲(chǔ)，并根據(jù)數(shù)據(jù)特點(diǎn)提供統(tǒng)一的服務(wù)能力對(duì)業(yè)務(wù)層開(kāi)放。

數(shù)據(jù)更新：數(shù)據(jù)是需要實(shí)時(shí)或者定時(shí)更新，數(shù)據(jù)來(lái)源通常是經(jīng)過(guò)大數(shù)據(jù)計(jì)算和處理后的各種數(shù)據(jù)，還有就是業(yè)務(wù)層校驗(yàn)有誤的數(shù)據(jù)，或者在使用過(guò)程不斷優(yōu)化的數(shù)據(jù)。

數(shù)據(jù)中心的獨(dú)立架構(gòu)部署是非常有必要的操作，大部分的數(shù)據(jù)都是具有聯(lián)動(dòng)性的，數(shù)據(jù)間的聯(lián)動(dòng)處理完全不用耦合到業(yè)務(wù)層面，數(shù)據(jù)的流動(dòng)校正安全性管理等等都可以在數(shù)據(jù)中心統(tǒng)一管理，規(guī)避掉數(shù)據(jù)混合部署帶來(lái)的系列復(fù)雜問(wèn)題。

四、大數(shù)據(jù)底層

數(shù)據(jù)服務(wù)能力的最底層需要海量數(shù)據(jù)處理的能力做支撐，所以用到很多大數(shù)據(jù)組件技術(shù)，對(duì)數(shù)據(jù)做存儲(chǔ)、計(jì)算、分析、搬運(yùn)等等操作。

數(shù)據(jù)存儲(chǔ)：大數(shù)據(jù)底層最常見(jiàn)的存儲(chǔ)就是文件形式，結(jié)構(gòu)化的數(shù)據(jù)庫(kù)存儲(chǔ)，半結(jié)構(gòu)化的日志型文件，還有一些非結(jié)構(gòu)化數(shù)據(jù)。

計(jì)算能力：對(duì)于海量數(shù)據(jù)的處理需要依賴各種并行計(jì)算，離線任務(wù)，實(shí)時(shí)計(jì)算等多種方式，達(dá)到快速處理的目的。

數(shù)據(jù)搬運(yùn)：數(shù)據(jù)處理完成之后并不會(huì)在底層直接提供服務(wù)能力，通常會(huì)把數(shù)據(jù)同步到上面數(shù)據(jù)中心，在對(duì)業(yè)務(wù)提供服務(wù)能力，這里搬運(yùn)可以是數(shù)據(jù)輸出，也可能是待處理的數(shù)據(jù)輸入。

大數(shù)據(jù)的底層組件則是系統(tǒng)的核心能力，對(duì)數(shù)據(jù)的精準(zhǔn)計(jì)算分析確保服務(wù)的能力，并且不斷的對(duì)現(xiàn)有架構(gòu)做自動(dòng)化和工具化管理，這點(diǎn)非常重要，海量數(shù)據(jù)管理的流程人工介入越多則說(shuō)明效率越低下，尤其在底層向數(shù)據(jù)中心推送數(shù)據(jù)或者數(shù)據(jù)接收的過(guò)程，需要約定好策略保證數(shù)據(jù)安全穩(wěn)定的自動(dòng)傳輸。

五、整體考慮

對(duì)一個(gè)復(fù)雜系統(tǒng)的設(shè)計(jì)，首先最關(guān)鍵的就是清晰的整理出業(yè)務(wù)模式，對(duì)業(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ù)底層能力這三大塊，并且要求各個(gè)大模塊之間不存在強(qiáng)耦合關(guān)系，確保模塊之間可以獨(dú)立的擴(kuò)展；

其次確定各個(gè)模塊需要的實(shí)現(xiàn)的核心功能，業(yè)務(wù)層保證基本的服務(wù)能力，然后把每個(gè)業(yè)務(wù)都需要的基礎(chǔ)功能向下抽取封裝，拆分出業(yè)務(wù)服務(wù)和公共服務(wù)，支撐業(yè)務(wù)能力；

然后確定各個(gè)模塊之間協(xié)作的方式，例如業(yè)務(wù)與數(shù)據(jù)中心的通信能力，接口標(biāo)準(zhǔn)，數(shù)據(jù)安全等細(xì)節(jié)，或者數(shù)據(jù)中心與底層大數(shù)據(jù)之間的數(shù)據(jù)搬運(yùn)模式，確保數(shù)據(jù)流通能力；

最后各個(gè)模塊具體的細(xì)節(jié)實(shí)現(xiàn)，這里需要考量的就是根據(jù)業(yè)務(wù)模式，如果可以選擇相同的組件和架構(gòu)方式，盡量統(tǒng)一架構(gòu)選型和組件依賴，降低不同模塊之間的壁壘；

上述完整的系統(tǒng)架構(gòu)從開(kāi)始搭建到提供穩(wěn)定的服務(wù)能力，大概耗時(shí)七個(gè)月的時(shí)間，期間不斷的演進(jìn)和升級(jí)，并且不斷上線新的服務(wù)模塊并進(jìn)行系統(tǒng)監(jiān)控，直至業(yè)務(wù)服務(wù)相對(duì)完善和系統(tǒng)相對(duì)穩(wěn)定。

六、源代碼地址

GitHub地址：知了一笑

https://github.com/cicadasmile/spring-cloud-base

GitEE地址：知了一笑

https://gitee.com/cicadasmile/spring-cloud-base