这种模式下，存在以下几个问题
1 可用性：假设一个完整的业务流程P访问的数据库被拆分为A、B、C、D、E 五个库，假设每个写库可用性为99%，那么这个业务流程P的可用性就为99%*99%*99%*99%*99%=95%,库拆分的越多，对系统的整体可用性挑战就越大。
2 性能：由于垂直业务库每个库的负载可能不一样，假设交易库负载很高，一个交易写库肯定不能够满足需求，这个情况下，交易库成为整个系统的瓶颈。
3 可扩展性：单个节点的可扩展性没有得到改善，交易库不能单独进行扩展。
单业务库水平、垂直拆分
在上一种情况，假设交易库是整个系统的瓶颈，需要对交易库进行单独的扩展。可以考虑交易的水平拆分或者垂直拆分，有可能同时进行两种方式拆分。
水平拆分一般根据业务无关的关键字进行拆分，横向扩展性比较好，但是对于查询的挑战比较大
垂直拆分一般根据业务来拆分，但是可能导致数据不均匀以及拆分不够灵活。对于查询来说，相对比较友好
拿交易库举个例子，可以先交易的类型进行业务上的垂直分库，在按照订单号进行水平分库。
假设可以分成M*N个库，那么单个库的故障会影响1/M*N 的交易，但是假设每个库可用性为99% ，那么交易数据库故障概率为 (99%)的(M+N)次方，如果数据库拆分的越多，发生单个数据库故障概率就越高。
这种方式存在的问题：
1 虽然单个节点故障影响的用户很少，但是整体可用会降低。
2 数据库管理上带来复杂的挑战，假设交易库表结构变更，需要执行M×N次脚本变更。
3 由于发生单个数据库故障的概率比较高，dba会很苦逼的，估计经常性要救火
4 开发和测试起来会非常苦逼，开发和测试成本会变高，查询非常复杂。
5 单个节点如果发生故障，没有失败检测并且切换机制
6 分库还不能在水平方向做到无限扩展，我们的算法是事先分配M个库，如果添加一个库基本上不可行
随机分库
对于第六个问题，在水平方向的无线扩展，可以考虑一种机制，在insert数据的时候，申请一个数据库编号，然后把数据库的编号作为一个字段保存或者在把这个编号添加到已经字段上。
例如假设我们申请insert数据库，得到一个数据库编号为1000，那么我们可以构造出来一个订单号为1000_tradeno，订单号前面是分库编号，订单号后面是实际tradeno，这样解决了水平无线扩展的问题。这种就是随机分库模式。但是这一种方式的局限性很大，
随机分库的缺点：
1 分库算法和业务耦合在一起，比较适合特定的场景，适用范围比较窄
2 对于insert操作，比较容易，对于update操作，必须有分库编号，也就是说，只能根据特定的字段来进行更新
3 不适合批量查询的场景，查询功能限制比较大，这也是分库带来的问题
单数据库备份以及失败切换
对于单个数据库，如果发生故障，会影响业务，但是能否在发生故障的时候进行切换。虽然可以实现，但是会存在一定的问题，需要特定场景进行特定的分析。这一块比较复杂，说起来可以在写一篇文章，就简单的介绍一下
以上就是总结的数据库的架构演变，数据库的演变需要很多基础技术做支撑，主要包括
1 强大的分布式数据库的管理中间件，主要屏蔽底层的数据库路由以及数据管理功能
2 强大的数据运维团队以及监控体系，能够检测出每个节点的数据库状态
3 强大的数据库管理管理团队，能够维护这么的数据库集群
4 强大的业务架构能力和技术架构能力，能够掌控这么复杂的业务场景。
