在分解单体应用程序到微服务体系架构时，重点考虑独立数据库拆分是很重要的。您需要想出一个可靠的策略，将您的数据库分割为多个与应用程序对齐的小型数据库。简而言之，您需要将您的应用程序/服务从使用单一的共享数据库中拆分出来。
您应该以这样一种方式设计您的微服务体系结构，即每个单独的微服务都有自己的独立数据库和自己的领域数据。这将允许您独立部署和扩展微服务。
传统的应用程序只有一个共享的数据库，数据通常在不同的组件之间共享。我们都使用过这样的数据库，并且发现开发更简单，因为数据存储在一个存储库中。但是这种数据库设计存在很多问题。
共享单个数据缺点
1、为多个服务提供单个数据库的传统设计造成了紧密耦合，并且无法独立部署服务更改。如果有多个服务访问同一个数据库，那么任何模式更改都需要在所有服务之间进行协调，这在现实世界中可能会导致部署更改的额外工作和延迟。
2、使用这种设计很难扩展单个服务，因为您只能选择扩展整个单块数据库。
3、提高应用程序性能成为一个挑战。使用一个共享数据库，在一段时间内，您最终会得到一个巨大的表。这使得数据检索变得困难，因为您必须连接多个大型表来获取所需的数据。
4、大多数情况下，关系存储是作为整体数据库的。这限制了所有服务使用关系数据库。然而，在某些情况下，无sql数据存储可能更适合您的服务，因此您不希望与集中式数据存储紧密耦合。
如何在微服务体系结构中管理数据
每个微服务都应该有自己的数据库，并且应该包含与该微服务本身相关的数据。这将允许您独立部署单个服务。单个团队现在可以拥有相应微服务的数据库。
微服务应该遵循领域驱动设计并具有有限的上下文。您需要基于领域来设计应用程序，领域与应用程序的功能是一致的。这就像遵循代码优先方法而不是数据优先方法一样——因此您首先设计模型。这是一种与传统的在开始处理新需求或新项目时首先设计数据库表的方法完全不同的方法。您应该始终努力保持业务模型的完整性。
在设计数据库时，查看应用程序功能并确定它是否需要关系模式。如果NoSQL数据库符合您的标准，请保持对它的开放态度。
数据库应该被视为每个微服务的私有数据库。没有其他微服务可以直接修改存储在另一个微服务中的数据库中的数据。
在下图中，订单服务不能直接更新定价数据库，只能通过微服务API访问。这有助于您实现不同服务之间的一致性。
事件驱动架构是在不同服务之间维护数据一致性的通用模式。与等待ACID事务完成处理并占用系统资源不同，您可以通过将消息卸载到队列中来提高应用程序的可用性和性能。这提供了服务之间的松散耦合。
队列的消息可以被视为事件，并且可以遵循发布-子模型。发布者发布消息，而不知道已经订阅了事件流的使用者。体系结构中组件之间的松散耦合可以构建高度可伸缩的分布式系统。
在从单体架构到微服务的过程中处理数据库更改是一项挑战。在本文中，我们了解了单体数据库设计的问题，以及如何在微服务体系结构中处理数据。如果您有任何问题，请让我知道，我很乐意进一步讨论。
For more information about Architecture for Containerized Applications, please download the free ebook provided by Microsoft here.
