Chris Richardson微服务翻译：微服务之事件驱动的数据管理

Chris Richardson 微服务系列翻译全7篇链接：

微服务介绍

构建微服务之使用API网关

构建微服务之微服务架构的进程通讯

微服务架构中的服务发现

微服务之事件驱动的数据管理（本文）

微服务部署

重构单体应用为微服务

原文链接：Event-Driven Data Management for Microservices

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

单体应用一般只有一个关系型数据库，这样的好处是可以实现 ACID 保证：

原子性（Atomicity）：原子粒度的更改

一致性（Consistency）数据库的状态始终保持一致

隔离性（Isolation）：并发的事务表现的像是串行执行，事务之间不会互相影响

持久性（Durable）：一旦事务提交就不会撤销

因此，应用可以简单的开始事务，更改（增删改）多行数据，然后提交事务。

使用关系型数据库另一好处是支持 SQL。SQL 是一种丰富的、声明式的标准查询语言，用户能简易的关联查询多个表中的数据，然后RDBMS 查询调度器会执行最优的查询方式，用户不必关系底层的细节。所有的数据在一个数据库中也方便查询。

然而微服务架构中数据访问变的复杂，因为每个微服务都拥有独立的数据库，仅能通过 API 来访问。数据封装保证了微服务的松耦合，各个服务可以独立其他服务演进。而如果多个服务访问同样的数据，架构更新会更耗费时间，也需要更多的服务协调。

不同服务可能使用不同类型的数据库，现代应用存储和处理各种各样的数据，关系数据库并不总是最好的选择。一些场景下，一种特殊的 NoSQL 能提供更方便的数据模型、更好的性能和可扩展性。例如：使用 ElasticSearch 这样的搜索引擎来进行文本的存储和查询；使用 Neo4j 这样的图谱数据库来存储社交图谱数据。因此，微服务应用会混合使用 SQL 和 NoSQL 数据库，即多态型数据持久方案。这也带来了一些挑战：

1）如何跨多个服务实现事务，维护数据的一致性。我们以 B2B 商店为例：客户服务维护用户信用额度等相关的信息，订单服务管理订单并确保新订单没有超过用户的信用额度。单体应用中，订单服务可以使用 ACID 事务来核对用户信用额度并新建订单。而在微服务架构中， order 和 customer 表是各个服务私有的：