本文介绍了数据库治理的读写分离能力的技术细节。
我们从应用的视角出发整理抽象了我们在访问、使用数据库时场景的一些稳定性治理、性能优化、提效等方面的实战经验，对于每一个后端应用来说，数据库无疑是重中之重，我们希望通过我们的数据库治理能力，可以帮助到大家更好地使用数据库服务。
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 内部会通过一些机制保证读写分离的强一致性效果。
白屏化能力：通过 AccessLog 实时感知读写分离情况
有读写分离能力，那么我们如何知道读写分离的执行情况，到底哪些应用，哪些请求被分离至了只读实例？MSE白屏化能力提供了一套完整的AccessLog。
读请求路由至只读实例
读请求路由至主实例
总结
MSE 从应用的视角出发，结合微服务治理通用的技术，MSE 推出的是完整的数据库治理解决方案，从SQL洞察、SQL流控降级与容错、连接池治理到数据库灰度、动态读写分离。我们希望通过数据库治理能力可以帮助用户的微服务可以更好地使用数据库，降低数据库使用的成本，提升数据库访问的稳定性。
MSE 的数据库治理能力也需要更多更加深入的客户场景与落地实践，如果您对MSE的数据库治理能力感兴趣，欢迎联系我们，只有经过客户打磨的产品才会愈发历久弥新。
在建设数据库治理能力的同时，我们也通过OpenSergo在与社区共同建设数据库治理的标准。
OpenSergo 在联合各个社区进行进一步的合作，希望通过社区来一起讨论与定义统一的服务治理标准。当前社区也在联合 bilibili、字节跳动等企业一起共建标准，也欢迎感兴趣的开发者、社区与企业一起加入到 OpenSergo 服务治理标准共建中。欢迎大家加入 OpenSergo 社区交流群（钉钉群）进行讨论：34826335。
