作者： xuecy 原文来源：https://tidb.net/blog/59ded91b

近年来互联网银行、P2P 平台如雨后春笋般地涌现，随着其规模不断扩大，已经开始威胁到商业银行传统个人信贷业务的市场地位，使得商业银行不得不采取措施应对这一新的市场竞争。金融行业早已非几十年前的垄断行业，线下信贷市场竞争激烈已近饱和，互联网， 信贷的兴起对商业银行而言不仅是竞争更是机遇。然而随着互联网个人信贷的发展，其所面临的问题和以及暴露的风险也接踵而来。自 2017 年下半年以来，监管部门出台《关于规范整顿“现金贷”业务的通知》、《小额贷款公司网络小额贷款业务风险专项整治实施方案》等监管政策。彰显了国家对互联网个人信贷市场的重视，市场也变得更加规范，商业银行在这个阶段介入将是良好的机遇。

互联网信贷市场潜力巨大，在互联网金融的大背景下，商业银行个人信贷业务完全可以向线上迁移，并且实现线上和线下的有效结合，这种结合将大幅提高商业银行的信贷收益。同时现阶段商业银行互联网个人信贷的发展有一种创新方式，就是金融机构和优质平台开展联合贷款，通过合作共赢的方式来扩大产品规模。

一、贷款业务模式现状

贷款类业务主要涉及两大类业务场景：

l 联机交易场景 ：面向具体用户端的单笔交易请求，对单笔交易的响应时间有较高的要求；

l 批量任务场景 ：面向金融机构内部的批量业务处理，属于计算密集型的工作，对处理机制及系统资源有较高的要求。

在商业银行将信贷业务由线下向线上演进的过程，给 IT 系统建设带来了很大的挑战，对数据量和实效性要求越来越高，诸如如下场景：

助贷业务的实时线上化（图 1）

​

联合贷业务的实时线上化（图 2）

​在以上业务场景中，各商业银行通过与互联网银行或者第三方支付系统合作，采用业务流程全线上技术，按照约定的资金比例，基于双方共同认可的规则审批制度，为符合特定准入标准的客户群，提供个人信用贷款，用于其生产经营周转，互联网银行或者第三方支付系统负责组织、发展客户，进行客户的贷款开立、发放、批量扣款等贷款生命周期内的业务管理，包含：

• 系统间数据交换： 网上直销 、信贷系统（额度扣减、释放）、财务管理系统数据归集等

• 系统内资金清算 ：批量代发带扣（房贷、信用卡还款、工资代发等）；

• 内部业务处理： 结息、计提等；

• 对账相关处理： 一般和第三方系统对账等；

• 数据平台准备数据： ETL、数据仓库、大数据平台等；

• 相关报表： 合规报表、监管报送、领导驾驶舱、审计财务报表等；上述各业务环节的数据量在快速增长，要想处理的又好又快，就要涉及到分布式、缓存等新一代技术架构的建设和升级，应对业务发展对高吞吐量、自动化、健壮性、可靠性、扩展性的技术支撑能力的要求。

二、传统技术架构

如何打造一个高可用、高性能、易扩展、可伸缩且安全的，且能够支撑线上个贷业务平稳、健康、可持续开展的应用系统迫在眉睫，传统银行 IT 人才的知识结构也多偏向 “IOE” 技术路线，更换技术路线对他们的知识结构也是一个挑战。

贷款系统在建设之初就要求系统能够快速准确完成大批量的数据导入、导出和业务逻辑计算，自动执行业务逻辑处理，希望批处理任务能够自动正确运行，最大限度减少人工干预，能够自动完成批量任务，遇到故障能够有完备的监控和告警机制，应用要足够健壮，第三方渠道过来的网贷数据经常有不规整的数据，客户期望不会因为数据错误或者无效数据导致程序崩溃和批处理失败，要求系统具备极强的容错能力，同时要求系统足够可靠，方便进行监控、跟踪和日志分析，灵活跳过、重试和重启，最后要具备灵活扩展性，网贷业务增长迅速，业务增长带有不可预知性，希望根据业务实际增长，动态进行弹性扩展。

经分析，发现银行传统架构有明显的局限性，满足不了贷款业务的互联网化的发展实际要求。

1、应用架构

传统商业银行的架构大多为集中式，硬件资源有很多还是 IBM 的主机和小型机。应用多为单体应用，即烟囱式开发模式，这种模式弊端很明显：

• 系统间集成、交互和对接成本高昂 ：“烟囱”系统连接需要不同技术团队间的协作，有很大的协调、沟通成本。不同系统架构、技术各异，还会导致五花八门的对接方式，成本高。

• 业务变化快、灵活性差 ：烟囱模式下，一个业务变化可能会涉及多个系统重复修改，系统间接口重新调整。随着各系统不断积累，逻辑越来越复杂，系统修改和接口调整会越来越难、代价越来越大。

• 抑制业务创新 ：每次创新都面临大量重复建设，在新开业务和创新项目尝试时，不得不面临较大的前期投入。一旦方向出错，损失巨大。

• 扩展性差 ：集中式应用架构，由于应用端是单点，如果出现硬件故障，系统完全不能使用，另外，如果系统的负载已经达到这台机器的上限时，很难通过快速扩展实现处理能力的提升，单纯的硬件资源的提升不仅成本比较高，并且还有上限。

2、数据库架构

银行关键业务系统数据库多为单机数据库，比如 Oracle ，DB2 等，也有部分非核心业务系统基于 MySQL 去构建，在传统数据库架构上也存在不少挑战：

• 扩展性差 ：集中式数据库的数据处理能力有限，尤其是涉及超过几千万甚至上亿的数据时，数据操作的响应时间会大幅下降，又不能通过增加机器的方式来解决。

• 成本高昂 ：随着系统的演进，性能指标不断发生变化，需要不断采购 CPU、内存、存储等资源满足业务发展，越往后成本会越高，并且即使增加了物理资源也不一定可以解决问题。

• 运维管理复杂 ：不断发展的大规模系统需要不断维护、快速迭代和优化。单机数据库运维变得越来越复杂。无法进行快速部署、升级、扩容和维护。

• 数据库国产化选型困难 ：缺少专业团队、经验外，更重要的是来自国内产品成熟度风险。传统银行个贷业务系统业务品种多、业务逻辑复杂，对实施厂商来说技术实力要求非常高。

三、分布式技术架构

分布式架构可以在系统的各个层面都具备横向扩展的能力，当系统出现瓶颈的时候，都可以通过增加部署节点的方式快速解决，可以很好的解决互联网贷款面临的高并发、大数据量的挑战。如果要用分布式的理念对银行的联机交易系统进行架构升级，需要涉及以下多个维度，以形成完整的分布式体系：

• 应用分布式： 通过对业务功能进行拆分，使业务系统更加灵活，同时每部分多实例运行，大幅提升系统的可用性及处理能力。

• 数据分布式： 通过对数据的分布式存储及访问，提升大数据量表的访问能力，增加数据库整体运行资源。

• 分布式缓存的合理使用： 降低数据库的访问次数，提升单个服务的响应速度，间接提升系统整体处理能力。

• 分布式事务： 针对不同业务场景，提供切实可落地的方案，解决跨服务、跨数据节点的事务一致性问题。

• 分布式调度： 协调多个分布式节点协同工作，有效控制日终处理时间。

上面提到的应用分布式目前主要以微服务的方式体现，已经形成一个独立的领域；数据层的分布式也是一个专项领域，尤其是以分布式数据库为代表的解决方案已经成为当前的主要模式。神州信息和 PingCAP (北京平凯星辰科技发展有限公司) 分别在分布式架构和分布式数据库两个领域属于行业领先水平，并且有多个客户端的成功案例。

1、应用架构

针对集中式应用架构的缺陷，神州信息自研了分布式技术平台 Sm\@rtGalaxy，其是基于对银行业务的深入理解，结合业界最新发展趋势，形成的一套完整的面向金融行业的分布式技术体系。在该体系下，系统的各个层面（服务、数据、缓存及计算）都具有分布式的特点，当某层成为瓶颈时，就可以利用分布式的特性，通过增加节点的方式进行解决，为系统的可用性、扩展性及性能等需求提供可靠的技术保障。Sm\@rtGalaxy 具有如下特点：

• 完整的微服务体系： 基于行业主流的 Spring cloud 构建完整的微服务体系，同时提供对应的开发平台支持，实现对应的 DevOps 能力，满足生产级的要求。基于该微服务体系，可以快速构建不同领域的微服务，快速应对市场的变化，并可以针对负载的差别做精细化的运维。

• 轻量级的数据分布式解决方案： 在应用架构层的数据分布式存储及访问，提供最小代价的数据分布式能力，可对接常用的 Oracle、DB2、MySQL 数据库，以及最新的分布式数据库 TiDB 等。

• 行业领先的分布式事务处理机制： 提供多种分布式事务的处理机制，应对不同的业务场景，尤其是默认的 SDT 模式对业务系统几乎没有侵入，就可以实现跨微服务和跨数据库的分布式事务，解决了分布式事务很难落地的行业难题。

• 无侵入的分布式缓存访问机制： 采用注解的方式完成缓存跟数据库的配合操作，对业务系统几乎无侵入；并且对读写交叉及并发写缓存可能造成的脏数据有完整的控制机制，其大幅提升金融系统对缓存的使用率，对整体的处理能力有进一步的提升。

• 开箱即用的典型业务场景支持： 在上述分布式体系之上提供了一套面向金融的典型的业务场景的应用框架，包括典型的联机交易、日间批量及日终批处理等的支撑，开发人员只需要在其上开发具体的业务逻辑就可以快速构建一套分布式特性的业务系统。

• 金融场景深度定制的分布式调度体系： 采用分布式的理念让更多的应用服务器和数据库服务器参与到运行体系，以及对大数量表在内部进行自动分段处理，大幅降低日终批处理的执行时间。

2、数据库架构

TiDB 数据库是国内厂商 PingCAP (北京平凯星辰科技发展有限公司) 自研的开源分布式关系数据库系统。该数据库是基于 Google Spanner/F1 架构的设计思想完全自主实现的最新一代的分布式关系数据库，具备一键见水平伸缩、分布式事务、强一致多副本数据库安全、云原生、高度兼容 MySQL 协议和生态等政要的分布式数据库特性，为金融类数据分布式处理提供了可靠的保障，具体特性如下：

• 水平弹性伸缩： 在数量动态增长和业务动态回收资源时，只需要通过增加或者减少机器来实现分布式数据库系统的架构，满足业务使用需求，应用层可以不用关心容量和吞吐量等问题。

• 分布式事务： 支持完整的 ACID 事务，应用可以把 TiDB 当成一个单机的 RDMS 来使用，并且提供金融级别的可靠性保证。

• 高可用数据安全： 提供强一致的 Raft 算法实现多副本存储，跨数据中心的数据安全保证，任意一个数据副本或数据中心宕机，均可快速自动的进行副本内接管，无需人工接入，确保数据服务的持续性，以及准确性。

• 实时数据分析： 通过内置的列式数据副本，以及与 Spark 的协议兼容，在海量数据存储下，提供同一套数据库内按照 SQL 语句级别的 OLTP 与 OLAP 数据处理，提供了快速的在线数据分析能力。

• 高度兼容 MySQL ：协议层完全兼容单机 MySQL 数据库，绝大多数金融场景下无需修改业务代码，迁移成本极低，同时可无缝接入 MySQL 周边生态工具。

四、典型合作案例

北京某城商行，也在积极的探索这种新一代分布式系统的建设，通过网联、个人无卡支付、网贷等多个系统的建设后，基本形成了以 Sm\@rtGalaxy 和 TiDB 的全行级分布式技术体系，也快速推动了行内的新业务的拓展，为数字化转型带来强有力的技术活力和高效化服务。

网贷系统架构图（图 3）

​在分布式数据库的技术调研和选型上，该银行调研了业内原生分布式主流产品，由于闭源、存储共享等原因，在业务适配和兼容性上存在较大的适配兼容问题；调研了传统数据库分库分表方案，由于在业务设计和对跨库的分布式事务的能力要求较高；最终将技术方案定位在开源 NewSQL 数据库领域，经过严谨的技术验证，首次尝试采用开源分布式数据库系统 TiDB 作为网贷系统应用在面向互联网业务的场景的适配，并进行了基于分布式兼容性和业务模型的优化，顺利完成了网贷系统的建设投产，网贷系统综合考虑选择 TiDB 的主要考量如下：

• 与 Sm\@rtGalaxy 完全兼容

• 与微服务应用体系适配完整

• 应用层与数据库层双重分布式事务保证选择

• 开箱即用，建设成本低

• 开源自主可控

• 代码完全开源

• 国内最大的生态社区

• 核心技术国人自研

• 开放平台 X86、ARM 等跨平台能力

• 原生分布式 SQL 数据库

• 事务型数据库

• 无需分库分表，应用高度透明

• 丰富的应用开发语言 /ORM/Driver 支持

• 提供多种异构同迁移工具

• 金融级高可靠性保障

• 无单点设计

• 数据强一致性

• 天然的多数据中心模式

• 弹性扩展能力强

• 在线横向扩展容量 / 性能线性提升

• 全自动化的数据重平衡和调度

目前网贷业务系统成功上线投产，已经实现授信客户数近千万，发放贷款突破千亿规模，日均渠道数据处理超百万笔，账务交易日处理量数十万笔，日批处理量达百万笔，通过对基础资源的弹性扩所容满足业务增长需求，现有资源完全满足其未来五到十年线上网贷业务发展需求。

该银行新网贷业务系统建设，使得分布式架构在互联网应用场景下的探索取得了良好的成效和大量的实战经验，创新探索出了一条建设金融级分布式应用与分布式数据库的整体实施方案，为行内基于 AS400 的核心系统分布式下移提供了一条切实可行的建设路径，目前已经在进行部分核心业务的下移工作。