在微服务开发中，随着业务量数据量的提升，数据库必定遭遇高并发等风险。这里我们可以先来看一下如下图：

这是一个典型的微服务实例，假设现在有一个订单微服务（可以是一个服务集群），这个服务必定对应一个业务库，那就是订单数据库，订单微服务处于一整个服务调用的链路中，他会被其他微服务来进行调用，可以是rest请求也可以是rpc等调用。

这个订单库是单库，单库在高并发的情况下必定出现瓶颈。此时，我们需要进行一定的优化。

根据“二八原则”，80%都是读请求，甚至更多，20%都是写请求，甚至更少。所以绝大多数的业务场景之下都是高并发读。假设我们现在的目的是，要提高并发读的性能以及高可用读。那么这个时候我们可以将单数据库优化为如下：

从图中可以看到，用户的请求并不是全部都到达一个单库，而是会被分流，这是一个非常典型的读写分离架构。一个主库对应三个从库，主从之间通过binlog进行数据复制，而且主从的表数据结构完全一致，数据也都一样。

像这样的一个主从架构可以保证高性能读以及高并发读，如果读库集群再次达到瓶颈则可以继续进行水平扩展。