來源：無敵碼農

導讀

在上一篇文章中我們通過場景舉例的方式，討論了一套相對通用的互聯網業務賬戶系統，從業務模型上應該如何定義。那麼除了從業務模型上進行定義外，在具體系統實現上又該如何設計？又有哪些需要注意的地方呢？在本篇內容中小碼農就和大家一起討論下賬戶系統的實現細節，希望可以和大家一起交流進步。

事實上賬戶系統的業務邏輯是比較複雜的，對數據的一致性要求很高，特別是記賬動作涉及強事務特性；另外，性能問題也是常常制約賬戶系統穩定性的一個比較突出的方面。在這種情況下，我們還需要考慮系統的業務通用性設計問題，而這必然也會涉及很多配置項的設計，增加系統的邏輯複雜度。但是，也只有處理好了這些問題，賬戶系統才能保證業務的持續擴張，否則再好的理念也只是空中樓閣。然而，處理好這些複雜的問題，事實上並不只是某一點的設計就可以達成的，既需要邏輯流程設計上的優化，也需要採用合適的技術方案，更需要一個合理的系統結構。

下面我們就從系統結構、整體流程、數據模型、記賬規則，以及日終對賬這幾個方面與大家探討從系統層面應該如何設計。另外對於賬戶系統中制約性能最常見的熱點賬戶問題，也會和大家一起探討。

系統結構

在之前的內容中，我們提到要設計一套可以滿足互聯網業務擴展的賬戶系統，所以賬戶是這套系統的基礎，爲了更好地支持不同業務、或同一業務不同賬戶的開戶，我們需要將開戶邏輯設計成獨立的子系統，獨立地提供包括開戶、賬戶信息查詢、餘額查詢在內的服務，以便邏輯複雜到一定階段後可以更容易的擴展。在完成開賬戶動作後，就需要根據業務規則，設計好邏輯體系下不同交易類型的記賬規則了，而這種規則配置是否智能，則是賬戶系統是否通用的關鍵；配置完規則後賬戶系統就可以接收業務發起的交易請求，並根據規則的配置完成業務資金流的處理了，所以，從系統結構層面也需要將記賬核心服務設計成獨立的子系統；此外，爲了適配業務層不同的交易類型，主要是隔離記賬邏輯與交易邏輯，還需要前置賬戶交易系統。

最後，爲了確保賬戶餘額與流水之間的平衡，我們還需要在日終時對主要資金賬戶進行對賬覈算，確保賬戶流水發生額與賬戶餘額的一致性。所以從系統結構層面，整個系統主要可以分爲四個部分：

之所以在賬戶系統、核心記賬系統之上設置一層賬戶層交易系統，是爲了將多變的業務交易邏輯與相對通用的記賬邏輯進行隔離，避免在覈心記賬系統中冗餘過多的業務邏輯導致後續出現臃腫的情況。例如業務層的交易類型可能是複雜多變的，如車費充值、押金支付之類，而這樣的邏輯是沒有必要讓記賬系統感知的，記賬系統只需要根據交易系統傳遞的記賬規則，根據會計分錄完成資金流處理即可。

整體流程

爲了確保系統能夠正常Run起來，需要對系統整體的流程進行規劃，這部分流程即包括線下流程，也包括線上流程，它是確保整個系統閉環的基礎。例如，以賬戶系統需要支撐A公司打車業務爲例，假設賬戶系統已經存在的情況下，那麼它需要支撐這個業務應該經歷以下兩個階段的流程：

（一）、線下規劃配置流程

按照正常的流程設計，在業務開展之前，需要根據實際的業務資金流設計好具體的賬戶及交易資金邏輯，這部分邏輯一般是由PM與資金部門線下確認後形成正式的產品規格文檔。之後，由具有權限的運營人員通過後臺，或者前期在沒有完善配置系統的情況下，由技術人員初始化到系統中，由於這部分配置關係到交易核心流程，所以在流程及操作規範的制定上要嚴格把控，避免配置錯誤導致的嚴重系統邏輯錯亂問題。

在這部分流程中我們首先需要配置業務主體，這裏需要爲A公司配置客戶開戶信息，之後需要按照之前業務模型定義的結構，在客戶下爲其開通表示打車業務線網約車用戶，至此在系統中就完成了“誰？要幹什麼？”的定義。而具體“怎麼幹？”，則是在後面我們要重點配置的內容。

那麼具體需要配置什麼內容呢？

因爲，賬戶系統本身是爲交易邏輯服務的，所以我們需要明確業務中涉及賬戶邏輯的交易有哪些類型，例如在約車業務中主要涉及到司機端開戶、乘客開戶、現金支付車費、餘額充值、餘額支付車費、司機提現等這些交易類型，所以我們需要爲這些交易類型定義交易編碼（tradeCode），並將其與之前開通的網約車業務用戶進行關聯，這樣在後續的系統交易流程中，就可以進行交易權限控制，各業務線邏輯各自關聯自身的交易類型，以免互相干擾了。

而定義了這些交易類型以後，賬戶層交易系統具體接收到這樣的交易請求後應該怎樣執行邏輯呢？在互聯網公司早期業務發展的過程中，很多都是將賬戶邏輯與交易邏輯耦合在一起的，這樣會導致各個業務賬戶邏輯陷入要麼繼續耦合，要麼各自定製、重複開發的怪圈。

而要讓這種邏輯變得通用，就需要將其規則化，即賬戶層交易系統接收到指定的交易請求類型後，會根據系統用戶交易規則配置，獲取開戶、記賬交易規則信息，然後記賬系統和開戶系統就會按照規則指定的邏輯執行了，這種執行邏輯識別規則，不感知具體業務邏輯。在上述流程中，我們將“平臺層開戶”也設計成了規則，只是這種開戶動作接口並不對實時交易接口開放，一般是通過後臺設置，即通過後臺調用開戶系統機構（平臺）開戶接口，開戶邏輯根據網約車平臺層開戶規則，自動開立“服務費賬戶”、“代收付平臺賬戶”、“結算賬戶”、“市場營銷賬戶”這類開展網約車業務所需的平臺層賬戶體系。

其他開戶交易類型，如司機端開戶、乘客開戶由於需要在具體用戶註冊、司機入駐時通過實時交易接口自動調用Api開通，所以這裏需要配置好開戶規則即可；至於，各個涉及資金變動的交易類型，如車費支付、餘額充值之類，涉及到具體的記賬規則的邏輯，也需要通過配置相應的交易記賬規則，關於記賬規則的配置設計涉及一點會計知識的細節，會在後面的內容中介紹到。

（二）、線上系統交易流程

完成系統級的數據定義及規則配置後，整個賬戶系統就會通過開放Api，爲各個業務交易系統提供線上賬戶交易接口服務了。

業務層交易系統向賬戶層交易系統發起交易請求後，系統會首先根據傳遞的客戶、用戶ID對請求權限進行識別，只有在（一）流程中設置了客戶、用戶主體信息的交易請求才被允許，之後賬戶層交易系統會根據傳遞的交易編碼（tradeCode）識別交易數據開戶交易類型，還是交易記賬類型。開戶交易類型則被轉發至開戶子系統進行開戶處理，開戶子系統根據tradeCode設置的開戶規則，完成註冊用戶賬戶體系的開通，如：乘客張三，會依次爲其開通客戶身份、打車用戶身份、以及打車用戶涉及的餘額賬戶，餘額返現賬戶，押金賬戶的開通。

而如果爲交易記賬類型，假設這裏爲乘客使用現金支付車費，則請求被轉發至記賬子系統，記賬子系統根據業務線客戶、用戶ID、乘客業務用戶ID以及tradeCode獲取記賬規則，完成資金邏輯記賬處理。

規則涉及的賬戶邏輯如下：

記賬規則

在賬戶系統中，記賬規則邏輯的設計是最爲複雜的一項設計，需要在兼顧會計邏輯的情況下，還需要將其設計成較爲通用的規則，以上面用戶支付車費的賬戶資金邏輯爲例，如何將其設計成規則配置呢？

在以上記賬規則表中，定義了業務線用戶ID（merchUserId），表示該業務模式在系統中的唯一編碼；記賬交易類型（tradeCode）由具體的業務線交易模式定義，例如打車業務用戶現金支付車費。這兩個字段由定義客戶用戶信息、用戶交易類型，可根據實際業務定義。

後面的字段主要定義了賬戶交易邏輯的情況，例如changeType中定義的記賬，表示按照規則正常的借貸方向進行餘額更新，而凍結、解凍則是對賬戶餘額進行凍結、解凍操作，增加、減少是根據規則直接對賬戶進行增加及減少操作，之所以定義上述不同類型，主要是爲了適應不同賬戶操作邏輯，具體定義及含義，大家也可以根據自身公司的實際業務情況進行定義。

可能這麼解釋大家會有比較大的疑問，我們以線上交易流程中涉及的網約車用戶現金支付車費的資金邏輯爲例：

根據規則表的設計，以上規則描述了各賬戶資金流的變動邏輯，其中涉及賬戶類型、借貸方向、資金類型、記賬科目以及記賬步驟。當業務層交易發起至賬戶層交易系統後，賬戶層交易系統會獲取以上記賬規則，並根據規則描述的賬戶類型，找到普通消費用戶、平臺層用戶、普通服務用戶對應的賬戶信息，並按照規則逐條進行記賬邏輯執行。

通用數據模型

在上面的流程及規則涉及中，以網約車業務爲例，通過兩個流程說明了賬戶系統應該如何支撐着項業務，雖然，看着並不是特別複雜，但是從系統設計上看卻是涉及了很多實體信息，接下來我們從數據建模的角度，看看如何設計系統的數據模型。

在模型中我們根據邏輯，抽象了客戶、用戶、賬戶相關實體，同時也抽象了賬戶流水、科目信息、記賬規則、開戶規則，交易類型等信息。系統通過這些實體設計相關表結構，系統就初步具備了運轉能力了，大家可以根據實際情況增加其他實體信息。

會計科目

會計科目是賬戶系統中比較基礎的概念，它的定義決定了賬戶的一些屬性特徵，例如是否可透支，屬於資產類or負債類，可以根據不同公司財務的需求進行設計。

記賬策略

大家知道記賬動作是強事務的，按照正常記賬邏輯以上規則執行過程中涉及的4個賬戶更新需要具有原子性，要麼都執行成功，要麼全部回滾，而對於普通消費賬戶、普通服務賬戶，這些賬戶都屬於個人賬戶，在線上實時交易中的併發度是有限的。而對於平臺層賬戶，包括代收付賬戶、服務費賬戶等，平臺所有的交易都涉及這些賬戶的資金變動，所以如果在某一個交易過程中對其加鎖，會導致該賬戶記錄的加鎖-更新動作非常頻繁，成爲熱點賬戶，影響系統性能。

所以在規則中我們加入了是否緩衝記賬的配置，一旦配置爲緩衝記賬，則在執行該規則時，只是把該記賬邏輯放入緩衝隊列的邏輯與其他規則在一個事務中，而具體賬戶更新邏輯則是由緩衝記賬系統完成，該邏輯可設置爲日間完成，或日終完成。

從而緩解熱點賬戶問題導致系統性能瓶頸，但是需要注意，這種方案也對緩衝記賬邏輯提出了比較高的要求，需要緩衝記賬系統儘量保證記賬動作執行成功，一旦執行失敗前面同步執行成功的記賬邏輯回滾起來會比較麻煩；另外，如果之前的同步記賬邏輯在發送緩衝隊列成功後，自身邏輯又失敗了，則需要及時發送衝正機制，取消該緩衝記賬動作。

日終對賬

爲了確保賬戶餘額始終處於相對正確地狀態，需要對日終賬戶流水進行各種試算覈對，確保所有流水發生額累加後的餘額+期初餘額能夠與當前餘額匹配，這裏會涉及到比較複雜的對賬邏輯，需要大家在實際系統研發實踐中加以考慮。

技術點拓展

在賬戶系統的研發設計過程中，還會涉及很多其他問題，例如賬戶流水數據量非常大，同時數據的留存時間又要求比較長，所以需要考慮數據的分佈式存儲，目前小碼農所在公司，採用了TIDB這種分佈式數據庫，大家可在實踐中根據自身情況進行選擇。

另外，賬戶的頻繁更新，在系統併發量非常高的情況下，還會遇到性能瓶頸，如何在保證用戶體驗及數據正確性的情況下，採取更多的技術手段，如採用Redis/Codis進行緩存記賬，也需要在實踐應用場景中進行探索。

後記

由於賬戶系統邏輯相對比較複雜，涉及很多會計知識及細節邏輯，本文只是描述了一種理念與思路，真正做好這套賬戶系統還需要大家根據自身場景進行取捨與裁剪。由於作者水平有限，不足之處，還請多多包涵！