美利財務平臺架構演進

說在前面

本文轉自「天河聊技術」微信公衆號

財務平臺在美利1年多的時間通過了2次平臺架構的演變，中間也遇到了這樣那樣的架構、技術的問題，今天整理了下，但願能夠給予你們一些啓發。

 

架構演變

財務平臺總體架構圖

業務處理流程

財務平臺是和美利的大數據平臺、用友NC系統進行合做來完成整個財務的帳務處理過程的。

大數據平臺把對接財務平臺的業務系統，如公司新核心、資產、負債、結算、支付等業務系統的mysql數據庫數據經過sqoop抽取到hive中進一步轉換成財務業務數據口徑數據推送到財務平臺接入服務數據庫中，再由財務平臺的批處理服務拉起臺帳轉換的任務進行集羣全服處理後，財務人員進行臺帳數據覈對後建立明細帳，在進行明細帳覈對後建立憑證數據，再把憑證數據推送到用友NC服務系統，財務餘額管理、總帳管理、相關財報管理有用友NC系統來實現。

 

財務平臺V1架構

1.0應用架構採用的是單體模式，數據庫架構採用的是分片架構

 

項目背景

技術的應用架構、數據架構必定是爲業務架構服務，脫離業務只談技術架構是紙上談兵。

爲了儘快知足業務需求，財務組面臨財務業務專業、複雜，數據量巨大這樣的問題，就要求開發要很懂財務業務知識、對海量數據處理的相關技術要熟悉、甚至要精通，代碼性能要很好，財務平臺從0到1搭建、財務組團隊也是從0到1搭建，所以面對這樣的客觀緣由，要快速落地財務平臺，對財務平臺靈活性（如會計科目、事務處理規則、會計規則配置靈活配置化）、擴展性（抽象出來事務處理規則引擎、會計規則引擎、計費引擎、帳務處理引擎）、帳務處理性能（能吞吐海量數據）都有很高的要求，所以更急切的架構是數據庫架構要能抗住這麼大的數據量，所以採用了數據庫分片架構，數據庫架構由個人上級阿兵主刀，感謝阿兵，到如今財務平臺已經到了平穩運營階段，抗住了第一次業務歷史數據億級別數據結帳以及到如今的單日業務數據量500W左右、月帳務處理數據量在5000W左右的一個體量。

 

應用架構爲何採用單體模式？

單體模式架構有不少好處

一、        代碼共享

二、        易於測試

三、        容易部署

 

所以若是須要從0到1快速落地一個項目這種應用架構方案是不二選擇，雖然財務平臺採用的是單體模式架構，可是財務平臺模塊設計是以微服務架構設計模式的，爲後期的微服務化架構落地打下了堅實的基礎。

沒有完美的架構只有最合適的架構，架構都是根據業務變化一步一步演變而來，不然有可能致使過分設計拔苗助長。

面對這麼大的數據量財務平臺採用了分片架構模式，中間件採用的是sharding-jdbc，這個框架財務平臺用的是1.5版本，基於client的實現jdbc規範的一個加強數據庫驅動，比較輕量級，目前財務平臺對其進行了一部分定製化開發，如今已經很穩定。目前的帳務處理流程是寫大於讀的場景，所以這個架構版本中是沒有考慮讀寫分離的。

在架構1.0版本中利息計提服務是採用的存儲過程邏輯來實現。

爲何要採用存儲過程

1. 存儲過程能夠更好的進行模塊化設計。

2. 執行更快，若是一個SQL要大量、重複執行、存儲過程要比SQL快的多。

3. 減小網絡消耗。

4. 版本迭代比較快，只專一開發SQL就能夠，開發、測試比較方便。

這種數據庫架構方案也是爲了快速落地。

 

財務平臺V2架構

架構1.0有哪些很差的地方呢

單體應用架構模式的弊端

一、        不夠靈活

二、        妨礙持續交付

三、        受技術棧限制

四、        技術債務，代碼耦合，牽一髮而動全身

 

存儲過程有哪些很差的地方呢

一、        執行進行SQL級別的數據庫優化

二、        運行在mysql服務器端，數據量大的話會形成數據庫服務器io、cpu性能消耗，沒法進行優化，在mysql環境下不一樣的應用服務的數據庫在一臺mysql實例上，一個數據庫的存儲過程把數據庫服務器資源都佔用，對其餘應用服務來講無疑是一場災難。

所以在架構2.0中咱們對利息計提進行了服務化，替換掉了所有的存儲過程，演變爲服務化架構模式。

 

財務平臺V3架構

爲何要作服務化、微服務化是爲了達到服務高可用的終極目標。

 

架構2.0中服務化架構仍是比較粗粒度的，那麼在這個架構模式下有哪些問題呢？

一、        服務以前仍是耦合到一塊兒的，沒有真正的解耦

二、        數據庫仍是耦合到一塊兒的

三、        不是嚴格的遵循了單一職責原則

四、        一些服務是耦合到一塊兒的不能作到真正的獨立部署、升級、替換，帳務服務是一個服務包括臺帳、明細帳、憑證

 

所以基於如今的服務化架構還須要進一步服務化，達到微服務化的目的，財務平臺採用的技術棧是spring cloud。

 

微服務化後帶來了哪些好處呢

一、        更便於開發、不一樣開發分工協做、持續交付

二、        應用啓動更快

三、        故障進一步隔離，一個微服務出現問題不會影響其餘服務，更不會影響整個應用

四、        理論上不受限制於技術棧，只要服務以前通信協議達成一致便可。

 

數據庫採用了讀寫分離

寫仍是sharding-jdbc+mysql數據庫集羣、讀採用的是elasticsearch，elasticsearch採用的是倒排索引機制，理論上比SQL查詢的效率要快上百倍以上，若是想詳細瞭解elasticsearch，請關注「天河聊技術」微信公衆號，有更詳細的關於elasticsearch的總結、還有其餘技術的一些見解。

 

微服務化後面臨的問題

最大的問題就是分佈式數據一致性的問題，目前財務平臺採用TCC實現的強一致性事務。其餘一些問題spring cloud生態體系基本上解決或者加以定製化。

 

財務平臺業財一體化架構的一些思考

財務平臺現階段來講是一個後知的系統。

 

對接財務平臺的系統之多、業務場景之多，數據治理是須要一個漫長而艱辛的過程，好比結算支付退票這種場景，線下結算的這種場景，線下還款等等業務場景，財務平臺拿到的數據並不是實時、徹底準確的，也多是一種業務上中態的數據，因此目前業務數據到財務平臺是通過大數據平臺這個橋樑來對業務數據進行統一對接，所以財務平臺沒法實時感知業務端的數據的，因此要達到真正的業財務一體化，決策者能夠實時看到財報，財報的實時性、準確性暫時仍是沒法達到的，這也是財務平臺將來規劃要實現的，後期要把財務平臺和業務數據真正的實時打通，業務系統所有線上化、財務平臺進行實時記帳、財務對帳流程自動化、帳務處理流程自動化，才能作到財報的實時性，最終也才能達到業財一體化的目的。

 

如今處理方案是T日抽取T-1日的業務數據來進行財務帳務處理，所以數據量集中在一塊兒對數據庫的壓力、服務器的壓力是很大的，峯值都在一個時間區間，除了這個時間區間其餘時間服務器基本上是空閒的，很大程度是這是一種服務器的資源浪費，這也是財務平臺架構上要後期優化的地方。

 

這個架構方案目前只是一個idea，尚未進行詳細規劃，算是一個思路，要走到這一步是須要一個漫長而艱辛的過程。

 

要實現這個目標要這些事情

一、        業務數據治理、操做所有線上化。

二、        業務數據與財務平臺實時打通。

三、        帳務處理徹底自動化。

 

說道最後

以上是針對財務平臺的三個版本應用、數據庫演變之路作了些總結，僅供參考。