点击「京东金融技术说」可快速关注

「摘要」白条早期定义为低频高额的消费产品，贷后以订单模式对外服务，现如今，白条日愈壮大，随着用户体量的攀升，场景不断的扩展，加上外单模式的并入，白条的使用频率越来越高，每月多个还款日会造成用户体验的缺失，因此白条账单模式应运而生。每月固定账单日和还款日，降低了用户的记忆成本，从而提升用户体验；与此同时，账单模式还能缩短资金实际占用时长，增加生息资产，同时减少渠道成本，由此诞生了白条天枢项目。

天枢系统架构

白条天枢项目经过3个多月的努力和拼搏，已于2017年4月20日正式上线，5月2日正式对新激活用户开放，5月12日正式切换第一个订单制老用户至账单模式，面对千万级的庞大用户数量以及６１８的高频访问及交易流量，对天枢系统是个巨大的考验，在检验系统稳定性的同时，确保账务准确无误，确保用户体验得到保证。

白条天枢系统业务的复杂度是比较高的，它不是一般的账单模式，而是新型的账单模式，具有互联网+的账单模式，即要像信用卡一样的账单，也要兼容白条分期的模式，天枢系统把账单模式和分期模式整合在一起，从信息流无缝的对接，到资金流正常的流转，合理利用多机房分布式的部署，底层数据采用分库分表的储存方案、缓存预热、异步处理、数据同步复制等技术，大大提升了白条业务系统的高性能、高质量和高可靠。下图为天枢项目整体设计：

业务架构

系统包括了两部分：白条分期和白条账单。白条分期主要由贷款单、分期单做为核心部件，所有的贷、还、逾、退围绕着贷款单和分期单做处理逻辑。白条账单主要是在白条分期的前提下，新增加了账单、账单明细等，将在账期内消费的订单进行打包汇总，生成一笔总的月度账单，还款模式也和之前分期模式下有所变化，以账单维度进行还款，大大减少了用户还款的频率。还支持按最低还款额还款，账单的分期为用户减少资金压力。

采用的技术框架为springmvc +JSF+JMQ 、容器使用tomcat、数据库采用mysql的集群、mongodb、ElasicSearch、Hbase、缓存使用R2M 做为白条天枢系统的整体开发部件。

白条的订单数据量是非常大的，而分期单和账单明细比订单还需要大6~12倍，面对这么大的数据量，而且数据基本上是热数据，白条采用按用户来做Hash做分库分表处理，在应用服务访问数据库时，必须通过路由访问层，取得用户所在的路由信息，通过动态路由算法返回用户所在的库及表进行数据的查询及更新操作，所有白条mysql集群配制dbrep服务，通过解析mysql的binlog 进行对线上数据的复制处理，将解析出来日志文件通过kafka消息中间件发送给数据平台，由数据平台按顺序消费此消息，将消息异步存放在ES集群、Hbase集群及mongodb集群，数据平台提供查询及写入的API，供其它的外部系统及平台来进行访问及加工处理。Dbrep 整体架构如下：

京东金融自主研发的数据库复制工具Dbrep是基于kafka、zookeeper、flume搭建的准实时数据同步系统，其主要涉及以下几大模块：

• Dbrep-node：是dbrep的运行容器，根据配置，其上可以运行dbrep提供的各种agent组件，如数据采集、数据落库等常用数据同步组件

• Dbrep-consumer：以嵌入的方式运行在用户的应用程序上，根据配置从消息中间件订阅消息，并交给用户相应的处理器进行处理

• Dbrep-console：dbrep配置管理控制台，负责node和consumer具体配置信息的配置，及状态监控，异常告警等基础功能

• ZK集群：存储dbrep基本配置，以及dbrep各节点间状态协调

• KAFKA集群：存储数据变动记录

Mysql数据库数据变动采集：通过模拟mysql的slave的方式，实时获取增量binlog，通过解析binglog，采集到数据库变动内容，并将变动内容以json格式存储到消息系统。（schema和表级别）

白条618备战

容量预估

备战618，对容量的预估是一个重要的环节，通过以往的618及双11的数据分析，可以预估计当年618的量=2倍去年双11的量，白条也是按个规律来增速。

服务拆分

服务不拆分的问题

• 从2014年消费者金融上线白条以来，白条的业务系统扩张成倍的增加，之前的系统为了满足业务的需要和快速的发展，同时为了减少服务器的成本部分，核心的业务都是部署到一个tomcat实例里，如果一个核心业务出现问题会给其它业务也带来致命的影响

• 上线一个非核心的业务，从而导致整体部署失败，直接影响可用率

解决办法

白条未拆分之前的部署环境，是把白条支付，白条退款，白条还款三大最重要的业务部署到同一个tomcat实例里，当有白条还款出现问题会直接影响到白条支付或白条退款，这点在系统上不是允许的。为了更好的解决这个问题，我们将白条的核心业务做了拆分，白条支付只能部署白条支付的业务，不处理其它任何与白条支付无关的业务，白条还款，退款也是一样，只部署与白条还款、退款的业务。

拆分的优点

• 各业务系统互相不依赖

• 方便扩容及问题的排查

• 结构清晰，方便后续维护

• 功能单一，技术研发人员读起来轻松上手

白条性能调化参数

调整数据库连接池参数

数据库的连接池的参数设置的合理性，直接影响到应用实例和数据库交互，设置过小会造成连接不可用，设置过大浪费太多的资源，因此数据库连接池参数的重要性是不可忽视的,白条使用的数据库为mysql数据库，采用分库分表储存方式，应用程序通过DBCP来访问数据库，其中核心的参数设置如下：

maxActive：链接池中最大连接数默认为8。

maxIdle：链接池中最大空闲的连接数默认为8。

minIdle：连接池中最少空闲的连接数默认为0。

maxWait：当连接池资源耗尽时，调用者最大阻塞的时间，超时将跑出异常。单位，毫秒数;默认为-1。表示永不超时。

minEvictableIdleTimeMillis：连接空闲的最小时间，达到此值后空闲连接将可能会被移除。负值(-1)表示不移除。

timeBetweenEvictionRunsMillis：每隔多少秒运行一次空闲连接回收器,用于回收空闲的连接数。

合理的连接池设置为：

• 评估数据库的最大连接数的设置,一般mysql单库的连接数不超过6000

• 评估应用实例的个数，单个实例设置的最大连接数*总的实例数据小于mysql 的总的连接数据

• maxIdle值与maxActive值应配置的接近

• 高负载系统的maxIdle值可以设置为与maxActive相同，让连接数量在minIdle与maxIdle间波动

调整tomcat参数

• Tomcat最大线程数（maxThreads） 设置1000

• Tomcat最大备用线程数（maxSpareThreads）设置750

• Tomcat最小备用线程数（minSpareThreads）设置50

• Tomcat 排队请求个数（acceptCount) ）设置为1000

• Tomcat URI编码为UTF-8

调整JVM参数

• Xmx设置JVM最大可用内存为2G

• Xms设置JVM促使内存为2G,此值可与-Xmx相同，避免每次垃圾回收完成后JVM重新分配内存

• XX:MaxPermSize设置持久代大小为256M

• XX:+UnlockExperimentalVMOptions设置解锁任何额外的隐藏参数

• XX:+HeapDumpOnOutOfMemoryError设置JVM在遇到OutOfMemoryError时拍摄一个“堆转储快照”

• XX:HeapDumpPath=$CATALINA_BASE/logs设置dump路径

• XX:ErrorFile=$CATALINA_BASE/logs/java_error_%p.log 设置错误文件日志

调整超时时间

• 数据库url超时配置(单位ms)

• ibatis配置超时时间(单位s)

• spring配置事务的超时时间(单位s)

超时时间在高并发系统中，是非常重要的参数，设置不合理可能会给系统带来极大的影响，请求处理不过来，造成服务的不可用，从而影响到正常的业务。

性能测试

读服务性能测试

读服务的性能测试一般是根据业务在各级的展示入口，如,当月、日待还，白条总额度，白条的资产总页面等。在大促期间，这些入口的量也是爆发式的增加，在性能测试这块，针对这些入口评估的压力值，一般为平常的10倍~20倍，比如说PC,APP的商品详情页面，在展示白条分期时，在618当天的调用量可达到15亿次的调用。

针对读服务的性能测试我们采用了如下处理办法：将线上服务拿一部分实例出来，通过JSF不同的别名，针对入口的单接口做压力测试，观察数据线上应用实例的情况，观察网络，磁盘，CPU,数据库的负载。

白条压力测试单台应用服务器的CPU图

白条压力测试单台应用服务器的TCP连接图

白条压力测试单台应用服务器的磁盘写入图

白条核心库的负载图

性能测试不达标解决办法：

• 服务器负载的问题，通过机器扩容或自动扩容解决，通过上下游的应用服务器来评估合理的机器数量

• 应用本身的问题，响应时间过长，通过走读代码，发现代码的瓶颈并进行优化，该增加缓存就增加缓存,设置合理的缓存失效时间 ，如果是数据库的问题，增加索引或扩容数据库来分摊压力

• 网络问题，通过升级网络核心的设备来解决

写服务性能测试

写服务的性能测试是比较困难的，为什么这么说呢，原因比较简单，就是生产的所有数据都是真实的交易数据信息，为了解决这类问题，在考虑做写服务的性能测试时，特别申请了同线上同一机型的N台数据库服务器。

搭建写性能环境：

• 申请应用数据库服务器，同线上保持一致，包括数据容量、服务器的性能、网络环境

• 申请注册的性能测试账户信息

• 写应用的逻辑修改，通过测试账户数据信息，动态路由到新的测试数据库环境，与生产保持隔离

• 隔离MQ消息及上下游相关的数据

性能压力测试:

• 通过自动化压力测试平台，将测试账户录入

• 指定JSF的别名为压力测试的别名

• 以小部分的量进行并发压力测试，后续逐步放大，观察数据库、应用服务器、网络、TCP 连接等关键指标

混合场景性能测试

混合场景的性能测试就等同于线上高并发的流量进来一个模拟，通过此场景来发现在单独读性能测试和单独写性能测试的不足，从而找到系统在整个高并发环境里的缺陷，并安排后续的改进工作。

切换演练

为了保证服务的稳定性，切换演练是每年大促前必做的一件事情，切换演练具体包括许多方面，如数据库、VIP、JMQ、接口降级等。

数据库的切换演练

数据库采用主从模式，多机房异地部署，应用在配置数据库的连接时全部使用域名的方式进行访问，域名到VIP的这层，是动态可配置的，一般情况下不做修改，在数据库服务器出现问题（X机、硬件问题等），会自动切换到指定的从库VIP下，来保证服务的高质量。

vip的切换演练

白条在外网的通过https访问，就少不了对VIP的依赖，在商品详情页面，https的方式来访问白条的分期展示，默认是按正常的一个vip 对应不同的机房，当VIP发生问题时，手动调整VIP的切换来保障整体的服务不受影响。

jmq的切换演练

JMQ 是京东自主研发的消息平台，全公司的研发消息处理都走这框架。白条做为非常核心的业务，所有核心的JMQ 都是单独部署并支持通过topic 来进行切换，通过jmq演练，为业务系统提供最可靠的服务。

降级开关演练

大家可以想想为什么在双11的0点，某宝还款是不可用的？答案其实比较简单，就是为了保证某宝在双11的 0点的交易，才这么做的。

白条在开发接口或应用时，针对接口必须提供可降级的配置信息，此配置数据信息直接接入白条单独部署的UCC的配置中心系统，为了保证大促，针对系统接口的划分也是不一样的，一些0级系统不能降级，一些展示类、流量类入口是可以降级的，当流量异常爆发时，通过开关的降级，保证最核心的业务不受到影响。

互动有奖

上面一堆硬干货是不是脑浆变胡辣汤了呢？

让我们来轻松一下吧！！！

最重要还有小小礼物拿 \\*^o^*//

请问白条的底裤是什么颜色滴？

说出你的理由，只要它足够牛，就有奖品（3名，帝都京东大厦自取）

京东金融技术说

▼▼▼

原创·实用·技术·专业

不只一技之长

我有N技在手

你看，我写，共成长！