【IT168&ITPUB专稿】本文根据刘慎宝老师在2018年10月17日第十届中国系统架构师大会(SACC2018)现场演讲内容整理而成。

讲师简介：

京东集团高级架构师，10+年互联网研发专家。2010年入职京东并历经几乎所有618和双11挑战。精通高并发服务搭建和业务建模，曾多次主导京东财务系统架构升级和数据库升级，主导结算魔方重构，订单台账优化、价保优化等重大研发项目，对财务系统有深刻理解。

正文：

不管是6.18，还是双11,对于财务系统来说，压力都非常大。电商大促，意味着每分钟几十万订单需要去支付、对账，然后才能进行生产，进行发票打印、资金结算，最终生成财务凭证。在财务系统支撑业务员运行过程中，京东走过了很多坑，希望这些经历，能帮助更多企业未雨绸缪。

京东的财务系统大概分三个阶段：京东分别用V1.0、V2.0和V3.0来归纳。

V1.0：业务领先，系统跟随

V1.0的时候，用八个字来形容，那就是“业务领先，系统跟随”。在2010年之前，京东业务主要聚焦在3C品类 。那个时候，互联网业务刚刚起步，主要以业务为中心，系统起到支撑业务的作用。对于财务系统来说，最大的需求就是快速搭建、迎合需求。这个时候的框架，用的是.NET的平台，语言用的C#，用membercache解决静态数据的问题，应对促销流。动态数据的读取问题，用数据库复制方式来解决。

V1.0阶段很快成为过去。2012年起，京东全品类扩张，结算类型更加多元化。京东财务系统也就进入了V2.0阶段。

V2.0：野蛮成长，系统林立

这一阶段的主要特色是“野蛮生长，系统林立”。京东财务的整个系统全部拆分成多个系统，系统之间相互关联。

为什么会形成这种特点?根源在于业务快速扩张和架构的大调整。

“站在巨人的肩膀上”，V2.0之后，京东财务系统选择了开源框架。从.NET的平台切换到Java平台。

当时的系统是怎样一种现状呢?系统林立。以结算系统为例，当时的京东有38条业务线，有20个结算系统。

当时订单量以几十倍的速度在增长，新上线了图书业务，和以前业务相比，新业务完全不同，体现在三点上。

首先，销售方式不同。包括实体书和电子书。在3C时代，京东只销售实体商品。

其次，采购方式不同。图书分供应商采购、总供应商结算，跟以前的逻辑完全不同，之前的结算系统没有这样的流程。

其三，结算方式不同。以前京东采购商品入库，然后结算。现在是由厂商配送，京东除了跟供应商结算货款外，还要结算安装费、售后服务费、售后维修相关的内容。

为了保持原有业务系统稳定增长，又要满足新业务系统快速发展需求，京东的做法是，来一个新业务建造一套新系统。

系统越来越多，研发和维护的成本越来越大，该怎么面对未来的成本压力，未雨绸缪-开启平台化整合。

进入2015年，业界有一个很出名的平台结构，那就是中心化结构。上层是实例，中间有中间层，底层是各种DB。中间层负责数据的存储、转化、查询。到设计的时候，让程序员专注于业务逻辑开发，不操心底层业务逻辑，大大提高了研发效率。

这种模式在特定阶段下很完美，确实能达到效果，但是我们没有采用!

在业务量恒定的情况下，中心化的结构没有问题，但是如果业务量持续增大，每天订单量增加到5000万，这样的架构就会出现问题。首先，这种中心化的结构，它的中心点就是最大的瓶颈点，在大数据交互的时候容易出现问题。比如：以现在2000万的订单量计算，如果要积累一年的数据，底层的数据库得有多少?如果按照500个数据库来算，任何一个故障，所有中间层就会卡死，系统拒绝服务，导致全局性的事故发生。

1、 数据库硬件出现问题

2、 局部数据库过热

V3.0：涅槃演化，归纳统一

从2015年以后，京东财务系统进入第三阶段，即“涅槃演化，归纳统一”的平台整合阶段。

“不要把所有鸡蛋放在一个篮子里“，形象的阐释了系统搭建要保证稳定的分布式思想，但是这种分布式设计架构存在中心集中数据查询成本问题 ，即要找出所有的“坏鸡蛋”，需要去每个“篮子”挨个寻找。如果底层分布太细，就会带来另外的成本压力。

总结来看，其实不管是哪种架构设计，都归为两类：一个是中心化思想，另一个是分布式思想。中心化思想它有利于数据统计，有利于数据汇总;但是分布式思想有利于分解数据风险。

如何把这两种架构思路统一，集装化部署?

京东财务的处理原则是，分布化拆分。双维度拆分，纵向和横向。纵向按照生产热度切分为生产数据和生产完毕的数据。这样生产数据已经是很小的一部分了，将生产数据再横向切分到N个计算中心里，每个计算中心之间是相互独立的。这样即使有问题，也是其中某一个点有问题，不影响全局。

计算中心的架构方式即为集装化部署，一套代码，研发一次，测试一次，多次部署，大大降低研发成本。

集装化，最基本的原则其实就是打包，把所有的实例DB缓存统一打包成一个整体，它可以集中部署，部署之后就就可以向外提供服务。并且，可以实时上线，增加线上的服务流量;流量下降后，可以实时下线。数据在计算中心只做流转，流转结束后，计算中心就清空。

回到之前的话题，京东财务如何解决数据汇总的问题?如何快速找出全部的“坏鸡蛋”?涉及到计算中心的一个特性：对下负责。简单理解，通过数据自动驱动，把所有的数据自动流转到下游。比如：出现坏数据，某个订单有问题，或者出现支付异常的情况后，订单会自动同步到异常处理平台。因为，异常处理的数据毕竟这占少数，这部分业务可以统一管理，简言之将坏鸡蛋自动汇总到一个篮子中。

另外，计算中心还有另外一个特性：对上负责。何为对上负责?对上就是指以服务接口方式注册到接单中心，提供服务，从而支持动态扩容缩容属性。

关于计算中心，还有一个插曲：京东价保系统的大促最佳实践。

价保，即在价保周期之内，你京东有促销降价，只要到点一下“申请价保”，系统就把差价退给你。大促期间的全周期价保，秒杀的巨大流量直接转移到价格系统的申请量。且计算逻辑更复杂，如计算你的商品的价保额，要取以前的下单商品金额，然后按照新的促销规则重新计算，再进行虚拟赔付、退款，每个系统都要交互，这中间的复杂性，是秒杀系统的几十倍。

价保系统的大流量并发处理和高计算能力，由两个计算中心群组成，第一个计算中心群是接单中心，负责对外接单;第二计算中心群是价格计算中心，负责调用各个不同的系统去核算可退金额。

下面我们来看一下使用集装化的计算中心构建的财务整体架构图

订单、拆分、商品、配送、仓储的数据，通过FDS数据转接层，然后下面对应每一个模块，包括支付对账、发票、清结算、资金、逆向。然后，最下面是抽象出来的各种平台，包括业务监控中心、流量监控中心、规则引擎中心、GPU计算中心等。对应各大银行进行清算。

以业务监控中心为例，所有的业务都会反映在数据上，反之通过数据变化可以实时生成业务监控报表，采集数据信息可以来源于DB、ES、MQ、缓存等，规则直接脚本配置即可生效。如：监控支付系统是否出现支付异常，只要将订单下单的消息数量和对账数量对比，如果差值过大，就一定是中间支付出了问题。

如何跟外部打交道呢?如果有接口，就通过财务接口来对接;如何没有接口，就通过RPA对接。

在京东财务系统架构图中，下面重点分享三个，即FDS、清算和RPA。

首先，FDS为什么会产生?从业务端看，我们在京东下单，消费者付钱，收货，这是一个整体过程。但在京东内部，被分为三个业务线，叫做“三流分离”，即信息流、资金流和物流。

信息流： 订单相关用户信息和商品信息;

资金流： 负责订单收多少钱，应收多少，应付多少;

物流： 仓库、运输、配送。

三流相互独立，但是京东财务系统环节，需要所有的数据信息，只能三流集中后才能进行业务处理。比如：一个订单要参与结算，需要这个订单的数据，包括商品类别，属于哪个供应商，商品的价格是多少，他采购价是多少……涉及到信息流和资金流，并且还要确认这个订单在多久以后才会参与结算，即物流。三流集中的就是由FDS系统来对接完成。

FDS其实就是一个数据处理平台，是把上面数据全部接下来之后，通过一定规则配置，清理成一定的计费数据，然后再流入清结算系统。订单数据经过清理，产生EBS中间表的数据，这样就可以导入EBS中间表。

其次是清结算。FDS把基本明细数据处理后，输入清结算进行结算。结算系统从V2.0时代的20个系统，被归纳为一个平台，叫做结算魔方。结算魔方的优化经过了三个阶段，即平台化、功能积木化、流程模块化。

在做结算的时候，京东遇到一个难题是，结算的牵扯的数量太大。如果每天按照500万订单来算，一年下来有多少数据?十年呢?京东的结算支持全生命周期防重，保证只要用户提交过一次结算，绝不能提交第二次结算。

在数据体量小的时候很简单，创建一个数据防重表就可以解决。但是在数量巨大的时候，还要保证性能高效，还要考虑硬件成本和研发成本，怎么解决?我们的解决方案是补偿性防重。

补偿性防重?结算数据拆分为准生产数据数据和结算完毕历史数据。

第一阶段： 准生产数据数据实现防重

用关系型数据库即可实现，降低研发成本，并且能保证接口性能，且组成计算中心可以横向扩展调度。

第二阶段： 二阶段补偿防重

结算历史数据存储在大数据平台，降低存储成本，而且方便后续分析

如果第一关防重过了，这时后台启动，自动去校验历史数据。如果历史数据校验确实在历史当中存在，已经被结算了，那这个单子会被打回来。

除了内部系统，还涉及到外部跟供应商系统交互。跟供应商对账，以前如果量小的时候，很简单，只要把销售明细，以excel的形式给供应商，按照这个结算就可以了。

但是，如果量大了后，每天几千万，一个excel根本玩不转。这个时候，财务要有一个统一对外接口，用ERP系统跟供应商系统对接，来确认要结算哪些单据，让供应商在系统里面直接通过统一的接口做系统之间的相互交互，这样就可以实现供应商自服务结算。

结算完要报税，常规的做法是会计人员去银行下载报税文件，然后导入。京东财务用RPA自动化的方式来解决。RPA是一个流程自动化机器人，可以实现CS端和BS端的自动调用。可支持二维码，滑块验证很多特性，可以实现银行对接，自动报税等跨系统重复性的工作。

归纳这么多，是希望把过去的经验进行梳理，提供给更多公司使用。为此，京东把一些优质模块(比如结算、财务)抽象出来，做成一个针对中小企业的解决方案，这就是朋贝系统。它可以针对ToC收付款，也可以针对ToB清结算，还能进行资金持有、管理。也能进行开票、报税，还能和政府系统打交道。其中，也附带了机器人功能。

走到V 3.0阶段，那么京东财务的下一阶段目标是什么?

未来是何种情景，谁都无法准确判断，但是互联网发展其实有一定规律可寻，从台式机、Internet，到现在的移动互联网、物联网，未来的发展趋势一定是连接一切，未来将各种数据统一接入系统，甚至政策信息等等。 通过联通各种信息的数据，做到更精准的资金预测，来支撑无界零售。

所以，京东财务系统的VX.0时代的目标是 “联通一切，智能无界”。