微服务架构(九): 数据管理

工作中使用了微服务架构，接下来的一段时间里，我会写一系列的文章来介绍微服务架构，这篇文章主要讲述了微服务架构中的数据管理。

翻译和整理自：

• http://microservices.io/patterns/data/database-per-service.html
  
• http://microservices.io/patterns/data/shared-database.html
  
• http://microservices.io/patterns/data/event-driven-architecture.html
  
• http://microservices.io/patterns/data/event-sourcing.html
  
• http://microservices.io/patterns/data/transaction-log-tailing.html
  
• http://microservices.io/patterns/data/database-triggers.html
  
• http://microservices.io/patterns/data/application-events.html
  
• http://microservices.io/patterns/data/cqrs.html
  
• http://www.cnblogs.com/dinglang/p/5679542.html （文中摘抄了这篇博文的大部分内容）
  

一、事件驱动架构

1.上下文和问题

你已经应用了 Database per Service 模式。每个服务都有它自己的数据库。但是，有一些业务事务跨越多个服务，所以你需要一种机制来确保多个服务之间的数据一致性。比如说，假设你在构建一个在线商城，应用必须保证一个新订单的数额不超过客户的余额。因为订单和客户在不同的数据库之间，所以你不能简单的用本地的ACID事务去达到这个目的。那么，怎么保障数据的一致性呢？

强制条件：  不使用两阶段提交协议  （译者注： 读者如果不了解分布式事务，可以参考下这篇文章： http://www.cnblogs.com/dinglang/p/5679542.html）

2.解决方案

使用一个数据驱动的，最终一致性的解决方案。每个服务在更新数据时会发布一个事件，别的服务订阅这些事件，当收到事件时，服务更新自己的数据。

示例：

1. Order Service 创建一个处于待定状态的订单，然后发布一个OrderCreated 事件。
2. Customer Service 收到这个事件，判断用户的余额满不满足这个订单的需求。然后它发布一个 Credit Reserve 事件或者一个 CreditLimitExceeded 事件。
3. Order Service 收到了 Customer Service 发布的时间，把订单的状态改成通过或取消。

3.结果

优点：

• 应用不需要使用分布式事务就能维持多个服务之间的数据一致性

缺点：

• 编程模型更复杂了

要解决的问题：

• 为了实现可靠性，应用必须原子的更新自己的数据库和发布事件。它不能使用传统的分布式事务的机制来拓展到数据库和消息代理的层面，而必须使用如下的模式中的一种，来原子的更新状态和发布事件：
  • Event sourcing
  • Application events
  • Database triggers
  • Transaction log tailing

二、事件源(Event sourcing)

1.上下文和问题

你已经应用了上文的事件驱动架构模式。为了实现可靠性，应用必须原子的更新自己的数据库和发布事件。使用分布式事务来覆盖数据库和消息代理层面不可行的，那么怎么做呢？

2.解决方案

解决这个问题的一个好方案是使用事件源。事件源把业务实体比如订单和客户持久化成一系列状态变化的事件。当一个业务实体的状态变化时，新的事件加入到这个事件列表的尾端。因为保存一个事件是单个操作，它是原子性的。应用可以通过重现这些事件的方式来重新构建一个实体现在的状态。

应用把事件持久化在一个事件存储中，它是一个事件的数据库。这个存储有一个增加和获取事件的api。这个事件存储也类似于一个消息代理，它提供了一个api让服务可以订阅事件。当一个服务把事件保存在事件存储中时，这个事件被传递到所有的订阅者那。

有一些实体，比如说客户，可能会有很大数量的事件。为了优化负载量，应用可以周期性地保存一个实体当前状态的快照。为了重新构建当前的状态，应用找到最新的快照和那个快照之后的事件，于是需要重现的事件就少了一点。

示例

Customers and Orders 是一个使用事件源和 CQRS的示例应用。这个应用使用Java语言编写，用到了Spring Boot。它使用 Eventuate构建， 这是一个基于事件源和CQRS的应用平台。下图展示了它是怎么持久化订单的：

应用以一系列事件的方式持久化Order ，而不是简单地把每个order当前的状态保存在表中。CustomerService可以订阅order events，然后更新自己的状态。

Order：

public class Order extends ReflectiveMutableCommandProcessingAggregate<Order, OrderCommand> {  private OrderState state;  private String customerId;  public OrderState getState() {    return state;  }  public List<Event> process(CreateOrderCommand cmd) {    return EventUtil.events(new OrderCreatedEvent(cmd.getCustomerId(), cmd.getOrderTotal()));  }  public List<Event> process(ApproveOrderCommand cmd) {    return EventUtil.events(new OrderApprovedEvent(customerId));  }  public List<Event> process(RejectOrderCommand cmd) {    return EventUtil.events(new OrderRejectedEvent(customerId));  }  public void apply(OrderCreatedEvent event) {    this.state = OrderState.CREATED;    this.customerId = event.getCustomerId();  }  public void apply(OrderApprovedEvent event) {    this.state = OrderState.APPROVED;  }  public void apply(OrderRejectedEvent event) {    this.state = OrderState.REJECTED;  }

这是CustomerService 订阅order events的一个事件处理器：

@EventSubscriber(id = "customerWorkflow")public class CustomerWorkflow {  @EventHandlerMethod  public CompletableFuture<EntityWithIdAndVersion<Customer>> reserveCredit(          EventHandlerContext<OrderCreatedEvent> ctx) {    OrderCreatedEvent event = ctx.getEvent();    Money orderTotal = event.getOrderTotal();    String customerId = event.getCustomerId();    String orderId = ctx.getEntityId();    return ctx.update(Customer.class, customerId, new ReserveCreditCommand(orderTotal, orderId));  }}

好处:

• 它解决了实现事件驱动架构的一个关键的问题，使得在状态改变时可靠的发布事件成为可能
• 因为它持久化的是事件，而不是领域对象，避免了对象关系不匹配的问题
• 提供了一个百分百可靠的改变对象实体的审计日志
• 使得实现基于时间的查询成为可能

坏处:

• 是一种不同的、不习惯的编程方式，需要学习曲线
• event store很难做查询，因为它需要把业务实体的状态重新构建，这有点复杂和低效。因此，这个应用使用Command Query Responsibility Segregation (CQRS) 去实现查询。

三、应用发布事件（本地表）

1.上下文和问题

你已经应用了上文的事件驱动架构模式。为了实现可靠性，应用必须原子的更新自己的数据库和发布事件。使用分布式事务来覆盖数据库和消息代理层面不可行的，那么怎么做呢？

2.解决方案

应用插入事件到EVENTS表中，作为本地事务的一部分。一个独立的进程poll这个EVENTS表，然后把事件发布到消息代理。

（译者注：关于这种方法，我从http://www.cnblogs.com/dinglang/p/5679542.html上摘录了一段更详细的说明，以方便大家对分布式事务、2PC、事件驱动有更好的理解：

分布式事务

提到分布式系统，必然要提到分布式事务。要想理解分布式事务，不得不先介绍一下两阶段提交协议。先举个简单但不精准的例子来说明：

第一阶段，张老师作为“协调者”，给小强和小明（参与者、节点）发微信，组织他们俩明天8点在学校门口集合，一起去爬山，然后开始等待小强和小明答复。

第二阶段，如果小强和小明都回答没问题，那么大家如约而至。如果小强或者小明其中一人回答说“明天没空，不行”，那么张老师会立即通知小强和小明“爬山活动取消”。

细心的读者会发现，这个过程中可能有很多问题的。如果小强没看手机，那么张老师会一直等着答复，小明可能在家里把爬山装备都准备好了却一直等着张老师确认信息。更严重的是，如果到明天8点小强还没有答复，那么就算“超时”了，那小明到底去还是不去集合爬山呢？

这就是两阶段提交协议的弊病，所以后来业界又引入了三阶段提交协议来解决该类问题。

两阶段提交协议在主流开发语言平台，数据库产品中都有广泛应用和实现的，下面来介绍一下XOpen组织提供的DTP模型图：

XA协议指的是TM（事务管理器）和RM（资源管理器）之间的接口。目前主流的关系型数据库产品都是实现了XA接口的。JTA(Java Transaction API)是符合X/Open DTP模型的，事务管理器和资源管理器之间也使用了XA协议。 本质上也是借助两阶段提交协议来实现分布式事务的，下面分别来看看XA事务成功和失败的模型图：

在JavaEE平台下，WebLogic、Webshare等主流商用的应用服务器提供了JTA的实现和支持。而在Tomcat下是没有实现的（其实笔者并不认为Tomcat能算是JavaEE应用服务器），这就需要借助第三方的框架Jotm、Automikos等来实现，两者均支持spring事务整合。

而在Windows .NET平台中，则可以借助ado.net中的TransactionScop API来编程实现，还必须配置和借助Windows操作系统中的MSDTC服务。如果你的数据库使用的mysql，并且mysql是部署在Linux平台上的，那么是无法支持分布式事务的。 由于篇幅关系，这里不展开，感兴趣的读者可以自行查阅相关资料并实践。

总结：这种方式实现难度不算太高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况。但分布式事务对性能的影响会比较大，不适合高并发和高性能要求的场景。

提供回滚接口

在服务化架构中，功能X，需要去协调后端的A、B甚至更多的原子服务。那么问题来了，假如A和B其中一个调用失败了，那可怎么办呢？

在笔者的工作中经常遇到这类问题，往往提供了一个BFF层来协调调用A、B服务。如果有些是需要同步返回结果的，我会尽量按照“串行”的方式去调用。如果调用A失败，则不会盲目去调用B。如果调用A成功，而调用B失败，会尝试去回滚刚刚对A的调用操作。

当然，有些时候我们不必严格提供单独对应的回滚接口，可以通过传递参数巧妙的实现。

这样的情况，我们会尽量把可提供回滚接口的服务放在前面。举个例子说明：

我们的某个论坛网站，每天登录成功后会奖励用户5个积分，但是积分和用户又是两套独立的子系统服务，对应不同的DB，这控制起来就比较麻烦了。解决思路：

1. 把登录和加积分的服务调用放在BFF层一个本地方法中。
2. 当用户请求登录接口时，先执行加积分操作，加分成功后再执行登录操作
3. 如果登录成功，那当然最好了，积分也加成功了。如果登录失败，则调用加积分对应的回滚接口（执行减积分的操作）。

总结：这种方式缺点比较多，通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。

 

这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。

本地消息表

这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅，借助关系型数据库中的表即可实现。

举个经典的跨行转账的例子来描述。

第一步伪代码如下，扣款1W，通过本地事务保证了凭证消息插入到消息表中。

第二步，通知对方银行账户上加1W了。那问题来了，如何通知到对方呢？

通常采用两种方式：

1. 采用时效性高的MQ，由对方订阅消息并监听，有消息时自动触发事件
2. 采用定时轮询扫描的方式，去检查消息表的数据。

两种方式其实各有利弊，仅仅依靠MQ，可能会出现通知失败的问题。而过于频繁的定时轮询，效率也不是最佳的（90%是无用功）。所以，我们一般会把两种方式结合起来使用。

解决了通知的问题，又有新的问题了。万一这消息有重复被消费，往用户帐号上多加了钱，那岂不是后果很严重？

仔细思考，其实我们可以消息消费方，也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前，检测下该消息（提供标识）是否已经消费过，消费完成后，通过本地事务控制来更新这个“消费状态表”。这样子就避免重复消费的问题。

总结：上诉的方式是一种非常经典的实现，基本避免了分布式事务，实现了“最终一致性”。但是，关系型数据库的吞吐量和性能方面存在瓶颈，频繁的读写消息会给数据库造成压力。所以，在真正的高并发场景下，该方案也会有瓶颈和限制的。

MQ（非事务消息）

通常情况下，在使用非事务消息支持的MQ产品时，我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述，还是以上述提到的“跨行转账”为例，我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。

先从消息生产者这端来分析，请看伪代码：

根据上述代码及注释，我们来分析下可能的情况：

1. 操作数据库成功，向MQ中投递消息也成功，皆大欢喜
2. 操作数据库失败，不会向MQ中投递消息了
3. 操作数据库成功，但是向MQ中投递消息时失败，向外抛出了异常，刚刚执行的更新数据库的操作将被回滚

从上面分析的几种情况来看，貌似问题都不大的。那么我们来分析下消费者端面临的问题：

1. 消息出列后，消费者对应的业务操作要执行成功。如果业务执行失败，消息不能失效或者丢失。需要保证消息与业务操作一致
2. 尽量避免消息重复消费。如果重复消费，也不能因此影响业务结果

如何保证消息与业务操作一致，不丢失？

主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败，都可以执行重试机制的（有些MQ可以自定义重试次数）。

如何避免消息被重复消费造成的问题？

1. 保证消费者调用业务的服务接口的幂等性
2. 通过消费日志或者类似状态表来记录消费状态，便于判断（建议在业务上自行实现，而不依赖MQ产品提供该特性）

 

总结：这种方式比较常见，性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性，理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下，不建议在交易业务中直接使用。

MQ（事务消息）

举个例子，Bob向Smith转账，那我们到底是先发送消息，还是先执行扣款操作？

好像都可能会出问题。如果先发消息，扣款操作失败，那么Smith的账户里面会多出一笔钱。反过来，如果先执行扣款操作，后发送消息，那有可能扣款成功了但是消息没发出去，Smith收不到钱。除了上面介绍的通过异常捕获和回滚的方式外，还有没有其他的思路呢？

下面以阿里巴巴的RocketMQ中间件为例，分析下其设计和实现思路。

RocketMQ第一阶段发送Prepared消息时，会拿到消息的地址，第二阶段执行本地事物，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。细心的读者可能又发现问题了，如果确认消息发送失败了怎么办？RocketMQ会定期扫描消息集群中的事物消息，这时候发现了Prepared消息，它会向消息发送者确认，Bob的钱到底是减了还是没减呢？如果减了是回滚还是继续发送确认消息呢？RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。如下图：

总结：据笔者的了解，各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ（ActiveMQ、RabbitMQ、Kafka）均未实现对事务消息的支持，所以需二次开发或者新造轮子。比较遗憾的是，RocketMQ事务消息部分的代码也并未开源，需要自己去实现。

其他补偿方式

做过支付宝交易接口的同学都知道，我们一般会在支付宝的回调页面和接口里，解密参数，然后调用系统中更新交易状态相关的服务，将订单更新为付款成功。同时，只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止。

其实这就是一个很典型的补偿例子，跟一些MQ重试补偿机制很类似。

一般成熟的系统中，对于级别较高的服务和接口，整体的可用性通常都会很高。如果有些业务由于瞬时的网络故障或调用超时等问题，那么这种重试机制其实是非常有效的。

当然，考虑个比较极端的场景，假如系统自身有bug或者程序逻辑有问题，那么重试1W次那也是无济于事的。那岂不是就发生了“明明已经付款，却显示未付款不发货”类似的悲剧？

其实为了交易系统更可靠，我们一般会在类似交易这种高级别的服务代码中，加入详细日志记录的，一旦系统内部引发类似致命异常，会有邮件通知。同时，后台会有定时任务扫描和分析此类日志，检查出这种特殊的情况，会尝试通过程序来补偿并邮件通知相关人员。

在某些特殊的情况下，还会有“人工补偿”的，这也是最后一道屏障。

译者注：摘录到此结束！）