微服务里的事件驱动数据管理

微服务下的分布式数据管理问题

单体应用程序通常具有单个关系数据库。 使用关系数据库的主要好处是应用程序可以使用ACID事务，这提供了一些重要的保证：

• 原子性–原子地进行更改
• 一致性–数据库状态始终是一致的
• 隔离–即使事务是同时执行的，看起来它们还是串行执行的
• 持久性–事务一旦提交，便不会撤消

有了这些，应用程序就可以可以很容易的地开启事务，执行更改（插入，更新和删除）多行的操作并提交事务。

使用关系数据库的另一个巨大好处是它提供了SQL，这是一种丰富，声明式和标准化的查询语言。我们可以轻松地编写将多个表中的数据合并在一起的查询。然后，RDBMS query planner确定执行查询的最佳方法。不必担心底层细节，例如如何访问数据库。而且，由于您所有应用程序的数据都在一个数据库中，因此查询起来很容易。

然后，当我们转向微服务架构时，数据访问变得更加复杂。这是因为每个微服务拥有的数据是该微服务专用的，并且只能通过其API访问。封装数据可确保微服务松散耦合，并且可以彼此独立发展。如果多个服务访问相同的数据，则schema更新需要对所有服务协调更新。

更糟糕的是，不同的微服务通常使用不同种类的数据库。现代应用程序存储和处理各种数据，而关系数据库并不总是最佳选择。对于某些用例，特定的NoSQL数据库可能具有更方便的数据模型，并提供更好的性能和可伸缩性。例如，对于存储和查询文本的服务来说，使用诸如Elasticsearch之类的文本搜索引擎是有意义的。同样，存储社交图数据的服务可能应使用图数据库，例如Neo4j。因此，基于微服务的应用程序经常使用SQL和NoSQL数据库的混合，即所谓的多语言持久性方法。

用于数据存储的分区，多语言持久性架构具有许多优点，包括松散耦合的服务以及更好的性能和可伸缩性。但是，它确实带来了一些分布式数据管理方面的挑战。

第一个挑战是如何实现在多个服务之间保持业务transaction的一致性的。要了解为什么会出现问题，我们可以来看一个在线B2B商店的示例。客户服务维护有关客户的信息，包括他们的信用额度信息。订单服务负责管理订单，并且必须验证新订单没有超出客户的信用额度。如果用单体应用程序实现此功能的话，订单服务可以简单地使用ACID transaction来检查可用的信用额度并创建订单。

相反，在微服务体系结构中，ORDER和CUSTOMER表是它们各自的服务专用的，如下图所示。

订单服务无法直接访问CUSTOMER表。它只能使用客户服务提供的API。订单服务可能会使用分布式事务，也称为两阶段提交（2PC）。但是，在现代应用中2PC通常不是可行的选择。 CAP定理要求您在可用性和ACID样式一致性之间进行选择，而可用性通常是更好的选择。而且，许多现代技术，例如大多数NoSQL数据库，都不支持2PC。维护服务和数据库之间的数据一致性至关重要，因此我们需要另一个解决方案。

第二个挑战是如何实现从多个服务检索数据的查询。例如，假设应用程序需要显示客户及其最近的订单。如果订单服务提供了用于检索客户订单的API，那么您可以使用应用程序侧联接来检索此数据。该应用程序从客户服务中检索客户，并从订单服务中检索客户的订单。但是，假设Order Service仅支持