上篇對賬戶系統的基本知識進行了詳細的分析，相信大家都基本了解了相關知識。本文主要對賬戶系統進行實戰總結，分享如何在實際工作中從0到1搭建賬戶系統，希望對你有所幫助。
前言
上文我們介紹了賬戶系統的基本知識友善大家了解，包括但不限于基本概念/名詞、核心業務流程/系統架構、業務價值等等，忘記的可以直接點選連結回顧下：賬戶系統從0到1搭建（1），本篇主要從實操的角度出發，分享如何從0到1搭建一個賬戶系統，内容主要包括以下幾部分：系統互動流程、核心流程/界面原型及核心業務規則、對外接口提供等。
一、系統互動流程圖
上圖是O2O電商賬戶清結算的系統互動流程圖，深藍色為賬戶系統，上遊系統為統一結算平台（視平台需要），再往上遊是請求入賬的幾個核心系統，例如業務計費系統、商家獎懲系統、分銷系統等等，以上系統是根據平台自身業務需要建設，有可能部分系統無，也有可能增加更多系統。
從上圖可以看出，賬戶中心不包含業務邏輯，正常情況下隻是承載1個記錄資金資料變動的角色，賬戶資金的增減變化是由業務系統觸發，除非特殊/緊急場景下需要人工手動調整賬戶資金資料。
二、系統0到1搭建
1. 核心流程/界面原型
為了友善大家更好的了解，原型界面及系統規則的部分我結合着業務流程來展開分享，結合着業務更容易消化了解，賬戶系統整體功能菜單結構如下圖所示，下圖是比較核心又通用的功能，實際建設過程中可根據自身平台需要添加其他附屬功能，如轉賬等：
（1）開戶流程：這個流程不涉及到系統頁面建設，賬戶系統隻是提供開戶接口至上遊系統（主要為商家/供應商/服務商管理系統），上遊系統根據業務需要，在商家滿足相關認證後，自行請求賬戶系統開戶接口完成開戶動作。
（2）入賬流程：這個是賬戶系統建設中最複雜也是最核心的流程，因為我們之前也說過記賬是最賬戶系統最核心也是最基礎的功能，資金入賬涉及到頁面開發的主要分為3部分：費用類型管理、入賬規則與當機規則管理，我分開說明下：
費用類型定義及用法：關于費用類型的定義及使用原則，我已經在結算系統從0到1搭建中詳細說過了，為了提高大家的觀感，我直接複制過來：
費用類型從字面意思上了解就是被結算資金的名稱，簡單來說這就是是一筆什麼錢，因為什麼場景産生的？再往上抽象一層，1個費用類型其實代表了業務的1個計費場景，對應了一個具體的計費規則（前提是費用類型顆粒度要足夠細化）他們之間的關系如下圖：
- 業務場景：費用類型=1：1或1：N
- 費用類型：計費場景/規則=1：1
費用類型的命名原則：大體原則是簡短同時能反映費用的業務屬性，這樣賬戶系統記賬的時候，賬務流水的業務屬性就會很清楚，使用者/營運可以很直覺地就知道這筆錢的因為什麼進來，這筆錢為什麼被扣掉，如下圖所示：
費用類型在系統間流轉過程：當上遊業務側新增一個計費場景時，賬戶系統需對應新增1個費用類型來表示此場景的資金類型，具體新增費用類型的營運流程，看自己公司要求，賬戶系統配置完成後，需要将費用類型編碼同步至上遊業務系統與前置結算系統，這2個系統需要将此編碼維護在自身系統中。
當此費用類型的資金進行入賬時，結算系統需要傳業務線ID、使用者ID外，害需要傳費用類型ID，因為賬戶系統需要根據費用類型ID比對對應入賬規則及當機規則，進而确定入到哪個賬戶中，費用類型新增流程如下圖：
費用類型原型圖：
費用類型管理：
入賬規則：這個可以直接從字面意思上來了解，就是此筆費用做資金入賬時的規則，入到哪個業務線哪個主體類型的哪個賬戶中，上遊系統請求賬戶中心請求入賬時，賬戶中心根據費用類型ID與傳業務線ID比對唯一入賬規則，比對到則正常入賬，比對不到則傳回錯誤，并通知相關人及時調整/配置對應入賬規則。
入賬規則管理：
新增入賬規則：
當機規則：當機規則也可以從字面上了解，即這筆資金進行入賬時，是否需要進行當機，若需要當機，如何當機？按照固定時間還是固定時長當機（可配置），當機規則是依附于入賬規則的，費用類型、入賬規則、當機規則三者間的關系如下圖：
當機規則管理：
新增當機規則：
（3）當機/解凍流程：當機/解凍流程分為2個次元：
賬戶當機：主要是因為賬戶主體觸發平台風控（如違規、輿情客訴等），需要将賬戶當機防止資金提現，可以手動當機，也可以由上遊系統（如獎懲/風控系統）通過接口當機，當機的類型主要分為：解凍、不可入賬不可提現、可入賬不可提現（使用較多）、可提現不可入賬，涉及原型圖見下圖（部分）：
賬戶管理：
賬戶詳情：
當機賬戶：
金額當機：金額當機有2種形式，1種是當機賬戶中可用餘額中的部分金額，原因與上文中賬戶被當機相同，通過營運/售後手動當機，1種是平台自身賬期需要，業務參與方的資金入賬時，便将流水按照固定日期或固定時長當機，此部分隻可系統自動當機。
當機金額（手動）：
（4）調賬流程：簡單來說就是手動調增/調減賬戶的金額資料，這個功能需要謹慎使用，僅在部分無法通過系統入賬的場景中使用，或進行業務前期階段使用，例如提現暫未實作線上化，就可以通過線下打款，線上手動扣除賬戶餘額來得方法來實作。
因為賬戶資料涉及到真實資金資料，為防止出現人為惡意調整賬戶資料或誤操作，給平台帶來不必要的麻煩和資金損失，系統層面需加上單天調整次數限制、每次調整時間間隔限制，并可以根據實際業務需要加上線上審批流程。
賬戶調賬：
除了我上文說的部分原型圖及規則，比較常見的原型頁面還有賬戶流水、操作記錄等，都比較簡單，在這我就不再贅述了，有一個點單獨提下：賬戶流水的字段裡面中請務必加上訂單号，能極大提高營運排查問題的效率
2. 賬戶接口
賬戶中心對外接口根據業務需要不同，也不盡相同，我列了一下比較常用的對外接口及相關參數（見下圖），實際工作中，可根據實際業務需要開發對應接口
三、總結
大部分涉及到資金分賬、充值/提現的業務都會涉及到資金資料記賬，賬戶系統作為實際記錄資金資料變動的載體，還是一個比較重要的底層核心系統。掌握賬戶系統的搭建能力對于此部分工作的展開具有很好的幫助，而且了解賬戶系統的核心設計方法和思路後，搭建一個适合自身平台需要的系統，難度整體可控。
本文由 @鲸爺陸 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。