不要在微服务架构中使用单一数据库

21CTO导读：当你把团队的整个代码库拆分，并转移到微服务架构时，不要忘记还有一个更重要的数据库设计。本篇文章告诉我们，如何拆分单一数据库。

当我们分解应用程序，采用微服务架构时，还有一点是，要重点关注单一数据库的改造。架构师们需要一个更可靠的策略来将单一数据库拆分为与应用程序一致的多个数据库。即将应用程序或服务中的单一共享式的数据库转为分布式数据库。
我们应该以更正确的方式来设计微服务架构，每个单独的微服务都拥有自己的独立数据库和域数据，这才能让人们能够独立部署和扩展自己的微服务。
传统应用程序中都是单一的数据库，数据通常在不同组件之间共享。开发者们都使用过这样的数据库，由于数据存储在单一一个存储库中，开发也更简便。但是这个数据库设计会存在一些问题。

单一数据库设计存在的问题
第一，微服务提供多个类型服务，但单一数据库的传统设计会产生紧密耦合，无法做为独立部署服务。
如果有多个服务访问同一数据库，则需要在所有服务间协调数据模式的更改，在现实工作中，这会导致额外的工作，延迟部署更新。
第二，使用这样的设计很难对单个服务进行扩展，因为你只能选择扩展单一数据库。
第三，使用单一数据库，对提高应用程序性能成为挑战。当使用单一共享数据库，在一段时间过后，我们最终会有着一个数据庞大的表，让数据检索变得很困难，我们必须连接多个大表格，方能获取所需的数据。
第四，在绝大多数情况下，我们将数据使用关系存储到数据库。而使用关系数据库会限制一些服务。在有些情况下，NoSQL数据存储可能更适合你，能够降低集中式数据存储的紧密耦合。
如何在微服务中的处理好数据
每个微服务都应该属于有自己的数据库，它仅包含与微服务本身相关的数据。这样就可以允许我们独立部署单个服务。每个团队都可以拥有自己相应微服务的数据库。如下图：

微服务应遵循领域驱动设计，并且具有一定的上下文。
人们应根据领域设计方法构建应用程序，与原来你的应用程序功能保持一致。就像遵循Code First方法而不是Data First方法一样，首要任务是设计模型。
与开始处理新需求或新建项目时首次设计数据库表的传统心态相比，这是一种截然不同的方法。
我们应尝试从维护业务模型的完整性开始。
在设计数据库时，需要查看应用程序功能并确定它是否需要关系模式。如果符合你的一些标准，请保持对NoSQL 数据库的开放态度。

接着我们要将数据库视为每个微服务的私有数据库，其它微服务不能直接修改另一个微服务数据库中的数据。
在下图中，订单服务将无法直接更新定价数据库，它只能通过微服务API访问它。这有助于我们实现不同服务的一致性：

事件驱动架构是维护不同服务之间数据一致性的常见模式。
我们可以通过消息队列加载来使应用程序更有可用性和高性能，而不是等待ACID事务完成处理和占用系统资源。这也让服务之间具有的更松散的耦合。
发往队列的消息可以视为事件，遵循Pub-Sub模型。发布者发布消息，但不知道哪些消费者订阅了事件流。
架构中组件之间的松散耦合可以构建高度可扩展的分布式系统。

处理从单片应用到微服务的旅程中，对数据库的更改会更加不容易。
在本文中，我们一起了解了单片数据库设计的问题以及如何在微服务架构中处理数据。如果大家有任何问题，欢迎告诉我，很乐意进一步和大家一起讨论~