什么是体系化建设

接下来简单介绍一下货拉拉围绕上述三点进行的相关能力建设。

稳定性

货拉拉 DBA 团队管理了MySQL（阿里云RDS、华为云RDS、AWS-Aurora RDS）、ES、Kafka、RabbitMQ、Redis-Cluster 以及各种组件 Canal/ZK 等)，同时在全球有若干个 IDC，每个 IDC 又包含了多环境（测试、预发、生产），上千人的研发团队，这么复杂的场景跟体量还真的需要一个专业的团队来管理。

MySQL

SQL事前发现

通过对预发环境的 SQL 旁路然后将旁路结果对历史记录进行对比就可以很容易发现每天DB新增了那些慢、危险SQL，然后及时地预警给测试跟研发同学进行优化改造。同时与发布系统打通进行卡口、未优化完成的 APPID 禁止发布，起到拦截作用。

SQL事中兜底

如何无差别防范任何 SQL 在任何场景下击穿数据库？一方面数据库中间件会实时感知数据库RT情况，一但RT整体响应异常则启动限流功能，或者 DBA 可以主动介入熔断、限流特定 SQL，甚至可以干扰执行计划做到走特定索引的功能。

同时 DMS 自愈系统会实时感知数据库 processlist 列表是否有堆积或者长查询，自愈系统会根据规则进行查杀动作，比如 CPU/IO 异常、SQL 执行时间超过规定时间、processlist 列表堆积、锁等待、连接数超警戒水位等。自愈系统要跟监控系统进行配合才能做到实时的感知能力，这也是需要进行个性化建设的。

可以看到该保障能力建设落地后，我们数据库 thread_running/processlist 列表堆积超过30（云上普遍都是4-8C这样的小规格活跃SQL数定在30相对合适的）的实例比例都不到1%（监控只要发现一次就视为异常），日常基于该指标就可以比较直观的评估最近一段时间数据库稳定情况了。

SQL事后治理

可以看到高危慢查询万分率常态化下都在万分之一附近波动。

SQL发布变更

其次威胁稳定性的来源就是日常数据库的发布变更了。发布主要解决3个方面的问题。

1、SQL规范

就是大家通常说的SQL审核，尤其是在具备一定规模跟体量的业务下SQL规范是很重要的，一些微小的缺陷都可能被大流量、高负载放大影响。由于开源系统跟我们自研的DMS 系统整合比较困难，索性就重新开发了一个，通过数据运营指标发现其实研发是很难遵守规范的，几乎每周都有10%做的变更不合规。所以试图将云上 DB 直接交给开发自己维护这一个角度看就很不可行。

2、变更安全

3、成功率保障

货拉拉是家快速成长的公司，每天数据库变更量日均在600+，因此发布的效率跟成功率是很重要的，效率上我们发布系统会自动识别部署架构比如阿里云我们由于大量使用分库分表很多集群是没有 slave 节点的或者有 slave 节点单不参与 online 业务，对 gh-ost修改后会自动优化相关 hook 函数保证 DDL 效率优先。

可以看到我们发布成功率还是非常高的，同时发布时长整体也都在10分钟左右就可以结束。

Redis

对 Redis 稳定性威胁最大的无非就大key、热key了。

大key、热key防御

对PHP短连接服务实现短链变长链，由于是 sidecar 部署模式引用到 mesh 层的网络开销就比较小，应用RT与Redis节点CPU分别下了40%、60%。

对热key进行本地化缓存+低粒度更新，rt增高问题迅速得到缓解。

Kafka

Kafka 本身其实是比较稳定的，但是对业务而言稳定性风险主要来自自身消费延迟感知问题，过去研发普遍会在消费系统里面埋点以此来感知消费延迟情况，但是实际效果上效果不是太理想，主要原因在于现在的延迟度量方式都是以 lags 这维度的，是比较抽象的。

延迟发现

资源/故障隔离

实际运维过程中来自 Kafka 本身的故障非常少，日常稳定性问题主要集中在诸如网络、磁盘异常导致的整体业务抖动，以及在防范一些 topic 生产或者消费导致的资源严重占用造成的相互响应问题。针对这个问题 DMS 系统设计了一个租户的概念，DMS 对集群broker 节点进行编组构成一个 Zone，创建 topic 时将 topic 指定到特定 Zone，实际创建时通过 go-sarama 接口将 topic 指定到特定机器（Zone），如下图：

这样设计的好处是实现资源隔离的目的、故障隔离的目的。比如某个Zone的机器异常不会影响其整体，同时对于单个Topic读写过大导致的资源占用也能很好的应对，同时还解决了Topic自由调度的问题，比如可以将一个小规格Topic迁移到大的Zone内，过程是对业务无感的也不用换链接地址。最后对提高资源利用率有很好的作用，因为不同Zone用的机器规格可能是不同的，日常扩缩容可以精确到Zone，避免集群整体扩容造成的浪费及业务影响。

ES、MQ

篇幅原因不一一介绍了。

赋能运维&研发效率

1、赋能 DBA

前面介绍过了货拉拉的基础环境其实是非常复杂的，DB选型多种类多，分布在几朵云上，每朵云都有独立运行的环境，DBA其实是很难通过云产品进行有效管理，如果只用单一云服务且体量有比较小依靠云 PaaS 产品也能解决一些日常问题，这显然不适合我们。

对DBA而言无非就是通过系统将日常工作自动化掉，且在一套系统上完成。

整体对DBA而言日常90%以上的工作可以借助平台完成。

2、赋能研发

科学合理的资源使用

MySQL

由于云是规格整体是偏小的应对突发异常的情况是比较弱的，我们将数据库拆分的比较细因此我们下掉了大部分slave节点。

Kafka

我对DBA的理解

1. 运维型 DBA：这是偏常见DBA的工作，能很好的在当下管理体系下按照标准完成日常工作，比如基本问题的处理、研发对接等。
2. 开发型 DBA：懂开发似乎是今天 DBA 的标配能力了，这类严格来说不是DBA了，我们今天一直说的泛化 DBA 其实就指的这类型的 DBA，而不是说你可以维护几款数据库产品，对他们的要求是很高的，一方面懂数据库，懂数据运维，懂开发(前端+后端)，懂数据库周边生态工具，以及快速的学习能力，因为上云的大趋势下 DBA 不在为基础设施所拖累 DBA 承载的面就要扩展，最后可能还是自己的产品经理，因为没有人给你画原型图也没有人告诉你页面该长成什么样子，什么地方该放什么按钮以及他是什么颜色的…，这些都要建立在上述复杂的要求之上。
3. DBA 架构师：这类 DBA 是经验+意识型的 DBA，对数据库有深度的理解、综合技术全面、对内知道什么阶段做什么事有清晰的规划，对外能搞定研发并建立良好的团队协作关系、能扛事也能搞事(推动做事)、建立个人及团队整体影响力。
   
   

近期好文推荐：

“高效运维”公众号诚邀广大技术人员投稿