本文原始碼：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基礎】
【資料分析】【技術導圖】【 職場】
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/263185.html
標籤：Java