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为例进行了讲解。微服务的拆分没有统一的解决方案,需要团队根据自己的业务和团队规模进行分析,结合目前的业务状况和发展趋势找到目前最好的拆分方案。