微服务下的分布式数据管理问题
单体应用程序通常具有单个关系数据库。 使用关系数据库的主要好处是应用程序可以使用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仅支持