網際網路賬戶系統如何設計（上篇）？
在很多網際網路公司業務發展的早期，業務模式比較單一的情況下，涉及使用者賬戶資金交易相關的邏輯也比較簡單，但是隨著公司業務模式的不斷創新及型別的多元化發展，會漸漸發現現有系統賬戶邏輯越來越雍腫，不僅難以支援新業務的擴張，對現有業務的支援也適配困難，最終導致新業務系統不得不重新搭建自己的業務賬戶邏輯，造成重複建設不說，也往往給後續的財務資金核算造成混亂。
以某網際網路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公司的租車業務與打車業務法律主體尚未進行拆分屬於同一家公司，但是財務上要求隔離兩類業務的資金流，那麼可以在賬戶系統上為租車業務開立租車業務使用者，如果張三使用了租車業務則為張三設定租車業務使用者並在該使用者下開立餘額、餘額返現、押金三類賬戶並配置業務及記賬規則，此外若希望業務資金在平臺上也有個完整體現也可以在租車業務使用者下設立相應的平臺賬戶，只是業務流程上可以採用緩衝或非同步記賬的方式。
而打車業務則需要根據普通客戶資訊為普通打車使用者開立相應的個人賬戶，若是司機則需要開通司機相關的業務賬戶，而平臺也需要開通相應的平臺賬戶。在資訊流上，客戶資訊為所有業務所共用，使用者資訊則是根據不同的業務設定，賬戶是根據業務掛在相應地業務使用者下。如若各業務間沒有橫向地聯絡，各業務層賬戶體系根據自身業務分別執行、互不干擾，而如果存在聯絡，如租車餘額可以進行打車，則可以設計為允許業務層間賬戶的互轉，只是這種資金流會更復雜，需要配置的記賬分錄也會更加複雜。
以上述模型的定義而設計的賬戶系統會初步形成一個具備支援多類業務賬戶邏輯並行的通用中臺賬戶系統雛形，從財務角度看賬戶層次會相對清晰。另外，圖中還定義了機構的概念以支援總公司-分公司這樣具備層級關係的財務核算需求，當然這種情況在網際網路公司的扁平化模式下並不常見，所以可以暫時忽略。
本篇通過業務場景舉例從業務模型上大概闡述了網際網路賬戶系統如何設計得相對通用和清晰，事實上在系統設計上也需要進行更多的設計，並且需要根據公司實際業務情況進行一定的取捨。
推薦閱讀