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

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

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

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

5、，支持快速集成，灵活程度提升pDevOps，自动化部署和测试，开发效率提升显著。14行业及业务模式消费金融系统架构演进历程关键技术创新实践总结与展望15演进过程遇到的主要痛点01020403交易吞吐量需要最大化微服务跟踪和监控产品研发效率不够高数据一致性保证问题微服务调用关系错综复杂，难以识别主流程，出问题难以定位和排查。解决方案：全链路跟踪监控服务化沉淀了大量构件，但构件组装仍然代价较高，仍然需要大量的编码工作，开发、测试、部署效率不高。解决方案：容器化、微服务集成和DevOps单体应用拆分成多个系统，数据状态从持久化到一个数据源变成多个数据源，保证数据一致性是一个巨大的挑战解决方案：分布式

6、事务管理器贷款属于长交易，前端需要及时受理和响应，后端流程大部分可以异步化，要求交易吞吐量最大化。解决方案：消息中间件1617服务调用及监控p 基于Springboot的微服务应用p DubboUX RPC服务间调用p Springboot+Jersey开放Restful微服务，Nginx负载均衡，向APP和WEB前端提供服务p 服务注册中心使用Zookeeperp 使用部分Spring Cloud组件服务调用及监控p分布式系统面临的挑战 系统越来越多，性能问题如何发现？服务多层次、嵌套调用，出现问题如何定位？分布式服务错综复杂，主流程如何识别？需要全链路跟踪和监控微服务！18全链路跟踪系统架

7、构关键点：p 日志埋点加入TraceIdp JavaAgent字节码修改实现应用开发无感知的日志埋点p 基于OpenTracing标准实现跟踪，而非私有化API19高效可靠的消息系统Kafka匹配消费金融的主要痛点：p每笔贷款申请都是长交易，需要尽量异步化p不需要实时给出结果，但必须实时受理和响应，要求低延时、高性能、高吞吐p必须技术稳定、支撑有力、并且自主可控功能功能Kafka(1.0.0)RabbitMQRocketMQActiveMQ社区活跃度(GitHub)5476可靠性-同步刷盘-异步刷盘-同步刷盘-异步刷盘-同步刷盘-异步刷盘-同步刷盘-异步刷盘消息投递低延时

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

9、 设置Consumer只读取committed的消息（isolation.level设为read_committed）。p 设置Broker端配置总副本数replication.factor至少为3。p 设置Broker端/Topic配置最少同步副本数min.insync.replicas为2。p 消息不丢失（持久化可靠性）保证通过足够多的副本数保证21实践：构建基于Kafka的可靠高效消息处理机制高效可靠的消息系统22Producers消息医院消息医院KAFKASDK消息医院数据库后台管理系统消息处理模块DLQRDQConsumerSDK1.消费失败，发送消息到DLQ2.消息医院接收错误消息

10、4.监听恢复消息，Cloud Bus ID过滤，重做处理3.往指定的Cloud Bus服务ID发送恢复、重做消息5.监听恢复通知，Cloud Bus ID过滤，默认通知异常消息的统一收集和处理，作为at-least-once消息投递保证的必要措施。消息医院消息医院DLQ监听模块监听模块监听故障消息存储RDQ处理模块处理模块构建消息发送消息管理后台管理后台角色权限管理消息管理统计查询消息处理消息处理重做线下处理通知处理应用应用（SDK SDK 2 2.0 0)统一配置统一配置统一认证统一认证高效可靠的消息系统实践：消息医院23数据一致性实践：分布式事务解决方案：两阶段提交、TCC、可靠消息投递、

11、SAGA（补偿事务新变种）p SAGA=Long Lived Transactionsp 每个子事务都有一个对应的补偿事务p 其中一个事务出现异常时自动调用其他子事务的补偿事务p Apache孵化项目ServiceComb：支持SAGA和TCC的事务管理器，Omega客户端和Alpha协调器（分布式结构）p SAGA和TCC的区别？24对比维度对比维度 两两阶段提交（阶段提交（2PC）补偿事务（补偿事务（SAGA）补偿事务（补偿事务（TCC）可靠消息投可靠消息投递模式递模式隔离性、一致性强隔离性、强一致性强隔离性、强一致性如果事务被回滚，存在隔离性如果事务被回滚，存在隔离性（脏读问题）追求（脏

12、读问题）追求短时间短时间内达到内达到一致性一致性准隔离性准隔离性、追求、追求短时间短时间内达到内达到一致性一致性read_committedread_committed可以可以保证保证隔离性，最终一致性，时隔离性，最终一致性，时间跨度较大间跨度较大可用性牺牲可用性牺牲可用性，CPCP支持，支持，APAP支持，支持，APAP支持，支持，APAP应用层面资源层资源层服务层服务层服务层服务层服务层服务层性能需要加全局需要加全局悲观锁悲观锁，低，低本地事务，本地事务，LockLock时间短，高时间短，高本地事务，本地事务，LockLock时间短，需要时间短，需要两次调用，较高两次调用，较高高高恢复方式

13、回滚回滚冲正冲正+对账对账+人工介入人工介入取消取消+对账对账+人工介入人工介入状态回滚、应用扫表补偿状态回滚、应用扫表补偿业务耦合度低低中中高高低低实现难度需要底层资源层支持，复杂，需要底层资源层支持，复杂，故障点多，实现难度高故障点多，实现难度高可框架支持，但每个子事务均需可框架支持，但每个子事务均需要实现对应的冲正事务，开发成要实现对应的冲正事务，开发成本较高本较高可框架支持，需要设计严谨的可框架支持，需要设计严谨的中间状态保存和取消机制，开中间状态保存和取消机制，开发成本高发成本高需要消息中件间支持，中需要消息中件间支持，中应用场景需要需要强一致性强一致性，容忍高开销，容忍高开销的场景

14、的场景补偿是可行的；补偿是可行的；快速响应结果快速响应结果；业务执行结果未隔离，业务执行结果未隔离，补偿不完补偿不完整整带来的带来的风险与成本可控风险与成本可控的场景的场景要求一定隔离性和一致性的业要求一定隔离性和一致性的业务；务；执行时间较短执行时间较短的业务的业务对一致性时间敏感度较低，对一致性时间敏感度较低，被动方处理结果不影响主被动方处理结果不影响主动方处理结果，需要保证动方处理结果，需要保证最终业务完成的场景最终业务完成的场景分布式事务方案对比25开户放款开资金户额度占用发送短信支付放款1234Saga/TCC 事事务协调器务协调器实践：全方位的分布式事务处理机制TX StartTX

15、 EndAccountServiceHttpCreditServiceDubboSmsServiceKafkaread_committedPaymentServiceDubbo发生异常，2、3，4未执行，不需要补偿发送短信Topic-1开资金户补偿-2取消额度占用-3支付放款补偿发生异常，重试一定次数，仍然失败则事务协调器调用-1进行补偿4发生异常，事务协调器调用-1、-2进行补偿，回滚3未提交的消息3启用事务消息，发生异常，重试一定次数失败后，事务协调器调用-1、-2进行补偿保证可靠消息发送Exactly-once保证At-least-once消费事务注册TXID26思考：TCC、SAGA能

16、解决所有问题吗？p 强事务一致是客户真正的需求吗？p 立等结果？p 借贷平衡？p 差错可调？p 风险可控？p p 最实在的实践：查询确认状态再作打算、一定要对账！需求那点事，树和千秋的故事27研发效率提升：微服务快速集成系统集成架构候选方案编排p系统调用统一管理,并有明确的流程顺序.p由一个中心“大脑”控制p典型的编排技术架构：ESB、activiti协同p职责分明,细节独立.p每个系统收到信号后启动p事件驱动的方式，高效、低耦合优点:l调用简单l流程清晰l数据状态实时同步缺点:l“中心大脑”服务任务过重,容易形成瓶颈l辅助服务的资源没有有效利用l性能耦合太重,性能随着流程复杂度的增加而明显下

17、降优点:l显著消除耦合l各服务的资源利用率高缺点:l看不到业务流程的进展l需要额外的工作来监控跨服务的流程,以保证其正确运行l事件必须得保证送达28研发效率提升：微服务快速集成29研发效率提升：微服务快速集成30研发效率提升：微服务快速集成示例：开户放款1、封装成轻量级springboot服务，以代理服务的方式注册到Spring Cloud Data Flow2、可视化协同集成微服务，形成流程，服务间以Kafka异步消息的方式通信3、以服务声明的方式打包成Docker镜像并推送到K8S平台，由K8S平台对服务进行容器编排和自动部署。31研发效率提升：微服务快速集成扩展：额度占用时触发营销活动，

18、营销微服务捕捉事件进行消息推送p 基于事件进行业务的扩展将变得更容易和灵活p 提高服务组件的重用性、开发效率p 可扩展性强、高可用特性容易实现p 分支、判断：通过增加中间节点进行判断，后面的节点自行先判断是否执行流程p 可作为重量级流程引擎、ESB的轻量级替代方案32系统灵活性提升：应用容器化虚拟机容器特征特征虚虚拟机拟机容器容器硬件接口模拟仿真模拟仿真直接访问直接访问OS类型通用通用LinuxLinux运行模式用户模式用户模式内核模式内核模式隔离策略HypervisorHypervisorCGroupCGroup、NamespaceNamespace资源损耗5%5%-15%15%5%5%启动

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

20、Oracle数据库同步存储同步中间件中间件Ceph磁盘SWIFTCeph磁盘SWIFT中间件同步配置中心配置中心配置信息同步k8s集群1应用APod应用BPod镜像同步k8s集群n镜像仓库镜像仓库.存储存储DNS应用CPod应用Pod应用DPod应用EPod应用FPod应用Podk8s集群1应用APod应用BPod应用CPod应用Podk8s集群n应用DPod应用EPod应用FPod应用Pod下一步：Kubernetes异地多集群容灾多集群面临的挑战：p 统一管理界面p 多集群应用交付p 多集群统一监控p 跨集群资源调度p 跨集群流量分发p 镜像仓库、配置信息、中间件数据、存储和数据库的同步3

21、6行业及业务模式消费金融系统架构演进历程关键技术创新实践总结与展望37总结与展望p 中邮消费金融系统发展历程 1.0时代：解决从0到1的问题，单体结构，商业中间件集成，性能、可靠性、灵活性差 2.0时代：分布式重构、服务化、去除商业中间件，性能、可靠性得到明显提升 3.0时代：解决数据一致性问题、服务可快速集成、容器化，灵活性、可扩展性提升明显p 关键技术创新实践 基于JavaAgent和OpenTracing的日志埋点实现微服务全链路跟踪和监控 基于Kafka的消息中间件最佳实践（可靠性、事务、多线程处理、消息医院）SAGA、TCC和可靠消息投递结合的分布式事务处理最佳实践 基于Spring Cloud组件、Kafka异步消息及Docker容器编排实现事件驱动的微服务快速集成 建立容器云PaaS平台和Devops实现研发效率提升，以及整体的系统灵活性提升p 消费金融4.0规划：复杂网络反欺诈、智能化（AI、知识图谱应用）、去中心化（区块链）3841