周講堂 | CACMP架構設計 – 基於數據中台考慮的PA標準化設計

2020-01-14 瀏覽量:416 分享:

CACMP一個有著資產運營服務能力的金融科技平台,資產服務能力的體現也是CACMP在廣鏈接思路上的延伸,在服務連接體係內的作用的發揮。CACMP一直在為資金端和資產端進行雙向賦能,在以汽車金融為核心領域中做出著實際的貢獻。在與資產方對接的過程裏,標準化資產的對接過程,是一個非常重要的過程。自動化,標準化,服務化的對接思路,是資產對接係統(Protocol Adapter簡稱PA)的主旨設計思路。當然為了整體CACMP業務中台及數據中台的核心建設目標,在設計PA的過程中,也經曆著不斷衍生的過程。開發過程以Spring Boot框架為基礎,融合了基本的微服務的設計思路(別問我到底微服務拆分粒度需要多細才可以,仁者見仁,你可以用單人的工作量來衡量,1個人能維護3-4個服務足以;你要是團隊配備了足夠的有經驗的員工,咋分都行;隻要運維服務能力跟得上,隻要願意在硬件設施上有大量投入,隻要能有效避免分布式事務,能滿足業務場景怎麽都是對的)。業務角度上說,PA這樣的係統除了做了和資產方的必要對接外,更為渠道管理係統提供了大量的數據的支持,為渠道管理模型提供了基本的輸入。

在我們構建PA0.x的時代,快速對接成為主旨,能快速使用各種現成的框架即可,如下圖:

 這是一個標準的使用著Spring Boot/Spring Cloud的過程(嘮叨一句Spring boot專注於快速、方便集成的單個個體,Spring Cloud是關注全局的服務治理框架,下次統一講講CACMP整體服務治理和數據治理的思路)。但作為一個以PAAS為目標的對接服務係統,考慮到係統的擴展性,考慮到日後的數據中台的建設,我們又做了新的設計和相應的服務拆分。PA和以前做的消息係統及工作流引擎不同,它自身偏向於業務,偏向於與量子風控管理係統的對接,數據的采集,數據的交互,數據的流轉,文本及影像資料的存儲,用戶信息的加密、各種短信認證、活體檢測等等。其中大量的數據的實時傳輸後期考慮利用Netty+FastDFS來處理,當然為了客戶端(我司提供相應的App及H5進件展業工具)而且有些文件在考慮向七牛的遷移。在整體設計過程中,進件的標識、資產方的標識、對應的資金方的標識、甚至下遊渠道服務商的標識都作為複合主鍵,在關係型數據庫中,進件標識更為重要;但是在作為冗餘信息存儲在HBase中,作為必備的查詢條件來使用。由於HBase不提供二級索引,它自帶的Row Key已經是唯一的索引了。

係統的交互更多是內部流轉,最終還是選擇了RabbitMQ作為我們的內部消息服務對接。可能為金融機構服務的多了,更多的考慮可靠性和高可用(RabbitMQ本身支持事務,雖然有可能阻塞,但有良好的確認機製,同時它自身的Mirror Queue的鏡像模式利用ACK保證主從一致性,不需要再利用ZK)。但既然是對外提供的服務,就必不可少的提供了服務網關,服務熔斷降級等基本邏輯。所以API 網關自然上線,從選型上最終還是考慮使用Kong(Nginx和Kong使用的是多進程非阻塞模式,CPU使用率采用的是多個進程的,本身Kong的可擴展性靈活性更強,Ngnix更被定義為反向代理或負載均衡工具)

 PA交互最多的就是量子風控,雙方通過消息隊列進行集成連接保證數據的貫通及一致性。在PA係統中會用到MongoDB,更主要的目的是放在業務型日誌的存儲上(MongoDB的數據庫文件主要有3種:Journal 日誌文件、Namespace 表名文件、Data 數據及索引文件),下一部分我們會介紹NICE係統的服務架構設計。