数据库治理的探索与实践

背景

在分布式系统架构中，业务的流量都是端到端的。每个请求都会经过很多层处理，比如从入口网关再到 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支持配置流控、隔离、熔断以及热点限流等四种规则。

• 流量控制

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

• 并发隔离

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

• 熔断降级

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

• 热点流控

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

 SELECT * FROM order WHERE tid = 1$

连接池治理

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

​

• 提前建连

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

• "坏"连接剔除

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

• 访问控制

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

数据库灰度

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

​

动态读写分离

总结

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

​

• 最后提一下服务治理的标准OpenSergo

OpenSergo 也会在9月推出数据库治理相关的标准，会进一步抽象与标准化数据库治理相关的能力。目前OpenSergo 社区正在联合各个社区进行进一步的合作，通过社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、字节跳动等企业一起共建标准，也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335