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