微服务|微服务架构下的数据库拆分微服务|数据库

?1现状微服务是当前非常流行的技术架构，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。在微服务架构下，我们将一个大型系统分为三部分：容器、发布和测试是独立的，但原始数据库仍然是一个（如下图）。现在我们需要拆分数据库。在三个系统A、B、C拥有各自的数据库后，我们的微服务最终才可以的部署、测试，形成三个独立的单元。本文就聊一聊数据库与业务系统的拆分以及业务的最终微服务化。

文章图片

2 方法【微服务|微服务架构下的数据库拆分】对于拆分的方法，可以参照下图演示的拆分方法，Service B和Service C之间通过数据异构的方式进行解耦，ServiceA和ServiceB之间、ServiceA和ServiceC之间则通过RPC进行通信。

文章图片

SOA
通过提供RPC接口，一个系统为以前共用表的服务提供接口，另一个系统调用该接口。在这种情况下，系统是解耦的，但是一方在调用RPC服务时仍然必须依赖另一方。此时，我们应该更加关注接口服务提供者，如果发生延迟或宕机，则需要有一种熔断降级等容错机制。同时，还需要考虑兜底数据。

数据异构
通过数据异构的方式，例如，系统B和系统C曾经是共同使用一个库表。数据库拆分后，该表的数据被放置在系统C中，而系统B只需要该表的一些字段。此时，通过异构的方式，将系统C的表可以异构为系统B中的表。通过这种方式，这两个系统是完全解耦的，并且也没有SOA的强烈依赖问题。关于数据异构的介绍可以参看之前发的文章架构修炼之道—数据异构的武器canal。

3拆分步骤 MySQL

搭建集群B、C将集群B、C以从库形式挂载到集群A。
将集群A主库设置为只读模式命令：set global read_only=on。
待从库无延迟后，集群B、C停止复制，执行如下操作命令：stop slave; 此时A、B、C三套集群均为只读模式。
修改应用url指向到正确的数据库集群，待确认无误后，通知DBA将集群A、B、C打开读写命令：set global read_only=off。
拆分完成，已经形成ABC三个数据库集群。
观察一段时间后drop冗余表，DBA在复制的时候实际上是全量复制，因此后续我们需要drop掉各自系统内不需要的表。可以用rename的方式先行标出，一段时间后再drop掉。

注意此方案需要停写！

4 SOA和微服务SOA是一种粗粒度、松散耦合的服务架构。服务通过简单且准确定义的接口进行通信，而且不涉及底层编程接口和通信模型。核心是接口的调用，这是分布式系统中的一种常用方法。

文章图片

微服务的重点是业务系统应该完全基于组件和面向服务。最初的单一应用系统将被划分为多个小型应用，这些应用程序可以独立开发、运行、部署、操作和维护。如果这些小应用程序需要交互，可以通过服务完成，例如提供Dubbo接口服务。每个小服务都独立的前端web、业务逻辑处理和数据库。

5 总结本篇文章对微服务架构下数据库的业务拆分做了描述，对拆库的方法和步骤以MySQL为例进行了讲解。微服务的拆分没有统一的解决方案，需要团队根据自己的业务和团队规模进行分析，结合目前的业务状况和发展趋势找到目前最好的拆分方案。