微服务治理热门技术揭秘：动态读写分离

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

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务治理热门技术揭秘：动态读写分离相关的知识，希望对你有一定的参考价值。

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

MSE 数据库治理完整解决方案

本文将详细介绍 MSE 数据库治理的热点功能，动态读写分离的设计与实现。

读写分离的概述

数据库动态读写分离的常见场景：

一个大客户的请求过来，查询数据库返回上万条几百 M 的数据，数据库的 CPU 直接打满。
微服务应用的某些业务并不是那么重要，却存在大量查询数据库的逻辑，影响数据库实例稳定性，从而导致整体服务质量的下降。
在业务处理过程中，如果对数据库的读操作远多于写操作，那么在做系统性能优化时就可以考虑引入读写分离的方案，一方面只读库可以承担主库的压力，另一方面能够有效的避免由数据更新导致的锁等待，提升微服务应用的性能。
随着业务的增长，我们在一定时机下需要对数据库实例进行扩容。根据经验大多数应用的读写比都在 5:1 以上，有些场景甚至大量的高于 10:1，在对数据库有少量写请求，但有大量读请求的应用场景下，单个实例可能无法承受读取压力，甚至对业务产生影响。

可以了解到的是数据库读写分离方案可以满足阿里云上大多数公司的稳定性治理、性能提升以及数据库扩容的需求。

如果了解读写分离实现的同学一定会关注以下这些问题：

MSE 是如何解决读写分离对业务的侵入性？如何做到业务无需改动一行代码，即可具备读写分离能力。
MSE 如何做到精细化动态的读写分离控制？即使我们不知道这个业务接口真实的 SQL 是什么，但我们已经可以控制这个接口的读 SQL 访问只读实例。
MSE 是如何解决读写分离带来的一致性问题？对于一致性敏感的业务，如何实现一致性的保障，满足业务在不同场景下对一致性级别的要求。

MSE 读写分离技术揭秘

读写分离也就是将数据库拆分为主库和从库，即主库负责处理事务性的增删改操作，从库负责处理查询操作的数据库架构。单单看读写分离的概念，第一感觉就是对业务的侵入性一定不小，那么 MSE 是如何做到无侵入的呢？

无侵入性：无需修改一行代码

MSE 数据库治理能力通过 JavaAgent 技术，动态增加用户的数据源，注入动态读写分离能力，支持运行时动态将弱读请求路由至只读实例。

MSE 在数据源层面实现了抽象，其中 DynamicConnection、DynamicStatement 会根据具体规则从而实现 Master/Slaver 的切换，做到根据 SQL 的读写类型、事务的状态以及用户的业务规则来做 SQL 的路由，将符合条件的读 SQL 请求转发至 RDS 只读实例中。

精细化路由：按照请求条件、接口、SQL 多层次多条件

很多时候我们通过编写 DAO 访问数据库，那么在一些复杂应用的场景下，我们很可能只知道 DAO 接口，在一些复杂场景下我们只知道微服务的接口，内部甚至搞不清楚到底调用的哪个 DAO 接口、SQL 语句，甚至如果是运维角色参与设计，我们很可能不知道哪个微服务接口导致的读请求导致数据库抖动，我们只知道入口应用的某个 uid。那么我们如何做到对业务接口内的读请求路由至只读实例呢？

MSE 数据库治理提供了应用层面完整的 callStack 信息，可以让我们站在应用的视角上清晰地看到哪些接口内部执行了哪些 SQL。

MSE 通过链路传递技术，支持在入口微服务、微服务接口、DAO 层面标记弱读请求的标记，支持标记的当前线程内的 SQL 调用、当前微服务内的 SQL 调用、符合流量条件的请求链路级别的所有 SQL 调用等多个层面的弱读标记传递，最终传递给读写分离组件的路由引擎进行 SQL 的路由依据的判断。

强一致性模式：指定接口、事务

当数据库负载很高时，例如对大表执行 DDL（如加字段）操作或大批量插入数据的时候，延迟会非常严重，从而导致无法从只读实例中读取最新数据。MSE 提供了一些策略解决如上问题，某些接口或者某些业务对一致性比较非常高，我们可以通过规则配置告诉 MSE 在特定场景下，某些读接口标记为强读请求。MSE 内部会通过一些机制保证读写分离的强一致性效果。