由於企業每條業務線都有各自的使用者、商家以及運營補貼策略。在開始階段我們並沒有統一的賬務系統，每個業務線都有類似賬務系統相應的系統。導致的問題就是資金池業務吻合嚴重，對賬難，以及資料不統一，另外成本也非常高，為此我們做了統一的賬戶系統。賬務系統作為到家業務線的基礎服務，為到家業務提供統一清算、賬戶、對賬、財務報表能力。
目前賬戶系統的日均流水金額達上億級別。我們按照業務線進行分庫，保證每個業務線落在同一資料來源上，對於數量快速增長的表水平拆分。另外還對一些資料量增長較快，但是只訪問近期新增資料的表做了冷熱資料分離，定期備份。
以整個支付的流程來對支付平台的架構做個說明：使用者下單 -> 交易生成賬單 -> 使用者確認支付 -> 交易校驗賬單 -> 生成交易請求 -> 收銀台調起三方完成支付 -> 同步交易、同步業務線。此時交易系統會對卡券進行核銷。
交易系統完成後，賬單會推送到賬務系統，賬務系統進行記錄，清算，入賬等。
因為業務的特色，清算分為不同的模組，有銀行渠道、合作機構、分傭、優惠券、保險等。清算後生成賬戶流水，對賬戶流水做歸檔、核算等處理。
對賬系統是乙個非常核心的系統。目前分為多級別對賬和多頻次對賬。多級別分為分賬對賬：對各種流水，以及總賬對賬，總分對賬：流水與總金額的對賬。多頻次對賬分為日對賬，準實時對賬，交易推送賬單之後約十分鐘進行檢查，賬務系統會查詢這筆賬單是否存在，以及對賬單的金額進行對賬。對賬系統會盡快的發現問題，進行差錯處理。出錯處理主要是掛賬、補單、退款和登賬。
從技術層面來說，主要分冪等性、資料一致性兩塊。
大多數系統會拆分成多個子系統服務,而乙個子系統往往會呼叫另乙個服務,服務之間相互呼叫就有可能出現伺服器處理完畢後沒有返回結果的情況。客戶端沒有接收到返回結果,就可能重複呼叫。冪等性是系統的介面對外的一種承諾(而不是實現), 承諾只要呼叫介面成功, 外部多次呼叫對系統的影響是一致的。
目前賬戶系統主要是根據業務需求做了幾種冪等性
1、充值時對充值流水號做了唯一的處理，外部呼叫充值介面時，傳乙個唯一的流水號，判斷這個流水號在系統中存在，就返回，多次呼叫，也不會給這個賬戶進行累加充值。1、本地事務2、對獎懲做了外部唯一 id 的冪等性，呼叫者會傳入唯一 id ,根據唯一 id 判斷此筆獎懲是否已經進行清分入賬。
3、訂單則有區別，因為訂單有乙個退款的流程，如果把訂單做唯一性，訂單發生退款時無法區分這個訂單是新增加的，還是退款的，這樣的話賬戶的金額就可能不準確。因此採用了賬單金額軋差。
訂單軋差是什麼呢？舉個例子，商家第一次支付的金額，傳到賬務系統進行清算，比如通過支付寶支付 100 元，那麼給這個商家進行入賬，入 100 元，下次該訂單發生了退款，假設退 90 元(此時交易系統會將該訂單實際支付金額傳到賬務系統，即 10元)，實際上本次需要給商家入賬 -90 元，而不是 10 元，此次用賬單的金額 -90 元跟舊的金額 100 進行乙個軋差，利用軋差結果進行清算入賬。
4、提現失敗返還，根據申請提現生成的提現 id 反查賬戶流水表,看是否有提現並且沒有提現返還,根據流水金額反向生成流水返還記錄及入賬，保證冪等性。
按照業務線進行分庫，使得對同乙個業務線的操作均落到同一資料來源上，利用本地事務進行資料的訪問和更新，從而保持資料一致性。
2、柔性事務（需冪等）
主要採用了 tcc 模式和事務補償的模式。
t:try。 完成所有業務檢查,預留出必須業務資源)；在 try 這段，是對這個資料進行乙個驗證，驗證通過之後，將資料資源進行預留。在 confirm 階段，只對這個資料直接進行操作，而不進行驗證處理，但是只操作預留這部分的資料。若是發生取消的操作，將預留的操作返回到賬戶。tcc 模式主要是用於餘額消耗。當商家只能用餘額支付時，先將其餘額支付的金額進行凍結，真正對賬單進行結算時，只使用第一部分凍結的金額，而期間不做任何驗證，訂單完成支付時，對它凍結的這部分金額做真正扣減。如果中間訂單取消了，將凍結的金額進行返還，這樣保證賬戶裡的金額真正發生消耗時是充足的，不用進行反覆的檢查。c:confirm。真正執行業務,不做任何業務檢查,只是用 try 階段預留的業務資源；
c:cancel。取消執行業務，釋放資源。
事務補償就是操作失敗後的補償。申請提現的時候將賬戶的金額進行扣減，只要申請提現成功，那麼賬戶金額就做扣減。真正提現出金結果，則會通知賬務系統，若出金失敗，賬務系統對提現系統的 id 進行查詢，按照提現申請時生成的賬戶生成提現失敗返還流水，按照返還流水更新賬戶金額。
3、訊息佇列（訊息應答ack機制）
交易系統是通過傳送非同步訊息到賬務系統，賬務系統處理成功之後，ack 訊息；處理失敗則不 ack 訊息。利用訊息系統重**送機制再次傳送訊息，保證賬務系統每條訊息均可處理成功。但可能會發生 ack 訊息後，訊息系統未接收到，那麼就會重複的傳送。所以用訊息佇列 ack 機制，一定要保證冪等性。例如：rabbitmq支援訊息應答。消費者傳送乙個訊息應答，告訴rabbitmq這個訊息已經接收並且處理完畢了，rabbitmq就可以刪除它了。
4、分布式鎖
直接鎖定資源避免了多節點操作引起的資料不一致，只有業務上的硬性要求的時候才用，目前用於控制提現申請的頻率。
技術執行與架構實踐
文章原文 本文討論如何構建技術執行能力.不論是企業招聘還是個人職業發展,都可以參照這個能力模型.先是回顧技術人員的3個能力象限.再從技術視角如何思考和判斷問題.到架構設計的原則.並通過交易和營銷的成功實踐分析,理解什麼是好的架構.前一篇提到的技術人的職責,可以總結為以下3點 技術視野和判斷力 tec...
系統架構 WebGIS系統架構與網路架構介紹
1 webgis的系統架構 顧名思義，webgis就是展現於網路上的gis。就是將gis這門學科所能提供的功能，以b s技術展現給使用者，使使用者只需要在瀏覽器上便能使用這些gis功能的乙個應用方向。web地圖現在非常普遍，當你瀏覽乙個web地圖的時候，就像在乙個很大的連續的上漫遊，你可以通過在地圖...
《雲計算架構技術與實踐》
摘要 2014年9月，由華為公司雲計算首席架構師顧炯炯編著，清華大學出版社出版的華為雲計算首部著作 雲計算架構技術與實踐 一書正式問世。雲計算概念誕生至今已發展了約八年時間，這八年來，相比雲計算誕生初期，雲計算技術條件 行業和市場環境均發生了巨大變化，廣大讀者對雲計算的認知需求，也從當初的粗淺概念階...