白条授信 | 生态系统架构及演进之路

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

---白条授信生态系统全家福，个个都是身怀绝技

「摘要」本文主要讲述了白条授信系统演变过程中的三个阶段，其次对整个系统架构进行了详细介绍，包括激活路由系统、组件化配置平台和监控相关内容，最后对系统进行了展望。

演 变 历 史

白条授信生态系统演变大致有三个阶段：

第一阶段：白条激活系统的第一版搭建是2014年6月，当时系统设计很简单，一个前端应用和一个后端应用，数据库是单库单表。当时只做了pc端一个流程。业务流程比较简单，仅通过银行卡鉴权完成实名认证，后续会走授信策略完成最终的用户激活开户流程。数据库仅采用sqlserver单库单表，用于数据的持久化。

第二阶段：之后随着业务的快速发展，增加了园区白条，乡村白条等，以及后续的开新，社交等业务流程，增加了许多差异化的激活渠道和应用场景。随着渠道越来越多，流程越来越复杂，这时带来以下问题：

• 入口多，太分散，难以统一管理

• 每个渠道之间界限难以界定，用户在后期管理中面临各种权限划分不清的问题

• 用户体验太差，整个开户体验很复杂耗时长

面对以上问题各渠道之间的协调和交互变得越来越重要，这时候激活路由系统孕育而生。这些差异化的激活渠道针对不同人群，满足业务，风控，以及产品体验上差异化的需求，同时还要最大化用户体验，最好的情况用户只需要点击一次按钮即可完成整个激活流程。激活路由系统承担对用户的分群和路由工作，用户在做白条开户业务前期的时候，它就已经开始工作，读取多个渠道的路由规则，结合渠道优先级完成相关计算后完成用户的分流，最后引导当前用户到最合适的流程页面上来。

此时应用系统也越来越多，在原来的单一系统上进行了垂直拆分，把一个应用按业务维度拆分成多个应用，数据库也从原来的一个sql server迁移到多个mysql数据库。

第三阶段：业务的快速发展是难以预料的，随之引来了新的问题：

• 新流程频繁的加入，并引入多种校验逻辑，相互间耦合不可避免，性能也越来越差；

• 海量的需求如洪水般涌来，目前团队成员已超负荷工作，工作进度依然无法令业务方满意；

• 依赖的外部接口越来越多且不稳定，系统内部互相依赖，系统频繁的出现问题，而且定位时间长。

针对以上种种问题新的升级改造势在必行。这阶段对所有的原子接口进行了组件化拆分和组装，并增加了可配置平台，可以很短的时间内配置出一套全新的定制化激活流程。同时对激活路由进行了多线程并行改造，更准确更快速的完成用户的分流，后面会对当前阶段的架构进行详细的说明。与此同时，所有应用子系统全部采用多机房部署策略，一旦某个机房出问题可以通过其他机房来保证业务正常运行，免受单机房故障影响。

前端工程根据不同运营商转发到相对应的机房，来处理请求减少跨运营之间的网络开销。每个应用的接口服务根据业务的重要等级也通过jsf采用不同分组来隔离，一旦出现流量高峰和异常情况，也能优先保证核心服务不受影响。最后数据库也做了水平方面的拆分，多库多表、主从互备满足海量数据的应用需求和性能需求。

技 术 架 构

总体概括包含三部分：激活路由，组件化&配置平台，监控分析系统。

白条授信生态系统，为什么是生态？它不是单单的一个应用系统。这里先列举一些数字，方便大家对它有个直观了解。它由24个核心应用子系统组成（这里还不算依赖的第三方应用），提供了200多个接口服务，10多个独立业务数据库（业务维度）涉及mysql，mongodb，hbase，总计数百张业务表。依赖的缓存工具有jimdb和r2m。数据监控方面有1000多个ump监控key和100多个rdp监控项以及400多张实时数据图表组成。整体技术架构图如下：

1、激活路由系统

首先介绍这个重要的系统，它就像整个生态系统的门卫和引路人，所有的请求都会先到达这里，这里会有两个环节，一类是名单类的校验逻辑，一类是用户信息相关的业务规则校验逻辑。后一类检验早期版本是放到路由后面进行的，这样会给用户体验形成一定影响，而且路由系统要对目前十多个激活渠道规则进行筛选，对系统性能也是一大考验。下面的图是路由前后两个版本的对比，左边是第一版，右面是改进后的第二版：

我们改进了原有顺序调用的次序，改成了多线程并行执行，实时筛选黑白名单和准入规则，并将结果落库，最后通过优先级规则和数据库的结果计算后得到一个最终的结果，整个过程依赖很多业务规则和第三方rpc接口的调用，但整体性能控制在了tp99在100ms左右。

在代码结构上也进行了大的重构优化，采用ExecutorService和模板方法设计模式等避免了原来大量if-else的方式，整体结构清晰可读性强。整个流程经过的每一个环节快照都通过mq异步存储到大数据中，用于后续的查询、离线加工和分析。目前线上承载的激活渠道已达到15种之多。

2、组件化&配置平台

随着业务的不断发展，越来越多的功能化模块被应用于内外部多个场景，不仅满足白条授信激活，还同时为金条，闪付，小白信用等等多个业务提供基础服务。组件化服务内部也细分了2个层次，最底层是原子粒度的服务，中间层是对原子服务的组合和封装，提供套装服务。

用户信息及属性相关都持久化到数据库中，数据表结构采用窄表的设计思路，具有很大的扩展，同时采用缓存来提高性能，并且采用jimdb和r2m双缓存的互备双写方案，其中一个出问题，可以通过zk开关来控制，做到秒级的切换。下图是双缓存的交互图：

另外还配备了一套配置管理系统，这个系统用于配置差异化流程所需要的关键要素以及功能节点。举个例子，之前要开发一套激活流程，由于定制化程度很高，都需要开发人员参与来实现，依赖的外部数据等等都需要按照新要求对接，测试上线等，整个过程需要多个开发人员全程参与，工期漫长，风险也很高，当业务需求增加或频繁变更时，人手不够就只能排队。现在真的可以说是分分钟完成一个业务需求的定制化开发，整个开发测试最快情况可在一天内完成，而且配置灵活能应对不断更改的业务需求。配置系统细化到每个接口字段上，通过MAP映射，灵活的对接上下游系统，甚至不用改一行代码。

3、监控系统

这里着重说一下监控系统，它依赖了多个监控系统来完善并最终实现了整个立体网状的监控。这个不仅包含了UMP，SGM，还有RDP和业务系统本身实现的上下游系统监控。监控是多纬度立体式的监控，不仅包含系统每个接口性能，存活，硬件监控外，还有数据的通过率和环比监控。

很多开发人员在完成一个需求开发上线后，基本就是代表这个工作的结束。但对我们而言，这仅仅是刚刚迈出第一步，监控系统将实时监控每个功能流程的各项指标数据，重点分析流程的整体转化率，甚至是每一个环节的转化率，如每种鉴权方式的通过率，用户主动流失率等等，进而通过各项数据指标来优化调整流程。对于某一种数据的波动也能分钟级的监控到，新的入口开放，活动上线，甚至黑产人员来作案都可以通过这些监控和图表清晰的查看，了如指掌。

上下游系统间的监控是在远程rpc调用的环节记录下第三方系统的上游返回结果和下游系统的结果，通过mq推送到监控数据表中，并通过worker来实时扫描每一个关键字段的信息进行比对，包含数值相同比对、数值区间、数据转化等比对项，发现异常及时的报警出来。有了这些细化到毛细血管的全方位监控，真正做到了在系统有一点的风吹草动的时候，都能够感知到，并且辅助的定位问题，有如鹰眼一样敏锐。

展   望

最后展望下未来，目前这个系统还有不完美的地方，也不是演进路上的终点。例如在激活路由环节还可以增加数据回流，大数据分析，实时的优化用户的路由结果，达到更精准更实时的效果。在数据持久化方便尤其是敏感数据的处理和使用更加高效和更加安全。

最最后在写这篇文章的时候，我正在内蒙进行自驾游，穿越草原，沙地，湖泊，丘陵，一路领略了各种各样的风景。就像在京东工作的的这三年里，经历了大大小小的无数次升级改造，抗过了多次的618和双十一的大促，回头看来系统每一次蜕变都能感受到它的美丽。在此放上一张达达线的公路美景，路在脚下，让我们继续前行...

     @李曼@白衣@郭江江@常平的机器遗忘世界  上期积极互动的童鞋到A座8层280工位找我领奖，过期不候哦

京东金融技术说

   ▼▼▼     

原创·实用·技术·专业

不只一技之长

我有N技在手

你看，我写，共成长！