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