微服务：如何拆分共享数据库？

在分解单体应用程序到微服务体系架构时，重点考虑独立数据库拆分是很重要的。您需要想出一个可靠的策略，将您的数据库分割为多个与应用程序对齐的小型数据库。简而言之，您需要将您的应用程序/服务从使用单一的共享数据库中拆分出来。您应该以这样一种方式设计您的微服务体系结构，即每个单独的微服务都有自己的独立数据库和自己的领域数据。这将允许您独立部署和扩展微服务。

1、为多个服务提供单个数据库的传统设计造成了紧密耦合，并且无法独立部署服务更改。如果有多个服务访问同一个数据库，那么任何模式更改都需要在所有服务之间进行协调，这在现实世界中可能会导致部署更改的额外工作和延迟。2、使用这种设计很难扩展单个服务，因为您只能选择扩展整个单块数据库。3、提高应用程序性能成为一个挑战。使用一个共享数据库，在一段时间内，您最终会得到一个巨大的表。

微服务应该遵循领域驱动设计并具有有限的上下文。您需要基于领域来设计应用程序，领域与应用程序的功能是一致的。这就像遵循代码优先方法而不是数据优先方法一样——因此您首先设计模型。这是一种与传统的在开始处理新需求或新项目时首先设计数据库表的方法完全不同的方法。您应该始终努力保持业务模型的完整性。在设计数据库时，查看应用程序功能并确定它是否需要关系模式。

数据库应该被视为每个微服务的私有数据库。没有其他微服务可以直接修改存储在另一个微服务中的数据库中的数据。在下图中，订单服务不能直接更新定价数据库，只能通过微服务API访问。这有助于您实现不同服务之间的一致性。

队列的消息可以被视为事件，并且可以遵循发布-子模型。发布者发布消息，而不知道已经订阅了事件流的使用者。体系结构中组件之间的松散耦合可以构建高度可伸缩的分布式系统。