工作中使用了微服务架构,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,这篇文章主要讲述了微服务架构中的数据管理。
翻译和整理自:
优点:
缺点:
要解决的问题:
解决这个问题的一个好方案是使用事件源。事件源把业务实体比如订单和客户持久化成一系列状态变化的事件。当一个业务实体的状态变化时,新的事件加入到这个事件列表的尾端。因为保存一个事件是单个操作,它是原子性的。应用可以通过重现这些事件的方式来重新构建一个实体现在的状态。
应用把事件持久化在一个事件存储中,它是一个事件的数据库。这个存储有一个增加和获取事件的api。这个事件存储也类似于一个消息代理,它提供了一个api让服务可以订阅事件。当一个服务把事件保存在事件存储中时,这个事件被传递到所有的订阅者那。
有一些实体,比如说客户,可能会有很大数量的事件。为了优化负载量,应用可以周期性地保存一个实体当前状态的快照。为了重新构建当前的状态,应用找到最新的快照和那个快照之后的事件,于是需要重现的事件就少了一点。
Customers and Orders 是一个使用事件源和 CQRS的示例应用。这个应用使用Java语言编写,用到了Spring Boot。它使用 Eventuate构建, 这是一个基于事件源和CQRS的应用平台。下图展示了它是怎么持久化订单的:
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));
}
}
好处:
坏处:
提到分布式系统,必然要提到分布式事务。要想理解分布式事务,不得不先介绍一下两阶段提交协议。先举个简单但不精准的例子来说明:
第一阶段,张老师作为“协调者”,给小强和小明(参与者、节点)发微信,组织他们俩明天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,这控制起来就比较麻烦了。解决思路:
总结:这种方式缺点比较多,通常在复杂场景下是不推荐使用的,除非是非常简单的场景,非常容易提供回滚,而且依赖的服务也非常少的情况。
这种实现方式会造成代码量庞大,耦合性高。而且非常有局限性,因为有很多的业务是无法很简单的实现回滚的,如果串行的服务很多,回滚的成本实在太高。
这种实现方式的思路,其实是源于ebay,后来通过支付宝等公司的布道,在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。如果不考虑性能及设计优雅,借助关系型数据库中的表即可实现。
举个经典的跨行转账的例子来描述。
第一步伪代码如下,扣款1W,通过本地事务保证了凭证消息插入到消息表中。
第二步,通知对方银行账户上加1W了。那问题来了,如何通知到对方呢?
通常采用两种方式:
两种方式其实各有利弊,仅仅依靠MQ,可能会出现通知失败的问题。而过于频繁的定时轮询,效率也不是最佳的(90%是无用功)。所以,我们一般会把两种方式结合起来使用。
解决了通知的问题,又有新的问题了。万一这消息有重复被消费,往用户帐号上多加了钱,那岂不是后果很严重?
仔细思考,其实我们可以消息消费方,也通过一个“消费状态表”来记录消费状态。在执行“加款”操作之前,检测下该消息(提供标识)是否已经消费过,消费完成后,通过本地事务控制来更新这个“消费状态表”。这样子就避免重复消费的问题。
总结:上诉的方式是一种非常经典的实现,基本避免了分布式事务,实现了“最终一致性”。但是,关系型数据库的吞吐量和性能方面存在瓶颈,频繁的读写消息会给数据库造成压力。所以,在真正的高并发场景下,该方案也会有瓶颈和限制的。
通常情况下,在使用非事务消息支持的MQ产品时,我们很难将业务操作与对MQ的操作放在一个本地事务域中管理。通俗点描述,还是以上述提到的“跨行转账”为例,我们很难保证在扣款完成之后对MQ投递消息的操作就一定能成功。这样一致性似乎很难保证。
先从消息生产者这端来分析,请看伪代码:
根据上述代码及注释,我们来分析下可能的情况:
从上面分析的几种情况来看,貌似问题都不大的。那么我们来分析下消费者端面临的问题:
如何保证消息与业务操作一致,不丢失?
主流的MQ产品都具有持久化消息的功能。如果消费者宕机或者消费失败,都可以执行重试机制的(有些MQ可以自定义重试次数)。
如何避免消息被重复消费造成的问题?
总结:这种方式比较常见,性能和吞吐量是优于使用关系型数据库消息表的方案。如果MQ自身和业务都具有高可用性,理论上是可以满足大部分的业务场景的。不过在没有充分测试的情况下,不建议在交易业务中直接使用。
举个例子,Bob向Smith转账,那我们到底是先发送消息,还是先执行扣款操作?
好像都可能会出问题。如果先发消息,扣款操作失败,那么Smith的账户里面会多出一笔钱。反过来,如果先执行扣款操作,后发送消息,那有可能扣款成功了但是消息没发出去,Smith收不到钱。除了上面介绍的通过异常捕获和回滚的方式外,还有没有其他的思路呢?
下面以阿里巴巴的RocketMQ中间件为例,分析下其设计和实现思路。
RocketMQ第一阶段发送Prepared消息时,会拿到消息的地址,第二阶段执行本地事物,第三阶段通过第一阶段拿到的地址去访问消息,并修改状态。细心的读者可能又发现问题了,如果确认消息发送失败了怎么办?RocketMQ会定期扫描消息集群中的事物消息,这时候发现了Prepared消息,它会向消息发送者确认,Bob的钱到底是减了还是没减呢?如果减了是回滚还是继续发送确认消息呢?RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。如下图:
总结:据笔者的了解,各大知名的电商平台和互联网公司,几乎都是采用类似的设计思路来实现“最终一致性”的。这种方式适合的业务场景广泛,而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ(ActiveMQ、RabbitMQ、Kafka)均未实现对事务消息的支持,所以需二次开发或者新造轮子。比较遗憾的是,RocketMQ事务消息部分的代码也并未开源,需要自己去实现。
做过支付宝交易接口的同学都知道,我们一般会在支付宝的回调页面和接口里,解密参数,然后调用系统中更新交易状态相关的服务,将订单更新为付款成功。同时,只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时,支付宝才会停止回调请求。否则,支付宝会每间隔一段时间后,再向客户方发起回调请求,直到输出成功标识为止。
其实这就是一个很典型的补偿例子,跟一些MQ重试补偿机制很类似。
一般成熟的系统中,对于级别较高的服务和接口,整体的可用性通常都会很高。如果有些业务由于瞬时的网络故障或调用超时等问题,那么这种重试机制其实是非常有效的。
当然,考虑个比较极端的场景,假如系统自身有bug或者程序逻辑有问题,那么重试1W次那也是无济于事的。那岂不是就发生了“明明已经付款,却显示未付款不发货”类似的悲剧?
其实为了交易系统更可靠,我们一般会在类似交易这种高级别的服务代码中,加入详细日志记录的,一旦系统内部引发类似致命异常,会有邮件通知。同时,后台会有定时任务扫描和分析此类日志,检查出这种特殊的情况,会尝试通过程序来补偿并邮件通知相关人员。
在某些特殊的情况下,还会有“人工补偿”的,这也是最后一道屏障。
译者注:摘录到此结束!)