架构方案：分库分表模式下，数据库扩展方案一，数据库扩展一，业务场景互联网项目很多即“数据量大，业务复杂度高，需要分库分表的业务场景”。这样的分层架构（1）上层是业务层biz，实现业务逻辑封装；（2）中间层是service层service，封装了数据访问；（3）下层是数据层db，存放业务数据；2、扩容场景及问题当数据量不断增加时，我们面临着两个数据库无法容纳的需求，需要对数据库进行扩容。这里我们选择2库模型——扩容为3库，如下图：此类扩容存在的问题（1）分库分表（2）影响数据的持续服务性；(3)规定时间完成，技术压力大，容易出现意外错误；如何在不停机的情况下平滑迁移数据，保证系统持续服务。二、扩容方案一、扩容方案示意图（一）分库分表基于MySQL数据库，使用shard-jdbc中间件（二）本方案思路基于SpringCloud微服务架构为一个整体2.解决扩容问题(1)扩容情况无需停服；(2)数据迁移压力小，无需指定时间；3.数据访问层基于二库分库分表的逻辑方案描述，简称：服务二基于三库分库分表，简称：服务三（1）提供两套services,Service2和Service3(2)数据库扩容后，如果访问Service3直接获取数据，流程结束。(3)如果访问服务三获取不到数据，则访问服务二获取数据。(4)在迁移开始的时间段内，访问压力仍然在第二个服务上。(5)这样，数据访问服务就不会停止。(6)这种访问方式基于SpringCloud易于实现。4.数据迁移层逻辑方案说明(1)关闭基于两个数据库的数据存储进程(2)启用基于三个数据库的数据存储进程，使得新存储的数据可以直接被访问服务三。(3)开发数据迁移中间件，扫描原有两个数据库的数据。(4)扫描数据根据分三库的策略判断是否需要迁移。(5)如果需要迁移数据，调用服务三的数据存储接口。(6)数据迁移完成后，删除原位置的数据。(7)这种迁移模型基于SpringCloud很容易做到。5、本方案迁移的优势（1）全程持续提供在线服务；(2)数据迁移中间件开发复杂度低；(3)可以在没有时间压力的情况下，以有限的速度缓慢迁移。
