微服务架构之事件驱动架构

前言

为了解决传统的单体应用（Monolithic Application）在可扩展性、可靠性、适应性、高部署成本等方面的问题，许多公司（比如Amazon、eBay和NetFlix等）开始使用微服务架构（Microservice Architecture）构建自己的应用。

微服务架构（维基百科）：
微服务 (Microservices) 是一种软件架构风格 (Software Architecture Style)，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

但是，微服务架构在带来一系列好处的同时，也带来了若干挑战。除了分布式系统固有的复杂性以外，微服务架构也深刻影响了应用和数据库之间的关系，与传统多个服务共享一个数据库的方式不同，微服务架构每个服务都有自己的数据库。对于开发者来说，这就为微服务中的数据管理提出了更高的要求。

微服务架构中的数据管理

在传统的单体应用中，通常使用单个的关系型数据库。这类数据库所提供的事务语义，具备ACID特性。

ACID：
- Atomicity（原子性）：一个事务中的操作是原子的，其中任何一步失败，系统都能够完全回到事务前的状态
- Consistency（一致性）：数据库的状态始终保持一致
- Isolation（隔离性）：多个并发执行的事务不会互相影响
- Durability（持久性）：事务处理结束后，对数据的修改是永久的

应用得益于数据库的这些特性，能够用简单的方式对数据进行修改与读取，而无需花费太多精力考虑数据一致性问题。

但是，在微服务架构下，为了在微服务之间建立松耦合的关系，通常每一个微服务都会拥有自己独立的数据库，仅仅通过对外暴露的API来进行数据交换。这种情况下，我们就要面临分布式数据管理带来的挑战。也就是说，在实现业务逻辑时，如何保证服务之间的数据一致性。

实时一致性

我们首先考虑在系统中实现实时一致性的情况。比如以一个银行系统为例，客户通常会有一个储蓄账户和一个理财账户。现在，考虑客户从自己的储蓄账户向理财账户转账10000元的场景。

假设现在有两张表 deposit_account 和 finance_account，分别用于存储储蓄账户和理财账户的信息，用户的ID是201。那么，在单一数据库场景下，通过数据库事务可以很容易完成这个操作：

Begin transaction
    update deposit_account_table set amount=amount-10000 where userId=201;
    update finance_account