ITPub博客

首页 > 架构设计 > 设计模式 > 刘慎宝 :京东集团财务系统架构设计之路

刘慎宝 :京东集团财务系统架构设计之路

原创 设计模式 作者:李代丽 时间:2018-12-07 12:25:12 0 删除 编辑

【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时代的目标是 “联通一切,智能无界”。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31545808/viewspace-2284492/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-09-19

  • 博文量
    72
  • 访问量
    135081