李远鑫 构建灵活可靠的消费金融大规模分布式系统

1. 构建灵活可靠的消费金融大规 模分布式系统 李远鑫 中邮消费金融有限公司 IT运营部总经理助理 1
3. 李远鑫 IT运营部 总经理助理 • 工信部认证:系统架构设计师、信息系统项目管理师 • 2010年:华南理工大学,计算机体系结构硕士毕业 • 2010年-2014年:中国邮政储蓄银行 • 邮政储蓄系统逻辑大集中 • 全国中间业务平台 • 2014年-2015年:中邮消费金融公司筹备组 • 2015年至今:中邮消费金融有限公司 3
4. • 行业及业务模式 • 消费金融系统架构演进历程 • 关键技术创新实践 • 总结与展望 4
5. 消费金融行业 p消费金融是一种新的金融业态,处于产业链的核心环节,是连接消费者和资金供给方的重要枢纽。 • List 1 • List 2 5
6. 消费金融行业 6
7. 快速响应市场和监管 的变化 消费金融行业 快速接入用户场景,极速响应请求 核心竞争力 稳定可靠的资金来源 和支付通道 快速自动审批的能力 智能严谨高效的风控模型 7 十面埋伏的反欺诈引 擎和资产保全系统
8. 中邮消费金融公司 正规持牌、股东阵容强 大,资金实力和风控能 力雄厚 成立3年时间,发展迅 速,业务规模和资产质量 在行业处于领先地位 渠道资源丰富:自营APP 和BATJ流量入口、邮政 邮储4万线下网点,O2O 全面拓展业务 经营良好,成立3年盈利 翻倍 8
9. • 行业及业务模式 • 消费金融系统架构演进历程 • 关键技术创新实践 • 总结与展望 9
10. 中邮消费金融的发展历程 10
11. 系统架构演进过程 消费金融1.0 2015年-2016年 集中式、单体结构,商 业中间件集成,性能、 可靠性、灵活性差 消费金融2.0 2017年-2018年 核心系统重构、分布 式、大规模服务化、交 易和流程异步化、基本 去商业中间件,性能和 可靠性提升 消费金融3.0 2018年至今 分布式事务管理、服务 快速集成、容器化、自 动化,灵活性和可扩展 性提升 11 未来4.0 智能化、去中心化、高 度自治
12. 应用架构 技术架构 系统架构演进过程 – 1.0 n指标 p日交易峰值:3万笔 p处理效率:3000笔/小时 p贷款审批时长:大部分>30分钟 p新产品研发周期:2-3个月 p软件成本:2400W n特点 p纯商用软件;建设成本和维护成本极高; p集中式商业中间件(ESB、流程引擎、规则 引擎等),交易同步处理过程多,单点的资 源压力极大,不可控; p烟囱式、交易型系统,创新困难,弹性差; p数据不共享,形成孤岛,整合利用困难。 12
13. 系统架构演进过程 – 2.0 n指标 p日交易峰值:30万笔 p处理效率:1.2万笔/小时 p贷款审批效率:90%的申请10分钟内完成 p新产品研发周期:1.5个月 p软件成本:2000W(人力成本) n特点 p 自主研发为主,成本有所降低,但新产品研发效率 仍然不高; p 去除商业中间件,替换为分布式开源中间件,可扩 展性和性能显著提升,自主可控; p 交互型系统,实现大部分业务领域服务化,交易和 流程异步化解耦,快速创新,有一定弹性,但经常 出现数据不一致性的问题; p 数据共享容易,大数据前移到中台,提供实时应用 13
14. 系统架构演进过程 – 3.0 n指标 p日交易峰值:130万笔 p处理效率:5万笔/小时 p贷款审批效率:95%的申请2分钟内完成,大 部分秒批 p新产品研发周期:2-4周 p软件成本:4000W n特点 p账务核心系统向分布式演进,通过分布式事务 管理器解决数据不一致的问题 p容器部署和容器集群管理,基础设施灵活可扩 展; p微服务在线化,支持快速集成,灵活程度提升 pDevOps,自动化部署和测试,开发效率提升显 14 著。
15. • 行业及业务模式 • 消费金融系统架构演进历程 • 关键技术创新实践 • 总结与展望 15
16. 演进过程遇到的主要痛点 微服务跟踪和监控 微服务调用关系错综复杂,难 以识别主流程,出问题难以定 位和排查。 解决方案:全链路跟踪监控 产品研发效率不够高 服务化沉淀了大量构件,但构 件组装仍然代价较高,仍然需 要大量的编码工作,开发、测 试、部署效率不高。 解决方案:容器化、微服务集 成和DevOps 01 02 04 03 交易吞吐量需要最大化 贷款属于长交易,前端需要及时受 理和响应,后端流程大部分可以异 步化,要求交易吞吐量最大化。 解决方案:消息中间件 数据一致性保证问题 单体应用拆分成多个系统,数据状 态从持久化到一个数据源变成多个 数据源,保证数据一致性是一个巨 大的挑战 解决方案:分布式事务管理器 16
17. 服务调用及监控 p 基于Springboot的微服务应用 p DubboUX RPC服务间调用 p Springboot + Jersey开放 Restful微服务,Nginx负载均 衡,向APP和WEB前端提供服务 p 服务注册中心使用Zookeeper p 使用部分Spring Cloud组件 17
18. 服务调用及监控 需要全链路跟踪和监控微服务! p分布式系统面临的挑战 ü 系统越来越多,性能问题如何发现? ü 服务多层次、嵌套调用,出现问题如何定位? ü 分布式服务错综复杂,主流程如何识别? 18
19. 全链路跟踪系统架构 关键点: p 日志埋点加入TraceId p JavaAgent字节码修改 实现应用开发无感知的 日志埋点 p 基于OpenTracing标准 实现跟踪,而非私有化 API 19
20. 高效可靠的消息系统 功能 社区活跃度 (GitHub) 可靠性 消息投递 消费模型 事务消息 消息堆积能力 消息堆积查询 消息重试 性能(常规) JMS客户端 Kafka(1.0.0) 5476 - 同步刷盘 - 异步刷盘 低延时 Long Polling 支持 百亿级别 不影响性能 支持 不支持 非常好 百万级 QPS 不支持 Kafka匹配消费金融的主要痛点: RabbitMQ 1246 - 同步刷盘 - 异步刷盘 有一定间隔 Push / Pull 不支持 影响性能 支持 支持 一般 万级 QPS 支持 RocketMQ 2541 - 同步刷盘 - 异步刷盘 有一定间隔 Push / Pull 支持 百亿级别 影响性能 支持 支持 非常好 十万级 QPS 支持 ActiveMQ 372 - 同步刷盘 - 异步刷盘 有一定间隔 Push / Pull 支持 影响性能 支持 不支持 一般 万级 QPS 支持 p每笔贷款申请都是长交易,需要尽量异步化 p不需要实时给出结果,但必须实时受理和响应,要求低延时、高性能、高吞吐 p必须技术稳定、支撑有力、并且自主可控 20
21. 高效可靠的消息系统 实践:构建基于Kafka的可靠高效消息处理机制 p 设置transactional.id以支持事务Producer。 p 设置enable.idempotence为true以支持Producer幂等发送消息。 p 设置Consumer只读取committed的消息(isolation.level设为read_committed)。 p 设置Broker端配置总副本数replication.factor至少为3。 p 设置Broker端/Topic配置最少同步副本数min.insync.replicas为2。 p 消息不丢失(持久化可靠性)保证通过足够多的2副1 本数保证
22. 高效可靠的消息系统 实践:构建基于Kafka的可靠高效消息处理机制 22
23. 高效可靠的消息系统 实践:消息医院 异常消息的统一收集和处理,作为at-least-once消息投递保 证的必要措施。 Producers Consumer 统一配置 SDK 4. 监听恢复消息,Cloud Bus ID过滤,重做处理 SDK 5. 监听恢复通知, Cloud Bus ID过滤, 默认通知 RDQ KAFKA 1. 消费失败,发送消息到DLQ DLQ DLQ监听模块 监听故障消息 存储 RDQ处理模块 构建消息 发送消息 3. 往指定的Cloud Bus服务ID发送恢复、重做消息 消息医院 2. 消息医院接收错误消息 消息处理模块 后台管理系统 消息 医院数 据库 消息医院 管理后台 角色权限管理 消息处理 重做 消息管理 线下处理 统计查询 通知处理 应用(SDK 2.0) 23 统一认证
24. 数据一致性实践:分布式事务 解决方案:两阶段提交、TCC、可靠消息投递、SAGA(补偿事务新变种) p SAGA = Long Lived Transactions p 每个子事务都有一个对应的补偿事务 p 其中一个事务出现异常时自动调用其他子事务 的补偿事务 p Apache孵化项目ServiceComb:支持SAGA 和TCC的事务管理器,Omega客户端和 Alpha协调器(分布式结构) p SAGA和TCC的区别? 24
25. 分布式事务方案对比 对比维度 两阶段提交(2PC) 隔离性、一致性 强隔离性、强一致性 可用性 牺牲可用性,CP 补偿事务(SAGA) 补偿事务(TCC) 可靠消息投递模式 如果事务被回滚,存在隔离性 准隔离性、追求短时间内达到 read_committed可以保证 (脏读问题)追求短时间内达到 一致性 隔离性,最终一致性,时 一致性 间跨度较大 支持,AP 支持,AP 支持,AP 应用层面 资源层 服务层 服务层 服务层 性能 需要加全局悲观锁,低 恢复方式 回滚 本地事务,Lock时间短,高 冲正 + 对账 + 人工介入 本地事务,Lock时间短,需要 高 两次调用,较高 取消 + 对账 + 人工介入 状态回滚、应用扫表补偿 业务耦合度 低 中 高 低 实现难度 需要底层资源层支持,复杂, 故障点多,实现难度高 可框架支持,但每个子事务均需 要实现对应的冲正事务,开发成 本较高 可框架支持,需要设计严谨的 中间状态保存和取消机制,开 需要消息中件间支持,中 发成本高 应用场景 需要强一致性,容忍高开销 的场景 补偿是可行的;快速响应结果; 业务执行结果未隔离,补偿不完 整带来的风险与成本可控的场景 对一致性时间敏感度较低, 要求一定隔离性和一致性的业 务; 执行时间较短的业务 被动方处理结果不影响主 动方处理结果,需要保证 最终业务完成的场景 25
26. 实践:全方位的分布式事务处理机制 开户放款 TX Start 事务注册 TXID 1 开资金户 发生异常,2、3,4未执行,不需要补偿 AccountService Http 2 额度占用 发生异常,重试一定次数,仍然失败则 事务协调器调用-1进行补偿 CreditService Dubbo -1 开 3启用事务消息,发生异常,重试一定次数失败后,事务协调器调用-1、-2 -2 进行补偿 3 发送短信 SmsService 保证可靠 Kafka 消息发送 Topic 保证 At-least-once发送短信 取 消 额 资 金 户 补 偿 read_committed Exactly-once 消费 度 占 4发生异常,事务协调器调用-1、-2进行补偿,回滚3未提交的消息 用 4 支付放款 PaymentService -3 支付放款补偿 Dubbo Saga/TCC 事务协调器 TX End 26
27. 思考:TCC、SAGA……能解决所有问题吗? p 强事务一致是客户真正的需求 吗? p 立等结果? p 借贷平衡? p 差错可调? p 风险可控? p …… p 最实在的实践:查询确认状态再 作打算、一定要对账! 需求那点事, 树和千秋的故 事 27
28. 研发效率提升:微服务快速集成 系统集成架构候选方案 编排 p系统调用统一管理, 并有明确的流程顺序. p由一个中心“大脑”控制 p典型的编排技术架构:ESB、activiti 协同 p职责分明, 细节独立. p每个系统收到信号后启动 p事件驱动的方式,高效、低耦合 优点: l 调用简单 l 流程清晰 l 数据状态实时同步 缺点: l “中心大脑”服务任务过重,容易形成瓶颈 l 辅助服务的资源没有有效利用 l 性能耦合太重, 性能随着流程复杂度的增加而明 显下降 28 优点: l 显著消除耦合 l 各服务的资源利用率高 缺点: l 看不到业务流程的进展 l 需要额外的工作来监控跨服务的流程, 以保 证其正确运行 l 事件必须得保证送达
29. 研发效率提升:微服务快速集成 29
30. 研发效率提升:微服务快速集成 30
31. 研发效率提升:微服务快速集成 示例:开户放款 2、可视化协同集成微服务,形成流程,服务间以Kafka 异步消息的方式通信 1、封装成轻量级springboot服务,以代理服务的 方式注册到Spring Cloud Data Flow 3、以服务声明的方式打包成Docker镜像并推送到K8S平 台3,1 由K8S平台对服务进行容器编排和自动部署。
32. 研发效率提升:微服务快速集成 扩展:额度占用时触发营销活动,营销微服务捕捉事件进行消息推送 p 基于事件进行业务的扩展将变得更容易和 灵活 p 提高服务组件的重用性、开发效率 p 可扩展性强、高可用特性容易实现 p 分支、判断:通过增加中间节点进行判 断,后面的节点自行先判断是否执行流程 p 可作为重量级流程引擎、ESB的轻量级替 代方案 32
33. 系统灵活性提升:应用容器化 特征 虚拟机 硬件接口 模拟仿真 OS类型 通用 运行模式 用户模式 隔离策略 资源损耗 启动时间 Hypervisor 5%-15% 分钟级别 镜像尺寸 GB-TB 虚拟机 容器 集群规模 p 更轻量、更快速、更好的可移植性 高可用策略 p 更容易实现自动化、更方便的配置、更容易管理 p 简化打包和部署,保持测试环境的一致性,减少人工维护成本 100+ 备份、异地容灾,迁移 33 容器 直接访问 Linux 内核模式 CGroup、Namespace 5% 秒级别 KB-MB 10000+ 弹性伸缩,负载均衡
34. 容器化实践: 搭建容器云PaaS平台 配置项:容器镜像、容 器实例数、所需资源、 弹性伸缩机制…… 健康探针 LivenessProbe、 RedinessProbe 应用商店 34
35. 研发模式的转变 – DevOps和持续集成 35
36. 下一步:Kubernetes异地多集群容灾 北京数据中心 DNS 新数据中心 多集群面临的挑战: p 统一管理界面 p 多集群应用交付 p 多集群统一监控 p 跨集群资源调度 p 跨集群流量分发 p 镜像仓库、配置 信息、中间件数 据、存储和数据 库的同步 镜像仓库 配置中心 k8s集群1 应用A Pod 应用B Pod 应用C Pod 应用… Pod … 中.间..件 k8s集群n 应用D Pod 应用E Pod 应用F Pod 应用… Pod 配置信息 同步 镜像 同步 中间件 同步 SWIFT 存储 … Ceph 磁盘 Oracle 存储同步 Oracle 数据库同步 36 配置中心 镜像仓库 k8s集群1 应用A Pod 应用B Pod 应用C Pod 应用… Pod … 中.间.件. k8s集群n 应用D Pod 应用E Pod 应用F Pod 应用… Pod Oracle SWIFT 存储 … Ceph 磁盘
37. • 行业及业务模式 • 消费金融系统架构演进历程 • 关键技术创新实践 • 总结与展望 37
38. 总结与展望 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、知识图谱应用)、去中心化(区块链) 38
39. 39
40. 40
41. 41