轉載自??互聯網賬戶系統如何設計

在很多互聯網公司業務發展的早期，業務模式比較單一的情況下，涉及用戶賬戶資金交易相關的邏輯也比較簡單，但是隨著公司業務模式的不斷創新及類型的多元化發展，會漸漸發現現有系統賬戶邏輯越來越雍腫，不僅難以支持新業務的擴張，對現有業務的支持也適配困難，最終導致新業務系統不得不重新搭建自己的業務賬戶邏輯，造成重復建設不說，也往往給后續的財務資金核算造成混亂。

?

以某互聯網A租車公司的業務發展路徑為例?

階段A

A公司在早期開展租車業務時根據用戶使用場景規定用戶必須在繳納押金以后才可以租車，并且支持用戶進行余額充值，余額可以支付租車費用以及購買相關優惠產品。所以賬戶資金流是這樣子的：

通過上述設計基本上就滿足了簡單的業務需求，用戶繳納押金單獨存放在一個押金賬戶，用戶的每次押金沖退都記錄賬戶流水(繳押金記+，退押金記-)；用戶余額充值單獨存放在一個余額賬戶，用戶的每次余額充值、消費、退款都記錄賬戶流水（余額充值記+、余額消費記-、余額退款記-）。

事實上，以上賬戶邏輯的設計基本已經能滿足業務早期的發展的需要了，并且如果賬戶流水記錄完整（例如記錄必要的業務類型，如余額購買了一張租車次卡）那么后續也能基本滿足早期業務的財務核算需求。遺憾的是，很多公司在類似以上簡單賬戶邏輯的設計上都比較混亂，如有的公司將賬戶直接綁定在用戶信息表上、有些直接更新賬戶余額，沒有完整記錄賬戶流水或賬戶流水記錄業務信息缺乏等，這種情況即使業務沒有多元化發展，也很難滿足后續業務邏輯的擴展，特別是會造成嚴重的財務數據核算困難，更不用談業務多元化發展后如何能夠快速支撐了，造成這種問題的原因是多方面的，這里也就不在贅述。

下面我們繼續看A公司租車業務的發展演進情況！

假設在A公司租車業務發展過程中為了鼓勵用戶進行余額充值，采用了充值+返現的形式進行活動，如：“充值100贈送20”，此時用戶余額賬戶的總金額應該是120，那么賬戶邏輯如何支持呢？

?

這里注意，之所以需要區分余額中真實充值和贈送的原因在于，如果產品邏輯允許余額退款，那么清晰地區分了真實充值和贈送所對應的余額的話，退款邏輯的實現將會比較簡單，否則就會變得比較痛苦，并且不清晰的邏輯也會增加造成公司資金損失的風險；另外如果余額返現賬戶變動流水記錄得比較明確的話，對財務后續的收入核算也會方便很多。

但是，是否這樣就能滿足業務需求了呢？

顯然，這樣還不能讓邏輯完全運行起來，因為增加了賬戶相應地交易邏輯與資金邏輯都需要進行相應的改變才行，以上業務場景中原來余額充值只需要調用余額賬戶記賬一次，現在需要根據充返邏輯再調用余額返現賬戶記賬一次；而余額消費則需要根據業務規則進行余額消費記賬，假設業務規則為“余額消費優先扣減余額返現賬戶，再次扣減余額賬戶”，那么系統交易及記賬邏輯如下圖所示：

?

從邏輯上看業務交易系統需要根據業務規則多次調用余額賬戶及余額返現賬戶進行記賬，并且需要從流程上保證兩個賬戶記賬調用的事務一致性，例如一筆消費訂單金額為20元，此時余額賬戶余額為10元，余額返現賬戶余額為5元，在優先消費返現賬戶金額扣款5元后無法再從余額賬戶消費15元時，交易失敗后需要回滾余額返現賬戶消費邏輯,余額返現賬戶“交易沖正 +5”。

?

階段B

在階段A中，單個業務會根據不同的產品設計進行賬戶邏輯的迭代，增加余額充返賬戶后雖然從賬戶邏輯層面只是增加了新的資金賬戶，但是交易邏輯卻是進行了較大的變更和調整；如果此時該業務場景又出現新的邏輯變化，例如某一天該租車業務針對某些信用良好的用戶進行免押金用車活動，并且支持這類用戶在退押金時可以選擇將押金的全部或部分金額進行余額充值，那么在流程設計上還會存在賬戶轉賬的情況（押金賬戶->余額賬戶）。

每次產品業務的迭代涉及用戶資金邏輯，都不免會影響交易邏輯及賬戶邏輯本身，但如果業務品類單一，這種迭代及擴展通過硬編碼方式多少還能繼續支持。但是，如果隨著公司業務向多元化發展，問題往往就變得復雜了。

假設A公司在主營租車業務發展態勢進入到趨于平緩的階段后，為了擴展業務范圍需要嘗試新的業務，例如，某團隊提出不能僅僅只搞租車也得弄個網約車平臺，那怎么弄？

?

首先肯定是需要先集結隊伍啦。集結完隊伍就需要好好分析分析下業務場景了，我們先大概看看一個網約車平臺的大概業務場景是什么樣子的，其中涉及的資金交易的流程應該如何設計呢？

在A公司的租車業務中，從參與角色角度來看涉及的邏輯并不算太復雜，只有“用戶、車、租車公司(內部可稱租車業務線)”，而從交易場景上看，用戶繳納押金、預存余額及余額消費都只是單向的C->B交易模型，如果不考慮公司層在線交易賬戶體系（這里是指公司層面的交易賬戶）業務復雜度還不算十分復雜，并且在這種單向業務模式下，沒有公司層面的在線交易賬戶本身并不影響業務流程，收入核算只需要線下計算即可，這也就是為什么前面會特意強調賬戶流水業務關鍵信息不能缺失的原因了。

而約車業務則是多向的C->B-C-B的交易模型，因為從參與角色上看除了普通打車用戶外，還有司機、打車平臺都會緊緊地參與到整個業務流程中；而從賬戶資金流上看用戶支付的車費不會以C->C的模式直接支付給司機，而是會由打車平臺代收，打車平臺扣除訂單抽成后剩下的車費才會打到司機在打車平臺開的賬戶上，司機才能從個人賬戶提現。

?

從上圖的分析中我們可以看到，我們需要為普通用戶、司機賬戶、打車平臺分別設置必要的賬戶邏輯，普通用戶賬戶邏輯與之前的租車業務比較類似，用戶可以直接支付打車費用、也可以通過余額充值后使用余額支付打車費用；而平臺則需要代收用戶的打車費用并且需要按照服務規則從代收的打車費用中扣掉部分服務費，然后通過代收/付平臺賬戶將車費實時結算給司機端收款賬戶，司機通過個人收款賬戶發起提現后經過結算賬戶完成提現。資金流如下：

此外，為了滿足產品邏輯的擴張，例如要具備凍結司機賬戶的業務功能，則需要設置凍結賬戶；平臺為了進行市場營銷活動，如發放紅包則需要設置平臺市場營銷賬戶等。

階段C

業務發展到這個階段，初步看好像并沒有太多的邏輯變動，并且看著只需要擴展下之前租車業務的賬戶邏輯就好了。但真的是這樣嗎？

事實上從單純的產品邏輯來看，同一套個人用戶賬戶貌似是沒有什么問題的，但是根據很多互聯網公司業務發展的路徑來看，不同的業務線根據發展情況不同往往會分別設置不同的法律主體，而且根據業務性質的不同監管層面的政策也是完全不一樣的，例如在國內運營的租車業務司機車費代收代發這類業務是要求運營公司具備支付牌照的，沒有則會牽扯到非法二清這樣的法律風險，而一般來說在沒有支付牌照又想繼續運營的話，替代方案目前主要是采用銀行資金托管的方式，即用戶資金通過銀行三類賬戶進行托管。

一旦涉及這類業務，整個系統的業務復雜度會成倍地增長，所以如果采用同一套個人用戶賬戶的話，資金流將會變得難以拆分，對整個系統的升級也會造成比較大的困擾。

另外如果除了租車業務、打車業務外又嘗試了別的新業務，如直播之類。業務類型完全不同，且財務本身就要求進行分類的話，只能重新設計新的賬戶邏輯了；但，從某種角度看這類賬戶邏輯實質上又是與之前業務存在共性的。如直播類平臺也是普通用戶充值，購買平臺禮物后打賞給主播，此時平臺會對用戶贈送的禮物抽成后將其轉換為可提現的余額結算給主播賬戶，這類賬戶邏輯與約車平臺其實是很類似的。

那么，是否存在既能統一財務數據又能良好地支持業務的橫向擴展相對通用的賬戶系統模型呢？

接下來繼續和大家探討一套可以持續擴展的業務賬戶系統該如何設計？

業務模型

首先我們分析下大多數在線資金業務涉及的邏輯實體，用戶是第一存在，但是用戶根據參與的性質不同又分為普通消費端用戶、普通服務端用戶，拿打車來說一個普通打車的人屬于普通消費端用戶，而司機個人則屬于普通消費用戶，并且司機身份也是可以轉換為普通打車用戶，另外就是平臺用戶，是指公司內部各個不同的業務主體，它們關聯的法律主體可能是同一個也可能是不同的。

所以綜上所說，我們需要的可能是一套“為不同公司主體下，不同業務的同一個／不同用戶提供不同賬戶交易邏輯支撐，并且可以滿足業務及用戶平滑擴張的系統”。

事實上要達到這樣的效果是很難的，需要在系統平臺層面進行良好地系統及業務架構設計，并且確保在制定業務規則時遵循一定的制度及規范才行。

以下圖示為目前業內相對比較完整的通用賬戶體系模型，俗稱“三戶模型”，最早是電信行業為適配復雜通信業務場景而設計的一套賬戶體系模型；而大部分互聯網公司業務的復雜度是低于復雜的電信業務的，所以在這里我們對此模型進行部分改進，以期形成適應互聯網公司業務發展的通用賬戶體系模型。

在上述模型中信息被劃分成了三個類型：客戶、用戶、賬戶。客戶是用戶身份信息的承載實體，例如張三這個人是一個客戶；而客戶也不僅僅只是針對個人，針對業務線所關聯的法律主體也劃分在客戶的范疇，如某某打車公司。而有了基本的客戶信息后，企業客戶具體可以開展什么業務，普通個人用戶是否使用了該企業客戶提供的服務，在模型中是采用用戶這個概念來承載的。企業客戶開展該業務時根據業務的設計需要開通什么平臺賬戶，普通個人用戶使用該業務服務需要開通什么樣的個人賬戶都可以根據業務的設計通過用戶下設立相應地賬戶進行隔離區分。

假設此時A公司的租車業務與打車業務法律主體尚未進行拆分屬于同一家公司，但是財務上要求隔離兩類業務的資金流，那么可以在賬戶系統上為租車業務開立租車業務用戶，如果張三使用了租車業務則為張三設置租車業務用戶并在該用戶下開立余額、余額返現、押金三類賬戶并配置業務及記賬規則，此外若希望業務資金在平臺上也有個完整體現也可以在租車業務用戶下設立相應的平臺賬戶，只是業務流程上可以采用緩沖或異步記賬的方式。

而打車業務則需要根據普通客戶信息為普通打車用戶開立相應的個人賬戶，若是司機則需要開通司機相關的業務賬戶，而平臺也需要開通相應的平臺賬戶。在信息流上，客戶信息為所有業務所共用，用戶信息則是根據不同的業務設置，賬戶是根據業務掛在相應地業務用戶下。如若各業務間沒有橫向地聯系，各業務層賬戶體系根據自身業務分別運行、互不干擾，而如果存在聯系，如租車余額可以進行打車，則可以設計為允許業務層間賬戶的互轉，只是這種資金流會更復雜，需要配置的記賬分錄也會更加復雜。

以上述模型的定義而設計的賬戶系統會初步形成一個具備支持多類業務賬戶邏輯并行的通用中臺賬戶系統雛形，從財務角度看賬戶層次會相對清晰。另外，圖中還定義了機構的概念以支持總公司-分公司這樣具備層級關系的財務核算需求，當然這種情況在互聯網公司的扁平化模式下并不常見，所以可以暫時忽略。

本篇通過業務場景舉例從業務模型上大概闡述了互聯網賬戶系統如何設計得相對通用和清晰，事實上在系統設計上也需要進行更多的設計，并且需要根據公司實際業務情況進行一定的取舍。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的互联网账户系统如何设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。