字节跳动的金融野心

来源 | CSDN

作者 | 马超

日前，武汉合众易宝科技有限公司（简称“合众支付”）股权变更引起广泛关注。因为穿透下来，接盘方背后站着的实际控制人是字节跳动创始人张一鸣。

尽管张一鸣掌控的其他公司斩获支付牌照并不意味着字节跳动直接掌控支付牌照，但字节跳动对此的回应透露出了默认的味道。9月3日，字节跳动方面向多家媒体确认获取合众支付牌照的信息，并表示此举将有利于提升用户体验，与其他支付方式一起更好地服务字节跳动旗下产品的用户。此次，字节跳动已获三张金融牌照，分别涉及保险经纪、互联网小贷、第三方支付。

没有支付牌照的互联网公司，算不上是一家行业巨头，阿里、腾讯、京东、美团、百度等都手握这一重要底牌。不仅如此，微众、百信等互联网银行其背后也都有BAT的身影。 第三方支付牌照是字节跳动借抖音进军电商交易的闭环，另外一方面对于字节跳动完成今年的业绩也是大有好处。前几年，字节跳动的营收上涨很快，从2016年的60亿元窜升到2019年的1400亿元，据称今年字节的营收目标要突破2000亿，而无论是年初的新冠黑天鹅，还是近日TikTok的强卖事件，对于字节跳动的高速增长而言都蒙上了一层阴影。

在这样的背景下，字节渴望通过支付牌照建立自己的金融帝国，一扫之前阴霾的用意也就非常明显了。 不过就公开资料来看，字节跳动之前的技术栈还是聚焦在AI算法推荐与视频技术等领域，没有过支付系统的相关经验，类似于Oceanbase、TiDB这类金融级数据库的研发经验似乎更是缺失，然而金融级数据库是恰恰是支撑支付系统的重中之重。下面，笔者就带大家一起来走近三方支付背后的金融帝国。

支付体系也险些被卡脖子，我国支付体系建立的前世今生

有些用户可能不会了解，其实我们在2000年上线的一代支付系统还是世界银行援建的项目，从设计到实现全部依靠国外的技术，因为当时我国的程序员是不懂金融的，而金融业也不懂IT，在2000年之前我国金融行业的IT部门，基本都是由会计部门下属的，在那之前我们几乎没有一个现代化的电子支付平台。

在上世纪90年代初期，银行的IT系统有个专有的术语叫“会计电算化”，从这个名字也能看出来，这是将会计使用的账本由人工记账变成电子记账，这种系统的设计不太会考虑什么互通互联的场景，当时各大银行基本都在体系内部开展卡系统的研发，也就是将银行的会计操作打造以各自零售客户资源为依托银行卡网络，形成了互相独立的发展模式。

这种分布式0.1版本架构的好处就是银行无法推托责任，必须对用户的投诉问题负全责，不过其缺点也十分明显，那就是各行的银行片标准不统一，遇到有刷卡需求的客户，商家要先找到那家银行的POS机开机签到后才能完成收款，整个交易流程比较繁锁。 后来为了提高银行卡使用的便利性，国家启动了“金卡工程”，中国银联在也在各地卡中心的基础上建立起来。

在成立之初，银联发布了《银行卡联网联合技术规范》，通过统一标准全面整合了ATM和POS等自助终端，建立起了现在互联互通的支付清算体系。 但是随着交易链条的不断增长，系统也不断的趋向复杂，目前最简要的支付业务流程都要用联机交易、风险控制、日终处理等三大模块共同参与完成，而每个模块分出来还有很多内容，下面这么复杂的图其实也只能说个大概，而当银行卡使用到一定阶段以后已经略显僵化，灵活方便、用户体验更好的三方支付产品也是在这个背景下出现的。

风控与便利的对决，银行支付VS三方支付

可能很多读者都有这样的一个问题，为什么银行不做三方支付功能，如此之大的蛋糕为什么要拱手让人呢？客观地讲，这不能单纯归罪于银行不思进取，其背后深层次原因还是在于我国银行本质上还是有政府信用背书的，风险控制才是银行的首要任务，在这样的语境下求稳是银行安身立命之本。 下面举个例子说明，相信各位读者在生活中进行水、电费缴纳或者信用卡还款的时候往往都会看到这个界面：

凡是这种带有“银行处理中”字眼的交易其实都是非实时性的交易。支付系统链条中各方本质上互不信任的，所以对于这种实时性要求不高的业务以一般以银行的处理回执作为支付凭证，用作仲裁的依据。所以这个回执的发送都是极度审慎的，具体表现就是一遇风吹草动处理时间就会变长。可能大家都有亲身经历，虽然绝大部分时间在网上缴纳电费响应都很快，不过真到了年底出账那几天可能是半天等不到个结果，本质上都是由于审慎的风控思维。

第二个比较典型的例子，就是大额转账了，大家日常在网银转账时选择通道时经常会看到以下画面，其中的大额通道其实就是指通过大额支付系统转账了。大额的特点是实时到帐，但是细心的读者也会发现，这个大额转账的通道，不是7*24小时全天开启的，是有营业时间的，这本质上也是因为银行支付系统需要一定的对帐时间，来确保自身的账务没有问题。

而第三方支付的出现恰好弥补了便利支付产品方面的空缺，这种支付模式是由支付宝首创的，买方选购商品后，使用第三方平台提供的账户进行货款支付（支付给第三方），并由第三方通知卖家货款到账、要求发货；买方收到货物，检验货物，并且进行确认后，再通知第三方付款；第三方再将款项转至卖家账户。

银行基于自身风险考虑是不会对于自己不熟悉的商户或者买家提供信用担保的，这是一个银行不会进入的领域，因此在三方支付牌照刚刚兴起时，引得无数机构竞相争夺。 不过2017年初，中国人民银行发布了支付新规明确了第三方支付机构在交易过程中，产生的客户备付金（即从买家付款到卖家收款之间产生的资金池），今后将统一交存至指定账户，由央行监管，支付机构不得挪用、占用客户备付金。而随着这项规定的出台，这也从某种程度上度绝了三方支付公司挪用备付金进行投资的渠道，风光一时的三方支付自此降温，成为了金融巨头才会考虑的细分市场。

Sql or NoSql？

这是个问题   在解读了支付系统自身的逻辑及发展历史之后我们再聊聊其背后的核心技术。考虑到抖音直播带货这么大的交易量还需要支持秒杀场景的话，必须有一个强力的数据库做核心。

目前数据库基本分为两种类型，一种是非关系型(NoSQL)数据库，这是一种类似于Hadoop式的Key-Value型数据库，这种数据库专门为海量数据服务，不过要求数据之间的关联计算不能太多，像字节视频社交的相关业务用户每条动态之间几乎不会进行关联计算的，因此相信之前字节对于NoSql数据库应该是比较熟悉的；另外一个是在关系型（Sql）数据库，比如电商场景下客户的一笔交易既要动商家的库存又要动买家的帐户余额，这种场景下一般关联计算还是要用关系型数据库的。而像“双十一”这样的秒杀场景，对于数据库来讲，既提供海量数据服务又提供高性能关联计算服务，这种明显是需要技术积累的，而打通NoSql与Sql任督二脉的国内大厂除了阿里之外，好像只有2015年红包大战前的腾讯做到了。

在笔者所在的银行业，一般将涉及客户帐余额变化的交易称为动帐类交易或金融类交易，微信红包的金额可能不大，但其实用户每抢一次红包都涉及一笔金融交易，而如此大并发的金融类交易，在之前业界根本闻所未闻，在红包的背后关键要靠 数据库的支持。

在微信支付之前，腾讯与字节一样也基本没有过金融的业务场景，而相比之前的社交场景，金融交易对于数据库的在性能、灾难备份等等方面的要求要高得多，想支撑微信红包首先要解决数据库的问题。 当时的腾讯在数据库方面已经有了不少的积累，拥有了两个自研的数据库，一个是NoSql的CKV也就是TBASE的前身，还有一个是Sql型的CDB也就是TDSql的前身，不过当时两个数据库团队一起评估了一下微信红包的流量，这是一个天量加关联计算性能全都有要求的场景，所以当时的结论是CKV和CDB，恐怕都无法支撑起微信红包的一片天地。 据称当时腾讯团队甚至想到是否要采用类似于网游的分区策略，也就是让用户在自己的服务区内部抢红包，想跨区还得重新注册ID。

不过这个问题在春节前两个月时解决了，腾讯的数据库技术团队把CKV和CDB合体了，他们CKV 中插入了CDB的“树结构”，这样在抢红包的时候，系统就不用告诉数据库每个数字的变化，而是数据库根据已有的关键数据，自己补全剩余的数据。CKV与CDB的联合大大提升数据库的效率，也成了至今还被我国数据库界同仁所津津乐道的一段美谈。

爆发式增长的靠的是一招鲜吃遍天，而对于拥有远大志向的公司来讲，没有深厚的内功根本无法开宗立派。不过在基础内功领域内的竞争，并不像流量之战一样吸引眼球。正如淘金时代的最大受益者不是金矿主，而是那些卖铲子的人，所以我们看到科技巨头在基础技术储备方面都有非常惊人的储备，而如果字节跳动拿到支付牌照，也同时吹响他们要向基础技术进行探索与转型的号角，那么字节跳动的未来可期。