数据库治理的探索与实践

Posted 2022-09-07 阿里云云栖号

背景

在分布式系统架构中，业务的流量都是端到端的。每个请求都会经过很多层处理，比如从入口网关再到 Web Server 再到服务之间的调用，再到服务访问缓存或 DB 等存储。

对于我们的系统来说，数据库是非常重要的一块。因此无论是在稳定性的治理上，还是在开发提效等场景下，数据库相关的治理能力都是我们系统所需具备的能力。

以下列举一些典型的数据库相关的治理场景：

• 某系统对外提供某查询接口，SQL 语句涉及多表 join，某些情况下会触发慢查询，耗时长达 30s，最终导致 DB 连接池/Tomcat 线程池满，应用整体不可用。
• 应用刚启动，由于数据库 Druid 连接池还在初始化中，但是此时已经大量请求进入，迅速导致 Dubbo 的线程池满，许多现场卡在初始化数据库连接的过程中，导致业务请求大量报错。
• 全链路灰度场景中，由于新的应用版本改了数据库表的内容，灰度流量导致线上数据库的数据错乱，业务同学连夜手动订正线上数据。
• 在项目初期没有对 SQL 的性能做好考量，随着业务的发展，用户量级的增加，线上遗留老接口的 SQL 逐渐成为性能瓶颈，因此需要有有效的 SQL 洞察能力帮助我们发现遗留的 SQL，并及时进行性能优化。
• SQL 语句处理时间比较长导致线上业务接口出现大量的慢调用，需要快速定位有问题的慢 SQL，并且通过一定的治理手段进行隔离，将业务快速恢复。因此在微服务访问数据层时，实时的 SQL 洞察能力可以帮助我们快速定位慢的 SQL 调用。

其实针对大多数的后端应用来讲，系统的瓶颈主要受限于数据库，当然复杂度的业务肯定也离不开数据库的操作。因此数据库问题，也是优先级最高的工作，数据库的治理也是微服务治理中必不可少的一环。

数据库治理相关常见场景

下面总结了微服务访问数据库层时，在数据库治理中的常见的一些场景与能力。

OpenSergo 领域中关于数据库治理的概览

慢 SQL 治理

慢 SQL 是比较致命的影响系统稳定性的因素之一，系统中出现慢 SQL 可能会导致 CPU、负载异常和系统资源耗尽等情况。严重的慢 SQL 发生后可能会拖垮整个数据库，对线上业务产生阻断性的风险。线上生产环境出现慢 SQL 可能原因如下：

• 网络速度慢、内存不足、I/O 吞吐量小、磁盘空间被占满等硬件原因。
• 没有索引或者索引失效。
• 系统数据过多。
• 在项目初期没有对 SQL 的性能做好考量。

对于线上常见的慢 SQL 问题，MSE 服务治理提供了场景化的解决方式。

• SQL 洞察

MSE 提供了秒级的 SQL 调用监控：

我们可以观察应用和资源 API 维度的实时数据（细化至秒级），同时 MSE 还提供了 SQL 的 TopN 列表，我们可以一眼看出 RT 高的 SQL 语句，快速定位应用变慢的根因。

我们通过 MSE 提供的 SQL 洞察能力，可以有效分析 SQL 语句是否写得合理，以及 SQL 执行的并发、RT 是否符合系统表现的预期，根据这些 SQL 洞察的数据，从而可以有效地评估系统的整体表现，为流控降级规则的配置提供重要依据。

• SQL 的流控降级

我们可以根据 MSE 自动识别的 SQL 语句，可以对出现慢 SQL 的应用配置线程数维度的流控或降级规则，当出现慢 SQL 调用时限制同一时刻执行的 SQL 数量，防止过多的慢 SQL 语句执行把资源耗尽。

关于 MSE 的 SQL 流控降级能力，MSE 支持配置流控、隔离、熔断以及热点限流等四种规则。

1、流量控制：通过流控能力，为服务接口配置流控规则，让容量范围内的请求通过，多余的请求被拒绝，相当于安全气囊的作用，可以有效保证 SQL 请求访问的流量控制在系统容量的阈值内。

后面 MSE 将会提供库、表维度聚合的 SQL 洞察能力，我们可以基于此能力控制指定数据库、表的流量控制在预估的容量范围内。

2、并发隔离：当流量近似稳态时：并发线程数 =QPS * RT(s)，其中 RT 升高，并发线程数升高，代表服务调用出现堆积。采用流量治理提供的服务并发隔离能力，给重要服务调用配置并发线程数限制，相当于一道“软保险”，防止慢 SQL 或者不稳定的服务过多挤占正常服务资源。

3、熔断降级：业务高峰期，某些下游的服务提供者大量的数据访问遇到性能瓶颈，出现大量的慢 SQL，甚至影响业务。我们对部分非关键服务的数据库访问配置自动熔断规则，当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果，这样既可以保障调用端不被堆积的数据访问请求拖垮，从而保障整个业务链路的正常运转。

4、热点流控：通过热点参数流控能力，自动识别 SQL 请求访问参数中的 TopN 访问热度的参数值，并对这些参数进行单独流控，避免单个热点访问过载；并且可以针对一些特殊热点访问（如极热门的抢购单品）配置单独的流控值。参数可以是 SQL 访问中的任意带有业务属性的条件，如以下 tid 参数的值。

连接池治理

连接池治理是数据库治理中非常重要的一个环节，通过一些链接池的实时指标，我们可以有效地提前识别系统中存在的风险，以下是一些常见的连接池治理的场景。

1、提前建连

在应用发布或者弹性扩容的场景下，如果刚启动实例中的连接并有没完成建立，但此时实例已经启动完成，Readiness 检查已经通过，意味着此时会有大量的业务流量进入新启动的 pod。大量的请求阻塞在连接池获取连接的动作上，导致服务的线程池满，大量业务请求失败。如果我们的应用具备提前建连的能力，那么就可以在流量到达前，将连接请求数保证在 minIdle 之上，并且配合小流量预热的能力，那么就可以解决以上这个让人头疼的冷启动问题了。

2、"坏"连接剔除

有时候连接池中会存在一些有问题的连接，可能是底层的网络出现了抖动，也有可能是执行的业务出现了慢、死锁等问题。如果我们可以从连接池的视角出发，及时地发现异常的连接，并且进行及时地剔除与回收，那么就可以保证连接池整体的稳定性，不至于被个别有问题的业务处理或者网络抖动给拖垮。

3、访问控制

理论上并不是全部数据库表都可以随便访问的，在某些时候，有些重要的表可能对于一些不太重要的服务来说，我们希望它是一个禁写、只读的状态，或者当数据库出现抖动、线程池满的情况下，我们希望减少一些耗时的读库 SQL 执行，又或者有一些敏感数据的表只允许某个应用去进行读写访问。那么我们就可以通过动态的访问控制能力，实时下发访问控制规则，来做到对于个别方法、应用的 SQL 面向数据库实例、表的禁读禁写等黑白名单的访问控制。

数据库灰度

微服务体系架构中，服务之间的依赖关系错综复杂，有时某个功能发版依赖多个服务同时升级上线。我们希望可以对这些服务的新版本同时进行小流量灰度验证，这就是微服务架构中特有的全链路灰度场景，通过构建从网关到整个后端服务的环境隔离来对多个不同版本的服务进行灰度验证。MSE 通过影子表的方式，用户可以在不需要修改任何业务代码的情况下，实现数据库层面全链路灰度。

总结

以上这些是 MSE 即将推出的一个数据库治理能力的预告，我们从应用的视角出发整理抽象了我们在访问、使用数据库时场景的一些稳定性治理、性能优化、提效等方面的实战经验，对于每一个后端应用来说，数据库无疑是重中之重，我们希望通过我们的数据库治理能力，可以帮助到大家更好地使用数据库服务。

原文链接

本文为阿里云原创内容，未经允许不得转载。