新达达财务账户系统演变

近几年O2O很火，凡是做O2O的，几乎都要面临要不要给账号绑定账户？支持哪些形式的支付？如何去结算？如何让用户提现等问题。今天跟大家聊聊新达达两年多财务账户系统的演变。

黑铁时代 - 时间的成本是最大的成本

大部分公司，在创业初期都会面临着人手不够充裕的境地，但市场的机会稍纵即逝，这就要求团队能够尽快的实现功能，不断试错。

达达第一个版本是几个小伙伴在汉庭酒店花费7天的时间做出来的，当然，达达的账户的“黑铁时代”也非常的简单。跟业务系统完全耦合，内嵌在对应的商户和配送员的账号数据表里。

这显然很接地气，早期的研发在开发业务的过程中对账户的操作也非常方便，这在每日单量处于几十到几千这个数量级上基本上都能work，随着单量的上涨，内嵌在业务表里的弊端逐渐显现：

• 业务场景发生变化，当需要增加新的子账户的时候，有需要在那张耦合的表里增加新的字段。长期以往，账号数据表的字段越来越多，对原来的表结构影响很大。

同时，还有不少的跟账户相关的功能亟待开发，当时的情况如下：

• 账户的充值功能缺失。

• 账户额度的手动调整的功能的缺失。

• 财务团队有一些数据上的需求，报表功能的缺失。

• 一些账户资金转移的流程审核的功能缺失。

总结

公司的创业阶段是跟时间赛跑的阶段，时间的成本就是最大的成本，大家讨论下来，决定购买一套外部的系统来解决我们的难题。当时我们采购的这套系统集支付钱包，账户管理，报表输出，风控管理，资金管理一体，看起来是可以全部解决我们的所有问题，我们的系统随即就演变成新的结构，业务系统通过调用这套第三方系统，将所有账户财务相关的事情都交由它来处理。 

青铜时代 - 钱在一定的程度上可以买到时间，但看运气

本质上，采用第三方的系统，是一件用钱买时间的交易。我们不需要维护一个团队专门去开发各种财务和账户相关的服务。但最后的结果证明了，对于一个高速发展，并且对财务和账户的需求越来越严格的公司，该自己开发的还是得自己开发。

我们在2014年11月份开始谈这款第三方系统，真正付诸实施调试是在二月份春节前后，正式切换到线上的时间在四月份。中间遇到了很多坑，包括： 

• 时间周期太长，对方不断delay。

• 业务的功能的定制化和当初销售的许诺不符（这一块有无数个槽点，任何不写上合同的允诺都是耍流氓），最终产生了很多需要加钱才可以定制以及相互之间的扯来扯去的事情。

• 服务太多，我记得一共大概有40个服务，除了对方的工程师，你自己根本无法维护。

• 我们正式切换的时候，对方工程师在场也是需要付费的。

如果觉得以上忍一忍就过去的话，就太天真了，真正的痛苦才刚刚来临。

• 出现过对方消息队列服务因为参数错误而堵塞的问题

• 出现过对方服务serialVersionUID超过最大值的问题

• 出现过对方上错版本代码导致我们服务不可用的问题

• 出现过对方悄悄上线了一个版本优化导致我们服务不可用的问题

达达的业务属于实时性比较高的业务，如果业务不可用，已经发单的商户的外卖就没办法送出去，用户就没办法准时收到产品，所以只要出现问题，我们的客服的电话就直接被打爆了。

最终让我们做出决定的是在我们的订单量到达每天30万的时候，数据库开始变得不堪重负了，每天到我们午高峰的时候，磁盘的IO都会异常的高，我们把数据库的配置参数innodb_flush_log_at_trx_commit从原来的1改成了0，这两个参数的区别在于，如果使用默认的1，则每次事务提交的时候，mysql会将log buffer写到日志文件里，之后再从这个日志文件flush到磁盘的数据文件；当设置为0的时候，mysql会按照1秒钟的间隔定时的做上述的操作，而在事务提交的时候不做上述的任何事情，这样，在数据的安全性上会有一定的降低，在server宕机或其他极端情况下，有可能丢失掉1s的数据。很显然，在当时的情况下，我们只能损失一定的安全性来保证系统的可用性。我们跟第三方服务方讨论数据库的分库分表方案，对方要我们跟商务谈，意思是可能还要加钱，而且一做估计有需要一两个月，很显然，我们的系统到一两个月后肯定是到极限了，如果再出现个什么事情，整个账户系统就没法收拾了，于是我们做了几个决定：

• 关闭原财务账户系统不需要的服务

• 关闭原财务账户系统不必要的log记录

• 做我们新的账户系统

总结

钱在一定程度上可以买到时间，前提是你能找到一个靠谱的服务提供商，反之，如果服务商不靠谱，非但节省不了时间，花费的时间有可能更多。总结下来，我们的这个第三方，排除服务上的问题，系统层级上，如果面对的是中小企业的，并且交易并发不高的，系统应该是够用的，我们后面自己开发的财务账户系统，很多思维也是借鉴的这套第三方系统。

白银时代 - 跟时间赛跑的三个月

一但做好了决定，我们立即展开了新的账户系统的开发，此时的人手是2个工程师。 我们的计划是花2个月，开发出一个叫账户核心的东西，包含了之前第三方服务的主要功能，用1个月时间进行数据校验，之后正式切换。

账户核心包括的功能有：

• 账户管理

• 交易模型管理

• 用户钱包

我们的这两位工程师非常给力，在同时处理原来老的业务的同时，两个月内突击开发，将账户核心的功能开发完毕。 

于此同时，数据库的瓶颈越来越明显，我们通过将DB的数据盘换成SSD又稍微给我们争取了一定的时间。 

2015年8月21日，在原第三方账户系统权限崩溃的日子里，我们切到了我们新的账户系统。而就在前一天，我们在两套系统的数据check中还发现了一个小bug并且修复。也就是说，如果这个bug迟修改一天，我们依旧没法度过这个难关。在持续观察数小时，数据一切正常后，我们的心才落下来。此时，我们的系统数据同步写到我们的账户核心，异步写到第三方的系统。

总结

热火朝天的六月份到八月份是我们跟时间赛跑的三个月，还好，我们刚好跑赢了时间，我们顶住了压力，这套系统即使在后面每日单量接近两百万的时候，依旧比较稳定的提供着服务。

黄金时代 - 细节是魔鬼，每一个模块都十分重要

我们接下来做的事情是完成模块的细分，为了应对日益增长的支付充值的需求，我们独立出收银台，从原来单一的支付宝渠道之外又将微信渠道，某银行渠道接入进充值渠道里。

同时财务同学对账户调整的需求以及一些简单流程的审批需求也越来越大，我们把财务管理工具也开发出来。

原来我们的配送员的工资提现都是通过数据库里拉取list，按照财务规定的格式打款。技术的本质是提高效率的工具，我们在财务管理工具里对接了支付宝，让财务负责资金的同学可以更加快速的进行线上付款。

达达的业务依旧在飞速发展，公司的融资也是一轮接着一轮，每个月财务的同学都需要准备数据，往往每到月初，我们需要被关到一个房间里，从业务数据库里把订单发生的每一笔资金情况导出，费事又费力。这时候我们就想，我们要做什么来解决这个问题？
除了业务台账外，我们增加了一种记账方式来保证我们能够记录所有的业务资金发生，我们称之为“资金帐”。

我们让业务在调用交易模型进行账户资金发生操作的同时，往记账服务里插一条或者数条资金流水，我们能够保证记账服务里记录的一定是实际发生的资金转移，跟业务台账的区别是，业务台账是业务期待发生的资金转移，而资金帐是实际发生的资金转移。

有记账当然就有对账，理论上业务台账跟资金帐应该也是没有差异的，但实际上由于种种原因（如网络原因，IDC机器的稳定性问题，数据补偿机制不全的问题等），总会是有差别的，而对账的任务就是消除这个差异。

16年5月份，达达的业务和到家的业务进行了合并，财务账户团队除了要服务原来的配送服务，到家的服务我们也会提供有力的支持，这需要我们的系统更加高效、可靠。

我们将账户核心进行了分拆

• 拆分出结算平台，负责公司的各业务线的结算业务。

• 拆分出收付款平台，负责公司代收代付业务。

• 账户核心更名为虚拟账户及交易模块，负责虚拟账户管理以及交易的管理。

• 记账服务新增报表服务，负责财务相关报表的输出。 

总结 

现在每天在新达达财务账户系统上的资金流水量每天为千万级，流水总发生额过亿，该系统在新达达集团发挥了越来越关键的作用。随着模块的越来越清晰，我们要深挖每个模块的细节，更加细致的让每个模块持续稳定的发挥它们的作用。