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