在上一篇文章中我們通過場景舉例的方式，討論了一套相對通用的互聯(lián)網(wǎng)業(yè)務(wù)賬戶系統(tǒng)，從業(yè)務(wù)模型上應(yīng)該如何定義。那么除了從業(yè)務(wù)模型上進行定義外，在具體系統(tǒng)實現(xiàn)上又該如何設(shè)計？又有哪些需要注意的地方呢？在本篇內(nèi)容中小碼農(nóng)就和大家一起討論下賬戶系統(tǒng)的實現(xiàn)細節(jié)，希望可以和大家一起交流進步。

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

下面我們就從系統(tǒng)結(jié)構(gòu)、整體流程、數(shù)據(jù)模型、記賬規(guī)則，以及日終對賬這幾個方面與大家探討從系統(tǒng)層面應(yīng)該如何設(shè)計。另外對于賬戶系統(tǒng)中制約性能最常見的熱點賬戶問題，也會和大家一起探討。

系統(tǒng)結(jié)構(gòu)

在之前的內(nèi)容中，我們提到要設(shè)計一套可以滿足互聯(lián)網(wǎng)業(yè)務(wù)擴展的賬戶系統(tǒng)，所以賬戶是這套系統(tǒng)的基礎(chǔ)，為了更好地支持不同業(yè)務(wù)、或同一業(yè)務(wù)不同賬戶的開戶，我們需要將開戶邏輯設(shè)計成獨立的子系統(tǒng)，獨立地提供包括開戶、賬戶信息查詢、余額查詢在內(nèi)的服務(wù)，以便邏輯復(fù)雜到一定階段后可以更容易的擴展。在完成開賬戶動作后，就需要根據(jù)業(yè)務(wù)規(guī)則，設(shè)計好邏輯體系下不同交易類型的記賬規(guī)則了，而這種規(guī)則配置是否智能，則是賬戶系統(tǒng)是否通用的關(guān)鍵；配置完規(guī)則后賬戶系統(tǒng)就可以接收業(yè)務(wù)發(fā)起的交易請求，并根據(jù)規(guī)則的配置完成業(yè)務(wù)資金流的處理了，所以，從系統(tǒng)結(jié)構(gòu)層面也需要將記賬核心服務(wù)設(shè)計成獨立的子系統(tǒng)；此外，為了適配業(yè)務(wù)層不同的交易類型，主要是隔離記賬邏輯與交易邏輯，還需要前置賬戶交易系統(tǒng)。

最后，為了確保賬戶余額與流水之間的平衡，我們還需要在日終時對主要資金賬戶進行對賬核算，確保賬戶流水發(fā)生額與賬戶余額的一致性。所以從系統(tǒng)結(jié)構(gòu)層面，整個系統(tǒng)主要可以分為四個部分：

之所以在賬戶系統(tǒng)、核心記賬系統(tǒng)之上設(shè)置一層賬戶層交易系統(tǒng)，是為了將多變的業(yè)務(wù)交易邏輯與相對通用的記賬邏輯進行隔離，避免在核心記賬系統(tǒng)中冗余過多的業(yè)務(wù)邏輯導(dǎo)致后續(xù)出現(xiàn)臃腫的情況。例如業(yè)務(wù)層的交易類型可能是復(fù)雜多變的，如車費充值、押金支付之類，而這樣的邏輯是沒有必要讓記賬系統(tǒng)感知的，記賬系統(tǒng)只需要根據(jù)交易系統(tǒng)傳遞的記賬規(guī)則，根據(jù)會計分錄完成資金流處理即可。

?

整體流程

為了確保系統(tǒng)能夠正常Run起來，需要對系統(tǒng)整體的流程進行規(guī)劃，這部分流程即包括線下流程，也包括線上流程，它是確保整個系統(tǒng)閉環(huán)的基礎(chǔ)。例如，以賬戶系統(tǒng)需要支撐A公司打車業(yè)務(wù)為例，假設(shè)賬戶系統(tǒng)已經(jīng)存在的情況下，那么它需要支撐這個業(yè)務(wù)應(yīng)該經(jīng)歷以下兩個階段的流程：

（一）、線下規(guī)劃配置流程

?

按照正常的流程設(shè)計，在業(yè)務(wù)開展之前，需要根據(jù)實際的業(yè)務(wù)資金流設(shè)計好具體的賬戶及交易資金邏輯，這部分邏輯一般是由PM與資金部門線下確認后形成正式的產(chǎn)品規(guī)格文檔。之后，由具有權(quán)限的運營人員通過后臺，或者前期在沒有完善配置系統(tǒng)的情況下，由技術(shù)人員初始化到系統(tǒng)中，由于這部分配置關(guān)系到交易核心流程，所以在流程及操作規(guī)范的制定上要嚴格把控，避免配置錯誤導(dǎo)致的嚴重系統(tǒng)邏輯錯亂問題。

在這部分流程中我們首先需要配置業(yè)務(wù)主體，這里需要為A公司配置客戶開戶信息，之后需要按照之前業(yè)務(wù)模型定義的結(jié)構(gòu)，在客戶下為其開通表示打車業(yè)務(wù)線網(wǎng)約車用戶，至此在系統(tǒng)中就完成了“誰？要干什么？”的定義。而具體“怎么干？”，則是在后面我們要重點配置的內(nèi)容。

那么具體需要配置什么內(nèi)容呢？

因為，賬戶系統(tǒng)本身是為交易邏輯服務(wù)的，所以我們需要明確業(yè)務(wù)中涉及賬戶邏輯的交易有哪些類型，例如在約車業(yè)務(wù)中主要涉及到司機端開戶、乘客開戶、現(xiàn)金支付車費、余額充值、余額支付車費、司機提現(xiàn)等這些交易類型，所以我們需要為這些交易類型定義交易編碼（tradeCode），并將其與之前開通的網(wǎng)約車業(yè)務(wù)用戶進行關(guān)聯(lián)，這樣在后續(xù)的系統(tǒng)交易流程中，就可以進行交易權(quán)限控制，各業(yè)務(wù)線邏輯各自關(guān)聯(lián)自身的交易類型，以免互相干擾了。

而定義了這些交易類型以后，賬戶層交易系統(tǒng)具體接收到這樣的交易請求后應(yīng)該怎樣執(zhí)行邏輯呢？在互聯(lián)網(wǎng)公司早期業(yè)務(wù)發(fā)展的過程中，很多都是將賬戶邏輯與交易邏輯耦合在一起的，這樣會導(dǎo)致各個業(yè)務(wù)賬戶邏輯陷入要么繼續(xù)耦合，要么各自定制、重復(fù)開發(fā)的怪圈。

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

其他開戶交易類型，如司機端開戶、乘客開戶由于需要在具體用戶注冊、司機入駐時通過實時交易接口自動調(diào)用Api開通，所以這里需要配置好開戶規(guī)則即可；至于，各個涉及資金變動的交易類型，如車費支付、余額充值之類，涉及到具體的記賬規(guī)則的邏輯，也需要通過配置相應(yīng)的交易記賬規(guī)則，關(guān)于記賬規(guī)則的配置設(shè)計涉及一點會計知識的細節(jié)，會在后面的內(nèi)容中介紹到。

（二）、線上系統(tǒng)交易流程

完成系統(tǒng)級的數(shù)據(jù)定義及規(guī)則配置后，整個賬戶系統(tǒng)就會通過開放Api，為各個業(yè)務(wù)交易系統(tǒng)提供線上賬戶交易接口服務(wù)了。

?

業(yè)務(wù)層交易系統(tǒng)向賬戶層交易系統(tǒng)發(fā)起交易請求后，系統(tǒng)會首先根據(jù)傳遞的客戶、用戶ID對請求權(quán)限進行識別，只有在（一）流程中設(shè)置了客戶、用戶主體信息的交易請求才被允許，之后賬戶層交易系統(tǒng)會根據(jù)傳遞的交易編碼（tradeCode）識別交易數(shù)據(jù)開戶交易類型，還是交易記賬類型。開戶交易類型則被轉(zhuǎn)發(fā)至開戶子系統(tǒng)進行開戶處理，開戶子系統(tǒng)根據(jù)tradeCode設(shè)置的開戶規(guī)則，完成注冊用戶賬戶體系的開通，如：乘客張三，會依次為其開通客戶身份、打車用戶身份、以及打車用戶涉及的余額賬戶，余額返現(xiàn)賬戶，押金賬戶的開通。

而如果為交易記賬類型，假設(shè)這里為乘客使用現(xiàn)金支付車費，則請求被轉(zhuǎn)發(fā)至記賬子系統(tǒng)，記賬子系統(tǒng)根據(jù)業(yè)務(wù)線客戶、用戶ID、乘客業(yè)務(wù)用戶ID以及tradeCode獲取記賬規(guī)則，完成資金邏輯記賬處理。

規(guī)則涉及的賬戶邏輯如下：

?

記賬規(guī)則

在賬戶系統(tǒng)中，記賬規(guī)則邏輯的設(shè)計是最為復(fù)雜的一項設(shè)計，需要在兼顧會計邏輯的情況下，還需要將其設(shè)計成較為通用的規(guī)則，以上面用戶支付車費的賬戶資金邏輯為例，如何將其設(shè)計成規(guī)則配置呢？

?

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

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

可能這么解釋大家會有比較大的疑問，我們以線上交易流程中涉及的網(wǎng)約車用戶現(xiàn)金支付車費的資金邏輯為例：

根據(jù)規(guī)則表的設(shè)計，以上規(guī)則描述了各賬戶資金流的變動邏輯，其中涉及賬戶類型、借貸方向、資金類型、記賬科目以及記賬步驟。當(dāng)業(yè)務(wù)層交易發(fā)起至賬戶層交易系統(tǒng)后，賬戶層交易系統(tǒng)會獲取以上記賬規(guī)則，并根據(jù)規(guī)則描述的賬戶類型，找到普通消費用戶、平臺層用戶、普通服務(wù)用戶對應(yīng)的賬戶信息，并按照規(guī)則逐條進行記賬邏輯執(zhí)行。

通用數(shù)據(jù)模型

在上面的流程及規(guī)則涉及中，以網(wǎng)約車業(yè)務(wù)為例，通過兩個流程說明了賬戶系統(tǒng)應(yīng)該如何支撐著項業(yè)務(wù)，雖然，看著并不是特別復(fù)雜，但是從系統(tǒng)設(shè)計上看卻是涉及了很多實體信息，接下來我們從數(shù)據(jù)建模的角度，看看如何設(shè)計系統(tǒng)的數(shù)據(jù)模型。

在模型中我們根據(jù)邏輯，抽象了客戶、用戶、賬戶相關(guān)實體，同時也抽象了賬戶流水、科目信息、記賬規(guī)則、開戶規(guī)則，交易類型等信息。系統(tǒng)通過這些實體設(shè)計相關(guān)表結(jié)構(gòu)，系統(tǒng)就初步具備了運轉(zhuǎn)能力了，大家可以根據(jù)實際情況增加其他實體信息。

會計科目

會計科目是賬戶系統(tǒng)中比較基礎(chǔ)的概念，它的定義決定了賬戶的一些屬性特征，例如是否可透支，屬于資產(chǎn)類or負債類，可以根據(jù)不同公司財務(wù)的需求進行設(shè)計。

記賬策略

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

所以在規(guī)則中我們加入了是否緩沖記賬的配置，一旦配置為緩沖記賬，則在執(zhí)行該規(guī)則時，只是把該記賬邏輯放入緩沖隊列的邏輯與其他規(guī)則在一個事務(wù)中，而具體賬戶更新邏輯則是由緩沖記賬系統(tǒng)完成，該邏輯可設(shè)置為日間完成，或日終完成。

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

日終對賬

為了確保賬戶余額始終處于相對正確地狀態(tài)，需要對日終賬戶流水進行各種試算核對，確保所有流水發(fā)生額累加后的余額+期初余額能夠與當(dāng)前余額匹配，這里會涉及到比較復(fù)雜的對賬邏輯，需要大家在實際系統(tǒng)研發(fā)實踐中加以考慮。

技術(shù)點拓展

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

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

后記

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

轉(zhuǎn)摘于：http://www.sohu.com/a/253132589_684445

總結(jié)

以上是生活随笔為你收集整理的账户系统的具体实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。