在分布式系统架构中，业务的流量都是端到端的。每个请求都会经过很多层处理，比如从入口网关再到 Web Server 再到服务之间的调用，再到服务访问缓存或 DB 等存储。
对于我们的系统来说，数据库是非常重要的一块。因此无论是在稳定性的治理上，还是在开发提效等场景下，数据库相关的治理能力都是我们系统所需具备的能力。下面总结了微服务访问数据库层时，在数据库治理中的常见的一些场景与能力。
OpenSergo 领域中关于数据库治理的概览
本文将介绍 MSE 服务治理最近推出数据库治理利器：无侵入实现数据库访问的读写分离能力。
什么是读写分离？读写分离也就是将数据库拆分为主库和从库，即主库负责处理事务性的增删改操作，从库负责处理查询操作的数据库架构。
稳定性
一个大客户的请求过来，查询数据库返回上万条几百 M 的数据，数据库的 CPU 直接打满。不知道大家是否遇到过类似的问题。
性能
在业务处理过程中，如果对数据库的读操作远多于写操作，同时业务上对于数据查询结果的实时性要求不高（例如可以容忍秒级的延迟），那么在做系统性能优化时就可以考虑引入读写分离的方案，只读库可以承担主库的压力，有效提升微服务应用的性能。
规模增长
随着业务增长，到了一定规模之后再扩容，但很多都卡在扩容这一步，极大的限制了应对市场变化的速度，其中数据库的扩容是最难的，目前常见的数据库扩容方式有以下几种方式：
- 垂直升级
- 分库分表
- 读写分离
垂直升级需要中断服务且高可用方面不及其它几种方式，分库分表在分区键的选择上会是个难点，SQL 使用上会有诸多限制，同时对业务的改造也是非常大的工作量。相对来说读写分离是对业务的侵入最低也最容易实现扩容方案。根据经验大多数应用的读写比都在 5:1 以上，有些场景甚至大量的高于 10:1，在对数据库有少量写请求，但有大量读请求的应用场景下，单个实例可能无法承受读取压力，甚至对业务产生影响。
综上所述数据库读写分离方案可以满足阿里云上大多数公司的稳定性治理、性能提升以及数据库扩容的需求。
读写分离常见方案目前业界流行的读写分离方案，通常都是基于上述主从模式的数据库架构。读写分离的实现方案多数是通过引入 odp、mycat 等数据访问代理产品，通过其读写分离功能来帮助实现读写分离。引入数据访问代理的好处是源程序不需要做任何改动就可以实现读写分离，坏处是由于多了一层中间件做中转代理，性能上会有所下降，数据访问代理也容易成为性能瓶颈。
