消费金融大规模分布式系统架构

1、构建灵活可靠的消费金融大规模分布式系统行业及业务模式消费金融系统架构演进历程关键技术创新实践总结与展望2消费金融行业List 1List 2消费金融是一种新的金融业态，处于产业链的核心环节，是连接消费者和资金供给方的重要枢纽。3消费金融行业4快速接入用户场景，极速响应请求快速响应市场和监管的变化快速自动审批的能力稳定可靠的资金来源 和支付通道十面埋伏的反欺诈引 擎和资产保全系统智能严谨高效的风控模型核心竞争力消费金融行业成立3年时间，发展迅速，业务规模和资产质量 在行业处于领先地位正规持牌、股东阵容强 大，资金实力和风控能力雄厚经营良好，成立3年盈利 翻倍渠道资源丰富：自营APP 和BATJ流

2、量入口、邮政 邮储4万线下网点，O2O全面拓展业务中邮消费金融公司6行业及业务模式消费金融系统架构演进历程关键技术创新实践总结与展望7中邮消费金融的发展历程8消费金融2.0 2017年-2018年未来4.0消费金融3.02018年至今消费金融1.02015年-2016年集中式、单体结构，商 业中间件集成，性能、 可靠性、灵活性差分布式事务管理、服务 快速集成、容器化、自动化，灵活性和可扩展 性提升智能化、去中心化、高 度自治核心系统重构、分布 式、大规模服务化、交 易和流程异步化、基本 去商业中间件，性能和 可靠性提升系统架构演进过程系统架构演进过程 1.0应用架构技术架构指标日交易峰值：3万

3、笔处理效率：3000笔/小时贷款审批时长：大部分30分钟新产品研发周期：2-3个月 软件成本：2400W特点纯商用软件；建设成本和维护成本极高；集中式商业中间件（ESB、流程引擎、规则 引擎等），交易同步处理过程多，单点的资 源压力极大，不可控；烟囱式、交易型系统，创新困难，弹性差；数据不共享，形成孤岛，整合利用困难。系统架构演进过程 2.0指标日交易峰值：30万笔处理效率：1.2万笔/小时贷款审批效率：90%的申请10分钟内完成新产品研发周期：1.5个月 软件成本：2000W（人力成本）特点自主研发为主，成本有所降低，但新产品研发效率仍然不高；去除商业中间件，替换为分布式开源中间件，可扩展性

4、和性能显著提升，自主可控；交互型系统，实现大部分业务领域服务化，交易和 流程异步化解耦，快速创新，有一定弹性，但经常 出现数据不一致性的问题；数据共享容易，大数据前移到中台，提供实时应用系统架构演进过程 3.0指标日交易峰值：130万笔 处理效率：5万笔/小时贷款审批效率：95%的申请2分钟内完成，大部分秒批新产品研发周期：2-4周 软件成本：4000W特点账务核心系统向分布式演进，通过分布式事务管理器解决数据不一致的问题容器部署和容器集群管理，基础设施灵活可扩展；微服务在线化，支持快速集成，灵活程度提升DevOps，自动化部署和测试，开发效率提升显著。14行业及业务模式消费金融系统架构演进历

5、程关键技术创新实践总结与展望13演进过程遇到的主要痛点01020403微服务跟踪和监控微服务调用关系错综复杂，难 以识别主流程，出问题难以定 位和排查。解决方案：全链路跟踪监控产品研发效率不够高服务化沉淀了大量构件，但构 件组装仍然代价较高，仍然需 要大量的编码工作，开发、测 试、部署效率不高。解决方案：容器化、微服务集 成和DevOps数据一致性保证问题单体应用拆分成多个系统，数据状 态从持久化到一个数据源变成多个 数据源，保证数据一致性是一个巨 大的挑战解决方案：分布式事务管理器交易吞吐量需要最大化贷款属于长交易，前端需要及时受 理和响应，后端流程大部分可以异 步化，要求交易吞吐量最大化。

6、 解决方案：消息中间件服务调用及监控p 基于Springboot的微服务应用p DubboUX RPC服务间调用p Springboot+ Jersey开放Restful微服务，Nginx负载均 衡，向APP和WEB前端提供服务p 服务注册中心使用Zookeeperp 使用部分Spring Cloud组件服务调用及监控p分布式系统面临的挑战 系统越来越多，性能问题如何发现？ 服务多层次、嵌套调用，出现问题如何定位？分布式服务错综复杂，主流程如何识别？需要全链路跟踪和监控微服务！16全链路跟踪系统架构关 键 点 ： 日志埋点加入TraceId JavaAgent字节码修改实现应用开发无感知的 日

7、志埋点基于OpenTracing标准实现跟踪，而非私有化 API17高效可靠的消息系统18Kafka匹配消费金融的主要痛点：每笔贷款申请都是长交易，需要尽量异步化不需要实时给出结果，但必须实时受理和响应，要求低延时、高性能、高吞吐必须技术稳定、支撑有力、并且自主可控功能Kafka(1.0.0)RabbitMQRocketMQActiveMQ社区活跃度(GitHub)547612462541372可靠性同步刷盘异步刷盘同步刷盘异步刷盘同步刷盘异步刷盘同步刷盘异步刷盘消息投递低延时有一定间隔有一定间隔有一定间隔消费模型Long PollingPush / PullPush / PullPush /

8、 Pull事务消息支持不支持支持支持消息堆积能力百亿级别 不影响性能影响性能百亿级别 影响性能影响性能消息堆积查询支持支持支持支持消息重试不支持支持支持不支持性能（常规）非常好 百万级QPS一般 万级QPS非常好 十万级QPS一般 万级 QPSJMS客户端不支持支持支持支持高效可靠的消息系统实践：构建基于Kafka的可靠高效消息处理机制p 设置transactional.id以支持事务Producer。p 设置enable.idempotence为true以支持Producer幂等发送消息。 p 设置Consumer只读取committed的消息（isolation.level设为read_c

9、ommitted）。 p 设置Broker端配置总副本数replication.factor至少为3。 p 设置Broker端/Topic配置最少同步副本数min.insync.replicas为2。 p 消息不丢失（持久化可靠性）保证通过足够多的2副1 本数保证实践：构建基于Kafka的可靠高效消息处理机制20高效可靠的消息系统Producers消息医院KAFKASDK消息医院数据库后台管理系统消息处理模块DLQRDQConsumerSDK1. 消费失败，发送消息到DLQ2. 消息医院接收错误消息4. 监听恢复消息，Cloud Bus ID过滤，重做处理3. 往指定的Cloud Bus服务I

10、D发送恢复、重做消息5. 监听恢复通知，Cloud Bus ID过滤，默认通知消息医院DLQ监听模块监听故障消息存储RDQ处理模块构建消息发送消息管理后台角色权限管理消息管理统计查询消息处理重做线下处理通知处理应用（SDK 2.0)统一配置统一认证高效可靠的消息系统21实践：消息医院异常消息的统一收集和处理，作为at-least-once消息投递保 证的必要措施。数据一致性实践：分布式事务解决方案：两阶段提交、TCC、可靠消息投递、SAGA（补偿事务新变种）pSAGA = Long Lived Transactions p每个子事务都有一个对应的补偿事务 p其中一个事务出现异常时自动调用其他子

11、事务的补偿事务pApache孵化项目ServiceComb：支持SAGA 和TCC的事务管理器，Omega客户端和Alpha协调器（分布式结构）pSAGA和TCC的区别？22对比维度两阶段提交（2PC）补偿事务（SAGA）补偿事务（TCC）可靠消息投递模式隔离性、一致性强隔离性、强一致性如果事务被回滚，存在隔离性（脏读问题）追求短时间内达到 一致性准隔离性、追求短时间内达到 一致性read_committed可以保证 隔离性，最终一致性，时 间跨度较大可用性牺牲可用性，CP支持，AP支持，AP支持，AP应用层面资源层服务层服务层服务层性能需要加全局悲观锁，低本地事务，Lock时间短，高本地事务

12、，Lock时间短，需要 两次调用，较高高恢复方式回滚冲正 + 对账 + 人工介入取消 + 对账 + 人工介入状态回滚、应用扫表补偿业务耦合度低中高低实现难度需要底层资源层支持，复杂， 故障点多，实现难度高可框架支持，但每个子事务均需 要实现对应的冲正事务，开发成 本较高可框架支持，需要设计严谨的 中间状态保存和取消机制，开 发成本高需要消息中件间支持，中应用场景需要强一致性，容忍高开销 的场景补偿是可行的；快速响应结果； 业务执行结果未隔离，补偿不完 整带来的风险与成本可控的场景要求一定隔离性和一致性的业 务；执行时间较短的业务对一致性时间敏感度较低， 被动方处理结果不影响主 动方处理结果，需

13、要保证 最终业务完成的场景23分布式事务方案对比开户放款1开资金户2额度占用4支付放款Saga/TCC 事务协调器实践：全方位的分布式事务处理机制TXStartTXEndAccountService HttpCreditService DubboSmsService Kafkaread_committedPaymentService Dubbo发生异常，2、3，4未执行，不需要补偿发送短信Topic-1开 资 金 户 补 偿-2取 消 额 度 占 用-3支付放款补偿发生异常，重试一定次数，仍然失败则 事务协调器调用-1进行补偿4发生异常，事务协调器调用-1、-2进行补偿，回滚3未提交的消息3启

14、用事务消息，发生异常，重试一定次数失败后，事务协调器调用-1、-2进行补偿3 发送短信保证可靠 消息发送Exactly-once保证At-least-once消费事务注册 TXID24思考：TCC、SAGA能解决所有问题吗？ 强事务一致是客户真正的需求 吗？ 立等结果？ 借贷平衡？ 差错可调？ 风险可控？ 最实在的实践：查询确认状态再 作打算、一定要对账！需求那点事， 树和千秋的故 事研发效率提升：微服务快速集成系统集成架构候选方案编排系统调用统一管理, 并有明确的流程顺序.由一个中心“大脑”控制典型的编排技术架构：ESB、activiti协同职责分明, 细节独立.每个系统收到信号后启动事件驱

15、动的方式，高效、低耦合优点:l调用简单l流程清晰l数据状态实时同步缺点:l“中心大脑”服务任务过重,容易形成瓶颈l辅助服务的资源没有有效利用l性能耦合太重, 性能随着流程复杂度的增加而明 显下降优点:l显著消除耦合l各服务的资源利用率高缺点:l看不到业务流程的进展l需要额外的工作来监控跨服务的流程, 以保 证其正确运行l事件必须得保证送达26研发效率提升：微服务快速集成27研发效率提升：微服务快速集成研发效率提升：微服务快速集成示例：开户放款1、封装成轻量级springboot服务，以代理服务的 方式注册到Spring Cloud Data Flow2、可视化协同集成微服务，形成流程，服务间以

16、Kafka 异步消息的方式通信3、以服务声明的方式打包成Docker镜像并推送到K8S平 台3，1 由K8S平台对服务进行容器编排和自动部署。研发效率提升：微服务快速集成扩展：额度占用时触发营销活动，营销微服务捕捉事件进行消息推送基于事件进行业务的扩展将变得更容易和 灵活提高服务组件的重用性、开发效率可扩展性强、高可用特性容易实现分支、判断：通过增加中间节点进行判 断，后面的节点自行先判断是否执行流程可作为重量级流程引擎、ESB的轻量级替 代方案30系统灵活性提升：应用容器化容器特征虚拟机容器硬件接口模拟仿真直接访问OS类型通用Linux运行模式用户模式内核模式隔离策略HypervisorCG

17、roup、Namespace资源损耗5%-15%5%启动时间分钟级别秒级别镜像尺寸GB-TBKB-MB集群规模100+10000+高可用策略备份、异地容灾，迁移弹性伸缩，负载均衡虚拟机更轻量、更快速、更好的可移植性更容易实现自动化、更方便的配置、更容易管理简化打包和部署，保持测试环境的一致性，减少人工维护成本容器化实践： 搭建容器云PaaS平台配置项：容器镜像、容 器实例数、所需资源、 弹性伸缩机制健康探针 LivenessProbe、 RedinessProbe应用商店研发模式的转变 DevOps和持续集成北京数据中心新数据中心OracleOracle Oracle数据库同步SWIFTSWI

18、FT中间件 同步配置中心配置中心配置信息k8s集群1应用A Pod应用B Pod同步镜像 同步k8s集群n镜像仓库镜像仓库.存储Ceph 磁盘存储Ceph 磁盘DNS应用C Pod应用 Pod应用D Pod应用E Pod应用F Pod应用 Podk8s集群1应用A Pod应用B Pod应用C Pod应用 Podk8s集群n应用D Pod应用E Pod应用F Pod应用 Pod下一步：Kubernetes异地多集群容灾多集群面临的挑战：统一管理界面多集群应用交付多集群统一监控跨集群资源调度跨集群流量分发 镜像仓库、配置 信息、中间件数 据、存储和数据 库的同步行业及业务模式消费金融系统架构演进历程关键技术创新实践总结与展望35总结与展望36 中邮消费金融系统发展历程1.0时代：解决从0到1的问题，单体结构，商业中间件集成，性能、可靠性、灵活性差2.0时代：分布式重构、服务化、去除商业中间件，性能、可靠性得到明显