货拉拉混合云环境下的数据库中间件建设之路

混合云场景下货拉拉数据库中间件建设之路 演讲人：林静 自我介绍 林静 前饿货了拉么高拉级数技据术专库家中，间负责件异团地队多活负数责据人层建设。 现任前货饿拉了拉么数高据级库技中术间专件家负，责负人责，异负地责多服活务数化据网层建设。 关，现D任A货L，拉R拉ed数is据M库es中h，间K件V负St责or人e等，产负品责。服务化网关、DAL、 RedisMesh、KVStore等产品 货拉拉数据库中间件团队负责人 目 录 混合云自建数据库中间件背景介绍 混合云自建数据库中间件实践 混合云自建数据库中间件展望 混合云自建数据库中间件思考 混合云自建数据中间件背景介绍 问题与挑战 1 业务体量持续增长，业务线不断增多，数据库总量不断膨胀 2 技术底座不断演进，新老服务过渡，多语言异构 3 混合云部署，云商存在显著差异 历史系统架构 ęL¢,L$ NodeJS GO C++ PHP JAVA ‡ª aaat Graana Aoo Jaa架 中间件, 中间件 MyCat Proy ShardingJDBC SartCient 业务自建 ,g ¢ 数据中间件 RDS ASRDS Arora RDS AreRDS DB,g,DBę,g建,,, 云RDSgQª 数据 Are 云 AS 云 云数据中,云 云 混合云自建数据中间件实践 当前系统架构 什么选择自建 功能GAP 优秀的产品层出不穷，在企业初期能够快速解决问题 不跨云 开源 云产品 大厂 产品成熟，云集成度较高，付费即上线 闭源 大厂普遍有自己的数据库中间件，深度定制 数据库中间件架构 数据库中间件建设成果 g云DB扩, 支持1024倍扩容 满足公司未来3~5年发展需求 g云DB保护 阻断常规风险 具备应对突发异常的应急能力 低延迟 99.999%延迟小于10ms 平均延迟小于2ms 可用 99.999%服务可用上线2年以来0故障 低本 成本占用不到RDS的5% 数据库领域还有哪些问题 数据安全覆盖不全 SQL缺乏审计，只能由业务研发插入特定代码来覆盖核心数据库。成本高，时间长，推进难 SQL治理粒度粗 数据库由云商托管，很多细节不再暴露给DBA。当前的统计报警都只能在类似吞吐量这种宏观角度，缺少更细粒度的观察方式 异常SQL只有发布到PRD环境造成问题后才能被感知到。研发和DBA一直处在亡羊补牢的被动状态 压力测试是系统容量保障的核心段。但在DB领域，现有的段经常出现测试SQL流量失真的问题，无法验证DB真正的容量 什么不直接使用云上SQL治理产品 按天收费，只能作应急段 功能参差不齐，有的云做的好，有的干脆没有 GAP 不能贴着业务做，和企业场景 实际需求有差别 集$ 和企业现有系统打通困难，需要投入大量开发成本 基于DBProxy的旁路SQL能力建设 SQL深度洞察效果图 混合云自建数据中间件展望 下一步最直接的挑战是“多AZ” 多AZ架构是什么：相当于云上的同城多活架构 有什么限制：使用多AZ架构可以提高可用性和容错性，但需要考虑成本和网络延迟的问 题 当前多AZ高可用架构设计 未来数据库中间件的展望 混合云数据库中间件走向何处 A B C 混合云自建数据中间件思考 无论什么时候稳定性都是第一位 海恩法则：把问题消灭在萌芽状态 1起线上故障 造成了一定的损失 19起冒烟 不能把抖动都直接归因到网络 300起事故隐患 不能有侥幸心理，警惕墨菲定律 1000异常反馈 不能忽略测试环境，业务研发反馈的问题 高可用设计有哪些要点 面向故障 •非核心依赖可降级 •核心依赖做好冗余 •建设系统“自证清白”能力 •最后一道防线动SOP 产品标准化 •针对不同使用特征，分集群隔离 •使用统一软硬件标准 •尽量复用企业现有标准 •接入标准化 •功能简单正交 排障智化 •服务监控，系统监控， 外部依赖监控 •链路追踪 •自动报警 管理自化 •最终“消灭”人工环节 •用户自助 数据库中间件研发培养 数据库中间件开发最大的门槛就在领域知识。只有先熟悉数据库领域知识，才能把数据库中间件做好 由于数据层访问往往是链路的最底层，性能问题会放大到整个服务链路。数据库中间件是对性能比较关注的工程项目 数据库中间件很大程度上是一个自驱动的产品。必须了解整个业务系统核心的痛点在哪，在业务研发和DBA提出诉求前，就做好准备 THANKYOU!