系统稳定性问题复盘
“Best Valentine gift ever. 100% uptime !” – Shing
背景
伴随着海外业务的快速发展，始自2019年12月初，Lalamove系统陆续出现运行缓慢，系统超载，各种瓶颈频现。而圣诞节，情人节等业务流量高峰接踵而至，稳定性成为当务之急。香港和深圳技术团队迅速于12月11日成立了SWAT小组，专攻系统稳定性，首要目标 “No downtime this Friday”(12月15日) ，也成了两地团队紧密合作完成的第一个任务。排查Incident 多发于业务高峰时段，尤其周五。由于各子系统耦合度较高，牵一发而动全身，给排查问题的根源带来了难度。更困难的是，问题/瓶颈 很可能不止一个。经分析Kibana&Cloudwatch日志，发现的问题有：
- 主服务接口延时 短时间迅速增加
- 部分接口访问量 短时间暴增
- 数据库CPU占用率过高，连接数过高，Write IOPS过高
- 数据库主从延迟
排查
初步排查发现，司机app在调用某地理位置上报接口 失败时，有重试逻辑。此逻辑解释了接口访问量暴增的情况，并且当请求失败时会放大系统出现的问题， 但并非问题本源。
策略
深入分析后，怀疑主要瓶颈在于数据库压力过大，进而导致一系列的延迟，阻塞和错误。策略时间紧迫，系统的压力每一天都在变大，已出现的问题随时可能再发生。结合两地团队过去的经验， Jason, Ray 和 Alex 制定了接下来的策略：
- 分多步, 并行走；
- 考虑尽可能多的场景，考虑最坏的场景；
- 多维度保证系统的稳定运行；
行动
行动小组接下来做了这些事情：
- 分析数据库日志
- 慢查询日志 – 高CPU
- 2条频繁发生的慢查询来自OA订单分配系统，每下一个单，OA都会从数据库取得大量司机信息, 占用了大量CPU资源在 Sending data 阶段。
- 在此感谢 Levi 同学的及时修复, 将其中问题最大的查询切到了redis
- Binlog – 高Write IOPS和高主从延迟
- 高峰时期有接近每秒700次的数据库更新来自 司机上报地址
- 短期方案将该请求分流，并且可随时降级
- 长期方案将该请求异步化，增加队列，批量更新
- 发现了一个AWS RDS 的大坑，将 Mariadb 从10.0.x 升级到 10.1 彻底解决了主从延迟的问题
- 新增从库
- 将时间不敏感的 SELECT 切到从库，减轻主库压力
- 特别是容易产生复杂查询的管理后台系统
- 定位 Top 3 流量接口
- 分流:
- 将主服务的大集群，按接口的流量和重要性程度拆分成4个小集群ALB，各自连接不同从库
- Vanactiveorderinfo: geofence 提醒，高频非重要
- Vanlocation: 司机地址上报，高频次重要
- Vanrequestlist: 抢单大厅，高频重要
- 其他
- 避免交叉影响
- 极大的降低了排查问题时的噪音
- 服务降级：
- 随时可将非核心服务的流量抛弃，减轻服务器压力以保证主流程顺利执行
- 脚本查杀 慢查询/连接，当数据库CPU/连接数 过载时
- 司机app取消重试
- 24-7 监控& 待命
总结
系统稳定性是一切产品功能的前提。在日常功能迭代的过程中，作为一名工程师，有责任保证系统在高负荷下的正常运行。产品功能的持续迭代和业务增长必然催生出技术债，这不是一次性就能搞定的事情，而是一个长期需要持之以恒的工作。
团队一个多礼拜持续不懈的努力，保证了系统在接下来的流量高峰(e.g. 周五，圣诞节，情人节）对业务的稳定支持。记得当时也是两地开始合作global system的时候，Alex, Simon, Oskar 和 Nishaad 就窝在深圳“坚毅”会议室，监控，热修复，定方案，执行，一直干到深夜，Alex, Simon 和 Nishaad还因此错过了回香港的末班车。
特别感谢 Ray, Jason Han, Jame Luo, Harry Zheng, Watson Zhan 在那2-3周频繁往返港深两地，提供和分享了宝贵的指导和经验。
作者：Team Leader 孙晨(chenimal.sun)