一、现状

现状

我们将一个大而全的系统一拆为三，容器，发布，测试都已经独立出去，但是原始的数据库还是一套，现在需要将数据库做一个拆分，A、B、C三个系统有各自的数据库之后，我们的微服务化在现有部署、测试等已经独立的基础上才算最终完成，形成三个各自独立的单元。因此本篇文章叙述的不是数据库的水平拆分也不是垂直拆分，不是讲述分库分表，而是讲述从业务系统去拆分数据库，把业务最终微服务化。

二、方法

拆分方案

2.1、SOA

通过提供RPC接口，将原先共用的表有一方系统提供接口服务，另一方系统来调用该接口。这种情况下系统之间是解耦了，但是数据调用的时候一方还是要强依赖另一方。这个时候要重新关注接口服务方如果down掉或者延时发生，需要有容错机制，比如熔断、降级等。同时要考虑好数据的托底展示，比如本机缓存，remote缓存。详细可参看《微服务下的网关与容错》里面有专项介绍。

2.2、数据异构

通过数据异构的方式，比如B系统与C系统原来是一张表，数据库拆分之后这张表的数据放在了C系统，但是B系统只需要这张表的部分字段，这个时候可以通过异构平台把C系统的表按需异构到B系统中的一张表。这样两个系统之间彻底解耦，各自微服务化，也没有了SOA方式的强依赖问题。关于数据异构的详细介绍可以参看这篇文章《数据异构的武器-BINLOG+MQ》

三、拆库的步骤(mysql)

集群A(源库)
集群B(新搭建)
集群C(新搭建)

DB拆库起始位置

注意此方案需要停写！

步骤一、搭建集群B、C
将集群B、C以从库形式挂载到集群A

步骤二、将如下集群A主库设置为只读模式
192.168.x.x xx.mysql.xxx.com
命令：set global read_only=on;

步骤三、待从库无延迟后，集群B、C停止复制，执行如下操作
命令：stop slave;
此时A、B、C三套集群均为只读模式

步骤四、研发人员修改应用url指向到正确的数据库集群，待确认无误后，（此时可回退，打开写后不可回退）
通知DBA将集群A、B、C三套打开读写
命令：set global read_only=off;

步骤五、拆分完成

DB最终位置

步骤六
观察一段时间后drop冗余表，DBA在复制的时候实际上是全量复制，因此后续我们需要drop掉各自系统内不需要的表。可以用rename的方式先行标出，一段时间后再drop掉。

===================================================================
回退方案
步骤一、集群B、C打开复制
命令：start slave;
步骤二、打开集群A的读写
命令：set global read_only=on;

四、SOA和微服务

SOA面向服务架构，是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。关键点是接口调用，这是目前分布式系统中常用的方法。目前开源的RPC框架也有很多比如知名的DUBBO服务等。

微服务的重点是业务系统要彻底组件化和服务化，原有的单体应用系统会拆分为多个可以独立开发、运行、部署和运维的小应用。这些小的应用之间如果需要交互就通过服务来完成，比如提供DUBBO接口服务。每个小应用内部从前端WEB到业务逻辑处理，到数据库访问，以及数据库都是独立的。

五、总结

业务简单，团队组织规模较小的时候一个单体应用就可以支持当时的业务发展。随着业务的发展规模越来越大，过程中如果技术架构升级没有跟上，就会面临后期拆系统，拆库的的阶段。本篇文章结合我工作中自身的经历集中对数据库的业务拆分做了描述，拆库的原则以及数据库新集群的创建方法。对于拆分，我们要拆的粒度有多大，或者多小，没有一个标准，关于这方面，推荐大家阅读一本书《恰如其分的软件架构》。

转载请注明作者及出处，并附上链接https://my.oschina.net/wangxindong/blog/1574768