余额宝的技术架构PPT.pptx

余额宝的技术架构 樊振华 余额宝惊人的数字 技术创新 嵌入式直销 技术跨越 新型云直销 嵌入式、清算整合、每日结转 T0交易、一键开户 IOE架构，压力已行业最大值 支持交易=3亿，账户数=800万 去IOE,选择云计算，跨越式迈进 面向未来，支持双十一指标 实现行业第一，插上业务腾飞的翅膀 双十一清算轻松完成，小收益快体验 余额宝系统技术创新之路 技术创新的飞跃 云上感觉真好！ 基于IOE的架构 一期架构下的瓶颈 网络链路长，对天弘端的基础环境要求极高； 扩展性不够，部分核心业务逻辑写到了DB层，非常依赖ORACLE的处理能力； 未做分布式处理，单点的资源压力极大； 单位建设成本高，IOE的购置和维护成本很大； 上云前的难点 内忧外患，一期系统仅上线试运行一周，功能仍需完善；系统设计是否能通过监管要求，仍心存忐忑； 超高指标，交易并发数从一期400指标突越至4000以上，几乎没任何心理准备和技术可行方案； 全面短缺，时间、资源、人力都严重不足，从技术方案评估到研发完成只有2个月；研发团队完全没有云计算的工作经历，几乎没人熟悉mysql； 分库分表和文件处理 如何分？数轮讨论后，敲定按账户来分，根据签约协议号的后三位来均等分配。 哪些表分？账户、交易、份额、份额明细、份额变动； 历史表怎么办？合并数据导入数据仓库，再按时间来分； 交互文件如何处理？每日须实时交易和文件逐笔对账，每小时一个文件，每天24个文件，再合并拆分成1000个节点导入对应的数据库；资产收益文件做导出合并； 总控设计 按节点清算，各节点之间保持松耦合； 消息机制，事物的一致性； 数据核对，总控来汇总每个节点的清算数据，再按清算规则核对数据的正确性； 收益分配，总控根据节点做第一次分配和尾差处理，节点根据总控传送的收益，再做第二次分配和尾差处理；节点将分配的明细汇总再传送至总控做数据核对； 清算指标对比 上云前 上云后 步骤 时间（秒） 步骤 时间（秒） 日初 3994.77 日初 57.84 数据导入 996.53 处理前备份 94.27 处理前备份 543.3 清算批检查 11.92 生成清算预检列表 60 清算批处理 59.45 清算预检 116.08 清算批处理数据同步 60 生成清算处理列表 90 快赎前备份 106.88 清算处理 3905.73 快赎导入 7.34 清算后提示信息 60 快赎批检查 11.5 支付汇总 10.8 快赎批处理 26.3 支付导出 396.53 快赎批处理数据同步 1 数据汇总 2686.2 支付处理 40.7 数据导出 4162.26 支付处理数据同步 120 日终 11099.27 支付导出 7.94 　 　 批后处理 12.89 　 　 批后统计 27.75 　 　 批后统计数据同步 90 　 　 数据导出 4.13 　 　 日终 246.98 　 　 份额同步 12.61 总计 28121.47 总计 999.5 系统投入产出比 阿里云 IOE 处理交易3亿笔 账户上限1000万 支持并发5000 清算30分钟 处理交易超15亿 账户数已超1亿 支持并发400 清算8小时 二期架构下的问题 多节点下的数据呈现还有点改进； 应用状态监控还未能做到事前预警； 程序调试和发布比较繁琐； 清算过程和文件交互处理仍需要技术配合； 余额宝的数据仓库 ODPS 数据存储总量 6T+(压缩值3-5倍) 每日数据吞吐总量10G+ 自7月份开放以来执行任务数接近10万个 复杂度大于1的任务数8000个以上 余额宝的数据架构 实 时 离 线 算法 建模 分类/聚类/回归/神经网络/… 云 数 据 中 心 业务数据 日志数据 外部数据 其他数据 数据 接入 RDS/ADS ODPS/OSS 数据 仓库 数据实验室 自主开发 数据 工具 采云间（DPC） 外部开发 业务 支持 生产 分析 数据 监控 资金 预测 运营 支持 合规 风控 …… 数据 安全 用户 研究 第二代的架构设想 完全采用分布式计算； 重构服务层； 支持实时和离线两种交易方式； 交易和结算功能分离，统一账户； 谢谢！