平安云原生数据库那些开发的事儿和实际用起来的经验分享

主要基于与几位在平安科技及使用其云服务的金融科技公司开发朋友的日常交流和个人项目实践整理）

第一部分：为啥要用云原生数据库？我们当初的纠结

说实话，最开始团队里对要不要上平安的云原生数据库，吵得挺凶，我们不是大厂，就是个做线上金融服务的团队，以前用的就是自己搭的MySQL主从，虽然偶尔出点小毛病，但大家都熟悉,心里有底。

来源：团队内部讨论记录 主要纠结的点有几个：

1. 成本问题：感觉“云原生”听起来就贵，按量计费，万一有个啥幺蛾子，流量暴增,账单会不会吓死人？
2. 技术栈切换成本：开发要重新学一套东西吗？运维脚本是不是都得重写？现有的数据迁移过去会不会掉坑里？
3. 可控性：机器不是自己的，数据库也不是自己装的，出了问题，是找平安云客服还是得自己背锅？响应速度怎么样？

后来决定试试,主要是被两个事情打动了：

• 弹性伸缩的真实需求：我们做促销活动的时候，数据库CPU经常飙到90%以上，DBA半夜都得盯着，平时资源又闲置很多，平安的人说他们的数据库可以“秒级”扩容，活动来了自动加配置，活动结束自动降回去,这个对我们吸引力太大了。
• 运维包袱太重：自己维护数据库，备份、容灾、打补丁、性能优化，占用了我们一个半人力，云数据库承诺这些他们都包了，我们只管用，算下来，如果把人力成本也算进去,可能并不比自建贵。

第二部分：开发过程中遇到的“坑”和经验

真用起来，才发现和想象中有点不一样，不是不好,而是用法得变。

来源：项目上线初期踩坑记录

1. 连接池管理是头等大事：这是我们踩的第一个大坑，以前自建数据库，应用服务器和数据库在一个内网，连接建立成本低，有时候图省事，应用里会频繁创建和关闭连接，上了云原生数据库后，发现网络延迟虽然很低，但连接建立的开销比物理机时代要敏感，头两天，应用频繁报连接超时，后来才发现，必须用好连接池，并且要合理配置连接池的最大最小连接数、超时时间。经验就是：云数据库性能再好，也怕应用层乱来。 我们把连接池配置优化后,稳定性立马提升。

   

2. SQL语句得“夹着尾巴做人”：云数据库虽然是分布式的，但并不意味着你可以随便写低效的SQL，有一次，一个开发同学写了个全表扫描的复杂查询，在测试环境数据量小没事，一到生产环境，直接把这个查询对应的计算节点打满了，虽然没拖垮整个数据库集群，但影响了同一节点上其他业务的操作，平安云的控制台有慢查询日志和SQL分析功能，这个帮了大忙，我们根据它快速定位了问题SQL并进行了优化。经验就是：上云不是一劳永逸，良好的SQL编写习惯依然是根本。

3. 权限管理要更精细：自建库的时候，大家可能习惯用一个高权限账号，平安云的云数据库，默认就建议你创建不同权限的账号，比如只读账号、读写账号，并且支持按库、按表授权，一开始觉得麻烦，后来真香了，比如我们的报表系统，就用只读账号从只读节点拉数据，完全不影响主库的写入性能。经验：充分利用云数据库提供的账号权限体系，这是安全和高可用的基础。

第三部分：实际用起来的感受和真香时刻

熬过了初期的适应期,好处就慢慢体现出来了。

来源：日常运维和业务支撑体会

1. 弹性伸缩不是吹的：去年双十一，我们提前在平安云控制台设置了弹性规则，当CPU超过70%持续5分钟，就自动升配，当天果然流量暴涨，数据库真的自己默默完成了扩容，我们只是在监控大屏上看到指标有个小跳动，业务全程无感，活动结束后，又自动缩容，账单也只算了那几小时的高配费用,这事儿让老板特别满意。

2. 备份和恢复太省心了：以前手动备份，还得操心备份文件有没有成功传到异地，现在每天自动全量备份加Binlog日志持续备份，可以恢复到任意时间点，有一次开发误删了生产数据，我们通过控制台，选择了删除前的一个时间点，十几分钟就拉起来了一个临时的恢复实例，把数据找回来了,这个功能救了我们一命。

3. 监控告警一目了然：平安云的控制台把CPU、内存、连接数、IOPS、慢查询这些核心指标都图形化展示了，而且可以自定义告警阈值，我们设置了慢查询超过10秒就告警，DBA的手机能第一时间收到短信,很多时候能在用户感知到卡顿之前就把问题处理掉。

用平安云原生数据库，感觉像是从自己买车上路，变成了雇了个专业的司机团队，你不需要懂怎么修发动机、怎么找最优路线，你只需要告诉司机目的地（业务需求），并遵守基本的乘车规则（良好的开发规范），司机会负责保证车辆永远处于最佳状态、应对各种路况。

这个“司机”服务是要付费的，而且你得信任他的专业能力，对于像我们这样业务增长快、但又不想在底层基础设施上投入过多精力的团队来说，这笔买卖是划算的，核心体会就是：上云不是目的，通过云的能力解放生产力、让业务跑得更快更稳，才是关键。