平安树叶背后的云数据库那些开发细节和实际应用经验分享

主要整合自平安科技资深技术专家在某技术沙龙上的分享实录,以及部分公开的技术博客文章）

说起平安树叶这个应用，可能外面的人不太熟悉，但在平安内部，这可以说是一个明星级的员工福利平台，它不是一个简单的应用，背后连接着平安集团几十家子公司，覆盖了从购物优惠、健康管理到生活服务等方方面面，这么庞大的一个生态，每天产生的数据量是惊人的，比如用户登录、浏览商品、下单、核销优惠券等等，这些行为数据就像一片片真实的树叶，不断生长和掉落，而我们的任务就是为这片“森林”建造一个稳定、高效且能随时扩展的“土壤”和“根系”——也就是云数据库系统。

最开始的时候，我们面临的挑战非常直接，业务发展太快了，今天可能只有几个子公司接入，下个月就可能翻一番，传统的自建数据库模式，从申请服务器、安装配置到上线，周期太长，根本跟不上业务奔跑的速度，业务流量根本不是平缓的，它有非常明显的波峰波谷，每天早上上班前后、午休时间、还有每个月发工资后的那几天，访问量和交易量会瞬间冲高，像坐过山车一样，如果按照最高峰值来配置硬件，平时大部分资源都浪费着，成本太高；但如果配置低了，高峰期系统就可能卡死甚至崩溃,直接影响几十万员工的体验。

我们很早就下定决心，必须全面转向云数据库，这里说的云数据库，不是简单地把数据库软件装在云服务器上，而是直接使用云服务商提供的、真正具备弹性伸缩能力的数据库服务。（来源：技术沙龙分享中关于技术选型部分的论述）这样做最大的好处就是“按需使用，按量付费”，在流量低的时候，系统会自动“缩容”，减少计算和存储资源，降低成本；当检测到流量开始飙升时，系统能在几分钟甚至几十秒内自动“扩容”，增加资源来应对压力，等高峰过去再缩回来，这个过程对前端应用几乎是透明的，业务开发团队不需要关心背后是加了10台机器还是20台机器,他们只需要专注于业务逻辑开发就好。

说起来简单，实际做起来坑也不少，其中一个深刻的经验就是关于数据库连接数的管理。（来源：分享中“踩坑与优化”环节）树叶应用是典型的微服务架构，后面有上百个服务模块，每个模块在运行时又会启动多个实例，如果每个实例都创建大量的数据库连接，很容易就把数据库的连接数撑满了，一旦连接数耗尽，新的请求就进不来，整个服务就不可用了，这比服务器CPU跑满还要致命，我们当时就遇到过因为一个非核心服务的代码bug，导致连接没有及时释放,差点拖垮整个核心数据库的险情。

吃一堑长一智，后来我们做了几件事：第一，强制在所有服务中引入并规范使用数据库连接池，避免频繁创建和销毁连接，第二，在应用和数据库之间部署了数据库代理（Proxy），由代理来统一管理连接，实现连接复用，这样后端数据库看到的连接数就大大减少了，第三，建立了严格的监控预警机制，对每个服务的连接数进行实时监控，一旦有异常增长，立刻报警,在问题发生前就能介入处理。

另一个让我们头疼的问题是“慢查询”，在业务快速迭代的阶段，开发人员为了赶进度，有时写的SQL语句可能没有经过充分的优化，或者对大规模数据表进行全表扫描，这样的“慢查询”一旦在高峰期执行，就会像高速公路上的事故车一样，堵住后面所有的请求，导致系统响应变慢。（来源：技术博客中关于性能优化的案例）我们的做法是，首先利用云数据库自带的全方位监控和慢查询日志分析功能，把那些执行时间超过阈值的SQL语句全部抓出来，DBA团队会和开发团队一起，像医生会诊一样，逐条分析慢查询的原因，是缺少合适的索引？还是SQL写法有问题？或者是表结构设计得不合理？找到根因后，再针对性优化，比如增加索引、重写SQL、或者对数据进行分库分表。

说到分库分表，这也是随着数据量爆炸式增长后不得不采取的策略，像用户行为日志、优惠券发放记录这类数据，增长速度极快，单张数据表很快就能达到亿级甚至十亿级，这么大的表，查询和更新效率都会急剧下降，我们根据业务逻辑，比如按子公司ID、或者按时间月份，对这些大表进行了水平拆分，把数据分散到多个物理数据库中，这个过程非常考验技术功底，要保证拆分过程中业务不停机，拆分后对现有代码的改动最小，我们利用了云数据库提供的数据迁移工具和一些中间件方案,实现了相对平滑的切分。

我想强调一下高可用和容灾的重要性，对于平安这样体量的公司，服务中断一分钟都可能造成巨大的影响和负面口碑，我们的数据库从来不是单点部署的。（来源：分享结尾关于架构可靠性的总结）我们采用了“一主多从”的架构，主节点负责写操作，多个只读节点负责读操作，读写分离不仅提升了性能，更重要的是，当主节点发生故障时，可以在几十秒内自动将一个从节点切换成新的主节点，实现故障转移，业务几乎无感知，数据会在异地备份中心进行实时同步备份，即使整个机房出现不可抗力的问题,我们也能在异地快速恢复数据和服务。

总结下来，支撑像平安树叶这样复杂的内部生态平台，云数据库带来的弹性伸缩能力是基础，但更重要的是我们围绕它建立的一整套开发规范、运维流程和故障应对机制，这其中有技术的选择，更有无数个深夜排查问题的经验教训，说到底，技术是为人服务的，让数据库稳定、高效地支撑业务创新，让几十万员工能顺畅地享受便利,这才是我们所有努力的价值所在。